Skip to content
Marc Gasser
Back to blog

The Spotify Model in Product Management: Why It Will Not Work for You

Summarise this article with
The Spotify Model in Product Management: Why It Will Not Work for You

The Spotify model is probably the most famous framework in modern product management. Squads, tribes, chapters, guilds. It came from a company that grew fast and wrote a whitepaper about it. That is exactly what made it a problem: a whitepaper, not an operating system. In most companies that copy it, it fails quietly.

The honest version comes from people who worked inside it. Jeremiah Lee, formerly at Spotify, has publicly described why it never quite worked at Spotify the way the paper claimed. It still gets copied.

What you get in this piece:

  • Why the Spotify model only partly worked even at Spotify.
  • The three assumptions it relies on that rarely hold elsewhere.
  • What to build instead when you work with AI agents.
  • Why three people plus agents outproduce a thirty-person tribe in 2026.

The thesis

The Spotify model solves a scaling problem that no longer exists in most companies in 2026. With AI agents, product management gets narrower, not wider. Copying squads copies an outdated formation.

What is the Spotify model, short and honest?

The Spotify model is a matrix of autonomous squads (small, mission-oriented teams), tribes (clusters of squads), chapters (disciplines like engineering) and guilds (interest groups). It reads like autonomy with light coordination. In practice it relies on a lot of implicit context most companies do not have.

The source is the Henrik Kniberg paper from 2012. It was a snapshot, not a recipe. Spotify itself changed the model significantly afterwards.

Which three assumptions must hold for the model to work?

For the model to work, three assumptions must hold: strong shared product sense, very clear product strategy, and a high engineering culture. Miss any one and autonomy turns into chaos and squads turn into silos.

In most DACH companies between 50 and 500 people, at least one is missing. Strategy tends to be vision, not a prioritised system. Product sense is concentrated in one person. Engineering is good but not uniform. The model collapses after 18 months into more meetings, not fewer.

What are the typical symptoms?

Typical symptoms: squads build past each other, roadmaps get negotiated laterally instead of decided vertically, chapter leads turn into shadow managers, OKRs reappear unchanged every quarter because nobody wants to cut. If you recognise this in your company, you did not implement the model wrong. You implemented a model that does not fit your company.

What do you build in 2026 instead?

You build a narrow product team and augment it with AI agents. One product decision role, one engineering lead role, one designer role, plus specialist agents for research, specs, QA and release notes. That is not a squad, that is a crew. Small, clear, with a context engine behind it.

In two recent setups I saw three product people plus agents service a backlog that used to need a 25-person tribe. That is not magic, that is reallocation. The tasks squads used to own (spec, research, test, release) are partly automatable today. What is left is deciding and writing.

The hard comparison: 30 versus 3 plus 10

A 30-person Spotify-style tribe ships a limited number of releases per quarter, weighed down by coordination cost. A 3-person crew plus 10 agents, with a working context engine, ships a comparable number with much lower coordination cost. HBR reports knowledge workers using GenAI gain 20 to 40 percent on specific tasks. In product work the lever sits on spec creation, research and release communication.

Outro

What works. Narrow teams with a clear mandate and a context engine beat any squad stack on paper in 2026.

What does not. Treating the Spotify model as an out-of-the-box recipe. It never was one.

⚠️ Warning. Loading a failed Spotify model with AI agents just automates your silos. Faster broken is still broken.

The deeper point: product organisation in 2026 is not a question of squad topology, but of context topology. Where the context sits, the decision sits. That is the same point I started with: a whitepaper is not an operating system.

If you are looking for a narrow cut for your product team, see our process.

Frequently asked questions

Does Spotify still use the model itself?

Not in the 2012 form. Spotify has changed the model significantly. Several former Spotify employees describe publicly that it had issues from early on.

Does that mean squads are wrong?

No. Squads as a concept (small, mission-oriented team) are fine. The problem is the matrix around them, which assumes a lot of context and maturity.

What is the leanest sensible setup in 2026?

A crew of 3 to 5 product people plus specialist agents for research, spec, QA and release notes. One person decides, the rest build.

How many agents per person are realistic?

Currently two to five, depending on task and context engine maturity. Anyone claiming more does not have them in production yet.

When is a bigger setup justified?

When the product demonstrably scales in volume, not complexity. Volume is additive, complexity is multiplicative. You do not scale complexity with more squads, you scale it with a better cut.

Written by

Serial Entrepreneur, Author

Marc is a serial entrepreneur. He started his first software company at 16, and has worked at the same intersection ever since: software product management meets go-to-market. He builds the bridge: Product × GTM × AI, as one system, not three departments. Three instead of thirty.