The product operating model

In short

This is our reference operating model for product organisations. Our own agentic operating model, Product Kata Core, runs on it. An operating model describes how an organisation turns its strategy into daily work: what it must be able to do, who owns it, and how the parts connect. This one does that for product as a function in a B2B company.

It is built from decades of product work and an analysis of the frameworks others have published. It is a starting point, not a standard: take what fits your business, tailor it, and leave the rest. The reasoning behind it, and the research it rests on, are in the background materials linked at the end.

Why it exists

This model is built on the principles we believe in, set out in the Product Kata manifesto. Read it alongside this page: the principles explain the choices the model makes.

Most product frameworks teach you how to build the right thing. Few teach you how to make a business out of it.

Discovery, delivery and team design are well covered. What decides success in B2B is covered thinly: whether the customer’s work actually changed, whether sales could sell the product, whether support could hold it, whether the price reflected the value, whether the second market was ever entered. In most companies that work has no named owner. It falls between product, sales and operations, and it gets done late or not at all.

AI has changed the game. When anyone can build, building is no longer the bottleneck. It never really was: products rarely fail because they could not be built. AI did not create this gap, and it is not the reason to close it. It has made the gap impossible to ignore. You win by changing how your customer works, and that takes the whole company, not only the product team.

This model covers the product from every side, a 360° view: the strategy that decides where to play, the work of building and launching, the commercial life of the product after launch, and the support the rest of the company needs from product. For product leaders it is a reference for organising product as a function. For product managers it shows what product work means day to day, and where their part of it sits.

It rests on decades of product work and an analysis of how product organisations work, described in How it was built below.

What it changes

The model pays back through three mechanisms. Investment concentrates: the same money spent on fewer, better-chosen things, and teams that know their constraints do not wait for permission. Fewer wrong things get built, and what is built earns: problems are evidenced before they become requirements, the organisation is ready when the customer is, and someone owns the offering after launch. The company works better with the product: requests reach product visibly and once, and a new team adopts a way of working that already exists.

Benefit	What changes
Economic	• Investment goes to the products and markets the strategy chose. • Better product-market fit: the product and its price match what customers expect and value. • The product reaches its revenue targets. Product owns its economic outcome, and the work does not stop at go-live. • Product managers spend their time on product work, not on untracked requests.
Functional	• A clear way of working for each kind of product work, from strategy to retirement. • Common rules for how product works within the team, with stakeholders and with customers. • One lifecycle and one language across teams, so the rest of the company can follow.
Social	• Product is the trusted advisor on why the product should grow, and in which direction. • Product knows what the market needs, and which products the business needs to succeed in it. • Stakeholders know what to expect from product, and what product expects from them.
Psychological	• Teams know what is expected of them. • Teams know how to work with their stakeholders and with their customers. • Teams are empowered to move as fast as they can, because the boundaries are stated rather than guessed.

The effects arrive at different speeds: delivery within a quarter or two, strategy two to six quarters after the decision, commercial results over years. Each area document states how its impact is measured.

The product operating model

Three operating areas cover the whole of product work. Strategy and portfolio sets the direction, product management is the day-to-day work, and product enablement makes it possible to accelerate and scale.

How the areas work together

Each area answers one question. Strategy and portfolio asks what we are allowed to do: where the company plays with products and how it wins there. Its capabilities set the direction for all product work. Product management asks what we do: its capabilities are the day-to-day work of product management, turning direction into a product in the market and keeping that product commercially alive. Product enablement asks what makes us able to do it: its capabilities accelerate and scale product work, with a shared way of working inside product and visible, reliable support for the rest of the company.

The first and the third both touch everything. One limits what product management may do; the other gives it the ability to do it faster and at scale.

Capabilities, practices and Type

Each area holds capabilities: what the company must be able to do. Practices, how the work is done, live inside the capabilities and are published capability by capability.

Every capability has a Type, which tells you whether it applies to you:

• Baseline: a capability every product company needs, whatever its size or market. A small company runs it lightly; it does not skip it.
• Situational: a capability that applies only when a stated condition is true, for example a second product, partners who sell the product, or an acquisition. The condition is written next to each one.

That is how you tailor the model: start from the Baseline, and add what your situation calls for.

The materials stand alone and are usable without any agent. Product Kata Core is the agentic operating model that executes them.

Operating area 1 — Strategy and portfolio

Purpose. This is where a company decides where it plays with products and how it wins there: which products exist, for whom, at what price and through which route to market. A strategy is a set of constraints, not a document. Its value is in what it rules out, and those constraints are what let the rest of product move fast. Portfolio is where strategy turns into money: direction is cheap, allocation is the actual decision. These decisions are made rarely and change slowly, which is exactly why getting them wrong is expensive.

ID	Capability	What the company must be able to do	Type
C01	Product strategy	Where we play and how we win — segments and ICP, the commercial route where it shapes the business, doctrine, north star, horizons	Baseline
C02	Land and expand model	How customers are won and grown in the chosen markets — buying centre, entry offer, expansion path, channel and partner routes; each market selects its motion	Baseline
C03	Pricing and packaging	Monetisation model, editions and packages, price architecture, discounting, the commercial construct of OEM and partner deals	Baseline
C04	Portfolio management	Which products exist, how investment is split, which cross-product initiatives run, the portfolio’s commercial performance, lifecycle calls per product	Situational — a second product is considered
C05	Business initiatives	Run cross-product initiatives from idea to delivery	Situational — a cross-product initiative is underway
C06	Market insight	The outside-in picture — competitors, market, buyer and regulatory shifts, adjacent technology	Baseline
C07	Product culture	What the product organisation rewards and expects	Baseline

The full area page: Strategy and portfolio.

Operating area 2 — Product management

Purpose. This is where direction becomes a product in the market, and where that product is kept commercially alive. It is where most product people spend their week, and where most frameworks stop halfway: they describe discovery and delivery well, then go quiet on everything after launch, which in B2B is where most of the value sits. The operational half, from requirements to release, and the commercial half, the offering, its insight, its markets and its end, are one job. Splitting them is how companies end up with feature factories.

ID	Group	Capability	What the company must be able to do	Type
C08	operational	Requirements management	Capture, type and connect everything asked of the product, so a problem links to the solution that answers it and sits in the right backlog	Baseline
C09	operational	Discovery	Decide what should be built and why, and validate it: value, usability, feasibility and commercial viability	Baseline
C10	operational	Delivery	Make it work, carry the trade-offs, hand over something releasable with its instrumentation	Baseline
C11	operational	Go-to-market	Get it into use — phasing, toggles, messaging, and sales, support and delivery ready	Baseline
C12	operational	Release management	Govern what is released and when; technical release separated from commercial release; availability states	Baseline
C13	commercial	Offering management	The offering’s commercial life: roadmap, business case, MVP→MLP, pricing execution, post-GA monitoring, fit, and the trigger for expansion and retirement	Baseline
C14	commercial	Product insights	The 360° view of one product from its market, including its commercial performance	Baseline
C15	commercial	Market expansion	Decide and run entry into a new segment, geography or channel, with its expansion roadmap	Baseline
C16	commercial	Retirement	End part or all of an offering deliberately, with migration and communication	Baseline
C17	commercial	Local offering management	Run a locally tailored offering inside the global one	Situational — the product is genuinely tailored per market

Release management and Offering management are horizontals: one holds the operational group together, the other the commercial group. The full area page: Product management.

Operating area 3 — Product enablement

Purpose. This is what lets a product organisation grow without falling apart. From two teams on, product needs a shared language: one lifecycle, one set of requirement types, one way of working that sales and support can follow. And product’s largest audience does not work in product. This area turns the requests from sales, support and operations into visible work with agreed service levels, so that product becomes a partner of the business rather than a bottleneck. The seven Baseline capabilities are the basics, because product does not work in a silo; the five Situational ones switch on when their condition is true.

ID	Capability	What the company must be able to do	Type
C18	Operating model	Define, run, develop and share its own product operating model — cadence, forums, decision rights, the stakeholder engagement model, service levels, rollout rules, knowledge management, certifications, its own maturity, the adoption of new practices	Baseline
C19	Product organisation	Keep the organisation explicit in three compositions: teams, product areas, capability ownership	Baseline
C20	Competency development	Build product skill on purpose — skills, career paths, training and coaching	Baseline
C21	Product structure	Describe the product as an artifact the same way everywhere — lifecycle model, requirement types, instrumentation guidelines, legal and compliance guidelines, package descriptions	Baseline
C22	Product tech stack(working name)	Choose, run and connect the tools, and the product data and insight infrastructure	Baseline
C23	Sales and customer success support	Support the people who win and keep customers, including marketing support	Baseline
C24	Operations support	Support onboarding, support cases and internal difficulties with the product once the customer is won, in tiers and to agreed service levels	Baseline
C25	Product operations	Staff a product operations team that supports the other product teams in running the capabilities	Situational — enablement work no longer fits beside product work
C26	Product marketing	Run product marketing as a product capability	Situational — product owns product marketing
C27	Partner and channel enablement	Enable the partners who sell, embed or deliver the product	Situational — the product reaches customers through partners
C28	Supplier management	Work with the suppliers whose solution components are part of the offering	Situational — third-party components are part of the offering
C29	M&A support	Bring the product view into acquisitions, divestments and mergers	Situational — the company acquires, divests or merges

The full area page: Product enablement.

How it compares

This is not the first attempt to describe product management, and it should not be. There is real value in the frameworks others have built, and this model stands on their work: the ISPMA body of knowledge, the Pragmatic Framework, AIPMM’s ProdBOK, Sequent Learning Networks’ product management life cycle model, SVPG’s product operating model, Melissa Perri’s product-led organisation, SAFe and Blackblot’s Product Manager’s Toolkit.

It differs from them in three ways. It treats operational and commercial product management as one job, with the commercial life of a B2B product described as fully as the building of it. It gives enablement its own area, because product does not work in a silo: its support of sales, customer success, operations and partners is named, with service levels. And it is written to be executed, by people and by agents, with every capability’s business impact stated.

Where it differs, it differs for one reason, set out in the manifesto: to increase the commercial impact of product work.

Read more: the benchmark compares the model with all eight frameworks, capability by capability, credits each one, and says where we differ.

How it was built

The model comes from nearly twenty years of building product organisations in B2B software and services, tested against field references and against the frameworks above. It is organised around capabilities rather than a process, because a process goes out of date with every reorganisation and a capability does not.

It is young where it says so. The capability list is settled; the practices under it are published one capability at a time, and each says where it has been run.

Read more: Product Kata Core, our agentic operating model, explains the framework behind the model: what operating areas, capabilities and practices are, the principles the model runs on, and the thinking behind its design.

Revision 11 · 30 September 2026 · Product Kata Core · CC BY-SA 4.0 · Using Product Kata Core