Prioritization & roadmaps
TL;DR
Prioritization is the job reduced to one sentence: you have 10x more good ideas than capacity, and the order you build them in is the strategy. Frameworks — RICE, ICE, cost of delay, Kano — don't make the decision for you. They make your reasoning legible, so it can be challenged and improved. The roadmap that comes out the other side is a communication of bets and their sequence, not a delivery contract. That's why now / next / later beats a Gantt chart for most audiences. And because every "yes" is a hundred implicit "no"s, saying no — clearly, with the reasoning attached — is the most valuable sentence a PM produces.
🎯 For the AI PM
Why it matters — AI bets break naive scoring. Effort is uncertain by an order of magnitude (quality is discovered, not scheduled), and a demo makes reach × impact feel huge before feasibility is known. Meanwhile stakeholder pressure to "do something with AI" injects fake urgency into the inputs.
What it changes in your decisions — You score AI ideas with an explicit confidence discount until a feasibility spike has run, and you hold roadmap slots for eval and data work — the unglamorous items that never win a RICE bake-off but determine whether anything else on the list ships well.
Ask yourself — "Is this AI feature high on the list because the evidence is strong, or because the demo was?"
Risk if ignored — A roadmap of impressive-sounding AI bets, none de-risked, all late — while the boring fix that users actually begged for waits another quarter.
Strategy first: OKRs are the translation layer
A roadmap answers "in what order," but that question only has a stable answer once something upstream has already decided "toward what." That's product strategy: not a template filled out once, but an ongoing set of choices about which customer problems you'll go deep on and which you'll deliberately ignore. Good product strategy sounds like a stand — "we go deep on X, and we will not chase Y even though a customer asked for it" — a real choice with a cost, not an ambitious mission statement. It also operates at more than one altitude: company strategy sets which markets and bets the business plays, and product strategy inside it decides which problems your product specifically goes after. The two need to visibly connect, or a team optimizes a product strategy the company strategy doesn't actually reward.
OKRs are how that strategy becomes decidable at the roadmap level. The Objective restates the strategic bet in outcome language ("become the default choice for X"); the Key Results are the measurable proof the bet is paying off. Teams get the sequencing backward more often than not: OKR cycles should be set by strategy, not the place strategy gets decided. If your quarterly OKR-setting ritual is where the real strategic calls happen, you don't have a strategy — you have a quarterly negotiation. Set strategy on its own, longer cycle, revisited only when the market or evidence genuinely changes, and let OKRs cascade from it every quarter. When a proposed Key Result doesn't trace back to a strategic choice you can name out loud, that's the signal to cut it from the roadmap — regardless of how well it scores on RICE.
Frameworks: engines for arguments, not answers
- RICE — score = (Reach × Impact × Confidence) / Effort. Its real value is the Confidence term: it forces you to admit which numbers are guesses. A 10/10 impact at 20% confidence should lose to a 6/10 at 90%.
- ICE (Impact, Confidence, Ease) — RICE's quick cousin. Fine for triaging a long list in an hour, too coarse for the final call on big bets.
- Cost of delay / WSJF — asks "what does waiting cost per month?" instead of "what is this worth?" This flips priorities when timing matters: a medium-value item ahead of a compliance deadline outranks a high-value item that's worth the same next year. Dividing cost of delay by duration (WSJF — weighted shortest job first) formalizes "do the quick valuable things first."
- Kano — separates basic features (absence infuriates, presence goes unnoticed), performance features (more is linearly better), and delighters (unexpected joy). The original model adds two more: indifferent (the user doesn't care either way — a signal to cut) and reverse (the feature actively annoys a segment — a signal to gate or remove). Its lesson: a product of pure delighters with a missing basic still fails. Check your top ten for uncovered basics before celebrating the delighters, and check for reverse features before assuming more is better.
All of them share failure math: garbage estimates in, confident-looking garbage out. The discipline isn't the arithmetic. It's writing your assumptions down where someone can tell you they're wrong.
Where the roadmap fights happen · a feasibility spike moves the dot
Cheap discovery work exists to reposition expensive bets before you commit.
do now
do few, de-risk first
say no
batch when idle
Same feature, two dots: the AI summarizer's effort estimate tightens dramatically once a feasibility spike has actually been tried — cheap discovery repositions expensive bets before you commit.
Note the summarizer appearing twice. A feasibility spike doesn't just reduce risk — it moves the dot. Effort estimates tighten dramatically once someone has actually tried it. Cheap discovery work exists to reposition expensive bets before you commit.
Roadmaps are bets, not promises
A roadmap does two jobs at once — aligning stakeholders and guiding the team — and the classic mistake is using one artifact for both:
- Now / next / later — the default for most audiences. Now is committed and specific. Next is planned but re-orderable. Later is directional. The buckets encode honesty about certainty, which date-based roadmaps destroy: paint a feature on Q3 and by Friday it's a commitment someone sold to a customer.
- Outcome-based roadmaps — organize by the problem or metric ("cut onboarding drop-off by 30%") rather than the feature. Harder to write, but they preserve the team's freedom to change solution without appearing to change plan.
- Date-based roadmaps — legitimate when dates are real: compliance deadlines, contractual commitments, coordinated launches. Use dates where dates exist. Don't invent them for decoration.
Whatever the format, reserve explicit capacity before feature prioritization begins: a platform/debt allocation (teams commonly hold 15–30% — see tech debt) and, on AI products, an eval/data line item. Debt never wins a head-to-head RICE contest against a shiny feature. That's precisely why it gets a reserved lane instead of a lottery ticket.
Saying no
Every framework ends at the same human moment: telling someone their thing didn't make the cut. The craft:
- Say no to the idea, yes to the problem — "we're not building custom dashboards this quarter, but the underlying reporting pain is real and here's where it sits on the list."
- Show the trade, not just the verdict — "for this to be now, one of these three things moves out. Which?" moves the argument from whether you care to what it displaces — which is the actual decision.
- Write it down — a visible, reasoned not-now list. Re-litigating the same request monthly because the reasoning evaporated is pure waste.
Failure modes
- Framework laundering — tuning RICE inputs until the spreadsheet blesses the thing you'd already decided. Everyone can tell.
- The peanut-butter roadmap — spreading capacity thinly over everything so no bet gets enough to actually win. Prioritization means concentration.
- Roadmap as contract — shipping the Q3 painting instead of responding to what you learned in Q2. The map ate the territory.
- Demo-driven prioritization — AI bets jumping the queue on wow-factor, with confidence never revisited after the applause.
- Loudest-voice allocation — priority by stakeholder volume. A framework's real political function is giving you something to point at that isn't a person.
- OKR theater — Key Results invented each quarter to fill a template, disconnected from any strategic choice you could defend. The roadmap ends up organized by whichever KR sounds most measurable, not by what the strategy actually needs to be true.
Practitioner checklist
- For my top five items: can I state reach, impact, confidence, and effort — and which of those numbers are guesses?
- Does anything urgent-by-timing (cost of delay) deserve to jump the value ranking?
- Are the basics covered (Kano) before the delighters?
- Does the roadmap encode certainty honestly (now/next/later) — and has debt/eval capacity been reserved off the top?
- Can I name the last significant thing I said no to, and does the requester know why?
- Can I trace each roadmap Key Result back to a specific strategic choice I could defend out loud — not just an ambitious number?