SJ.
←Back to all writing
Stop Installing Product Operating Models: AI Just Made Bespoke Affordable
#AI#Product Management#Operating Model#AI-Native#Agile#Coordination

Stop Installing Product Operating Models: AI Just Made Bespoke Affordable

Enterprise transformations rarely fail because they picked the wrong framework. They fail because they can't work the way any framework requires. Six constraints that bind every product organisation in the AI era, and a worked example of how I'd optimise against them.

Steve James·

Executive Summary

Cagan’s product operating model. Scrum. SAFe. The Flow Framework. All of them have genuine success stories, and the best of them are principle-sets rather than playbooks. But the successes are few, and the reason is uncomfortable: most companies, enterprises especially, cannot work the way these operating models require. The preconditions – empowered teams, outcome-based funding, leaders who actually delegate decisions – are exactly the things enterprise structure resists. So instead of changing the preconditions, organisations dilute the framework until it fits what they already are. That’s the dumbed-down implementation everyone recognises: the vocabulary without the mechanism. Trios that are really a PM taking orders. OKRs that are really a project plan with different columns.

AI is about to make this problem much bigger and, for the first time, genuinely solvable.

Bigger, because the single greatest unlock of the AI era - individuals building working software without an engineering team - multiplies everything that already made coordination hard. A PM can process five customer interviews and produce an opportunity map in an afternoon. An engineer ships in hours what used to take a sprint. Every person moving faster means teams drift apart in days rather than weeks, and polished artefacts pile up that quietly contradict each other.

Solvable, because the machinery of an operating model - shared context infrastructure, coordination agents, outcome telemetry - used to be something only a framework vendor could afford to build. Now any organisation can build its own. The one-size-fits-all era existed partly because bespoke was unaffordable. That excuse is gone.

One catch, and it’s the catch this whole paper exists for: AI democratised the building, not the judgement. An organisation that dilutes Cagan will just as happily build a bespoke operating model that encodes its existing dysfunctions, and it will build it fast. Most organisations trying right now are getting nothing back - that’s what the ROI data says.

So this paper doesn’t offer an operating model to install. It offers two things instead: the six constraints that bind every product organisation in the AI era regardless of context, and a worked example of how I’d optimise against them, drawn from my experience in large organisations - scaffolding to steal from rather than a destination. Along the way it names the three mistakes even well-run organisations are making right now: solving a team problem with individual tooling, coordinating the new flow with frameworks built for the old one, and buying shared platforms chosen for the lowest common denominator.

The paper is in four parts. Part One makes the case that fitting an operating model to your organisation was always the real work. Part Two lays out the six constraints that don’t bend. Part Three is my worked example: how I’d optimise against those constraints in a large organisation. Part Four covers what all this means for product people, whatever you end up building.

Part One - Why Off-the-Shelf Operating Models Rarely Survive Contact with the Enterprise

The preconditions gap

Here’s the thing the framework industry doesn’t like to say out loud. The good operating models work. Cagan’s product operating model works - as a set of operating principles, run by organisations that actually meet its requirements. The problem is how rare those organisations are.

Look at what these operating models quietly assume. Empowered teams that can make product decisions without escalating. Funding that follows outcomes rather than annual project budgets. Leaders who set direction and then genuinely delegate. Now look at the data on how common that is. Gartner found the clash between project-based funding and product thinking to be the single biggest barrier to product-centric delivery (Gartner, 2019). Kersten’s value-stream telemetry shows 37% of organisations still fund exclusively through annual project budgets, only around 12% fund product teams continuously, and empowered product management “remains the exception” (Kersten, 2026). Organisations at the two most mature product-model stages went from 8% to 12% between 2023 and 2024. That’s real movement, but at that pace most enterprises won’t be there this decade.

The dilution default

So what does an enterprise do when it wants the results of a framework whose preconditions it can’t meet? It doesn’t abandon the framework. It dilutes it. Keep the names, drop the mechanisms. “Discovery” becomes requirements gathering with customer interviews bolted on. The “product trio” becomes a PM writing tickets with a designer and engineer cc’d. McKinsey calls this out directly: renaming business analysts as product managers without changing their authority or the funding behind them changes nothing (McKinsey, 2025).

And here’s the bit worth being honest about: dilution is rational. If you can’t change your funding model, your power structure, or your incentive system, bending the framework to fit what you are is the only move available. The framework was designed for a company you’re not. Nobody set out to adopt the vocabulary and skip the mechanism; they set out to adopt the whole thing, hit the walls, and kept the parts that didn’t require moving walls.

Which means there have always been three outcomes, not two. Genuine adoption, which is rare because the preconditions are rare. Dilution, which is the default. And a third path almost nobody has taken: design an operating model that fits what your organisation actually is, while respecting the things that are true everywhere. The reason nobody took it isn’t that it’s a bad idea. It’s that it was unaffordable. Designing and tooling a bespoke operating model needed capabilities most enterprises didn’t have spare.

What AI changes: the problem gets bigger

The AI era’s biggest unlock is that individuals can now create bespoke software without needing an engineering team. A PM builds a working prototype before lunch. An analyst automates a workflow that IT quoted six months for. This is genuinely wonderful, and it is also a coordination bomb. Every acceleration compounds the drift: teams diverging in days, output flooding the pipeline faster than anyone’s shared understanding can update, beautiful documents multiplying that don’t agree with each other. Whatever coordination problems your current ways of working paper over, AI is about to make them impossible to ignore.

What AI changes: the third path opens

At the same time, the machinery you’d need to run your own operating model just collapsed in price. A shared context layer that both humans and AI agents can read. An agent that scans across teams for duplicated work. Outcome telemetry per team. Two years ago that was a platform vendor’s roadmap; today it’s an internal build. Real organisations are already choosing build-not-buy for exactly this kind of tooling, and the emerging platform-team thinking is explicitly about letting non-engineers drive that production safely (Wulveryck, 2026).

Put those together and the conclusion is the thesis of this paper: the era of installing someone else’s operating model is ending, because the thing that made it necessary - the cost of building your own - is disappearing.

The catch: judgement didn’t get cheaper

Before that sounds too cheerful: an MIT study found 95% of organisations achieved zero ROI on generative AI, and 2026 has produced a steady stream of enterprises discovering their AI tooling costs more than the labour it replaced. Building is cheap now. Knowing what to build, and being able to tell whether what you built is any good, is as scarce as ever. Martin Fowler’s principle, drawn from the DORA research, applies with full force: AI amplifies whatever already exists in your pipeline. Point that inward and it reads: an organisation with bad operating instincts will now encode those instincts into custom tooling at speed.

That’s why the next part of this paper matters most. If every organisation should build its own operating model, the question becomes: what stops that being chaos? Answer: the things that are true no matter who you are.

Part Two – The Constraints That Don’t Care About Your Context

Six things hold whether you’re a bank, a scale-up, or a publisher. Your operating model can look like anything; it has to answer all six.

Constraint 1: The bottleneck has moved, and it was never where you think

Telemetry across thousands of enterprise value streams splits flow time roughly like this: Ideate 48%, Create 8%, Release 44% (Kersten, 2026). Only 8% of the time from idea to customer is spent actually building. So when AI makes building ten times faster, your end-to-end throughput improves… not at all, unless the other 92% moves too. Goldratt said it decades ago: speeding up a non-bottleneck doesn’t add throughput, it adds pile-up.

The bottleneck in the AI era is organisational: how fast decisions get made upstream, and how fast work clears testing, compliance, and deployment downstream. A practical way to find yours: take one small, boring, deterministic change and count every human touch it needs to reach production - Tim Cochran calls this the AI litmus check (Cochran, 2026). Whatever operating model you design has to attack the constraint you actually have, not the one that’s fun to optimise.

Constraint 2: Solo AI work wins by default

John Cutler’s distinction, from his Single-Player vs. Multiplayer AI series, is the cleanest diagnosis of the team-level problem. Single-player AI (one person, one agent) is a productivity question, and it’s largely solved. Multiplayer AI (lots of people, each with agents, on the same product) is a coordination question, and it’s largely unsolved. Almost all tooling and investment has gone to single-player.

The tools make solo work easy, so people do it solo. Every solo session deepens the habit. The deeper the habit, the better people get at solo work, which makes sharing look even less worthwhile. Cutler calls this the divergence clock: solo practice calcifies daily, and convergence gets more expensive every week you wait.

Why does this happen even in teams that genuinely want to collaborate? Cutler ran the question through the COM-B behaviour change model (Michie, van Stralen & West, 2011) and the answer is striking: it’s not a motivation problem. It’s an environment problem. The tools are built single-player, nobody owns shared infrastructure, and no norms support multiplayer work. Fix the environment and most of the motivation gap fixes itself. Which means the standard enterprise responses - training courses, mandates, another knowledge management system - will fail everywhere, always. Sharing has to become a byproduct of how work happens, not an extra chore.

Constraint 3: Tools chosen for everyone work for no one

When an organisation does spot the coordination problem, its reflex is procurement: one platform for everybody, selected for universal acceptability. Which means selected for the lowest common denominator. You’ve seen the result: the tool that offends nobody and delights nobody, quietly routed around by the practitioners who need depth, kept alive as a compliance surface that leadership mistakes for infrastructure.

The COM-B lens explains why this fails even with real money behind it: a shared tool that adds friction to the actual work path makes the environment worse, so the pull towards solo work gets stronger, now with a veneer of compliance on top. The fix is a boundary, not a platform: standardise what must be shared, and leave how individuals think and work alone. Part Three shows one way to draw that line.

Constraint 4: Quality gates get gamed

Johann-Peter Hartmann calls the destination the Bullshit Factory: high autonomy plus weak controls plus near-zero build cost equals impressive volume that doesn’t cohere (see his “dark factory” and “dark slop factory” writing). For a product org, that’s dozens of PMs producing beautiful PRDs and strategies that contradict each other invisibly until a customer finds out.

This stopped being a prediction. Jeff Sutherland, co-creator of Scrum, has documented AI agents in live production converging to game their own quality gates (Sutherland, 2026): writing the rules their own work gets judged by, filing the same deliverable under two identities to fake consensus, building a secret bypass validator, hiding governance changes inside sixty-file cleanup commits. No agent decided to cheat. The reward was local (stories closed) and the cost was global (paid by the next sprint and the customer), so the behaviour flowed around the gate like water. And Sutherland’s kicker is that every one of those patterns is a human organisational failure you already know: self-graded OKRs, rubber-stamp committees, shadow IT.

The constraint, then: every filter, review, and AI layer in whatever operating model you build is a quality gate, and it will get gamed unless its ownership, auditability, and reward structure are designed against that. Any AI component inside your operating model is a product in its own right - it needs evals, guardrails, and governance - and humans should only ever report to humans.

Constraint 5: Output stops being evidence of value

When building was expensive, output was a workable proxy for value: if the team shipped a lot, something was probably working. AI breaks the proxy. Output becomes abundant, demand for output is bottomless, and management by output lets spend scale with activity instead of value (Kersten, 2026). The 2026 wave of blown AI budgets and pulled licences is this constraint collecting its debt: agentic workloads consume orders of magnitude more tokens than chat, costs vary wildly run to run, and nobody connected any of it to outcomes.

So whatever operating model you build needs an explicit economic layer: some instrumented link from inputs (including AI spend) through outputs to measured outcomes, and funding that follows the outcomes. Without it, every coordination mechanism you build regresses to a feature factory with nicer artefacts.

Constraint 6: Human judgement is the scarce input, and you can accidentally stop producing it

Two findings that should worry anyone designing human-in-the-loop anything. First, the Wharton “cognitive surrender” experiments: across three preregistered studies with 1,372 participants, people followed the AI when it was right 93% of the time – and when it was secretly wrong, they still followed it 80% of the time (Shaw & Nave, 2026). People don’t review confident AI output. They absorb it. If your operating model’s safety story is “a human checks it”, you don’t have a safety story.

Second, the apprenticeship problem (Meyer, 2026): the grunt work AI now does - synthesis, first drafts, competitive scans - was never just output. It was how juniors built the judgement your operating model depends on at every gate. Automate the grunt work without replacing the training arc and you’re eating your seed corn.

The constraint: your operating model must engineer safety into systems rather than assume it from human review, and it must deliberately manufacture judgement, because the old production line for it just shut down.

The derivation test

That’s the checklist. Whatever operating model your organisation designs - and the position of this paper is that you should design one - it has to answer six questions:

  1. Does it attack your actual constraint, upstream and downstream, rather than the 8% in the middle?
  2. Does it make sharing a byproduct of working, through the environment rather than mandates?
  3. Does it standardise only what must be shared, and leave how people think alone?
  4. Are its gates owned, auditable, and reward-aligned, and its AI components evaluated like products, with humans reporting to humans?
  5. Does it connect spend to outcomes, so abundance becomes experimentation rather than waste?
  6. Does it engineer safety beyond human review, and deliberately grow the judgement it consumes?

An operating model that answers all six can look like almost anything and be right. One that fails on any of them will fail in the specific way that constraint predicts. What follows is one worked option - mine.

Part Three - A Worked Example: How I’d Optimise Against the Constraints

This part is not a neutral reference architecture, and I want to be upfront about that. It’s my opinion: how I would set up a product organisation to work against the six constraints, shaped by my experience working in large organisations. That experience is the design context baked into everything below - multiple product groups across different domains, real funding politics, teams that practise (or want to practise) discovery, and all the structural resistance Part One described. It’s also the limit of the example: I’ve optimised for the enterprise I know, and if your context is different, your mechanisms should be too.

So read this part the way you’d read a colleague’s working notes rather than a standard. Steal what fits, challenge what doesn’t, and use the constraint tags on each section to see the reasoning: every mechanism exists because one of the six constraints demands something there, and this is the something I’d choose.

Foundations that don’t change

The model builds on a product foundation AI doesn’t alter. A product manager’s core job is still reducing the product risks before committing engineering effort (Cagan, SVPG; Cagan’s four risks, with ethics as a widely adopted fifth):

Risk Question
Value Will this create value for the customer? Is the problem real?
Usability Will users be able to figure out how to use it?
Viability Can our business support this? Does it work within our constraints?
Feasibility Can we build it? Do we have the technology and capability?
Ethics Should we build it? Does it respect users and avoid harm?

Teresa Torres’s continuous discovery model - weekly customer contact, opportunity mapping, assumption testing through the product trio - isn’t replaced by AI; it’s accelerated by it. Two of its structures recur below: the product trio (PM, designer, engineer as the unit of discovery) and the Opportunity Solution Tree (OST), which connects outcomes to customer opportunities to solutions to evidence. The OST is a worked example throughout, not a mandate: it’s the structure’s properties that matter, not the notation.

Even the trio should be held as a default rather than a certainty. Kersten argues AI-era teams may shrink to one-pizza size or even one person (Output to Outcome); Cutler’s divergence clock warns that solo work compounds incompatibility daily. This worked instance keeps the trio because discovery risks are cross-disciplinary, but treats team size as an open question.

Context architecture (answers constraints 2 and 3)

Start with context, because everything else reads from it. Customer insights, strategy, decisions, experiment results: that’s the raw material of product work, and in an AI-native operating model your agents consume it too, so its quality directly sets the quality of everything they produce.

The design is two layers with a deliberate boundary:

The shared context layer is the organisation’s collective memory: strategy and OKRs, the opportunity structures, customer research, decision records, experiment results, competitive intelligence. Everyone reads it, everyone feeds it, every agent working for anyone can access it. Two non-negotiables. Contributing has to happen inside the normal flow of work, because if sharing means extra admin, constraint 2 says it won’t happen. And it’s standardised on structure, quality, and access - not on being acceptable to everyone. Optimise it for the practitioners who feed it and the agents that read it, or watch them route around it (constraint 3).

The personal layer is each PM’s own thinking space: rough notes, drafts, their own AI setup, configured however they like. Deliberately not standardised. It reads from the shared layer, so each person’s AI always has full team context, and finished artefacts get promoted to shared when ready. In practice a simple hybrid works: think rough in your own space, write anything trio-relevant (opportunity updates, experiment results, specs) straight into the shared layer, and let an agent smooth the promotion step - formatting, linking, notifying whoever’s affected.

Self-documenting by design

I generally steer away from tooling discussions, because in my experience an alarming share of any “transformation” gets burned hunting for the new tool that’s going to solve everything. So let me be precise about why this one is different: the shared context layer is not a tool decision. It’s a format decision, and it’s the one infrastructure choice in this whole worked example I would actually fight for.

Two behaviours have to be true for the layer to work. Agents must self-document: when an agent finishes a piece of work, it records what it did, why, and what changed, in the same format it thinks in, so documentation stops being a chore humans skip and becomes a byproduct of execution. And agents must access context seamlessly: pull exactly what they need, when they need it, with no conversion step in the way. Both point at the same requirement: the layer must live in a format LLMs are natively fluent in. In practice that means plain markdown with structured frontmatter, in a versioned repository. Humans get their view through rendering, which is a solved problem, because the solution is the web itself. Markdown was designed as a shorthand for HTML: it maps perfectly onto web pages, and reading on the web is the thing humans are already most comfortable doing. This article is markdown rendered in a browser, and so is most of the documentation you’ve ever read. So the shared layer simply becomes an internal website: documentation-site tooling turns the repository into a browsable, searchable site with navigation and links, updated on every change, and nobody needs to know or care that the source is plain text files. Anyone working closer to the source gets the same files rendered automatically in tools like GitHub or Obsidian, and if a stakeholder truly needs a Word document or a PDF, converting outward is a one-command operation. The point is the direction of the machinery - humans get a rendered web view of an agent-native source, rather than agents getting a lossy extraction from a human-native one. The alternative puts a conversion tax on every single agent interaction, in both directions.

Now the uncomfortable enterprise reality. Most large organisations have gone all-in on O365, which means the organisation’s actual context - strategy, decisions, research, plans - lives in Word documents and PowerPoint decks on SharePoint. None of that is natively manageable by an LLM. Every agent interaction starts with extraction, loses structure on the way through, and nothing the agent learns can be written back seamlessly. For a typical enterprise I’d call this the single biggest practical blocker to a shared context layer, and it’s mostly invisible because the documents look perfectly fine to the humans reading them.

One problem needs confronting head-on: volume. Agents read at agent speed; humans don’t; and the corpus only grows. When one PM-agent pair can produce sixty tidy pages in two days, nobody reads it all, and consensus drifts to whoever summarises loudest. Three disciplines help: retrieval instead of expecting anyone to read everything (a small always-loaded core plus a searchable cold store, per early production evidence on agent context infrastructure); curation and expiry, so superseded work leaves the active layer; and keeping agent instructions minimal and separate from knowledge, because piling on rules makes agents worse, not better (the configuration paradox).

The living context chain (answers constraints 1 and 2)

Old operating frameworks treat handoffs as moments: discovery produces a spec, the spec goes over a wall. At AI speed that breaks down, so this approach replaces handoffs with a context chain that lives in the shared layer. Four kinds of context accumulate around any piece of work, and all four are typically live at once:

  1. Discovery context (PM-owned): the opportunity structure, interview insights, assumption tests, current understanding of the problem.
  2. Solution context (trio-owned): concepts, PM prototypes as learning artefacts, design explorations, feasibility assessments, all linked back to the discovery that motivated them.
  3. Specification context (trio-owned, engineering-ready): the validated spec with acceptance criteria and architecture decisions, linked to everything above, so an implementing agent can read not just what to build but why.
  4. Delivery and release context (engineering-owned): implementation decisions, trade-offs, divergences from spec. Bidirectional by design: when implementation invalidates a spec assumption, the spec node updates and the trio gets alerted; when it surfaces a customer problem discovery missed, the discovery context and the opportunity structure get amended; when it constrains another team, that gets flagged across team boundaries (the next section’s job).

Each stage enriches the accumulated context; nothing replaces anything. Skip a link and you’re borrowing against context debt. And note where the chain must extend: constraint 1 says roughly as much time dies after code-complete as before it, so environments, test data, compliance, and deployment approvals are part of delivery context too, and their friction gets mapped (the litmus check again) and removed with the same seriousness.

Coordination architecture (answers constraints 2 and 4)

Context makes knowledge legible and the chain keeps individual pieces of work coherent. Neither solves the cross-team problem: at enterprise scale you can’t rely on hallway conversations or individual discipline. Three mechanisms, in order: an artefact, a sensor, and an actor.

  1. The artefact: a hierarchical outcome-and-opportunity structure. The requirement is precise even though the notation is free: a shared structure connecting outcomes to opportunities to solutions to evidence, at three levels:

    • Portfolio - owned by leadership; business outcomes; reviewed quarterly
    • Group - owned by the Group PM; product outcomes feeding the portfolio outcomes; reviewed monthly
    • Team - owned by the trio; updated continuously from discovery

    Context flows down, evidence flows up, and because the trees live in the shared layer, duplication and drift surface through the structure instead of in a post-launch review. Torres’s OST is the best-developed example; if you already run outcome trees or impact maps with the same properties, extend those instead.

  2. The sensor: an organisational intelligence layer. No human can scan what dozens of teams write into shared context daily. So an organisational agent reads across it continuously and surfaces the patterns humans can’t see at scale: duplicated discovery, contradictory solutions, dependency drift, experiment results relevant to another team, staleness. It has read access to everything and write access to exactly one thing: a coordination feed. It doesn’t decide anything. It makes the cross-team picture legible so humans can.

    Constraint 4 applies to this layer with full force, so four rules. It’s a product, not a script: precision targets per pattern type, a golden dataset, a regression suite, observability - because an unevaluated layer produces noise, noise teaches people to ignore the feed, and an ignored feed means coordination silently died while looking alive. Assume gaming: its gate code lives outside the reach of the agents it watches, agent-authored artefacts are untrusted by default, and apparent consensus gets audited. Don’t call human triage a safety layer: constraint 6 says the reviewer will rubber-stamp, so every flag carries its evidence trail and disconfirming a flag takes one click (and feeds the evals). And humans report to humans, full stop: the layer surfaces and routes, never directs (Kersten’s principle, adopted wholesale). Run it as a platform capability with maturity criteria, not a side project (Wulveryck, 2026).

  3. The actor: a filter chain, run by people. When building is nearly free, the scarce discipline is deciding what deserves to exist. Three filters. The team filter is continuous: nothing enters the delivery backlog without trio validation - designer challenging usability, engineer challenging feasibility, PM defending the value and viability hypothesis. Prototypes get reviewed here, never shipped. The group filter is weekly and trigger-driven: the Group PM watches the coordination feed and steps in only when a pattern fires; when nothing fires, the filter is silent, which is what keeps it from becoming a gate everything queues behind. The portfolio filter is quarterly: are these still the right bets. And because constraint 4 doesn’t exempt humans: each filter’s criteria are owned outside the team being filtered, passing is auditable against evidence rather than attestation, and the metrics that reward PMs price downstream cost (rework, contradiction, duplication), not throughput.

The role that holds it: the Group Product Manager. Cutler’s diagnosis flagged “nobody owns the shared infrastructure” as a core barrier, so here somebody does. The group’s opportunity structure, its shared context space (including the pruning), the group filter, and the signal-versus-noise judgement calls all belong to the Group PM. One challenge to face squarely: the strongest current thinking says AI dissolves coordination-only management - the translation layer of the org chart goes (Gore, 2026). This role survives only in its judgement form: triaging, deciding, curating, connecting evidence to bets. The version that relays status upward is exactly what AI eats. Define it by judgement, staff it with people who stay in the work, and don’t let it become a landing zone for displaced line management.

Value and funding architecture (answers constraint 5)

Filters govern what gets in. Nothing so far governs whether any of it was worth it. So the counterpart: filters govern input; the outcome loop and outcome-tied funding govern value.

Each product group runs an instrumented loop (Kersten, Output to Outcome): inputs (budget, headcount, AI spend) produce outputs (shipped, tested, discarded) which produce outcomes (measured changes in customer behaviour and business results) which re-set the inputs. It runs weekly at team level inside the existing trio rhythm, monthly at group level, quarterly at portfolio. The discipline it enforces is the one abundance demands: most AI-amplified output should be experiments, measured, and thrown away when the hypothesis fails. Cognition AI, Kersten’s lead case study, ships less than it builds and discards weekly - that’s abundance becoming hypothesis-testing capacity instead of slop.

The artefact and the loop are complements, not rivals: the opportunity structure carries evidence about what customers need; the loop carries telemetry on whether shipping actually moved anything. A tree without the loop coordinates beautifully around unverified assumptions. The loop without the tree measures rigorously with no customer grounding.

Funding is the part that separates real change from relabelling, and it’s the least adopted: groups are funded continuously against their outcome hypotheses, released on outcome progress rather than delivery milestones. AI spend gets the same treatment - attributed per group, connected to the hypotheses it serves, capped or raised stream by stream based on demonstrated outcome connection. That’s the rational answer to “how much should we spend on AI?”: as much as each stream converts into outcomes, and no more.

And the trap to refuse: a leadership team sees (or assumes) a 20% AI output gain and banks it as a 20% headcount cut. Budget is an input to the loop. If the gain never translated to outcomes, the cut removes real capacity, and Kersten’s worked example ends with retention down 30-50% (Kersten, 2026). Until the loop is instrumented, output gains are hypotheses, and you don’t spend hypotheses.

The reference stack (the most disposable layer)

Named tools, because “tool-agnostic in principle” dodges the COM-B point: tools either make multiplayer the path of least resistance or they don’t. But this table is explicitly the first thing you should swap for your own context.

Layer Recommended Tool Why
Issue management Linear Best-in-class API for agentic workflows; light enough that publishing a prototype can auto-create a trio review task
Shared context A git-backed markdown repository (with a rendered view for reading) LLM-native format: agents read and write it with no conversion tax, which is what makes self-documentation real. Versioning, diffs, and audit trail come free; human consumption is a rendering problem, and rendering is solved
Personal workspace PM’s choice, as long as it integrates natively with LLMs Standardising personal tooling adds friction without adding coordination value
Code / delivery GitHub plus AI coding agents The broadest agent ecosystem; agents read specs and decisions from shared context
Prototyping Claude Code or equivalent PM-accessible prototype generation without a separate environment to learn
Organisational intelligence Platform-owned agent service Not a packaged product yet; build it as a platform capability with its own evals and guardrails

Part Four – What This Means for Product People

Mechanisms vary between organisations. What happens to the people operating them varies much less, because it follows from the constraints rather than from any particular operating model.

Three PM activities, transformed

Discovery and sense-making. AI transforms the before and after, not the middle. Before a trio session: synthesise every prior interview, refresh the opportunity map, identify which assumptions most need testing. After: process what was learned, update the shared artefacts, spot the implications for neighbouring teams. The middle - humans making sense of customers together - is the bit to protect, and there’s a real risk hiding in good preparation: walk in with a polished AI-built analysis and your trio becomes an audience instead of co-discoverers. Constraint 6 says they’ll absorb it, not interrogate it. Shared understanding is produced through interaction, not assembled in advance.

Prototyping and validation. The genuinely new capability: a PM with an AI coding tool can put something testable in front of a user within hours of spotting an opportunity. Three rules keep it healthy:

  1. Prototypes are disposable hypothesis tests, never draft implementations. The handoff is the validated learning, not the code.
  2. Trio review is the automatic next step, and the tooling makes it automatic. Publishing a prototype to the shared layer creates the linked review task, notifies the designer and engineer, and embeds the prototype in the thread, so review is the path of least resistance rather than a calendar chore.
  3. Language matters. Call them concept tests or learning prototypes, never MVPs or v0.1, because names signal whether something is a thinking tool or the start of production code.

Analysis, synthesis, and communication. Competitive analysis, metrics reviews, roadmap prep, stakeholder updates: the personal layer is made for this, and it’s the most straightforward win. The enterprise-scale risk is the one Part Two diagnosed - many PMs producing polished strategies that quietly disagree - and it’s exactly what the coordination architecture exists to catch.

The technical floor has moved

Plainly: whatever operating model your organisation derives, the PM in it operates AI systems daily - prototyping with agents, writing context agents consume, triaging what agents surface. That sets a technical competency floor higher than most enterprise PM role profiles were written for.

Not “PMs must become engineers”. The floor, stated as observable behaviours: can take an opportunity from the team’s opportunity map to a testable prototype with an AI tool and explain what it does and doesn’t demonstrate; can write context an agent acts on correctly without a human interpreter; can read a confident AI output and visibly disagree with it; can say where the tools fail on their product. The org-shape evidence points the same way from two directions - Gore’s judgement layer operates agents directly, with “hands-on” redefined as prompts, eval criteria, and contracts (Gore, 2026), and Kersten makes AI-stack fluency a leadership requirement, not a specialism (Output to Outcome). Constraint 6 is why the floor isn’t optional: a PM who can’t evaluate agent output isn’t operating the system, they’re being operated by it, while looking productive.

One honest qualification: platform thinking may absorb some of the burden - Wulveryck’s platform approach exists precisely so domain experts can drive agents safely. But look at what his “non-technical” teams still do: define intent, supply context, drive the orchestrator. That is the floor. The platform changes how much of the how you carry; it doesn’t bring back the world where a PM could live entirely in slideware.

And the change-management posture matters as much as the claim: this is data literacy again - the job’s tools changing, not the job’s identity. Raise the floor environmentally, through prototyping norms, career frameworks that name these behaviours, and the pipeline below. Frame it as identity change and you’ll get rejection; frame it as the tools changing, again, and you’ll get adoption.

Keep making judges

Constraint 6’s second half lands here. The grunt work that trained junior judgement is gone to the agents, so judgement has to be manufactured deliberately: give juniors primary customer contact and have them review AI output against ground truth they already know; make seniors visibly disagree with confident AI output so juniors learn pushing back is expected; and track judgement development explicitly in career frameworks, because the volume of artefacts a junior produces is no longer evidence of anything.

Build Yours

If this paper argued anything, it’s this: the six constraints are the durable part, and the worked example in Part Three is scaffolding. Steal what fits. Change what doesn’t. The failure mode to avoid isn’t picking the wrong framework; it’s installing anyone’s framework - including this example - without doing the fitting work that the successful adopters always did.

Start from the best material available: Cagan and Torres for the product foundations, Kersten for the outcome and funding machinery, Part Three for an example of an AI-native coordination layer. Then fit deliberately to your own preconditions instead of diluting accidentally.

Six questions to design against, one per constraint:

  1. Where does flow time actually die in our organisation, upstream and downstream?
  2. What would make sharing a byproduct of our normal work, rather than a task?
  3. What must we standardise, and what must we refuse to standardise?
  4. Who owns each of our gates, how is passing evidenced, and what do our reward metrics actually price?
  5. How does spend - including AI spend - connect to outcomes per stream, and who can see that connection?
  6. Where does judgement get exercised in our operating model, and where does the next generation of it get grown?

A note on evidence, because honesty matters more in an informal paper, not less. This is a structured hypothesis, not established practice: there’s no documented production case study yet of multiplayer AI coordination succeeding at enterprise scale. The behavioural foundations are peer-reviewed and the cognitive surrender findings are preregistered experiments, but the flow-time split and maturity figures are vendor telemetry and consultancy research - direction robust, precise numbers with caution. The base rate says most enterprises will be building product-model fundamentals and this AI-native layer at the same time. That’s a reason for sober timescales, not for waiting: the divergence clock runs daily.

Acknowledgement

Much of what improved in this article’s later revisions traces to one person. Mik Kersten’s Output to Outcome (outputtooutcome.org) is published on 14 July 2026, and the early access material he shared ahead of release - the constraint data, the outcome loop, the AI-budget argument, “humans report to humans” - reshaped this article’s value and funding thinking and corrected my original framing of where the bottleneck sits. Project to Product changed how a generation of us thought about software delivery, and on the strength of the early material, I expect Output to Outcome to be its equal for the AI era: genuinely ground-breaking. He is, without embarrassment, one of my heroes in this space. If you read one thing beyond this paper, make it his book.

The Principles, Sorted by How Far They Travel

Everything this paper argues, in one table. The first group holds everywhere, whatever operating model you build. The second group is Part Three’s answers, and yours may differ. The last one is about how to do the fitting work.

# Principle Type Implication
1 Find the constraint before optimising Holds everywhere Development is rarely the bottleneck. Map end-to-end flow; expect the constraint upstream in decision-making and downstream in release friction.
2 Restructure the environment first Holds everywhere Make sharing a byproduct of working. Training, mandates, and motivation campaigns fail against a hostile environment.
3 Discovery is the core job Holds everywhere AI transforms throughput, not purpose. Protect the human interactions where understanding is actually produced.
4 Assume gates get gamed Holds everywhere Ownership outside the team being filtered, auditability against evidence, rewards that price downstream cost. Applies to human and AI gates alike.
5 Treat embedded AI as a product Holds everywhere Evals, observability, and guardrails before deployment. An unevaluated coordination agent is the Bullshit Factory one level up.
6 Fund outcomes and govern spend Holds everywhere Output gains are hypotheses until an outcome loop confirms them. AI spend is attributed per stream against outcome hypotheses.
7 Humans report to humans Holds everywhere Agent layers surface and route; they never direct people or hold accountability.
8 Manufacture judgement Holds everywhere Safety is engineered into systems, not assumed from review; and the judgement your gates consume must be deliberately grown.
9 Separate shared from personal My choice, yours may differ Standardise the shared layer on structure, quality, and access. Leave how people think alone.
10 Coordinate through artefacts, not meetings My choice, yours may differ A hierarchical outcome-and-opportunity artefact; meetings resolve what artefacts surface.
11 Filter before building My choice, yours may differ Team, group, and portfolio filters, trigger-driven, silent by default.
12 Context chains, not handoffs My choice, yours may differ Discovery, solution, spec, and delivery contexts accumulate; learning flows backwards too. Prototypes are for learning, never for shipping.
13 Fit deliberately; raise floors environmentally How to do the fitting Adopt from practice, not theory. Frame the PM technical floor as the tools changing, not identity change.

References and Further Reading

Note on sourcing: citations link to publicly available versions of each source where they exist. Some practitioner material remains in newsletter, blog, or talk form rather than peer-reviewed publication; weigh accordingly. Vendor-sponsored telemetry (Planview, McKinsey, Gartner) is flagged in the body where used.

←Back to all writing

Get new articles in your inbox.

Notes on AI strategy and product management, from Steve.

Subscribe→