Nearly 15 years ago, Spotify initiated a shift in how software teams were organized. The infamous Spotify model gained popularity among tech companies scaling software development. At the time, Spotify's tech org was 250 strong, and even if the authors of the initial paper (pdf) warned the model wasn't meant to be applied strictly, calling it instead "a snapshot of [Spotify's] current way of working", it became one of the most copied team designs in tech.

Fast-forward to 2026; Spotify is providing a new take on shipping software, the product loop.

Will the product loop make as many waves and forever mark tech companies searching for an operating model in the new age of AI, or will it remain as an attempt to promote Spotify’s own A/B testing solution, Confidence?

The product loop

The product loop is a new formal take on how software teams can operate in the age of AI. At first glance, it feels like a previous era great team’s operating model, but it goes beyond that and proposes a way to leverage AI speed gained at build step to spend more time, as a team, on other steps, in particular those that inform future decisions (Observe: measure & learn). The time saved building gets invested in developing a much better understanding of the results, which theoretically improves subsequent iterations.

For more details on the product loop, see Spotify's blog post.

The product loop. Credit: Spotify Confidence blog

The product loop is landing at a pivotal time. It’s clear there is a need for evolving the current agile-derived models, and it cannot be the obvious “since PM can build, let’s just do that and replace developers” approach (see The Builder PM trap). It’s got to go beyond.

Lately, I’ve been thinking a lot about the future of the product triad, the right size of software teams, and the constraints that will remain in spite of AI. My conclusion: software development isn’t in need of an evolution of the current dominant operating model but of a tectonic shift, and what Spotify suggests with the product loop corroborates that intuition.

Breaking change required

The recent acceleration of changes brought by agentic software development (e.g., Claude Code, Codex or Cursor) and other autonomous LLM-powered workflows shouldn’t result in a mere augmentation of existing roles in existing organization designs (that’s the Ford-attributed “faster horses” analogy).

Harnessing the true power of AI demands much more significant changes. Changes that aren’t easy to apply because they require rethinking how things work a few levels deeper than when agile and subsequent models such as Spotify’s got traction. It’s not just about the org; it’s about the roles as well—people's jobs and entire careers!

Implementing the product loop while keeping current roles is the same as adopting agile without any automation or recurrence (a fallacy).

To quote Spotify directly:

"The same people, or the same tightly integrated team, need to be involved across all four turns"

This means we need a breaking change, yet most orgs, including management, aren’t currently ready, or equipped to make such a call. Current teams and roles must radically evolve together for a successful loop to function. In my mind, this means we need to go beyond current boundaries, establish a common base combined with specialization rather than narrow expertise and siloed scope.

What tighter teams look like

It’s unreasonable to expect existing PMs, product designers, and software engineers to become experts in their peers’ disciplines, but tech workers have to become much better all-rounders so that truly symbiotic teams can arise. With specialization on top of a broader shared base, common goals become truly common instead of mostly a product problem (an easy trap to fall for).

With tighter teams, we aren’t trying to replace anyone or remove what’s core to a given function. Instead, we seek to increase the porosity between roles. Making the boundaries between product, design and engineering less rigid is now possible thanks to the new time unlocked by AI speed in software development, and the knowledge-leveling capabilities brought by LLMs.

This combination allows some work to be performed by team members who were not historically involved, to improve the overall team’s ability to solve its business problems. This has always been the vision; having everyone working as one, aligned on goals, business, users, and tech constraints. It was indeed a vision rather than a reality in most orgs, but AI and models such as the product loop now provide a tangible trail to fulfill it — even if it won’t be for everyone.

Spotify is Spotify

Spotify has north of 3,000 engineers, and we can guesstimate the product org to be 400+, with brilliant minds dedicating their time to fine tuning the org for the AI era. This isn’t your typical startup, and what works for Spotify will not work as is for smaller orgs, especially with a culture that isn’t Spotify’s.

If we simply look at the “learn” phase of the product loop, we can see it heavily relies on A/B testing, a practice that is embedded within Spotify product culture and only truly applicable at some scale, both in terms of user base and team. Smaller companies can instead learn from simpler mechanisms (KPIs, engagement data analysis, qualitative feedback from users, support tickets) as acknowledged by Spotify in the blog post’s FAQ:

"The validation step doesn't require A/B tests specifically. It requires some mechanism for exposing hypotheses to reality and generating honest feedback. [...]. The important thing is that each cycle generates evidence that updates the team's understanding."

Even though teams are already meant to consistently assess the success of their initiatives to drive future decisions, it's often imperfect, sometimes completely unreliable. Combined with the authority of Spotify's take on software development, it could lead to disasters. If your teams aren’t already great at measuring success at a slow pace (e.g., monthly, quarterly) or are unable to establish reliable learning mechanisms, good luck with the consequences of aimlessly spinning product loops that will look good on a career page, less so in practice.

This risk is actually well identified by Spotify too; a loop can go too fast. The goal of the product loop isn’t indeed to chase shipping velocity as much as every dogmatic interpretation of the Agile Manifesto has over the years (the “continuous delivery of valuable software” bit), but to change how we produce by sharing the end-to-end process, backed by continuous learning rather than continuous delivery.

Of course, the end goal is to leverage AI to bring more value to end users and generate more revenue, but this isn’t what makes the product loop model worth looking at. The underlying relevance of the product loop is that it's a method that leverages AI rather than supercharges existing roles in trendy but ephemeral ways (see: The Builder PM Trap).

A refreshing take on what the future looks like

What Spotify suggests is akin to the articulation of a plausible future for us all, tech workers. The exact steps don’t matter as much; what matters most is the underlying rationale that team roles have to evolve, supported by a method rather than a blanket “<role X> must <build|design|research>” injunction.

So far, the facts that engineers had to be more involved in product topics and product managers had to build more were not backed by a method organizations could experiment with. I’m not saying Spotify’s model is right or wrong here; I’m saying it’s a very relevant take that is worth testing. But, as we’ve seen in the past, the risk with such organizational models is that they can become the only root of every team design for the next decade. On top of that, it’s easy to take the model as just an adjustment of the current dominant, agile-derived one, and implement it too superficially (e.g., rebrand existing processes as product loops without evolving roles).

Spotify’s product loop is a rare take supporting the fact organizations must evolve to produce more value with AI. Not just churn code or use tokens faster because it’s easy, feels productive and resonates with LinkedIn or X influencers' content. Doing so is missing the point, and forgetting we aren’t here to ship code at all but to solve problems in ways that are worth paying for. Not all organizations will be able to implement the product loop as is, but its philosophy comes free. AI must be leveraged, not just used.