Topics2 of 5: The Product Operating Model
The Product Operating Model
The Product Operating Model describes how the best product companies work: small, empowered teams are given problems to solve, and are judged by the results they achieve rather than by the features they ship.
9 min readUpdated
On this page7 sections
Based on the work of Marty Cagan and the Silicon Valley Product Group (SVPG), especially the book Transformed: Moving to the Product Operating Model (2024). Summarised in our own words; it does not reproduce their text.
What it is
An operating model is simply how a company decides what to build, and how it builds it. SVPG uses the name Product Operating Model for the way the strongest product companies do this. It is less a process than a set of beliefs: trust teams with problems, test ideas before committing to them, and judge success by what changes for customers and for the business.
In Transformed, moving to the model means changing three things:
- How you build: small, frequent and reliable releases, with the monitoring to know what each one did.
- How you solve problems: teams are given problems, and work out the solution with customers, instead of being handed one.
- How you decide which problems to solve: a product vision and strategy, rather than a list of requests from around the company.
Feature teams and empowered product teams
The clearest way to see the model is to compare two kinds of team doing the same job.
| Compared | Feature team | Empowered product team |
|---|---|---|
| Is given | A roadmap of features to build | A problem to solve and an outcome to reach |
| Success means | The feature shipped on time | The problem is solved: a measure moved for customers or the business |
| Who picks the solution | Stakeholders or management, before the team sees it | The team, with stakeholders, after testing ideas |
| The product person acts as | A project manager or backlog administrator | The owner of value and viability, alongside design and engineering |
| Engineers are | Asked to implement | Involved from the start, and often the best source of ideas |
It might build referrals, or find that a clearer “invite your team” step after sign-up does more, for less work.
Outcomes over output
Output is what a team produces: features, stories, story points. Outcome is the change that output causes: customers succeed more often, revenue grows, support requests fall. Output is easy to count and easy to plan; the outcome is what the business actually needs.
- Write team objectives as outcomes with a measure, for example “Halve failed first payments this quarter”.
- Keep output measures such as velocity for planning, not as goals in themselves.
- Expect some ideas not to work. If it was cheap to find out, that is learning, not failure.
Strategy, discovery and delivery
Product strategy
Decides which problems matter most. It picks a few areas to focus on, backed by insight from data and customers, and turns them into objectives for each team.
Product discovery
Works out what to build. Before committing engineers to a solution, the team tests ideas quickly with prototypes, conversations and small experiments.
Product delivery
Builds and ships it, in small, frequent, reliable releases. This is where Scrum or Kanban usually lives.
Discovery tries to answer four questions before anything is built: will customers value it, can they use it, can we build it, and does it work for the business? Discovery and delivery run side by side, all the time. They are not phases.
How it relates to Scrum
Scrum is a framework for delivering work; the Product Operating Model is a wider view of how a company works. They fit together well, with a few points worth knowing.
| In Scrum | In the Product Operating Model |
|---|---|
| Product Owner: accountable for value and the order of the backlog | Closest to the product manager, who owns value and viability. SVPG argues this must be a capable product manager with real authority, not a proxy who only writes tickets. |
| Developers: create a usable increment every sprint | Engineers and designers take part in discovery as well as delivery. The tech lead brings feasibility to every decision. |
| Scrum Master: helps the team and organisation work well | No direct counterpart. The model expects managers and leaders to coach people and remove obstacles. |
| Product Goal: the long-term objective for the backlog | A team objective written as an outcome, coming from the product strategy. |
| Sprint Goal: the objective for one sprint | A step toward that outcome. It can include discovery work as well as delivery. |
Put simply: a Scrum team handed a list of features is a feature team, however good its sprints are. A Scrum team handed a problem and trusted to solve it is an empowered product team.
Where to start
- Pick one team and give it a problem with a measurable outcome instead of a feature list.
- Make sure that team has a product manager, a designer and engineers who talk to customers every week.
- Write the outcome as the team’s Product Goal, and review progress on it at every Sprint Review.
- Leave room in each sprint for discovery: a prototype, a few customer conversations, a small experiment.
- After a quarter, ask two questions: did the outcome move, and what did we learn?
Further reading: Transformed: Moving to the Product Operating Model by Marty Cagan (Wiley, 2024), and SVPG’s articles at svpg.com. This page is our own summary; read the book for the full argument.
How ScrumTeam helps
Keep outcomes, not just tickets, in view.
- A Product Goal at the top of the backlog, set by the Product Owner
- On Starter and up: goals with weighted key results and check-ins, at company, team and project level
- On Starter and up: work items linked to the goals they serve, so output stays tied to outcomes
- A goal for every sprint, with the Product Goal shown while you write it
- Reports: velocity, cycle time and cumulative flow on Starter and up