The skill: Choosing what gets built, what waits, and what gets killed.
How to score and compare options
Start by framing items as problems, not features. "Reduce checkout friction" gives the team room to find the best solution. "Add Apple Pay" prescribes the answer before understanding the question. If your backlog is full of features, you've already narrowed the solution space before prioritization even started.
For quarterly roadmap decisions, score with RICE:
- Reach — users affected per quarter
- Impact — effect per user (0.25 to 3)
- Confidence — your certainty as a percentage
- Effort — person-months
- Score = (Reach × Impact × Confidence) / Effort
RICE works when you have data on reach and can estimate effort reasonably.
For weekly triage of smaller items — the "should we do this in the next sprint?" calls — use ICE:
- Impact — how much will this move the needle? (1-10)
- Confidence — how sure are we? (1-10)
- Ease — how easy is this to do? (1-10)
- Score = Impact × Confidence × Ease
Faster, lighter, good enough for decisions that don't need a spreadsheet.
The exact score never matters. What matters is that the framework surfaces the 2-3 obvious choices and discards the obvious bad ones. Then you apply delayed intuition — have a conversation, use your gut, and select among the shortlist the framework surfaced. Both frameworks have the same trap: they're only as good as your inputs. If you're guessing at reach and impact, you're dressing up opinions as math.
How to allocate across your roadmap
Instead of stack-ranking every project against every other project — a process that devolves into politics — allocate investment across slices.
Pick your primary slices and write down the ratio for each:
- Goals — user growth vs. retention vs. revenue (e.g., 50/50 growth vs. retention)
- User types — enterprise vs. self-serve (e.g., 70/30)
- Product pillars — core platform vs. integrations vs. new verticals
Then pick projects that fill each slice. Validate with secondary slices:
- New features vs. tech debt — what's the split?
- Riskiness — core bets vs. blue-sky experiments
- Marketing impact — does this give the go-to-market team something to work with?
When you write down your gut feeling about these proportions, getting team agreement becomes remarkably easy. You can nest it too — splitting "user growth" into 50/50 onboarding improvements and viral loops.
When allocating, ask one question most teams skip: does this item strengthen our ability to reach users, or just add product surface area? Elad Gil argues that post-product-market-fit, your distribution channel and customer base are your biggest assets — not your product backlog. A feature that deepens an existing distribution channel often beats a new feature that has no channel behind it.
Don't treat the roadmap as a contract. Treat it as a rolling bet you re-assess as the company changes shape. Gil observed that Google reorganized roughly every 6-12 months during hypergrowth. Your roadmap should reflect the same cadence of ruthless re-evaluation. Things should always feel tight — you should never feel like you have too many people, and should always feel like you have too few.
How to protect your focus
Every Monday, categorize your tasks into three buckets. Leverage tasks have disproportionate upside — give them your best effort and most creative energy. Neutral tasks need competent execution, then move on. Overhead tasks get minimum viable effort. Shreyas Doshi's observation: most PMs apply equal effort to everything and exhaust themselves on the wrong things. The discipline isn't working harder — it's knowing which tasks deserve your best thinking and which just need to get done.
If your team is working on 5 things simultaneously, they're finishing none of them. Limit work in progress. One bet at a time.
And check your backlog. A backlog with 200+ items is a graveyard, not a plan. If an item has sat untouched for 90 days, archive it. You can always bring it back. You won't.
How to break deadlocks and avoid theater
When you can't get consensus, Jeff Bezos's rule: "I know we disagree on this, but will you gamble with me on it?" The alternative — debating until everyone agrees — kills velocity. Bezos argues that most decisions only need about 70% of the information you wish you had. Waiting for 90% makes you slow. If you're good at course correcting, being wrong costs less than being late.
Before you prioritize anything, check whether your options are even worth doing. Amazon's "customer obsession" sounds like a platitude until you see how they operationalize it: every major product decision starts with a press release written from the customer's perspective. If the press release isn't compelling, the feature doesn't get built — no matter how well it scores on RICE. Prioritization frameworks compare options. They can't tell you whether any of the options matter.
Watch for prioritization theater. John Cutler observed that 90% of prioritization spreadsheets are faux rigor. Teams spend days scoring items, then override the results based on gut feel or stakeholder pressure. The spreadsheet becomes a rationalization tool, not a decision tool. Warning signs: horse-trading initiatives to placate stakeholders, sticking to the plan when new data says pivot, chasing utilization rates instead of impact. If the prioritization process takes longer than the actual decision, something is broken. The goal isn't a perfect spreadsheet. It's a force-ranked list of bets the team actually believes in.
Template
Do's and Don'ts
Written with ❤️ by a human (still)