Product roadmap and prioritization

Use this when the user hands over a backlog, a list of requests, or competing priorities, or asks what to build next. Also use it to run the periodic review of roadmap commitments against what actually happened.

What you need first

The candidate items, the goal they serve, any dates already promised, and the team's real capacity. No goal means you pick the sharpest one you hear and mark it INFERENCE. No effort sizes means you score with rough person-month bands and flag sizing as the first ask of the team.

Score, cut, order

1. Write each candidate as one line: the user, the job, the outcome. Anything you cannot phrase that way goes back to the user as a question, not onto the roadmap.
2. Score every item on reach, impact, confidence, and effort, the RICE model: score = (reach x impact x confidence) / effort. Reach is customers per cycle from real metrics. Impact is 0.25 / 0.5 / 1 / 2 / 3 on how much it moves the goal. Confidence is 100% / 80% / 50% on the estimates behind it. Effort is person-months across product, design, and engineering in whole numbers, minimum 0.5. Show the score and a one-line reason beside each, so the ordering can be argued with. Evidence grades stay in the reason line, not inside confidence.
3. Cut before you order. Kill duplicates, fold near-duplicates, and park anything that serves no goal. The cut list carries reasons, and nothing cut returns without new evidence.
4. Lay the survivors into now, next, and later. Now holds only what fits this cycle, with named owners. Later is not a graveyard: each item keeps the trigger that would promote it.
5. Check capacity against the team they named. If now exceeds it, say what drops and ask. Never silently overload the cycle.

Review the commitments

When the ask is a review rather than a fresh ordering: read the roadmap, the scored backlog, and the last review, and log what you could not reach. Open with one line — the period, and how many now-items shipped, slipped, or went quiet. Then three short blocks: shipped; slipped, with the reason and the new date; stuck, with the owner and the unblock ask. Score each commitment red, yellow, or green — a slip with no new date is red. Show the same fixed KPI table every time; never drop a metric because it looks bad. End with the forward half: asks, each a decision needed from a named person by a date, and three to five outcome-led commitments for the next period, plus the one call the period needs, written so the decision maker can answer yes or no. Keep a log of reviewed items so the same stuck thing is never re-flagged without saying what changed since.

Output

The scored list, the now-next-later roadmap with owners, and the cut list with reasons — saved dated. Report the top three and the first cut in the chat; the full sheet lives where the team reads it. File now-items as tickets only on a yes. A period where everything is on track is three lines saying so, not a report.

When the sizing is guesswork

Scores are not a hard rule: a dependency or a table-stakes bet may jump the order with a dated reason naming the trade-off. Never promise a date or a scope the decision maker did not approve, and never reorder silently after a review — every change gets a dated note.