POM in the AI Era

Part of our AI Driven Product Operating Model hub. Start there for the full map of guides, checklists and templates.

In July 2026 Marty Cagan wrote about what he calls the AI productivity paradox. Plenty of teams are clearly delivering faster with AI, yet their outcomes aren’t improving. He points to McKinsey, which describes growing adoption but a hard-to-find performance impact, and to an Atlassian report where most executives say AI sped things up but very few can show a return across the whole organization.

Why it isn't a real paradox

Cagan’s take is that most people use AI to speed up the old project-model way of working, and slowness was never the only problem with that model. It was built to deliver output, not outcomes. He quotes AI product leader Hilary Gridley, who says it has “never been easier to run 10 times faster in the wrong direction.”

Build to learn, build to earn

• Build to learn: Discovery. AI accelerates prototypes and tests that show whether a solution is valuable and viable, before committing.
• Build to earn: Delivery. Once evidence exists, AI accelerates commercial-quality building: reliable, accurate, scalable, performant.

Weaker teams use AI to churn out the old model’s paperwork faster: business cases, roadmaps, PRDs and code. Stronger teams use it to find a solution that’s actually worth building.

What to change in your operating model

Signs you are inside the paradox

• You ship more features every quarter and customer metrics don’t move.
• AI-written PRDs, roadmaps and decks pile up, and nobody can name a decision they changed.
• Prototypes go out to customers as real products, with no quality bar in between.
• Leaders judge AI by hours saved instead of outcomes moved.
• Teams still get handed a list of features to build, just with a shorter deadline.

AI at each concept of the model

A build-to-learn week (illustrative)

EXPERIMENT CARD (BUILD TO LEARN)
Assumption we are testing:
Which risk? value / usability / feasibility / viability
Prototype (what we built, with which tools):
Who we test with, how many, how:
Success threshold agreed before the test:
Result:
Decision: build to earn / iterate / stop
What this prototype is NOT: it is not production code or a customer commitment.
Safeguards: customer data handled responsibly; test participants informed.

Risks to manage

• Trusting generated requirements and analysis without checking where they came from.
• Being sloppy with customer data in prototypes and test tools.
• Mistaking a convincing prototype for proof that people want it.
• Letting speed wear away the review habits that catch bad ideas.

West’s blog on the APOM Guiding Principles sees it much the same way. AI may push organizations to become faster, smaller and flatter, as long as they have a strong, evidence-based operating model built on the fundamentals.

Evals: the discovery habit for AI products

If what you ship is itself an AI feature, discovery needs a new habit. Teresa Torres of Product Talk calls it evals. Instead of judging AI output by feel, teams write down what good looks like, test outputs systematically and track quality over time. In operating-model terms, evals sit with discovery and delivery: they test value and feasibility before release and watch quality after it.

Outcome metrics for AI features

An AI feature still needs an outcome, not just a usage count. This table pairs common AI features with outcome-style metrics. The examples are illustrative, so plug in your own baselines and targets.

What the McKinsey research adds

McKinsey’s operating-model research says that rolling generative AI tools out across the software life cycle, and building capability on purpose, can improve developer experience and productivity in code generation, documentation, translation and test creation. It also warns that operating-model maturity, especially ways of working, correlates most strongly with business results. Put that next to SVPG’s paradox and the message is simple: AI helps most where the model around it already turns speed into learning. See the evidence section for caveats.

Governing AI-built work

• Give every AI-assisted decision that reaches customers a named human owner.
• Keep prototype environments and data apart from production, and say so on the experiment card.
• Note which parts of a spec, analysis or design were drafted by AI and who checked them.
• Set a quality bar a prototype has to clear before it goes anywhere near customers.
• Review AI incidents without blame and feed what you learn back into evals and constraints.
• Don’t put customer data into tools your security and legal teams haven’t approved.

PRODUCTION READINESS NOTE
Solution and outcome metric (baseline and target):
Evidence it is worth building (link to experiment cards):
Quality: reliability, accuracy, performance, scalability results
Instrumentation: what we will measure after launch
Monitoring and alerts: owner on call
Rollout: A/B or staged release plan
Rollback plan:
Human owner accountable in production:
Approved by (product, design, engineering):

A 30-day plan for product leaders

1. Week 1: list where teams already use AI and what it produces, then note which outcomes those artifacts actually changed.
2. Week 2: pick one team and give it an outcome with a baseline. Ask it to use AI for discovery experiments, not extra output.
3. Week 3: bring in the build-to-learn experiment card and the production-readiness note.
4. Week 4: hold an evidence review. Did AI shorten the time to a decision, or just add to the pile of artifacts?

Related guides in this hub

• AI Driven Product Operating Model
• What Is the Product Operating Model?
• POM vs APOM compared
• Outcome-based funding and allocation

Sources

SVPG, "The AI Productivity Paradox" (July 23, 2026), citing McKinsey and Atlassian’s State of Teams 2026. Also: Product Talk, "AI Evals: A Hands-On Guide for Product Teams" (September 2, 2026); McKinsey, "The bottom-line benefit of the product operating model" (December 19, 2023). Metrics tables are editorial and illustrative.