Capstone: one decision, end to end

Two minutes of setup saves ten minutes of hesitating, and both of these are decisions you should make now rather than at minute forty when you are invested:

• Pick the item, and pick the hard one. The best candidate is the backlog item that has been argued about more than twice and decided zero times, which is exactly the one you wrote down in b1. If you have drifted to an easier item since then, drift back. An item that has never been argued about will pass all five checkpoints and teach you nothing, because nothing about it was ever contested.
• Get the evidence in front of you before you start. Whatever exists: the ticket counts, the interview notes, the dashboard, the email where somebody asked for it. You are not going to gather new evidence in the next hour. Checkpoint 1 and checkpoint 2 are largely about finding out how little you actually have, and that finding is one of the more valuable outputs of the session.
• Decide now what you will do with an empty field. The answer is: write "unknown" and size the work to find out. Do not fill it in with something plausible, and specifically do not fill it in with a drafting tool. An empty field is a research task with a size; a plausible field is a decision you did not know you made.

The order is not arbitrary and it is not just the order of the sessions. Each checkpoint produces the input the next one silently requires, which is why skipping one does not save time so much as move the failure later:

• Without checkpoint 1, checkpoint 4 has nothing to rank. You cannot compare two asks stated in different units, and "what should we build" without an evidenced problem underneath is a conversation about who is most senior.
• Without checkpoint 2, checkpoint 1 is an assertion with a number in it, which travels further than an assertion without one and is not better.
• Without checkpoint 3, checkpoint 4 has nothing to decide about. A spec is where the scope, the exclusions and the trade-off actually live, and you cannot cost a decision whose boundary is undefined.
• Without checkpoint 5, everything above it is unfalsifiable. A decision with no metric cannot be wrong, so nothing you learn this quarter feeds the next one.

The order also matches the order in which things get expensive. Fixing a problem statement costs ten minutes. Fixing a missing metric after the build costs a quarter. Everything in this hour is arranged so that the cheap corrections happen first.

Six failures that show up every single time this session is run. None of them is carelessness. Each is a reasonable instinct arriving at the wrong moment:

• The comfortable item. Halfway through checkpoint 1 you notice the item you chose is genuinely contested and swap to a cleaner one. That is not a change of subject, it is the exercise working, and swapping is how you spend an hour confirming something you already knew.
• Filling the empty field. A reach number is missing, so you put a plausible one in. Ten minutes later it is a score, twenty minutes later it is a ranking, and by checkpoint 4 an invented number is carrying your decision. Write unknown. Size the work.
• The 70-point spec. Four checks pass, you feel good, and the remaining two need you to give something up. Almost everybody stops here on the first pass. Stopping at 70 is not a partial success, it is the specific failure b5 exists to name.
• Marking effort instead of artifact. "I thought hard about the segment" is not a named segment. The checklist asks what is on the page, and you will be tempted to answer with what is in your head.
• Drifting into delivery. Around checkpoint 5 the hands start reaching for a plan: phases, sequencing, who does what by when. It feels like progress because it is progress on a different job, and it will eat your last fifteen minutes.
• Polishing. The written thing gets better and the decisions in it do not change. Fluency is the easiest thing to add in this hour and the only thing that is worth nothing at all, which is the whole argument of the course applied to your own afternoon.

Most people fail at least one of the five on the first run, and the most common is checkpoint 2, because most backlog items are carrying either no research or one memorable conversation that has been quoted so often it feels like several.

A failed checkpoint you can name is a research task with a size attached, which is a genuinely useful output. "Checkpoint 2 failed: my only evidence is one call with our largest account, and I have been treating it as a theme for four months" is a better result from this hour than five soft passes. It tells you what to do on Monday, it takes one sentence to explain to your team, and it converts a stuck argument into a piece of work.

What is not useful is a generous pass. The bar exists because the alternative to marking yourself honestly is not a slightly kinder mark; it is a decision that gets finished later by whoever hits the gap first, in whichever direction suits them, without telling you.

A solution wearing a problem's clothes reads exactly like a problem statement. It has a who, it has a pain verb, it sounds like discovery. "Team admins need a way to export their meeting summaries to the CRM" is the shape of a problem and the content of a solution, and the giveaway is that it contains the answer.

Two tests, both fast:

• The alternatives test. Can you name three genuinely different ways to address this statement? If the statement only admits one solution, it is that solution. "Admins cannot tell their account team what was agreed without retyping it" admits at least four approaches. "Admins need a CRM export" admits one.
• The noun test from the steps above. Strike the buildable nouns and see what is left standing. If the sentence collapses, you were describing a feature.

The reason this matters at checkpoint 1 rather than later: a solution stated as a problem will pass every subsequent checkpoint. You will find evidence for it, spec it beautifully, decide in its favour and instrument it properly, and at no point will anything in the process tell you that the alternatives were never considered, because they were excluded in the first sentence before anybody was paying attention.

This happens more often than the neat version of product management admits, and it is not a failure of this checkpoint. Roughly a third of carried backlog items turn out to have no countable signal behind them at all, which is itself the most decision-relevant thing you will learn in this hour.

Write the field as unknown, then write one line on how you would fill it and what that would cost. "Unknown. Support could tag this for two weeks and tell me whether it is 5 tickets or 200, which is an afternoon of their time." That sentence turns a stalled argument into a small, cheap, assignable task, and it is a far stronger position than a plausible number nobody can source.

What you must not do is let a drafting tool supply the number. It will, immediately, with confidence and a plausible order of magnitude, and from that moment the item is indistinguishable from a well-evidenced one anywhere downstream.

The anecdote that gets promoted is never the weakest evidence you have. It is usually the most emotionally legible: a named customer, a specific moment, a sentence you can quote in a meeting and watch land. It travels because it is good communication, and it survives because nobody ever asks the second question.

Two review questions kill it politely, and they are the two from b3 that you should be running on yourself here:

• "How many people said this?" A theme has a number. If the honest answer is one, you have an anecdote, and saying so costs you nothing because anecdotes are allowed to exist.
• "Can you show me one of them saying it?" Applied to yourself, this catches the theme that emerged from your own synthesis rather than from anybody's mouth. Those are the ones that read as the most insightful lines in the document, and they are the ones with no verbatim underneath.

The specific hazard when a tool did the synthesis: an over-generalised theme has a real quote attached, so it survives the second question and dies only on the count. That is why the count goes in the line rather than in a footnote. It is the only one of the four rules that a fluent restatement cannot survive.

Verifying is slower than synthesising, always, with no speed-up available anywhere. Ten minutes is deliberately not enough time to verify a real body of research, and the purpose of the box is to make you find out how much verification your carried item has never had.

So spend the ten minutes on the strongest theme rather than spreading it across all of them. Verify one properly: count it, find the verbatim, read the verbatim, label the claim. Then mark the rest as unverified, which is accurate. A document with one verified theme and three honestly flagged as unverified is more useful to a reader than four themes of unknown provenance, and it is the version you can defend in a review without preparing.

The ladder in b5 goes 15, 35, 55, 70, 100, and the gap between 70 and 100 is not a gap in effort. Rungs 1 to 4 are all fixed by supplying information: research, metric definitions, constraints. Every one of them makes the document more complete without asking anybody to lose anything. The last rung is different. Non-goals and the explicit trade-off are the two checks that require somebody to give something up, which is why they survive four rungs of a very capable drafting process and why they survive your first pass too.

Three prompts that get you over it, in ascending order of discomfort:

• "What will somebody assume is included that is not?" The gentlest entry into non-goals, because it is a question about other people's expectations rather than about your ambition. Whatever comes to mind first is a non-goal, and it should be written in the words the person would use.
• "What am I choosing this over?" Not what am I not doing in general, but what specific alternative is losing. There is always one, even when the item looks uncontested, because the alternative is at minimum the next item on the list.
• "Who is worse off if this ships, and what will I say to them?" The one that finishes the trade-off. If you cannot answer the second half in the words you would actually use, the decision is not made yet. This is b6's test for a real decision and it is unforgiving on purpose.

And a warning about the score itself: 100 out of 100 certifies that six decisions were made and written down. It does not certify that they were good ones. A perfectly complete spec for the wrong problem scores 100, which is why checkpoints 1 and 2 come first and why the signable test is the real bar.

Common, and not a problem for this checkpoint. You do not need a document; you need four sentences, and four sentences is fifteen minutes of work rather than an afternoon:

• Who this is for, in the segment language from checkpoint 1.
• What success is, as a number with a baseline, even if the baseline is a placeholder until checkpoint 5.
• What we are not doing, as a list of at least three things somebody would otherwise assume.
• What we chose this over, and who loses by it.

Those four sentences are most of a spec, and they are the four that a drafting tool will not produce for you because none of them is a writing problem. Everything else in a PRD is context arranged around them, and it can be produced in a minute once these exist.

Run one diagnostic on your own scoring before you trust it. Look at every confidence value you wrote. If they all sit between 0.7 and 0.9, nobody scored confidence - somebody scored enthusiasm, and that somebody was probably you, and it is a completely normal thing to have done.

Real confidence values are lumpy, because real evidence is lumpy. Two independent signals agreeing buys you a high number. One unverified signal from an interested party buys you a middling one. No evidence at all buys you a low one, and writing 0.25 next to something a senior person asked for is one of the more uncomfortable things in this hour and one of the more valuable.

The fix is not to argue about the decimal, it is to state the basis instead of the number. "0.8, two independent signals" and "0.8, it feels likely" occupy the same cell and are entirely different claims, and only one of them survives being read out loud in a review. Write the basis in the cell next to it, and the conversation about whether the number is right becomes a conversation about what would raise it, which is a much shorter conversation with an action at the end.

Every cut you make in this checkpoint needs a condition attached, stated concretely enough that the person who lost could go and satisfy it. A no with a condition is a deal. A no without one is a door, and people spend entire quarters pushing on doors.

The condition has to be checkable by somebody other than you, and it has to be something they can actually do. "If we see more demand" is not a condition; it is a way of ending the conversation. "Three logged losses on workspaces over twenty seats, with the competitor named, and it comes back into the next planning cycle" is a condition, and it converts an argument about priorities into a small piece of work that either happens or does not.

Write yours down now, while you still remember why you cut the thing. In eight weeks you will remember the decision and not the reasoning, and a cut whose reasoning has evaporated is functionally the same as no decision at all.

The trap here is subtle because the metric that fails it is usually the best metric. The thing you actually want to measure is often something that happens in a person's head or on their desk: how long it took them to find an answer, whether they trusted the output, whether they stopped doing the manual workaround. None of that is a product event.

Three honest responses, and one dishonest one that you should watch yourself for:

• Pick the closest observable proxy and label it a proxy, in the spec. Then the gap between the proxy and the thing is a known limitation rather than an ambush at the readout.
• Add a cheap direct instrument alongside it. A one-question in-product pulse, or five interviews booked for the week of the readout. Weak evidence you have labelled weak beats strong evidence about the wrong thing.
• Accept that some outcomes are measured by research rather than analytics, and put that research on the calendar next to the read date rather than hoping for it.
• The dishonest one: pick the proxy and then talk about it as though it were the real thing. That is how a team ends up defending a number instead of a goal, and it is almost never done deliberately.

Then ask the question that closes this checkpoint: could an engineer start building the instrumentation tomorrow from what I have written? If the answer is no, you have a metric in principle, which is a metric you will not have.

It is thirty seconds of extra work and it is the highest-leverage sentence in the entire hour: the metric, the threshold, the date, and the action on each side including the side where you stop.

"If the number has not reached X by date Y, we stop and do Z instead." Write it now, while nobody knows which way the number will go, and put it somewhere a stakeholder will read it while the threshold is still uncomfortable. A rule that lives only in your head is not a rule, it is a memory that will be revised by whatever the number turns out to be.

Then write the action on the losing side concretely enough that a disappointed person could execute it without a meeting. "We reallocate the two weeks to interviewing the accounts that did adopt it" survives a bad Monday. "We will reconsider our approach" does not survive lunch.

The line sits at the decision because that is where accountability changes hands, not because of any organisational chart. Everything before it answers "is this the right thing to build, and how will we know". Everything after it answers "how do we get it built on time". Those are different questions, they are answered with different evidence, and the people who are good at one are frequently mediocre at the other.

Three practical consequences of holding the line:

• You stop being the bottleneck on sequencing. If the delivery team owns the plan, they can resequence when reality changes without asking you, provided they have your trade-off and your cut order. That is the actual output they need from you, and it fits on a page.
• Your artifacts stay checkable. A spec and a metric definition are things somebody can disagree with on the evidence. A milestone plan produced by a PM who is not doing the work is a set of estimates with no basis, and it will be treated accordingly and then quietly replaced.
• The handover has a receipt. The packet is a real thing that either exists or does not, which means the conversation about whether product did its job stops being about impressions.

If your organisation genuinely expects you to do both jobs - and plenty do - then do them both, and know which one you are doing at any given moment. The failure is not the combination. It is doing the delivery half in product's language, where estimates get treated as commitments and a Gantt chart gets read as a decision.

• Day one: put the six checks at the top of your spec template, not the bottom. At the bottom they are a review step that gets skipped when you are busy. At the top they are a prompt, and they change what gets written rather than what gets caught. This takes four minutes and it is the single highest-return thing on the list.
• This week: ask the two polite questions in one review that is not yours. "What are we not doing here?" and "how will we know it worked?" Neither reads as an attack, both are just checks 4 and 3 asked kindly, and a team that gets asked them twice starts writing the answers into the spec beforehand. That is the whole mechanism of the change, and it does not require any authority.
• Before the next thing gets approved: fix the read date and the baseline. One calendar invite, with the audience already on it, on the date the number gets read. Then find out what the number is today. Those two acts together are what convert a build into a bet, and they cost an afternoon of somebody's time exactly once.

Notice what is not on this list: a new framework, a template rollout, a process proposal, or a document explaining the course to your team. All four are things people do in week one and none of them survives to week six, because they ask for a decision from somebody who has not felt the problem. The three above ask for nothing from anybody and are visible immediately.

Whichever checkpoint you marked as a fail is the most useful output of this hour, because it is specific, it is yours, and it comes with a next action already attached.

If it was checkpoint 1, your item is a solution and the whole argument has been about implementations of an answer nobody agreed on. Take it back to the alternatives test with the person who asked for it, which is a fifteen-minute conversation and usually a surprising one.

If it was checkpoint 2, you have a research task with a size. Say the size out loud: two weeks of tagging, or five calls, or one afternoon with the dashboard. A named, sized task competes for time. "We should do more research" does not.

If it was checkpoint 3, write the four sentences. Who it is for, what success is as a number, what you are not doing, and what you chose it over. Fifteen minutes, and you will have most of a spec plus the two decisions you had been deferring.

If it was checkpoint 4 or 5, the fix is a conversation rather than a document: one with the person who owns the estimate you invented, or one with whoever can pull the baseline. Both are short, both are cheap, and both are much easier to have before the build than after it.