Over the past few years, the Product Model (sometimes referred to as the Product Operating Model) has become a common reference point in conversations about modern product organizations. The term was coined and popularized by the Silicon Valley Product Group, most notably in their article The Product Operating Model: An Introduction, as a way to describe how many of today’s strongest product companies are organized and operate.
At Better Product Work, we use the same core definition and principles, shaped and learned first hand through years of hands-on experience at companies such as Spotify, iZettle, and Einride,
In our own article The Product Operating Model, we build on these principles and describe the Product Model as a fundamentally different way of organizing and operating a company to consistently create technology-powered products that customers love and that work for the business.
By now, many people have read about the Product Model. Fewer have seen what it really looks like in practice. In a previous article, co-written with Marty Cagan, we used Spotify’s Discover Weekly to illustrate how the Product Model shows up inside a real organization. That article has been published both on the Better Product Work site and on SVPG’s site, and tells the story of how Discover Weekly came to life inside Spotify.
In this article, we take the next step.
The Product Model is often defined in contrast to a more conventional, project- and plan-driven way of working. To make those differences even clearer, we will use the same Discover Weekly example and ask a different question:
What might this have looked like in a more conventional organization?
In a different system, Discover Weekly might never have made it past a roadmap discussion.
To understand why, we will contrast the Product Model with a conventional approach across four fundamental dimensions:
-
How we decide what to work on (product strategy)
-
How we figure out how to solve it (product discovery)
-
How we build and deploy solutions (product delivery)
-
How we lead and manage people and teams (leadership and culture)
The first three are commonly included in Product Model definitions. The fourth reflects an explicit extension we make at Better Product Work, based on experience: you cannot sustain empowered product teams without changing how leaders and managers show up.
By replaying the Discover Weekly story through these lenses, we aim to make the Product Model tangible, not as an abstract ideal, but as a set of system-level choices that dramatically change how likely good ideas are to emerge, survive, and succeed.
1. How We Decide Which Problems to Solve (Product Strategy)
One of the clearest differences between the Product Model and a conventional approach is how decisions about what to work on are made.
In the Product Model
In the Product Model, leadership provides strategic direction, not detailed solutions.
That direction is grounded in a shared understanding of:
-
the product vision,
-
the strategic objectives,
-
and the customer or business problems that matter most right now.
In the Discover Weekly example, leadership clarity existed around who mattered and why. Spotify had strong signals that lean-back listeners represented a critical growth opportunity, and that engagement and long-term retention were key outcomes. That context shaped priorities without prescribing how those outcomes should be achieved.
Context shaped priorities without prescribing how those outcomes should be achieved.
Importantly, this strategic direction was informed by data and insights, not abstract ambition. Usage data, engagement metrics, and qualitative understanding of user behavior all contributed to making certain problems more important than others.
This context enabled dialogue between product leaders and teams. Teams were trusted to explore how best to move the needle, while leaders retained responsibility for setting focus and making trade-offs. Choosing one problem to pursue implicitly meant not pursuing others.
In a Conventional Approach
In a conventional, project- and plan-driven organization, this decision process usually looks very different.
Rather than framing problems and outcomes, leadership tends to pick a high-profile idea as the answer:
-
“AI-powered music discovery”
-
“A new personalization feature”
-
“The next big platform bet”
These ideas are often based on gut feel, internal momentum, or loosely defined goals. Business case decks are used to justify the investment before anything has been tested, giving an illusion of certainty.
Once an idea is approved, it becomes the strategy. Project teams are assigned to deliver the chosen solution, often with long time horizons such as 12–18 months. These timelines are typically based on estimates produced before meaningful discovery has happened, and are therefore built on assumptions rather than evidence. Alternative ways of addressing the underlying problem are no longer explored, and learning rarely influences direction once execution has begun.
Strategic context is limited. Teams are told what to build, but not given enough insight into the data, assumptions, or trade-offs that led to that choice. As a result, they cannot reason effectively about alternatives or adapt when reality changes.
Why This Difference Matters
When strategy is expressed as a solution, uncertainty is treated as a threat. Ideas must be justified up front or not pursued at all.
When strategy is expressed as a problem, an outcome, and clear strategic context, uncertainty becomes expected. Teams can explore different approaches, test assumptions, and focus on the levers that truly matter.
This often leads to doing fewer things, more deliberately. Leadership focus shifts from approving ideas to creating clarity and alignment around what is worth solving now, and what is not.
Leadership focus shifts from approving ideas to creating clarity and alignment around what is worth solving now, and what is not.
That shift does not guarantee success. But it significantly increases the chances that promising ideas are explored rather than dismissed before any real learning can occur.
2. How We Solve Problems (Product Discovery)
Once a problem has been identified, the next question is how an organization actually goes about exploring possible solutions. This is where the contrast between the Product Model and a conventional approach becomes especially concrete.
In the Product Model
In the Product Model, solutions often emerge from teams working close to real user problems and close to the enabling technology.
In the Discover Weekly case, the initial idea did not come from a roadmap or a strategic initiative. It came from engineers experimenting during a hack week, a space created for exploration outside of roadmap commitments, combining existing recommendation capabilities in a new way. The idea was then shaped through close collaboration between engineering, product, and design. Early skepticism from design forced the team to confront real user risks, strengthening the solution rather than blocking it.
Early exploration happened at very small scale:
-
internal testing through fishfooding and dogfooding,
-
followed by limited exposure to real users,
-
with feedback gathered from actual behavior, not opinions.
Crucially, this learning happened before any significant investment was made.
As evidence accumulated, something else became visible. When early signals showed high engagement and retention, other teams began to prioritize supporting the work. Not because they were told to, but because the data made the impact obvious.
Strategic focus combined with real evidence led to aligned prioritization.
In a Conventional Approach
In a more conventional organization, problem solving typically looks very different.
Time is often spent upfront designing “the perfect solution”, for example months of UI and concept work during a pre-study or formal planning phase, before testing whether users actually want it. Learning is delayed until late, if it happens at all.
Small-scale testing is rare. Instead, ideas are evaluated through:
-
large focus groups,
-
executive reviews,
-
and internal opinion-making forums.
Teams are usually overloaded with pre-defined delivery commitments, leaving little room to explore emerging ideas. Even when engineers, designers, or product managers see promise in an idea, it struggles to get attention or resources, because it is not part of an approved initiative or someone’s pet project.
As a result, many potentially valuable ideas never get the chance to generate evidence. They are blocked or delayed long before they can prove themselves.
Why This Difference Matters
In the Product Model, discovery is a way to create clarity through evidence. Ideas earn attention by showing impact.
In a conventional approach, discovery is often replaced by debate and persuasion. Attention flows toward the loudest idea or the highest-ranking sponsor. The winning idea evolves into a funded project, and whether it actually works is discovered only at the end.
The difference is whether the system allows learning to happen early enough, and cheaply enough, for good ideas to survive.
The difference is whether the system allows learning to happen early enough, and cheaply enough, for good ideas to survive. It does that by giving teams space to explore problems and outcomes, rather than binding them to pre-defined feature delivery. When that happens, funding naturally flows toward ideas that have at least some evidence behind them.
3. How We Build and Deploy Solutions (Product Delivery)
How an organization builds and deploys software does more than produce features. It shapes how teams collaborate, how learning accumulates, and whether high-performing teams can emerge over time. In a Product Model, delivery is designed not only to validate impact, but to grow capable, collaborative product teams.
In the Product Model
Teams build and deploy in small, frequent increments.
Releases are not treated as one-time events, but as opportunities to validate real-world impact. Each change is, implicitly or explicitly, a test of whether the team’s understanding of the problem and solution is improving.
In the Discover Weekly example, the playlist was not launched to everyone at once. It was rolled out gradually, first internally and then to small percentages of users. Engagement, retention, and behavior were monitored closely, and the product evolved based on what teams learned in production.
This way of working is supported by delivery capabilities such as:
-
partial rollouts,
-
A/B testing,
-
real-time metrics and observability,
-
and fast feedback loops from real users.
Just as importantly, teams owned delivery end-to-end. The same team that explored the idea was responsible for running it in production and improving it over time.
This continuity matters. It allows teams to:
-
build shared context and trust,
-
learn from the consequences of their own decisions,
-
and improve not just the product, but how they work together.
Over time, this is how high-performing, collaborative teams are formed. Not through process mandates, but through repeated cycles of shared problem-solving, feedback, and learning.
In a Conventional Approach
In a conventional, project-driven setup, delivery looks very different.
Work is organized into large initiatives with long development cycles. Teams are assembled to deliver a predefined scope, often under time pressure and with limited opportunity to adapt.
Because learning happens late, success is largely assumed until release. When issues surface, they tend to be costly, disruptive, and politically difficult to address.
Teams are often temporary. A project team delivers the solution and then disbands. Another group inherits the result, frequently without full context or ownership. Knowledge is lost, accountability is diluted, and teams rarely get the chance to learn from the outcomes of their own work.
There is often little investment in instrumentation to observe real user behavior, and limited capability to analyze what actually happens after release.
This setup makes it difficult for strong teams to form. Collaboration is transactional, psychological safety is fragile, and improvement focuses on coordination rather than capability.
Delivery becomes about completing scope, not about building products or teams that improve over time.
Why This Difference Matters
When teams own delivery end-to-end, ship small changes frequently, and observe the resulting impact through instrumentation, learning compounds. Products improve, and so do the teams building them.
When delivery is organized around temporary projects and big launches, learning resets. Teams may get better at executing plans, but not at solving problems together.
The difference is not whether an organization “does agile.” It is whether its delivery model is designed to develop teams as a long-term asset, or to treat them as short-term delivery capacity.
4. How We Lead and Manage People (Leadership & Culture)
The differences described so far are not sustainable without a corresponding shift in how leaders and managers show up. The Product Model does not work as intended under command-and-control leadership. How people are led and managed is not a side topic; it is a prerequisite.
In the Product Model
In the Product Model, leaders set direction and boundaries, and then deliberately step back from prescribing solutions.
Leadership responsibility is focused on:
-
articulating a clear product vision, strategy, and objectives,
-
defining constraints such as regulatory, financial, or brand boundaries,
-
and making the hard prioritization decisions that create focus.
Within that context, teams are trusted to solve the problem.
Managers play a different role as well. Rather than coordinating tasks or tracking compliance, product leadership focuses on:
-
coaching teams,
-
developing capabilities,
-
improving collaboration,
-
and helping teams make sense of customer and business context.
Clarity becomes a leadership duty
Clarity becomes a leadership duty. When teams understand why their work matters, how success will be judged, and where they have room to maneuver, autonomy becomes possible without chaos.
In the Discover Weekly story, this shows up clearly. Even though the CEO did not initially believe in the idea, he trusted the system enough not to interfere. Leadership belief in the way of working mattered more than belief in any single solution.
In a Conventional Approach
In a conventional organization, leadership and management often reinforce the opposite behavior.
Leaders tend to specify solutions and plans, making key decisions at the top. Direction is expressed as “build this by that date,” rather than as problems to solve and outcomes to achieve.
Managers focus on:
-
oversight and coordination,
-
managing dependencies,
-
reporting status and escalating decisions.
Strategic context is often incomplete, fragmented, or deliberately withheld. As a result, teams hesitate. They lack the information needed to make good decisions, so they escalate instead.
This creates a familiar cycle:
-
low clarity leads to hesitation,
-
hesitation leads leaders to step in,
-
stepping in reinforces dependency,
-
and autonomy shrinks further.
Micromanagement is often treated as a personality issue. In reality, it is a predictable outcome of a system that does not provide clarity or trust teams with real responsibility.
Why This Difference Matters
Empowered product teams do not emerge simply by reorganizing or renaming roles. They are the result of consistent leadership behavior that reinforces ownership, learning, and accountability.
When leaders set clear direction and constraints, and managers focus on coaching and team development, teams can take responsibility for outcomes rather than just execution.
When leadership defaults to control and prescription, teams may deliver what they are told, but they will not learn, adapt, or innovate in meaningful ways. Over time, this leads to weaker product decisions and poorer business outcomes.
You cannot have a Product Model with project-style leadership.
The way people are led and managed either enables everything described in this article, or quietly undermines it.
The System Decides What Survives
Discover Weekly is often remembered as a great product idea. What is easier to miss is how fragile that idea actually was in its early days.
In a different system, it might never have made it past a roadmap discussion.
In a different system, Discover Weekly might never have made it past a roadmap discussion.
It might have been rejected as too risky, too vague, or too hard to scale.
Or it might have been turned into a large initiative, over-designed, over-funded, and ultimately underwhelming as the system they were operating in would not have allowed the idea to learn its way forward.
That is the central lesson of the Product Model.
The difference between a Product Model and a conventional, project-driven approach is not a single practice or role. It is a set of reinforcing choices about:
-
how problems are framed,
-
how solutions are explored,
-
how software is built and deployed,
-
and how people are led and developed.
Together, these choices determine whether uncertainty is treated as something to eliminate up front, or something to work through deliberately. They determine whether teams are asked to deliver plans, or trusted to solve problems. And ultimately, they determine which ideas are given the chance to survive long enough to prove their value.
At Better Product Work, this is why we emphasize leadership, collaboration, and team development as integral parts of the Product Model. Empowered product teams do not emerge by accident. They are shaped over time by how work is structured, how learning is encouraged, and how leaders show up day to day.
The Product Model does not guarantee success.
The Product Model dramatically improves the odds, by creating an environment where good ideas can survive long enough to prove themselves.
And perhaps more importantly, it makes success less dependent on heroics, exceptional individuals, or lucky breaks, and more dependent on a system designed for learning, focus, and trust.
That is what Discover Weekly ultimately illustrates. Not a recipe to copy, but a reminder that the system you design will decide which ideas live, and which ones quietly disappear.