Handbook
/
Product & Engineering
Prioritization Frameworks That Actually Work
You have infinite ideas and finite time. Here's how to decide what to build next without overthinking it.
Every startup has more ideas than capacity. Feature requests from users, technical debt to address, new directions to explore, bugs to fix—the list never ends. Without a clear way to prioritize, you either build the wrong things or spend all your time deciding instead of doing.
Here are frameworks that actually work for startups.
The Fundamental Question
Before any framework, ask: What is the one thing that would most move our key metric right now?
That metric might be:
•
Activation rate
•
Retention at Day 7
•
Revenue
•
NPS
•
Time to value
Focus on one metric at a time. Trying to optimize everything optimizes nothing.
Framework 1: ICE Scoring
Impact × Confidence × Ease
Score each factor from 1-10:
•
Impact: How much will this move the needle on our key metric?
•
Confidence: How sure are we about the impact estimate?
•
Ease: How quick and easy is this to implement?
Multiply the scores. Highest total wins.
Example:
Feature
Impact
Confidence
Ease
Score
Onboarding flow
8
7
5
280
Export to PDF
4
9
8
288
New pricing page
6
5
7
210
In this example, Export to PDF wins despite lower impact because high confidence and ease make it a safer bet.
When to use: Early-stage when you’re uncertain about impact and need to ship quickly.
Weakness: Scores are subjective. Calibrate as a team to maintain consistency.
Framework 2: RICE Scoring
Reach × Impact × Confidence / Effort
Similar to ICE but adds Reach:
•
Reach: How many users will this affect in a given time period?
•
Impact: On a scale of 0.25 (minimal) to 3 (massive), how much will this change behavior per user?
•
Confidence: Percentage confidence in your estimates (20%, 50%, 80%, 100%)
•
Effort: Person-weeks required
Formula: (Reach × Impact × Confidence) / Effort
Example:
Feature
Reach
Impact
Confidence
Effort
Score
Onboarding flow
1000
2
80%
4
400
Export to PDF
200
1
100%
2
100
Push notifications
500
1.5
50%
3
125
When to use: When you have data on reach and need to balance impact across user segments.
Weakness: More complex. Works better with actual user data.
Framework 3: Effort vs. Impact Matrix
Plot features on a 2×2 grid:
High Impact
|
Quick Wins | Big Bets
(Do First) | (Plan Carefully)
|
-------------------+-------------------
|
Fill-ins | Money Pits
(Do Eventually)| (Avoid)
|
Low Impact
Low Effort High Effort
•
Quick Wins (High Impact, Low Effort): Do these immediately
•
Big Bets (High Impact, High Effort): Plan and execute carefully
•
Fill-ins (Low Impact, Low Effort): Do when you have spare cycles
•
Money Pits (Low Impact, High Effort): Don’t do these
When to use: When you need a quick visual to facilitate team discussion.
Weakness: Doesn’t give numerical ranking. Good for rough sorting, not fine decisions.
Framework 4: Cost of Delay
Ask: What does it cost us to not have this feature?
Measure in dollars per week. A feature that costs $10K/week in lost revenue is more urgent than one costing $1K/week, regardless of development time.
This framework is particularly useful for:
•
Revenue-blocking issues
•
Competitive threats
•
Regulatory deadlines
•
Customer retention risks
When to use: When features have clear economic impact and time sensitivity matters.
Weakness: Hard to estimate cost of delay for features without direct revenue impact.
Framework 5: User Segment Priority
Different users have different importance:
1.
High-value retaining users – They pay you and stay
2.
High-value churning users – They pay but are leaving
3.
Activated but not paying – They use it but need conversion
4.
New users activating – They’re just getting started
5.
Potential users – They haven’t signed up yet
Prioritize features that help users higher on this list. A feature for retaining paying users usually beats a feature for acquiring new ones.
When to use: When choosing between features for different user segments.
Weakness: You still need other frameworks to prioritize within a segment.
Framework 6: One-Thing Focus
Skip the frameworks entirely. Ask: If we could only ship one thing this quarter, what would it be?
Commit to that one thing. Everything else is secondary.
When to use: When you’re drowning in options and need radical focus.
Weakness: Can miss important maintenance and small wins.
Making Frameworks Work
Involve the Team
Prioritization shouldn’t be top-down. Engineers often have insights into effort. Customer-facing teams understand impact. Collaborative scoring produces better results.
Time-Box the Process
Prioritization is useful; excessive prioritization is waste. Set a limit: 1 hour per week max on prioritization discussion. Then execute.
Update Regularly
Priorities change. Review monthly or when significant new information emerges. But not so frequently that you never finish anything.
Trust Intuition Sometimes
Frameworks are tools, not rules. Sometimes you have conviction about something that doesn’t score well. Test it. If your intuition is consistently wrong, trust the frameworks more.
Avoid Analysis Paralysis
When scores are close, just pick one. The difference between the top three options is usually less important than executing well on any of them.
Common Prioritization Mistakes
Feature Factory Mode
Building whatever users request without evaluating impact. Popular requests aren’t always high-impact.
Shiny Object Syndrome
Prioritizing new features over fixing existing ones. Sometimes the highest-impact work is making what you have work better.
Ignoring Technical Work
Excluding technical debt, refactoring, and infrastructure from prioritization. This work has impact too—usually on future velocity.
HiPPO (Highest Paid Person’s Opinion)
Letting the loudest or most senior voice override structured analysis. Use frameworks to democratize decisions.
Sunk Cost Bias
Continuing work because you’ve already started, even when priorities have shifted. It’s okay to stop things.
The Meta Framework
Here’s how to choose which framework to use:
•
Very early stage (pre-PMF): Use intuition + ICE. Speed matters more than precision.
•
Post-PMF, pre-scale: Use RICE or Cost of Delay. You have data to inform decisions.
•
Scaling: Use effort-impact matrix for quick decisions, RICE for quarterly planning.
•
Urgent situations: Cost of Delay. What’s the most expensive thing not to do?
Key Takeaways
•
Start with the key metric you’re optimizing—focus on one at a time
•
ICE (Impact × Confidence × Ease) is simple and works for early-stage
•
RICE adds Reach for more nuanced prioritization
•
Effort vs. Impact matrix is good for quick visual sorting
•
Cost of Delay works when features have clear economic impact
•
Involve the team, time-box the process, and trust intuition occasionally
•
Avoid feature factory mode, shiny objects, and ignoring technical work
AIMake has access to all of this
Our AI has access to the entire Startup Handbook. Ask it anything about building your startup.
Get started →
← Previous
Monitoring and Observability for Early Startups
Next →
Security Basics Every Founder Should Know