The workflow
Seven stages, each closed by one question. When the answer is no, work goes back one stage, not to a meeting.
Gate question
Can we say the number and the appetite in one sentence?
Purpose
Decide whether this is worth time at all. One page, written before anyone opens a design tool: the problem in the words of the person who has it, who has it and how often, the evidence you have and the evidence you lack, the outcome and the number that would prove it, the appetite, and what you are not doing.
Typical failure
Skipping to the solution because a model made it easy to render one. The frame is what the prototype will be judged against.
- Artifact
- A one-page frame: problem, who, evidence, number, appetite, not-doing.
- Skills
frame-the-problem
What changed in 2026
- Before
- A slide with a vision.
- Now
- A page with a number and an appetite.
- Why
- Output is free. The frame is the judgment.
Gate question
What did we learn that changes the spec?
Purpose
Learn before committing. Building to learn: prototypes, interviews, assumption tests, a throwaway agent that runs on last month's data. The point is to be wrong cheaply. Keep the notes short and dated, and separate what the prototype settled from what it could not settle: usually the edge cases, the failure modes, and the cost of being wrong in production.
Typical failure
The demo that convinces the room and skips straight to a ticket.
- Artifact
- Prototype notes, interview notes, assumption tests.
- Skills
prototype-to-spec
What changed in 2026
- Before
- Mockups, then a long PRD.
- Now
- Working prototypes in hours. Product managers build their own.
- Why
- Cagan's building to learn. Affirm, Uber and Slack report the same practice.
Gate question
Could an engineer and a coding agent start without a meeting?
Purpose
Record the decision. The PRD is short and gated: a capability map when the request bundles several testable capabilities, the goal and the success criterion with a number, the boundaries of autonomy for anything that acts on a person's behalf (Always, Ask first, Never), the data each capability reads and writes, an evals plan for every probabilistic behavior, and what is out of scope.
Typical failure
A ten-page document nobody reads, or a prototype standing in for a decision nobody made.
- Artifact
- A PRD in gated phases, with boundaries and an evals plan.
- Skills
write-prd
What changed in 2026
- Before
- The PRD as the main document.
- Now
- A short alignment spec next to the prototype, with the boundaries of autonomy explicit.
- Why
- The ten-page PRD died. The decision record did not.
Gate question
Does every slice ship behavior, in an order that lets the team find its pace?
Purpose
Make it buildable in small, verifiable pieces, then put the pieces in the order that lets the team find its pace. Vertical slices, each crossing collect, decide, show and write. Sizes XS to L; above L you split, you do not estimate. Then the board: Features in Now / Next / Later, scored by ROI impact, with every prerequisite of a Now Feature pulled into Now and marked with its inherited priority. The go-live set in dependency order is wave 1. Dates are derived from the chain and the team's capacity, never typed.
Typical failure
Horizontal layers ("build the data model", "build the API") that ship nothing for weeks. Or a ranked list whose top item cannot be built, because its two unglamorous prerequisites sit at the bottom.
- Artifact
- The decomposition, the Now / Next / Later board with the enabling chain, the execution plan, the capacity simulation.
- Skills
decompose-spec,prioritize-now-next-later,execution-plan,capacity-simulation
What changed in 2026
- Before
- Estimation first, then a ranked list.
- Now
- Appetite first, vertical slices, the chain pulled into Now, dates derived from capacity.
- Why
- Shape Up. Now / Next / Later. Small batches.
Gate question
Does each item pass the four-reader test?
Purpose
Put it in the tracker so four readers can act. Epic for the outcome, Feature for the deliverable capability, User Story for the testable behavior. One fixed parent. The why written from the consequence of absence. Acceptance criteria an engineer can verify. For AI behavior, eval cases instead of deterministic criteria. For work an agent will execute, an agent brief with the verification command and the Never list.
Typical failure
Items that only their author understands.
- Artifact
- Epic, Feature, User Story, eval cases, agent brief.
- Skills
-
backlog-standard,epic-feature-story-templates,why-it-exists,user-story-writing,eval-cases,agent-brief
What changed in 2026
- Before
- One reader, the engineer.
- Now
- Four readers, one of them a coding agent.
- Why
- Spec-driven development. AGENTS.md as standing context.
Gate question
Threshold met on the held-out set, and zero never-cases?
Purpose
Ship each slice to the agreed bar. Deterministic checks for the ordinary software around the model. Eval pass rate on the golden set for the probabilistic parts, in CI, before merge. Shadow mode before any agent acts on real records. Promotion up the autonomy ladder only on evidence.
Typical failure
A green pipeline and a feature that is right 92 times in 100 when the risk tier needed 99.
- Artifact
- Passing checks, the eval pass rate, shadow results.
- Skills
sprint-planning,eval-cases
What changed in 2026
- Before
- Tests pass or fail.
- Now
- Evals: a threshold on a distribution, with guardrails for the tail.
- Why
- Probabilistic features. Torres and Pollick make the case.
Gate question
Did the number move? What do we delete?
Purpose
Find out whether the number moved. Read it. Feed production failures back into the golden set. File defects as descriptions, not diagnoses. Snapshot the backlog with a cutoff and show the delta, including what was removed. Review with the sponsor by reading last week's commitments first. Publish the roadmap with its photo date.
Typical failure
Celebrating output. The only question that matters here is whether the number moved and what that tells the next frame.
- Artifact
- Snapshot, review deck, roadmap status, bug cards.
- Skills
-
weekly-backlog-snapshot,backlog-review-meeting,roadmap-status,publish-roadmap,bug-report
What changed in 2026
- Before
- Launch, then move on.
- Now
- Production failures feed the golden set. Autonomy is earned tier by tier.
- Why
- Continuous error analysis. Autonomy ladders.
- Defect loopA bug card links to the story whose behavior broke, never asserts a cause, and returns through Write.
- Eval loopEvery production failure that matters becomes a golden-set case. The threshold is renegotiated with evidence, never silently.
- Learning loopThe metric read at Ship and learn is the first line of the next frame.
- Cadence loopWeekly snapshot, weekly review, roadmap with a photo date.
Prioritize what makes it live
Finding the problem is half the job. Cutting the work in the right order is the other half.
How much does it move the number?
The ROI impact: effect on the Epic's metric, reach, confidence, against effort. No estimate, no rank.
When?
Now, Next or Later. A commitment band, not a date. Dates are derived later from capacity and dependencies.
What has to exist first?
The enabling chain: the features that carry little value alone and without which the valuable one never goes live. They inherit Now.
The board for the Acme Epic
| Feature | Impact | Effort | ROI | Band | Why here |
|---|---|---|---|---|---|
| F01 Meetings and notes | 1 | 3 | 1.00 | Now, enabling F02 and F03 | Nothing drafts and nothing previews without the list of finished meetings. Lowest value alone, built first. |
| F02 Follow-up draft and send | 3 | 11 | 0.49 | Now | The reason the Epic exists: the draft is the main time saving. |
| F03 CRM write-back | 3 | 15 | 0.36 | Now | Moves the second metric directly; the write path is the autonomy contract. |
| F04 Activity trail | 2 | 2 | 0.60 | Now | Measures the Epic's number; without it nobody can read the result. |
| F05 Manager weekly digest | 2 | 8 | 0.05 | Next | Valuable once F04 has two weeks of data. Scoped, not yet estimated to the story. |
| F06 Drafts in a second language | 1 | 8 | 0.01 | Later | One rep in ten works in a second language. Reason recorded, no scope yet. |
| F07 Schedule the next meeting | no stories | To refine | Not estimated, so not ranked and not scheduled. |
The enabling chain
F01 carries almost no value alone. Nothing ships without it, so it is built first. Read from the right: F02 and F03 carry the value, F01 makes them possible, F04 measures the result, F05 waits for two weeks of trail data. Wave 1 is F01, then F02 and F03 in parallel, then F04.
Open the capacity simulation Read the spec preview Open the backlog document
The backlog document is where the review happens before anything reaches the tracker: the whole backlog in plain language, wave by wave, with the sprint planning inside it and a capacity bar that alerts the moment a person or the team is above the limit.
The full method with the worked example: docs/prioritization.md.
Four readers
A backlog item used to have one reader. Now it has four, and they read differently.
Engineer
What to build and how to verify it.
Designer
The person's situation and what is out of scope.
Executive
The why and the number, in one sentence, without jargon.
Coding agent
Explicit intent, explicit boundaries and an explicit way to check its own work. It cannot walk over to your desk.
The test of a good item: can each of the four act on it without a meeting?
Twelve principles
Each one gives the rule, what it prevents, where it lives in the method, and who is making the same argument now.
-
Start from the number
An initiative names the outcome and the number it will move before anyone builds. No number, no initiative. There is a question to investigate instead.
MoreLess
- Prevents
- Output that feels like progress. Teams that used AI to accelerate their project model shipped more and improved nothing.
- In this method
frame-the-problemandwrite-prd: goal and success criterion with a number. The weekly review reads the number back.- Who is saying it
- Cagan's AI productivity paradox: the problem was never speed, it was that the ideas were not worth building. Hilary Gridley: "it's never been easier to run 10 times faster in the wrong direction."
-
Prototype to learn, spec to commit
Build prototypes to find out whether something could work and whether anyone wants it. Write the spec to record the decision, the boundaries and the success criterion. A prototype's assumptions are not requirements until someone writes them down and signs them.
MoreLess
- Prevents
- The prototype-as-spec failure: a convincing demo ships with its guesses intact, and the why is never written.
- In this method
prototype-to-speclists what a prototype settles and what it cannot.write-prdis deliberately short.- Who is saying it
- Cagan separates building to learn from building to earn. Aakash Gupta: the ten-page PRD died, the alignment PRD did not. Product managers at Affirm and Uber build their own prototypes. Lenny Rachitsky lists taste and judgment first among durable skills.
-
Write the why from the consequence of absence
The "why it exists" field starts with what happens if the item does not exist: to whom, how often, what it costs. If nothing happens, cut the item.
MoreLess
- Prevents
- Justification by feature: "we need a filter because users want to filter."
- In this method
why-it-exists, mandatory on Epic, Feature and Story.- Who is saying it
- Amazon's working-backwards practice, write the announcement first and then decide, is the older form of the same test.
-
Pass the four-reader test
An engineer, a designer, an executive and a coding agent must each be able to act on the item without a meeting. Direct sentences, one idea per item, no figurative language, no rule inside a rule.
MoreLess
- Prevents
- The item only its author understands. The agent that fills gaps with guesses.
- In this method
user-story-writing, seven rules.agent-brief.- Who is saying it
- Linear writes plain-language issues and calls user stories an anti-pattern; the shared point is clarity for the reader. Spec-driven development makes the spec the agent's persistent context.
-
Sequence by the chain, not by the score
Every slice crosses the stack and ships behavior a person can verify. Decide the appetite before you estimate; above size L you split. Then place Features in Now / Next / Later, score them by ROI impact, and pull every prerequisite of a Now Feature into Now with its inherited priority written. The go-live set, in dependency order, is wave 1, and every week has something demonstrable.
MoreLess
- Prevents
- The most valuable feature at the top of a list that cannot be built, because its two unglamorous prerequisites sit at the bottom. Layers that ship nothing. Estimates that become promises. A team that never finds its pace.
- In this method
decompose-spec,prioritize-now-next-later,execution-plan,capacity-simulation. The worked example: prioritization.md, and the live simulation.- Who is saying it
- Basecamp's Shape Up (appetite, scope hammering). The Now / Next / Later roadmap, popularized by Janna Bastow at ProdPad, as the alternative to dated roadmaps. DORA's findings on small batches. Cagan's building-to-earn phase expects commercial quality per slice, not a demo.
-
Structure serves navigation, not ceremony
Three levels, one fixed parent, dependencies as relations, effort in Story Points. Enabler work has no persona and does not invent one. Any section that does not help one of the four readers gets deleted.
MoreLess
- Prevents
- Fake users. Template filling. A backlog nobody can query.
- In this method
backlog-standard,epic-feature-story-templates.- Who is saying it
- Linear's minimal required fields (title, team, status). The sections here exist because four audiences and a weekly snapshot read them, not for their own sake.
-
For AI behavior, the acceptance criterion is an eval
When the behavior is probabilistic, acceptance is a threshold on a distribution: a golden set from real inputs, a scoring method, a pass rate agreed before the build, and negative cases that say what it must never do. If you cannot write the eval, the item is not ready.
MoreLess
- Prevents
- The feature that meets every criterion, passes CI, is right 92 times in 100, and becomes the top source of support tickets two weeks later.
- In this method
eval-cases.write-prdrequires an evals plan for AI parts. The Definition of Ready includes it.- Who is saying it
- Teresa Torres: defining correctness "is the product team's job"; prefer code assertions, then golden sets, then a model as judge. Rick Pollick: "Acceptance is no longer a checkbox; it is a threshold on a distribution." Critical Path: if you can't write the eval, you can't ship the feature.
-
Autonomy is earned, tier by tier
Observe, alert, propose, act with review, act alone. Promotion by evals on a held-out set and by shadow time, never by enthusiasm. Irreversible actions stay capped until the owner accepts the cost of an error in writing.
MoreLess
- Prevents
- The agent that sends the email on day one.
- In this method
- Boundaries Always, Ask first and Never in every spec. The ladder itself lives in agent-design-principles, skill
autonomy-tiers-and-evals. - Who is saying it
- Pollick on runtime guardrails for the tail. Torres on error analysis as a continuous habit. Microsoft's HAX guidelines and Google's PAIR guidebook on keeping people in control.
-
Bugs describe, they do not diagnose
A bug card records what the person saw, what the source said, what was expected, and where. It never asserts a cause. It links to the story whose behavior broke and asks for the origin of the data to be verified.
MoreLess
- Prevents
- Fixing the hypothesis instead of the defect. Blame.
- In this method
bug-report.- Who is saying it
- Standard incident practice. It matters more with AI features because the cause is often a data or prompt input nobody checked.
-
A roadmap is a dated photo, not a promise
Snapshot the backlog weekly with a cutoff, show the delta, and open the review with last week's commitments. The roadmap carries its photo date on every page.
MoreLess
- Prevents
- Roadmaps that promise dates no one re-derived. Reviews that re-litigate instead of advance.
- In this method
weekly-backlog-snapshot,backlog-review-meeting,roadmap-status,publish-roadmap.- Who is saying it
- Cagan's 2026 essays on predictable roadmaps versus outcomes. Linear on keeping product discussion at the feature level, not in the task.
-
Write for the agent in the room
Assume a coding agent will read the item and act on it. Give it the why, the acceptance criteria as verifiable checks, the Never list, and the verification command. Keep standing conventions in AGENTS.md or CLAUDE.md, not in people's heads.
MoreLess
- Prevents
- The agent that builds the wrong thing well.
- In this method
agent-brief. The repository's own AGENTS.md shows how the skills compose for an agent.- Who is saying it
- Spec-driven development: GitHub Spec Kit, Kiro's steering files, Claude Code's CLAUDE.md. Lenny Rachitsky: "First AI came for coding, next it's coming for deciding what to code."
-
Volume is not progress: delete nine
When the model offers ten PRDs, ten prototypes or a hundred tickets, pick one and delete nine. Measure the backlog by what it removed this week as well as what it added.
MoreLess
- Prevents
- The noise AI makes free: more documents, more tickets, more updates, no better decisions.
- In this method
- The weekly snapshot reports items removed. The review deck has a line for what was cut.
- Who is saying it
- Practitioner pushback in 2026 surveys of product managers. Chip Huyen, quoted by Cagan: "AI makes building easier, but the hardest part remains knowing what to build."
Twenty-one skills
Each skill is a folder with a SKILL.md that an AI coding assistant can load, and plain Markdown anyone can read.
| Skill | What it does |
|---|---|
| Write the items | |
backlog-standard | The standard: hierarchy, fixed parent, Story Points, Predecessor and Successor relations, Definition of Ready and Done. |
epic-feature-story-templates | Epic (11 sections), Feature (15), User Story (9), and what each section must contain. |
why-it-exists | The why field: starts from the consequence of the item not existing, in plain language. |
user-story-writing | Seven writing rules so a story needs no rules inside rules. |
spec-preview-html | The functional and technical spec as one readable page: a plain sentence per item, numbered sections, glossary, derived schedule. Live example. |
work-item-card | A five-second card for a task or a follow-up. |
| Plan and decompose | |
write-prd | The spec before any card or code, in gated phases. |
decompose-spec | Vertical slices with acceptance, verification, dependency and size. |
prioritize-now-next-later | Now / Next / Later with ROI impact and the enabling chain: every prerequisite of a Now Feature inherits Now, and the go-live set in dependency order is wave 1. |
capacity-simulation | Named people, weekly capacity, Fibonacci points, dependencies, a reserve for enabling work, and the week the Epic lands. Live tool. |
execution-plan | Spec to ready-to-load items, phases and a schedule derived from dependencies. |
bug-report | Lean bug cards that describe what happened and never assert a cause. |
| Run the cadence | |
sprint-planning | The planning layer: owner, points and sprint written back to the tracker. |
weekly-backlog-snapshot | A living document plus a frozen weekly snapshot with deltas. |
backlog-review-meeting | The weekly sponsor review, with two mandatory anchors. |
roadmap-status | The roadmap at the depth requested, from executive view to drill-down. |
publish-roadmap | Stakeholder formats from one source, versioned. |
| AI era | |
frame-the-problem | One page before any design tool: the problem, who has it, the evidence, the number, the appetite, what you are not doing. |
prototype-to-spec | What a prototype settled and what it cannot, so a demo never becomes a ticket. |
eval-cases | Acceptance criteria for AI behavior: golden set, scoring method, threshold, never-cases. |
agent-brief | An item a coding agent can build: the why, verifiable checks, the Never list, the verification command. |
Templates, the complete Acme example and the reasoning are in the repository.
Sources
Read in October 2026. Most are practitioner essays, not studies. The method takes their arguments, not their numbers.
- Marty Cagan, The AI Productivity Paradox, SVPG, July 2026. Also AI Product Management 2 Years In and The Product Operating Model.
- Teresa Torres, AI Evals: A Hands-On Guide for Product Teams, Product Talk, September 2026.
- Rick Pollick, Evals Are the New Acceptance Criteria, June 2026.
- Critical Path, If you can't write the eval, you can't ship the AI feature.
- Chen Ye Zhu, Golden Eval Sets: Behavioral Product Specs for Production GenAI.
- Aakash Gupta, AI killed the 10 page PRD. But the PRD isn't dead and The AI Product Operating Model.
- Lenny Rachitsky, the ten skills for the age of AI (January 2026) and "First AI came for coding, next it's coming for deciding what to code".
- Linear, Write issues, not user stories and the Linear Method.
- Product School, Product Management Trends: 11 Shifts Shaping 2026.
- LogRocket, Is the PRD dead? and How we replaced PRDs with AI prototypes.
- Uber Engineering, AI prototyping.
- David Haberlah, What 638 practitioner voices reveal about PMs' AI transformation.
- Spec-driven development: Spec-Driven Development in 2026, GitHub Spec Kit and Kiro, Kiro.
- Basecamp, Shape Up. DORA, research on software delivery.
- Microsoft, HAX Toolkit. Google, People + AI Guidebook.