Outcome-based Roadmap

When a roadmap cell holds a feature name, only one thing can be judged at the end of the quarter: whether it got built. Ship all five cells and the quarter goes down as a success, and nobody asks what changed because of it.

Pagedeck closed a quarter exactly that way. Five items sat on a timeline roadmap, the format that pins dates onto a calendar, and all five shipped. When Grace asked what had improved, nobody in the room had an answer. The share of teams still around thirty days after signup was 30 percent, the same figure the quarter had started with.

The order was backwards. The team decided what to build first and attached a purpose afterward, so when a cheaper path to the same result appeared mid-build there was no basis for changing the cell. An outcome-based roadmap writes the result into the cell and leaves the method blank. Moving the share of surviving teams from 30 percent to 38 percent becomes the content of the cell, and the means of getting there stay changeable inside the quarter. The cell then survives a change of method, which is the whole point of writing it this way.

A cell opens with a number rather than a feature name, and four kinds of information sit under it. The number is what the quarter gets judged against, so it goes first.

1. The outcome sentence — the current value, the target value, and the deadline in one line. "Improve retention" is not an outcome sentence; "move the share of teams surviving to day 30 from 30 percent to 38 percent by the end of Q4" is. Retention is how much of your user base keeps coming back.
2. Why this number — two lines on how the cell connects to the company's headline figure. If the north star metric is weekly document editors, the note explains that surviving teams sit upstream of it.
3. The hypotheses — two or three candidate ways to move the number, each labeled as a candidate rather than a commitment. List rebuilding the first-week onboarding flow next to making team invites easier, and losing one of them doesn't shake the whole cell.
4. How it gets checked, plus interim markers — where the number is read and what has to be true partway through. A milestone is a checkpoint planted mid-course to confirm progress, and here it's written as a state rather than a date: by the end of August, the new onboarding flow is live for half of incoming teams. A date on its own can't be judged met or missed, and a state can.
5. Owner and confidence — who holds the cell, and the odds of hitting the target value this quarter as high, medium, or low. A low label is what keeps the cell from being read as a commitment.

One condition has to hold before a cell gets written. The team has to be able to move the number itself. If retention depends on ten different factors and only two of them sit with the product team, the cell mostly works to blur who is accountable. The owner still has to explain a quarter where the figure dropped because prices went up.

A product manager writes it and refreshes the numbers each quarter. A product manager is the person who decides what gets built and why, and stays accountable through launch. What gets revised is the hypothesis list; the outcome sentence doesn't change mid-quarter. Start lowering target values because the number won't move and the format loses its only safeguard.

Four groups read it, each looking at a different line.

1. The team building the work reads the hypothesis list. Because the methods are listed as candidates, there's room to propose a cheaper one. A two-day change can take the place of a three-week build without the cell being rewritten.
2. Leadership reads only the outcome sentence. It's the line Grace copies into board material. Even without feature names, what the company is buying this quarter is legible.
3. Sales and customer success find this format the most awkward. Customers ask about features, and the document holds numbers. So a separate rule usually rides along: only hypotheses marked high confidence get mentioned outside the company.
4. Organizations that also run goal-setting check the overlap with OKR, the practice of splitting a goal from the key results that confirm it. The same number showing up in two documents at two different values is a common outcome.

With four audiences, the format needs stakeholders — anyone affected by the result or able to affect it — walked through it once. Someone who opens the document expecting a feature list reads a cell of bare numbers as the absence of a plan.

"This quarter's cell is a number, not a feature. The goal is day-30 retention from 30 to 38."

What gets built is still open; what has to change has been settled.

"We never committed to that feature. We committed to the number, and we're looking at three ways in."

A correction: don't read items on the hypothesis list as a fixed plan.

"We can't move this number. Half of it sits with pricing."

The factors outside the team's hands are large enough that this makes a poor cell.

Pagedeck has run one cell this way since that review. Mia wrote the share of surviving teams as an outcome sentence and hung three hypotheses under it. Rebuilding the first-week onboarding flow moved the figure to 34 percent in six weeks. The other two were never started, and deleting them at the end of the quarter didn't count as a failure.

The most common reading is that the format means starting a quarter without deciding what to build. With no feature names in the cell, that's a fair assumption. In practice the hypothesis list makes the opening candidates clear, and the only difference is whether those candidates count as promises. Leave the misreading in place and the team spends the first two weeks of every quarter picking work.

The other common belief is that writing a number down creates accountability on its own. With a target value and a deadline attached, it looks that way. But accountability only works paired with control. Put a number the team can't move into a cell and what's left at the end of the quarter is an evaluation rather than a lesson. Accountability without control turns the cell into a place to assign blame.