Product Roadmap and Capacity Plan

Collect everything that competes for the team's time: the strategy deck, request backlog, sales asks, support tags, churn interviews and last year's roadmap. If the strategy is still open, settle it first in a product strategy document, and rank a long list with a RICE prioritization template before you plan.

Write each line as the result it buys, not the thing being built. Marty Cagan, founder of the Silicon Valley Product Group, points to a roadmap line that reads "integrate PayPal as an additional payment method"¹. It doesn't say whether the point is customers who can't pay another way, international payments, lower fees or keeping up with a competitor. Each would be judged by a different result.

Put the evidence beside each line, specific enough that someone could check it: a deal count, a support tag volume, a named incident. If there is none, leave the cell blank instead of restating the idea. A blank cell on a promised line tells you which promise to question first.

On a slide, a date promised to a customer looks just like a vague intention. Give every line one of four commitment levels, and use the same words every time.

Commit late. Cagan traces the grief over commitments to when they are made². "They are made too early," he writes, before the team knows it can deliver or that the result will solve the customer's problem. His fix is a little discovery first, then a date the team can commit to with confidence.

The team behind Basecamp, the project management app, is stricter still. In Shape Up, Ryan Singer's guide to how they build products, each six-week bet is a commitment, and they bet only one cycle ahead³. On your roadmap, the further out a line sits, the lower its level should be.

Lower a level as soon as you learn a line was never promised. Raise one only through a real decision, and record who made it, where and when. Silent upgrades are how roadmaps lose credibility.

In a 2006 paper in the Project Management Journal⁴, Bent Flyvbjerg builds on Daniel Kahneman and Amos Tversky's research. People, he writes, "underestimate the costs, completion times, and risks of planned actions."

He retells a story from Kahneman: a team writing a high school curriculum estimated 18 to 30 months. About 40% of comparable teams, one member recalled, had given up, and the rest took 7 to 10 years. This one took 8 years.

The fix Flyvbjerg describes is to forecast from "actual performance in a reference class of comparable projects." For a product team, the closest comparison is its own recent record. The Scrum Guide⁵ is blunter: "Only what has already happened may be used for forward-looking decision making."

Count finished items, not story points. The Kanban Guide⁶ defines throughput as "the number of work items finished per unit of time," measured as an exact count. Anyone can redo that count from a ticket export.

1. 1

   Export the last six periods

   Pull each team's closed items for the last six quarters or cycles, with close dates.

2. 2

   Count each item once

   Count it in the period it reached done. Leave out duplicates and anything withdrawn or rejected.

3. 3

   Split planned from unplanned

   Separate roadmap work from interrupts, such as incidents and urgent asks, and from work started then dropped.

4. 4

   Take three numbers

   Plan on the median, which one odd quarter barely moves. Promise against the lowest period, and use the best only to discuss upside.

Have the team estimate each line in the unit you counted: finished items. For each team and quarter, add up the estimates on Committed and Planned lines and divide by the median. The template's verdicts: Room at 0.8 or below, Tight up to 1.0, Over above 1.0 and Fiction above 1.5.

Don't subtract a guess for unplanned work. The team finished those planned items while handling interrupts, so the median already allows for a typical quarter's share.

Still, count interrupts in their own column. Quarterly surveys of Google's site reliability engineers put their average time on toil, the repetitive work of keeping services running, at about 33%⁷. Interrupts are its top source. Show your own interrupt share to anyone who wants to add more.

Note every line that can't start until something else finishes, and mark the dependency hard or soft. Hard means the work is impossible, or must be redone, without it. Soft means it ships anyway at a cost. Write that cost down, or readers will treat it as hard. Then look for two patterns:

• A committed line resting on something only planned or directional. Raise the dependency through a decision, or lower the line.
• A dependency on another team, due in the same quarter as the work that needs it. Move the dependency earlier or the dependent work later.

When a quarter is over capacity, decide what comes off now, not in its last month. Drop a line, lower it to directional so it stops counting, or move it to the next quarter after checking that quarter's ratio. Cut committed lines with no evidence first, and see whether two large items for one team can be split across quarters.

Slides get forwarded without their context, so write a short narrative to travel with yours. Cover what the quarter is for, what is committed and to whom, what is only planned or directional, what the capacity check found and what comes off next.

With the quarter settled, spec each committed line in the PRD template. To skip the counting, open this template in River and send your ticket export: it fills Delivery History and Capacity Check before it touches the plan.