Why Prioritization Is So Hard

The difficulty isn't technical — any spreadsheet can rank features. The difficulty is that prioritization makes tradeoffs explicit. Choosing feature A over feature B means the team working on A isn't working on B. People whose preferred feature isn't chosen feel their judgment isn't valued.

Most founders avoid this discomfort by maintaining vague roadmaps, promising everything is coming soon, and never fully committing to a clear order. The cost: engineering teams with no clear direction, stakeholders who can't plan, and products that grow in every direction without getting significantly better in any.

A prioritization framework gives you a defensible, transparent process. When you say no to a request, you can explain exactly why — with a scoring system, not just an opinion.

The RICE Framework

RICE is a practical scoring model that works well for early-stage teams:

• R (Reach): How many users will this feature affect per month?
• I (Impact): How much will this improve outcomes for those users? (Scale: 0.25 = minimal, 0.5 = low, 1 = medium, 2 = high, 3 = massive)
• C (Confidence): How confident are you in your Reach and Impact estimates? (Scale: 50%, 80%, 100%)
• E (Effort): How many engineer-weeks will this take?

RICE Score = (Reach × Impact × Confidence) / Effort

A feature that reaches 500 users, with medium impact (1), 80% confidence, requiring 2 weeks of effort: (500 × 1 × 0.8) / 2 = 200

A feature that reaches 2,000 users, with high impact (2), 50% confidence, requiring 10 weeks of effort: (2,000 × 2 × 0.5) / 10 = 200

Same score, very different features. The second is a bigger bet. The first is a more certain win. Context determines which to prioritize.

RICE isn't a perfect model — the inputs are estimates, and estimates can be biased. But the process of filling in the numbers forces honest conversations about assumptions.

The Tier System for Complexity

Not every roadmap decision needs RICE scoring. A simple tier system is often sufficient for early teams:

Must-do: Blocks users, breaks core functionality, creates legal/security risk. These go to the top of the queue regardless of scoring.

Should-do: High confidence, meaningful impact, reasonable effort. Core roadmap.

Nice-to-do: Low effort, moderate impact. Do these when capacity allows, don't sacrifice high-impact work for them.

Won't-do (now): Explicitly deprioritized. Document why. Prevents the same conversation happening every quarter.

How to Handle Sales-Driven Feature Requests

"We'll close the $200K deal if you just build this one feature" is one of the hardest prioritization scenarios. The feature may or may not align with your product direction. Here's a framework:

Is this feature strategic or tactical?

If the requested feature serves multiple users and fits your product direction, it deserves to be evaluated on its merits. If it's a bespoke customization for one customer, the question is whether the deal value justifies the engineering cost and the maintenance overhead.

Apply the $X = Y weeks formula. If the feature requires 6 weeks of engineering, what's the minimum deal size that justifies it? ($X per week of engineering cost × expected revenue over contract life). If the deal doesn't clear this bar, the math doesn't work.

Negotiate scope reduction. Often, customers need 20% of what they're asking for to get 80% of the value. Can you identify the minimal version of the feature that unblocks the deal?

Managing Stakeholder Expectations

The best prioritization process in the world doesn't help if stakeholders don't know how it works or feel excluded from it.

Share your prioritization framework with key stakeholders. "We score features using RICE and tier them into must/should/nice/won't" is transparency that builds trust. When someone's feature is deprioritized, they understand the process even if they disagree with the outcome.

Regular roadmap reviews (quarterly) with stakeholders give them a window to advocate for their priorities. Closing the feedback loop — "we considered this and here's why it scored the way it did" — is more relationship-building than most founders expect.

Prioritization is ultimately a judgment call. Frameworks make the judgment process more consistent and less political — but they don't replace the judgment.