Feature Prioritization for Indie Hackers: The RICE Framework

Introduction

Prioritization is the most underrated skill for indie founders. Without a systematic approach, it’s easy to fall into the “shiny feature” trap—building what excites you instead of what moves the needle for your business.

RICE (Reach, Impact, Confidence, Effort) is a lightweight prioritization framework developed by Intercom that helps you make data-driven decisions about which features, improvements, and experiments to build next. Unlike gut-feeling decisions, RICE gives you a quantitative score that’s easy to explain and compare across your product roadmap.

This framework is particularly valuable for indie hackers and small teams because:

• It requires no complex tools or spreadsheets
• It forces you to think critically about assumptions
• It reveals hidden biases in your decision-making
• It’s adaptable to any product or service

What is RICE?

RICE is an acronym for four key variables in the prioritization formula:

Reach

Definition: The number of people who will be affected by this feature or experiment within your chosen time period (typically a quarter or 3 months).

How to estimate it:

• Count active users impacted by the change
• Consider user segments (e.g., “200 enterprise customers” vs “15,000 free-tier users”)
• Be specific: avoid vague estimates like “many” or “most”
• Time-bound it: “How many in the next 3 months?”

Example: If you’re adding dark mode and 40% of your 10,000 monthly active users have requested it, your reach is approximately 4,000 users.

Impact

Definition: How significantly this change will affect each individual user. It measures the magnitude of the effect on the user’s satisfaction, productivity, or value gained.

How to estimate it (use a scale):

• 3 = Massive impact (transforms user experience, solves critical pain point)
• 2 = High impact (significantly improves workflow or satisfaction)
• 1 = Medium impact (noticeable improvement but not game-changing)
• 0.5 = Low impact (nice-to-have, minor convenience)
• 0.25 = Minimal impact (edge case, very small effect)

Example: A faster search feature might be 2 (high impact) because it saves time on a frequent task. A new color theme might be 0.5 (low impact) because it’s aesthetic but doesn’t change functionality.

Confidence

Definition: How confident you are in your Reach, Impact, and Effort estimates, expressed as a percentage (0–100%).

Confidence levels:

• 100% = Certain (based on data, past experiments, or strong evidence)
• 80% = High confidence (educated guess with reasonable assumptions)
• 50% = Medium confidence (uncertain, some assumptions may be wrong)
• 25% = Low confidence (very speculative, lots of unknowns)

Why it matters: A feature with high reach/impact but low confidence (e.g., 25%) gets heavily discounted. This prevents you from over-investing in risky bets.

Example: If you surveyed users and 80% said they want feature X, your confidence might be 80%. If a cofounder just mentioned they’d like it, confidence might be 25%.

Effort

Definition: The total amount of work required to build and ship the feature, measured in person-weeks.

How to estimate it:

• 1 person-week = 40 hours of focused work
• Include design, development, testing, and deployment
• Account for your team’s velocity and context-switching
• Be realistic: add buffer for unknowns

Example:

• Tweaking a button color: 0.25 person-weeks
• Adding a new filter to your dashboard: 1 person-week
• Rebuilding your authentication system: 4 person-weeks

The RICE Formula

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

How it works:

• The numerator (Reach × Impact × Confidence) represents the expected value of the feature
• The denominator (Effort) normalizes for how much work it takes
• Higher scores are better—features that deliver more impact with less work

Example calculation:

• Reach: 5,000 users
• Impact: 2 (high)
• Confidence: 80% (0.8)
• Effort: 2 person-weeks

RICE Score = (5,000 × 2 × 0.8) / 2 = 8,000 / 2 = 4,000

Compare this to another feature:

• Reach: 500 users
• Impact: 3 (massive)
• Confidence: 40% (0.4)
• Effort: 3 person-weeks

RICE Score = (500 × 3 × 0.4) / 3 = 600 / 3 = 200

The first feature scores 4,000 vs 200—you should prioritize it first despite lower impact, because it affects far more users with acceptable confidence.

How to Use RICE: Step-by-Step Guide

Step 1: List Your Features and Experiments

Create a backlog of everything you’re considering:

• New features your users are requesting
• Product improvements or optimizations
• Experiments to test hypotheses
• Technical debt or infrastructure improvements
• Bug fixes affecting many users

Pro tip: Limit this to 10–20 items per planning session. Too many options dilute focus.

Step 2: Estimate Reach, Impact, Confidence, and Effort

For each item, have 1–2 team members estimate independently, then discuss:

Step 3: Calculate RICE Scores

Use a spreadsheet, simple tool, or even pen and paper. The math is straightforward.

Step 4: Rank and Review

Sort by RICE score (highest first). But don’t blindly follow the ranking:

• Sanity check: Does the ranking match your intuition? If not, dig deeper.
• Strategic alignment: Do top-scoring items align with your business goals?
• Risk management: Are you balancing quick wins with bigger bets?
• Dependencies: Do some items depend on others?

Step 5: Commit to Your Top Items

Pick the top 3–5 items for your next sprint, build window, or quarter. Document assumptions so you can revisit them later.

Practical Examples

Example 1: SaaS Product

Scenario: You run a project management tool with 5,000 active users.

Decision: Start with recurring tasks (1,875), then bulk import (1,360).

Example 2: Consumer App

Scenario: You have a photo editing app with 50,000 monthly active users.

Decision: Build undo/redo first (60,000)—it’s a fundamental feature with high confidence.

Advanced Tips

Use RICE for Experiments, Not Just Features

RICE isn’t just for product features. Use it for:

• A/B tests (change button color, pricing tier)
• Marketing experiments (new landing page, email campaign)
• Growth initiatives (referral program, affiliate partnerships)

Experiments often have lower effort and help you reduce uncertainty.

Update Scores with Real Data

After shipping a feature or running an experiment, measure actual impact:

• How many users actually used it? (Real Reach)
• Did it improve retention, revenue, or satisfaction? (Real Impact)
• How much effort did it actually take? (Real Effort)

Use these learnings to calibrate future estimates.

Account for Your Team’s Velocity

If your team has a proven velocity:

• Tight timeline: Prefer features with lower effort (quicker wins)
• Longer runway: You can tackle more ambitious projects (higher reach/impact)

Beware of Anchoring Bias

When estimating, avoid anchoring on the first number mentioned. Encourage independent estimates before discussing.

Consider Seasonal Factors

If your product has seasonal patterns:

• Plan Reach estimates for when the feature will have most impact
• A summer feature might affect more users in June-August
• A holiday feature might affect users in Nov-Dec

Common Pitfalls to Avoid

1. Overconfidence

Don’t assume 100% confidence unless you have hard data. Most estimates should be 50–80%.

2. Underestimating Effort

Features always take longer than expected. Add a buffer (e.g., estimate 2 weeks but assume 2.5).

3. Ignoring Unknown Unknowns

If you’re entering new territory, lower your confidence score. Don’t estimate blindly.

4. Treating RICE as Gospel

It’s a framework, not a law. Use it to inform decisions, not replace judgment. Strategic bets with lower RICE scores might still be worth pursuing.

5. Not Revisiting Assumptions

Plan to re-score every quarter. Market changes, user feedback, and team capacity evolve.

Tools and Resources

Spreadsheet templates:

• Google Sheets RICE calculator (search “RICE scoring template”)
• Excel pivot tables for ranking

Further reading:

• Intercom’s RICE framework (original article)
• Prioritization frameworks comparison (LogRocket guide)
• Lean analytics for validation (book by Alistair Croll & Benjamin Yoskovitz)

Related prioritization methods:

• WSJF (Weighted Shortest Job First): Adds “job size” weighting
• MoSCoW: Categorizes as Must, Should, Could, Won’t (simpler, less quantitative)
• Kano Model: Prioritizes by feature type (basic, performance, delighter)

Final Thoughts

RICE helps you break the “shiny feature” trap and make more objective decisions about your roadmap. It won’t make decision-making effortless, but it will make it intentional and defensible.

The real power of RICE isn’t the formula—it’s forcing yourself to articulate assumptions, challenge biases, and think critically about trade-offs.

Action: Score your top 10 feature ideas using RICE this week. Document your estimates and revisit them in 3 months. Compare estimated vs. actual impact. Iterate.

Quick Reference Card

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

Reach: # people affected in next 3 months
Impact: Scale 0.25 (minimal) → 3 (massive)
Confidence: % certainty in your estimates
Effort: Person-weeks required

Higher score = higher priority

RICE in Practice: Real-World Scenarios

Running a Quarterly Planning Session

RICE is most powerful when done as a team exercise (even if your “team” is just you + one advisor or co-founder).

1-hour quarterly planning template:

0:00–0:15 — Brain dump: List every idea in your backlog. Don’t filter yet.

0:15–0:30 — Independent scoring: Each person scores items silently. No discussion until scores are revealed.

0:30–0:45 — Discussion: Compare scores. Items with large disagreements in scores (e.g., one person gives 2 impact, another gives 0.5) are the most important to talk through. The disagreement reveals different assumptions about users.

0:45–1:00 — Decision: Commit to the top 3-5 items for the next sprint or quarter.

When RICE Scores Conflict with Intuition

RICE is a tool, not an oracle. If the scores suggest building Feature X but your intuition says Feature Y is more strategic, don’t blindly follow the score.

Common reasons RICE and intuition conflict:

1. Your Reach estimate is wrong: You estimated 5,000 users affected, but it’s actually 500. Recalculate.

2. The strategic value isn’t captured: RICE doesn’t account for competitive positioning. A feature that blocks a key competitor may have low RICE but be essential.

3. The Confidence score is too high: If you haven’t talked to users, your confidence should be 25-50%, not 100%. Overconfident estimates inflate scores artificially.

4. You’re undervaluing risk: High-RICE items sometimes carry hidden risks (technical debt, security implications, support burden). Add a “Risk” column if this matters.

Recommended approach: Use RICE to force rigorous thinking, but include a “Strategic Override” field. If an item has a strong strategic reason to be prioritized despite a lower RICE score, document it explicitly. That transparency prevents gut-feel decisions from hiding as data-driven ones.

Prioritizing Technical Debt and Infrastructure Work

RICE was designed for features. Technical debt and infrastructure work don’t have “users” in the traditional sense. How do you score them?

Reframe for infrastructure:

• Reach: Number of users indirectly affected by the improvement (usually all users)
• Impact: Use 1-3 based on risk reduction, performance improvement, or future velocity enabled
• Confidence: How certain are you that this will improve the situation?
• Effort: Same — person-weeks to complete

Example: Refactoring authentication system

• Problem: Current auth code has security vulnerabilities and slows down every new feature
• Reach: All 2,500 users (security affects everyone)
• Impact: 2 (high — unblocks 3 planned features, reduces security risk)
• Confidence: 80%
• Effort: 3 person-weeks
• RICE Score: (2,500 × 2 × 0.8) / 3 = 1,333

Compare that to a feature request with RICE of 400. The infrastructure work likely deserves priority despite being invisible to users.

Rule of thumb: If technical debt is visibly slowing feature development or creating security/stability risk, treat it as a first-class priority. The compounding cost of deferred maintenance always exceeds the short-term cost of doing it.

Beyond RICE: Complementary Prioritization Approaches

RICE is excellent for quantitative comparison but has blind spots. These methods complement it:

Opportunity Scoring (Kano Model):

Categorize features by user satisfaction impact:

• Must-haves (Basic): Absence causes dissatisfaction; presence is expected (login, email notifications)
• Satisfiers (Performance): More is better; directly proportional to satisfaction (speed, reliability)
• Delighters (Excitement): Unexpected features that create strong positive reactions (unexpected personalizations, “wow” moments)

Prioritize must-haves first (foundation), then satisfiers (core value), then delighters (differentiation).

MoSCoW Analysis:

Quick categorization for sprint planning:

• Must have: Cannot ship without this
• Should have: High value, but can be delayed if needed
• Could have: Nice to have if time allows
• Won’t have: Explicitly out of scope for this sprint

Use MoSCoW inside sprints where RICE handles quarterly planning.

Buy-a-Feature Exercise (for customer discovery):

Give your 10 best customers a budget of “100 feature dollars” and let them allocate it across a list of potential features. This reveals true willingness-to-pay for features without asking hypothetical questions.

The features that get the highest “purchases” across multiple customers are almost always high-RICE items — it’s a great way to calibrate your estimates.

Building a Prioritization Culture

For solo founders, the biggest risk isn’t using the wrong framework — it’s not having any framework at all.

Without structure, you’ll default to:

• The loudest voice: The last customer who complained gets their feature built
• The shiny object: The most technically interesting problem gets your attention
• LIFO queue: Last in, first out — newest requests jump the queue

All three patterns lead to the same outcome: a product roadmap that optimizes for noise rather than value.

Habits that build better prioritization:

1. Weekly backlog review (30 minutes): Review new requests from support, reviews, and user calls. Score rough RICE. Add to the ranked backlog.

2. Monthly roadmap session (1 hour): Re-score top-20 items with any new data. Commit to top 3-5 for the month.

3. Quarterly retrospective (2 hours): Review what you shipped. Compare estimated RICE to actual impact. Update your scoring calibration.

4. Say “not now” clearly: When users request features, don’t say “maybe later.” Say “we’ve considered this, it’s in our backlog at position X, and here’s roughly when we might get to it.” This manages expectations and respects users’ input without committing you to building everything.

RICE Spreadsheet Template

Here’s a minimal RICE tracker you can copy into Google Sheets:

Column A: Feature/Idea Name
Column B: Reach (# users in next 3 months)
Column C: Impact (0.25 / 0.5 / 1 / 2 / 3)
Column D: Confidence (% as decimal: 0.5, 0.8, 1.0)
Column E: Effort (person-weeks)
Column F: RICE Score  [= (B×C×D)/E]
Column G: Rank [sort by F descending]
Column H: Status (Backlog / In Progress / Done)
Column I: Notes

For the formulas to work in Google Sheets:

• F2: =(B2*C2*D2)/E2
• Sort column G by column F descending

Start with 10 items, run the numbers, and pick your top 3. That’s enough to get started. Refine the process over time.