The Post-AI PM Playbook
  1. Preface · It was always about product sense
  2. 01 · You can only sell what you understand
  3. 02 · The product operating model as your shared context layer
  4. 03 · Composition, not headcount
  5. 04 · Guardrails to reduce assumptions and hallucinations
  6. 05 · Two moments for the humans in the loop
  7. 06 · Run it as loops, not projects
  8. How to start

Chapter 01

You can only sell what you understand.

Selling is the scarce skill now. And you can only sell what you actually understand: the customer, the pain, and what they would pay to make the pain stop.

The discipline that used to hold the job together

For most of the last twenty years, the thing that stopped product teams from building the wrong thing was cost. Engineers were expensive. Design cycles were expensive. Everything downstream of a decision compounded, so the decision itself had to be careful.

Roadmaps existed to defend the scarce input from being wasted. Sprint choreography existed to protect it from being interrupted. Requirements docs existed to make sure the scarce input built the right thing on the first try. Stakeholder alignment across finance, legal, and compliance existed to keep the scarce input from being blocked halfway through.

Every ritual the PM inherited from the 2010s was a variation on the same theme: developer time is precious, act like it. The whole shape of the job was inward-facing coordination in service of one scarce input.

That input is not scarce anymore.

What actually changed

Building is cheap now. Not free. Tokens still cost, work-in-progress still costs, focus is still scarce, and it is still expensive to build the wrong thing. But building is cheap enough that the discipline the old inward stack was built to enforce has lost its object. You can prototype a feature over a lunch. You can spin up specialist agents to do work that used to require hiring. You can put working software in front of a real buyer before the roadmap deck would have been finished.

The bottleneck moved. That is the fact from which everything else in this playbook follows.

Where the scarcity moved

The scarce input is customer signal.

Not "what customers say in a discovery interview." That is abundant; it always was. What is scarce is evidence sharp enough to bet on. Named buyers with real budgets who will name a real close condition. Pricing conversations where a specific number gets a specific yes. Unit economics assembled from actual usage. Objections raised by people who would actually sign. Every one of those is finite, contested, and won by the team that goes and gets it, not by the team that waits for it to walk in.

You can only sell what you understand

Here is the part that gets skipped. You cannot sell to a buyer you do not understand. Selling is not a deck and it is not a pitch cadence. It is the act of naming a pain so precisely that the person feeling it recognises themselves in the sentence. That only works if you actually know the customer, the pain, and what they would pay to make it stop.

Which is why the PM job's centre of gravity has to move outward. Inward work does not go away. Stakeholder alignment across finance and legal and compliance still exists. The pieces that used to be politics get to be evidence now, because AI can acquire and process the data the classical PM did by hand. Roadmap conversations still happen. Budget conversations still happen. But the weight of the job, where the PM actually spends the week, where the hard calls get made, moves outward. To the market. To the buyer. To the pricing edge.

If your week is 80% inward and 20% outward, you are running the 2015 job in 2026. It will not get you fired this quarter. It will make you obsolete over three years.

One abstraction layer up

AI can now do most of the data-collection and pattern-processing work the classical PM used to do manually. Surveys, transcript coding, funnel analysis, competitor scraping, first-pass customer interviews, market sizing pulled from public filings. All of it is either fully agentic now or minutes-with-AI work rather than weeks-with-humans work.

What humans do instead is one abstraction layer up. You decide which signals are worth acting on. You decide which bets are worth opening. You decide what is worth spending time and tokens on. You choose.

AI acquires; humans size. AI processes; humans commit.

The old PM job was to make sure the developer builds the right thing. The post-AI PM job is to make sure the whole system, humans and agents and buyers and the market, is pointed at the right thing. Same responsibility, higher altitude, sharper stakes.

The three risks stay. Everything else moves.

The durable spine of the PM job is unchanged: feasibility, viability, desirability. Three risks the PM is accountable for shrinking before the team commits real resources. That framing is thirty years old and still correct. The AI-native product manager still owes each risk an answer before a bet activates.

What changed is not the risks. It is the time allocation across them and the evidence available to reduce each one.

Desirability used to be reduced by discovery interviews and slow prototypes. Now it is reduced by putting a real thing in front of a real buyer and watching whether they reach for their wallet. Named buyer, testable close condition, evidence you can point at.

Viability used to be reduced by spreadsheets built by hand and defended in stakeholder meetings. Now it is reduced by unit economics AI helped assemble in an afternoon, priced against pricing conversations that actually happened. Evidence-based, not politics-based.

Feasibility used to be reduced by engineering estimates that were guesses in a suit. Now it is reduced by prototypes AI helped ship in an hour. The question shifted from "can this be built?" (usually yes) to "should this be built at all, and by whom, and with what specialist composition?"

The three risks still gate every bet. What is different is the discipline the PM applies to shrink them. Outward instead of inward. Commercial instead of coordinative. Evidence-based instead of alignment-based.

What replaces cost as the discipline

Cost was the old rule that kept teams honest. What replaces it is proof of demand.

Not proof of concept. Not investor thesis. Not internal alignment across five stakeholders. A named buyer. A testable close condition. Evidence you can point at that says: this specific person, or this specific segment, will do this specific thing when we give them this specific offer.

If you cannot answer that, the bet does not open.

That is the rule that carries over from "developers are scarce, be careful what you build" to "developers are cheap, be careful what you choose." The gate moved from the sprint boundary to the bet boundary, but the discipline is the same: no wasted commitment.

A bet without a named buyer is a hobby with a Jira board. In the old world, that hobby was expensive and slow, so you could catch it in review. In the new world, it is cheap and fast, so you have to catch it at the gate. The gate is proof of demand.

What this rules out

Naming what dies is as important as naming what replaces it.

  • PM as roadmap defender — a role that made sense when the roadmap was allocating scarce developer capacity. There is no scarce developer capacity to defend. Fossil work.
  • PM as project manager — coordinating tickets, updating docs, running standups. All of that is either done by agents now or should not be done at all.
  • PM as internal alignment broker — the value used to come from getting five stakeholders to agree. The value now comes from getting one buyer to sign. The alignment work still happens; it just is not the job.
  • PM as ticket router — routing work between engineers is now routing work between specialist agents, and even that is being absorbed into the harness.

The move is not to accelerate any of these. Wrapping fossil work in AI does not save the fossil. It just makes the fossil faster. The move is to replace the whole discipline.

What this looks like on a Monday

You review customer signal that came in over the weekend. Pricing conversations, objection patterns, usage anomalies, competitor moves. You identify one that seems worth going deeper on. You decide whether to open a bet on it. If you do, the first artefact is not a spec. It is proof of demand: a named buyer, an offer, a testable close condition.

Then you compose the specialist team, human and agent, that will chase that bet. Not because the sprint needs planning. Because the composition depends entirely on the problem you are chasing, and the problem changes every Monday.

Everything downstream of that follows.

Artifact: the proof plan / sell-before-build script.

References

  • Heritage (pre-AI): The Mom Test (Rob Fitzpatrick, 2013) on named-buyer discipline. Steve Blank's customer development. Eric Ries's build-measure-learn. The core insight, sell the pain not the pill, is older than the transition; the AI era makes it load-bearing where it used to be optional.
  • Neighbour (2026): Ben Frazier's "proof of demand" writing on AI-era product discovery. Kajsa Körfgen on operational execution in AI-native teams.
  • Opposing view: Marty Cagan's "AI productivity paradox" — the argument that AI amplifies the inward PM stack (docs, alignment, coordination) rather than dissolving it. This chapter's claim is the opposite: amplifying the fossil is not the move.
  • Load-bearing to the rest of the site: Ch2 operationalises this chapter. Ch1 names the what; Ch2 names the how.