The product operating model benchmark

In short

We benchmarked our product operating model against eight established frameworks, capability by capability. No single framework covers all three of our operating areas. Most have a clear focus of their own: a body of knowledge, market-facing product management, empowered product teams, or delivery at scale. The commercial life of a product after launch is where they thin out most, and it is where B2B products earn most of their money.

Why this benchmark exists

Product work succeeds commercially only when the whole of it is covered. Strategy, the day-to-day product work, and the organisation that supports both. Most frameworks take one of these as their focus, and many do it very well. The Product Kata product operating model is built to hold all three in one view, for the commercial success of the product, and this benchmark shows what that means in practice: where our model is different, where it builds on others, and where it is still behind them.

We are not aiming to be the perfect framework. We have gathered what we know about commercial product management, work that is scattered across the field. Much of it exists in one framework or another, and some of it is missing from all of them. Holding it in one view is our aim, and the view is not complete. The section Where others go further than we do today lists them.

Nobody builds a product operating model from nothing, and we did not. Every framework below has shaped how product management is practised, and several shaped ours directly. We credit them by name where we took their ideas, and we say plainly where we chose differently, so that a product leader who already uses one of them can see what our model would add, what it would change, and what it would not.

Two limits, stated up front. We compared the frameworks’ published material with our own model, and the ratings are our reading of it. We can only see what each publisher has made available: a framework that looks narrow here may cover more in its paid courses or books, and a gap may be a deliberate choice of focus rather than an oversight.

The benchmark

The eight frameworks

Framework	Publisher	What it is
ISPMA SPM Framework	International Software Product Management Association	A body of knowledge for software product management, with syllabi and certification; the syllabi are openly licensed
Pragmatic Framework	Pragmatic Institute	Thirty-seven activities in seven categories, from market to support; the backbone of a training and certification programme
ProdBOK	AIPMM	A body of knowledge in the style of PMBOK, organised by the product lifecycle phases from conceive to retire
Product management life cycle model	Sequent Learning Networks (Steven Haines)	The product manager as business manager of a product across its life, within a product management system covering organisation, competencies and maturity
The product operating model	SVPG (Marty Cagan)	A principle-based model of empowered product teams: strategy, discovery, delivery, teams and culture
Product-led organisation and product operations	Melissa Perri; Perri and Denise Tilles	How an organisation becomes product-led, and the product operations function that supports it
SAFe	Scaled Agile, Inc.	An enterprise framework for delivery at scale, including lean portfolio management and a product management role
Product Manager’s Toolkit	Blackblot	A methodology of models, roles and templates for technology product management

Ratings by operating area

Key: ● the framework names this as its own area or activity · ◐ covered in part, or inside something else · ○ not found in its published material.

Operating area	ISPMA	Pragmatic	ProdBOK	Haines	SVPG	Perri	SAFe	Blackblot
1 · Strategy and portfolio	●	●	◐	●	◐	●	●	◐
2 · Product management	●	◐	●	●	◐	◐	◐	◐
3 · Product enablement	◐	◐	◐	●	●	●	●	◐

Ratings by capability

Capability	ISPMA	Pragmatic	ProdBOK	Haines	SVPG	Perri	SAFe	Blackblot
C01 Product strategy	●	●	◐	●	●	●	◐	◐
C02 Land and expand model	◐	◐	○	○	○	○	○	○
C03 Pricing and packaging	●	●	◐	◐	○	○	○	●
C04 Portfolio management	◐	●	◐	●	○	◐	●	○
C05 Business initiatives	○	○	○	○	○	◐	●	○
C06 Market insight	●	●	◐	●	◐	●	◐	●
C07 Product culture	○	○	○	◐	●	●	◐	○
C08 Requirements management	●	●	●	◐	◐	◐	●	●
C09 Discovery	◐	◐	◐	◐	●	●	◐	◐
C10 Delivery	◐	○	◐	◐	●	○	●	◐
C11 Go-to-market	●	●	●	●	◐	◐	◐	●
C12 Release management	●	○	◐	○	◐	○	●	○
C13 Offering management	◐	◐	●	●	○	◐	◐	◐
C14 Product insights	●	●	◐	●	◐	●	◐	◐
C15 Market expansion	○	◐	○	◐	○	○	○	○
C16 Retirement	●	○	●	●	○	○	○	○
C17 Local offering management	○	○	○	○	○	○	○	○
C18 Operating model	◐	◐	◐	●	●	●	●	●
C19 Product organisation	○	○	◐	●	●	●	●	●
C20 Competency development	○	○	○	●	●	◐	●	◐
C21 Product structure	◐	○	◐	◐	◐	◐	◐	◐
C22 Product tech stack	◐	○	○	○	◐	●	◐	○
C23 Sales and customer success support	●	●	◐	◐	◐	◐	◐	●
C24 Operations support	●	◐	◐	○	○	○	◐	◐
C25 Product operations (S)	○	○	○	◐	●	●	◐	○
C26 Product marketing (S)	●	●	●	●	◐	○	○	●
C27 Partner and channel enablement (S)	◐	●	○	○	○	○	○	◐
C28 Supplier management (S)	●	◐	○	○	○	○	●	○
C29 M&A support (S)	○	○	○	○	○	○	○	○

(S) = Situational in our model. A ○ against a Situational capability usually means the framework does not address that situation, not that it is weak.

How to read it

No single framework covers all three areas fully, and that is the gap our model is built for. The strongest in strategy are ISPMA, Pragmatic and Haines; the strongest in the product organisation and its ways of working are Haines, SVPG, Perri and SAFe. The commercial life of a product after launch (offering management, market expansion, retirement) is where the frameworks thin out most, and it is where B2B products earn most of their money.

Our breadth is in the combination, not in the parts. Almost every capability in the model exists in at least one framework, often described better and earlier. What is new is holding the operational and commercial halves of product management as one job, next to an enablement area that treats product’s support of sales, operations and partners as a capability with service levels.

Others go further than we do in several places, and we list them under Where others go further than we do today.

Our analysis of each framework

Each framework in four parts: in short, what we credit, where we differ, and our critique.

ISPMA SPM Framework

In short. The most complete and precise reference model for software product management, from the association of experts, researchers and practitioners behind it. Its three layers say what the product manager owns, what they orchestrate, and what they take part in.

What we credit. It was early to treat legal and IPR, sourcing, ecosystem management, delivery models and financial management as core product management work, and its layers state accountability honestly. Its syllabi are openly licensed, which few frameworks do. We keep ISPMA’s discipline of saying who owns what.

Where we differ. ISPMA separates the strategic product management the product manager owns from the development, marketing, sales and support work they orchestrate, and it deliberately does not prescribe organisation design. We hold operational and commercial product management as one job, and we make the product organisation and its support of other functions capabilities of their own. Our reason is the B2B scaling problem: when nobody owns product’s side of the relationship with sales and support, the product manager becomes the bottleneck.

Our critique. The split between owning and orchestrating leaves the product manager accountable for results that others deliver, with no model for how that support is organised. That is a deliberate choice, and it leaves the hardest part of scaling to the reader: how the product organisation is set up, and how product supports the rest of the company.

Pragmatic Framework

In short. A framework of thirty-seven activities in seven categories that made market-driven product management mainstream. It is the backbone of Pragmatic Institute’s training and certification.

What we credit. Much of today’s standard vocabulary (win/loss analysis, buyer and user personas, distinctive competencies, product profitability) came into common use through it. Its coverage of product marketing and sales enablement is the strongest of the eight, and that interface decides a lot in B2B.

Where we differ. Pragmatic frames product management as the market-facing, business-owning role and leaves development and delivery to others. We keep discovery, delivery and release inside product management, because in B2B the trade-offs made during delivery change what can be sold. We treat product marketing as a capability only where product owns it, since in many companies it sits with marketing and its work already happens inside go-to-market.

Our critique. With development and delivery outside the frame, the decisions that shape what can actually be sold happen where the product manager is not looking. Release management and retirement are not named in the published framework, so the commercial life of the product after launch rests mostly on marketing programmes.

ProdBOK (AIPMM)

In short. A body of knowledge in the style of PMBOK that walks the whole product lifecycle in seven phases, from conceive to retire. Its first edition was published in 2013.

What we credit. It includes a qualify phase for beta and launch readiness that most modern models skip, and a full retire phase. Its role definitions, including the product portfolio manager and the product owner outside Scrum, are careful and useful.

Where we differ. ProdBOK is organised by lifecycle phase; our model is organised by capability, with no fixed sequence. Phases make a good teaching path. Capabilities make a better operating model, because a B2B product is in several phases at once: one module in discovery, another being retired, a third expanding into a new market.

Our critique. We found no edition newer than 2013, so it predates product operations, delivery at scale as it is practised today, and AI in product work. It is light on how the product organisation runs and supports the rest of the company.

Sequent Learning Networks: Steven Haines

In short. The product manager as the business manager of a product, a product line or a portfolio across its whole life, set inside a product management system of lifecycle, organisation design, maturity model and competency model. Published in The Product Manager’s Desk Reference and taught through Sequent’s courses.

What we credit. Of the eight, the closest to our full scope. Haines treated product management as the business management of an investment across its whole life, and treated the product function itself as something to design, professionalise and mature, well before product operating model became a common term. His post-launch auditing and strategic mix management are the same ideas as our offering management and product insights, published earlier. His product master plan, one plan of record per product, anticipates the single source of truth our model runs on.

Where we differ. Haines’s model is phase- and gate-based, with the product manager as the general manager of the product. Ours is capability-based and written to be executed partly by agents, which changes how much of the routine the product manager has to carry. We have not yet built the maturity model Haines has; ours is designed in and will be built from adopters’ experience.

Our critique. A product manager as the general manager of everything is a heavy load for one person, and the gates assume a product moves through its life in sequence. We could verify only part of the model from public material, so this reading is partial.

SVPG: Marty Cagan

In short. A principle-based product operating model: empowered product teams working on problems and outcomes, with strategy, discovery and delivery as its core. Set out on svpg.com and in Transformed (2024).

What we credit. SVPG put product operating model into common use and made empowered teams, outcomes over output, and the four risks standard. Our discovery capability uses Cagan’s four risks (value, usability, feasibility, viability) directly. SVPG’s writing on product culture and on leaders as coaches is the clearest there is, and its view of product operations as a force multiplier, never process police, is the test our enablement area is held to.

Where we differ. SVPG deliberately leaves out several things our model includes: release management, feature roadmaps, business cases and portfolio governance, on the grounds that they tend to bring back feature-factory behaviour. We take that risk seriously and keep them anyway, in a specific form. B2B contracts, enterprise buyers and annual price increases make a commercial release, a committed roadmap item and a business case real obligations, and leaving them unnamed does not remove them; it leaves them to whoever argues loudest. So we separate commercial from technical release, keep portfolio decisions at the level of envelopes and exits, and hold every rule to the test that it must work without policing.

Our critique. The model says little about the commercial life of a product after launch: pricing, offering management, market expansion and retirement are not part of it. That is consistent with its focus on building the right product, and for a B2B company it leaves a large part of the money unaddressed.

Melissa Perri: product-led organisation and product operations

In short. How an organisation becomes product-led, in Escaping the Build Trap (2018), and the product operations function that supports it, in Product Operations (2023) with Denise Tilles.

What we credit. Perri and Tilles defined product operations as a function with a coherent scope (business data and insights, customer and market insights, and process and governance), and it is the closest existing description of how a product organisation supports itself. We use their term, product operations, for the team in the same sense. Perri’s work also names incentives as the main thing that stops companies becoming product-led, which is close to how we define product culture, and her strategy cascade gives a usable link from company strategy to team work.

Where we differ. Perri and Tilles describe product operations as a team that grows with the pain it relieves. We describe the capabilities first and the team as one Situational way of staffing them, because a company with one product team still needs a lifecycle, requirement types and a route for requests from sales and support, and does not yet need a product operations team. We agree with their advice to start with the most acute pain.

Our critique. Delivery, release, pricing and retirement are outside the published scope, so the commercial life of the product is covered mainly through data and insights. A company too small for a product operations team finds less guidance on how to run the same work without one.

The name. Melissa Perri has used the same name, the Product Kata, since 2015, from the same origin: Toyota Kata.

SAFe

In short. An enterprise framework for delivering software at scale, with lean portfolio management and a product management role that serves an Agile Release Train’s backlog. It is a delivery framework, not a product management framework. We include it because it is widely used in enterprise software companies, and many product managers work inside it.

What we credit. SAFe has the most developed model for funding and governing a portfolio: funding value streams rather than projects, with lean budgets and guardrails. It was early to write the separation of deployment from release into a framework, which is close to our split between technical and commercial release. It treats suppliers and compliance as first-class concerns. We borrow its portfolio thinking.

Where we differ. SAFe starts from delivery at scale and portfolio flow, and product management serves a release train’s backlog. Our model starts from the commercial life of the product. For a large enterprise aligning many teams, SAFe’s starting point makes sense; for a B2B software company whose problem is that products ship and then stop earning, we think the commercial starting point matters more. We do not take its delivery structure.

Our critique. SAFe coordinates teams from the top, on a fixed planning cadence, and it is not designed for empowered product teams. We are not alone in this reading: Marty Cagan argued in 2018 that in SAFe the idea of a dedicated, empowered product team is lost, and Melissa Perri explains why she does not recommend it. Commercial product management (pricing, packaging, positioning, sales enablement, retirement) is thin or absent in its published material.

Blackblot Product Manager’s Toolkit

In short. A methodology of models, roles and templates for technology product management, published as a book and a template toolkit.

What we credit. The most rigorous requirements discipline of the eight, strong template discipline, and an explicit model for grouping functionality into offerings and bundles that anticipates what our product structure capability describes. It also treats process efficiency (how meetings, decisions and sign-offs work) as part of product management method.

Where we differ. Blackblot splits product management into a product planner and a product marketer, arguing that they need different expertise. We keep one job with two halves, because in B2B the person who decides what to build needs to own whether it sells.

Our critique. The split between planner and marketer is where feature factories come from: one person decides what to build, another is left to sell it. Its flow model is stage-gated, which fits a product moving through its life in sequence better than one that is in several stages at once.

Where others go further than we do today

Stated so that a reader can take what our model does not yet give them from the framework that does:

• Positioning and messaging as a named discipline: ISPMA, Pragmatic and Blackblot give it a box of its own. In our model it runs through several capabilities instead: portfolio-level positioning in product strategy, product-level positioning in offering management, tested in discovery, delivered against in delivery, and turned into messaging and fine-tuned in go-to-market. A reader looking for one positioning box will not find it, and we think that is right, but it has to be explained.
• Product architecture and technology management as a product concern: ISPMA, SAFe, SVPG.
• A maturity model for the product function: Haines. Ours is designed in, owned by the operating model capability, and not yet built.
• Forecasting, and a named mechanism from strategy to team goals: Haines, SVPG, Perri, SAFe.

What our model adds

• Operational and commercial product management as one job, from requirements to retirement, with the commercial half described as fully as the operational one.
• The commercial life of a product in B2B as named capabilities: the land and expand model, offering management, market expansion and local offering management, none of which is named as such in the frameworks above. M&A support is also absent from all eight.
• Product’s support of sales, customer success, operations, partners and suppliers as capabilities with service levels, so that the load on product is visible and the product manager stops being the bottleneck.
• Written to be executed, by people and by agents, with every capability’s business impact stated on four dimensions: economic, functional, social and psychological.
• Openly licensed (CC BY-SA 4.0), as ISPMA’s syllabi are, with no certification: credibility has to come from measurable use.

Frameworks we did not benchmark, and why

Scrum and Kanban are not in the benchmark because they are delivery frameworks, not product management frameworks. They describe how a team plans, builds and improves its work, and they do it very well. We have great respect for both, and our model leans on them in many places.

• Scrum, by Ken Schwaber and Jeff Sutherland: short, fixed iterations, a team that inspects and adapts its work at a steady rhythm, and a shared definition of when something is done.
• Kanban, in the Kanban Method and the Kanban Guide: making work visible, limiting work in progress, and managing the flow of work rather than keeping everyone busy.

What we borrow from them lives at the level of practices, inside capabilities such as delivery, release management and requirements management: short iterations, limits on work in progress, visible flow. They do not set out product strategy, pricing, the portfolio or the commercial life of a product, and they do not claim to. That is why they are not compared here.

A product owner is not a product manager. The product owner is a role defined in Scrum: accountable for maximising the value of the team’s work and for managing the product backlog. Many companies use the title for product management, and the two are often mixed up. The product owner’s work can be part of a product manager’s week, but it is not what product management is. It leaves out the commercial side of the job: who buys the product and why, at what price, in which markets, and how the product earns through its whole life. That is what the principles we build on are about. Marty Cagan makes the same point: the product owner’s responsibilities are one part of the product manager’s job, held by the same person. Melissa Perri draws the same distinction.

The same goes for discovery methods, such as Teresa Torres’s continuous discovery habits and Eric Ries’s Lean Startup. We use their thinking in our discovery capability. They are methods for one part of the work, not product operating models.

Version 2 · 30 September 2026 · Product Kata Core · CC BY-SA 4.0 · Using Product Kata Core