Prioritization Frameworks

Why prioritize?

You have infinite ideas and limited time. Without prioritization:

• You work on whatever feels urgent today
• Important-but-not-urgent work never happens
• You build features nobody uses
• You never finish anything because you’re always starting something new

Prioritization means deciding—consciously—what matters most.

Impact/Effort matrix

The simplest framework. Plot features on two axes:

                High Impact
                    │
    Quick wins ─────┼───── Big bets
    (Do first)      │      (Plan carefully)
                    │
    ────────────────┼────────────────────
       Low Effort   │      High Effort
                    │
    Fill-ins ───────┼───── Money pits
    (Do if time)    │      (Probably don't)
                    │
                Low Impact

How to use it

1. List your features/ideas
2. Estimate impact (user value, business value)
3. Estimate effort (time, complexity)
4. Plot them
5. Work top-left (quick wins) first

Example

Do first: Password reset Plan for later: Real-time collaboration Skip or defer: Custom themes

RICE framework

More structured scoring: Reach × Impact × Confidence ÷ Effort

Components

Reach: How many users affected in a time period?

• “500 users per month will use this”

Impact: How much does it help each user?

• 3 = Massive impact
• 2 = High
• 1 = Medium
• 0.5 = Low
• 0.25 = Minimal

Confidence: How sure are you about reach and impact?

• 100% = High confidence (data-backed)
• 80% = Medium (some data)
• 50% = Low (mostly guessing)

Effort: Person-weeks (or hours, or days—be consistent)

Formula

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

Example

Priority order: Onboarding > Export > Mobile app

When to use RICE

• Comparing many features
• Need to justify priorities to stakeholders
• Want to reduce gut-feel bias
• Team disagrees on what matters

ICE framework

Simpler than RICE: Impact × Confidence × Ease

Each on a 1-10 scale. Multiply them.

When to use: Quick prioritization, smaller backlogs, early-stage products.

MoSCoW method

Categorize, don’t score:

• Must have: Without this, the release/product fails
• Should have: Important but not critical
• Could have: Nice to have if there’s time
• Won’t have: Explicitly out of scope (this time)

Example: MVP for task app

Build order: All Musts → Shoulds → Coulds if time remains

When to use MoSCoW

• Defining MVP scope
• Release planning with hard deadlines
• When you need to cut scope
• Communicating priorities to stakeholders

Cost of Delay

When timing matters: what do we lose by waiting?

Types of delay cost

Linear: Every week of delay costs the same

• Example: A feature that brings $1K/week revenue

Exponential: Cost increases over time

• Example: Compliance deadline—minor now, critical later

Fixed deadline: Worthless if late

• Example: Conference demo, tax season feature

Peak opportunity: Value decays after a point

• Example: Holiday shopping feature

Using cost of delay

Calculate: Cost of Delay / Duration (CD3)

Priority: Payment fix = Compliance > New feature

When to use

• Time-sensitive decisions
• Revenue-impacting features
• Compliance/deadline work

Kano model

Categorize features by customer satisfaction impact:

Must-haves (Basic): Expected. Missing = angry customers. Present = neutral.

• Example: App loads, login works

Performance (Linear): More = better. Direct correlation to satisfaction.

• Example: Speed, storage space

Delighters (Excitement): Unexpected positive. Absence doesn’t hurt.

• Example: Smart suggestions, delightful animations

Indifferent: Users don’t care either way.

• Example: Backend refactoring (invisible to users)

Reverse: Some users actively dislike this.

• Example: Forced tutorials, aggressive upsells

Prioritization implication

1. Must-haves first: You can’t delight users who can’t log in
2. Then performance: Improve core value
3. Then delighters: Differentiate from competitors
4. Skip indifferent: Unless technically necessary
5. Avoid reverse: Unless data proves you wrong

Weighted scoring

Create your own scoring system:

1. Define criteria (impact, effort, strategic fit, risk)
2. Assign weights (importance of each criterion)
3. Score each feature
4. Calculate weighted total

Example

When to use

• Complex decisions with multiple factors
• Need to balance competing priorities
• Want to make tradeoffs explicit

Anti-patterns in prioritization

HiPPO (Highest Paid Person’s Opinion)

Priorities set by whoever has most authority, not best judgment.

Fix: Use frameworks. Make reasoning explicit. Gather input.

Squeaky wheel

Whoever complains loudest gets priority.

Fix: Aggregate feedback. One loud user ≠ common problem.

Recency bias

Whatever was mentioned most recently feels most important.

Fix: Review the full backlog, not just new items.

Sunk cost fallacy

Continuing features because you’ve already invested, not because they matter.

Fix: Evaluate current value, not past investment.

Analysis paralysis

Spending so long prioritizing that you don’t build anything.

Fix: Time-box prioritization. Good enough beats perfect.

Quick prioritization for solo builders

Don’t need complex frameworks? Try this:

1. List everything you could build
2. Ask for each item: If I could only ship one thing, is this it?
3. Force rank the top 5
4. Work on #1 until done
5. Re-evaluate when done

That’s it. Simple, effective.

Making prioritization stick

• Write it down: Priorities you forget aren’t priorities
• Review regularly: Weekly or per-sprint
• Say no explicitly: “Won’t” list is as important as “Will” list
• Revisit assumptions: Priorities change as you learn

Further reading

• How to slice work effectively : Break priorities into deliverables
• When to say no : Declining features and requests
• Product discovery techniques : Understand what to prioritize
• Technical decision making : Choosing how to build priorities