Feature Prioritization When There's Just You

You have 14 tabs open. A Notion page with 40 feature ideas. Three users who emailed this week with contradictory requests. And approximately zero bandwidth to run a scoring committee.

Standard prioritization frameworks were not built for this situation. They were built for product teams with analysts, quarterly roadmap reviews, and the luxury of disagreement. When you're solo, the frameworks don't just feel heavy — they actively mislead you.

Here's why the popular ones fail, and what to do instead.

Why RICE Breaks Down Immediately

RICE scores features on Reach, Impact, Confidence, and Effort. The math is: (Reach × Impact × Confidence) / Effort.

The problem is the numerator. Reach requires knowing how many users will be affected. Impact requires estimating magnitude. Confidence is literally a percentage representing how sure you are about the other numbers.

As a solo founder with 80 users and two months of revenue data, you don't have statistically meaningful reach figures. You have guesses dressed up as inputs. When you multiply three guesses together and divide by a fourth guess, you get a number that feels precise and is completely made up.

RICE is useful when a growth team has run enough experiments to make reasonable estimates. That's not you yet. Running RICE on thin data doesn't give you clarity — it gives you false confidence in whatever you were already planning to build.

ICE Has the Same Problem, Faster

ICE (Impact, Confidence, Ease) is RICE's lighter cousin. Fewer inputs, same issue: you're scoring features on dimensions you can't measure yet.

The honest version of an ICE score for most indie SaaS features looks like: "I think this will have medium impact (3/10), I'm not very confident (4/10), and it seems moderately easy (6/10), so the score is... 72." Then you do the same for the next feature and get 68, and you pick the first one.

You were going to pick the first one anyway. ICE just made you spend 45 minutes justifying it.

MoSCoW Sounds Reasonable Until You Use It

Must Have, Should Have, Could Have, Won't Have. Clean buckets. The problem is that solo founders in growth mode tend to put everything in Must Have and Should Have because everything feels urgent when you're the only person accountable for growth.

MoSCoW requires honest triage, and honest triage requires emotional distance from your own roadmap. Teams achieve that through disagreement — someone argues the "must have" label down to "should have." When you're alone, there's nobody to push back. The framework assumes a social dynamic that doesn't exist.

What Actually Works: The P1–P5 Stack

Instead of scoring, rank. Instead of formulas, use a single forcing question applied repeatedly. Here's the framework:

P1 — Breaks the product or blocks revenue. Bug that causes data loss. Checkout flow that's broken for 20% of users. Anything that makes existing customers unable to do the thing they pay for. P1 gets fixed before anything else, full stop.

P2 — A real user is waiting, and they've said so. Not "users probably want this." An actual human who pays you (or is about to) has asked for a specific thing and your answer right now is "not yet." P2 is your short queue of confirmed demand.

P3 — Strategic bet with a clear hypothesis. You believe this feature will unlock a specific outcome: reduce churn, enable a new segment, improve activation. You can write the hypothesis in one sentence. If you can't write it in one sentence, it's not P3 yet.

P4 — Good idea, no urgency. Nice-to-have. Users mentioned it once. You'd feel good building it. It lives here until evidence promotes it to P2 or P3.

P5 — Parking lot. You wrote it down so you'd stop thinking about it. Revisit in 90 days or never.

The system is intentionally brutal about P1 and P2. Nothing jumps to P3 without a hypothesis. Nothing jumps to P2 without a real human attached to it.

How to Run This Without Losing Your Mind

Once a week — Friday works well — spend 20 minutes doing exactly three things:

1. Check P1. Is anything broken? Fix it or schedule it for Monday morning.
2. Update P2. Did any users contact you this week with requests? Add them. Did you ship something from P2? Remove it. Did something sit in P2 for 6 weeks without you touching it? Move it to P4 — you've been avoiding it for a reason.
3. Reread your P3 hypotheses. Did you learn anything this week that confirms or kills one? Update accordingly.

That's it. The whole session is 20 minutes because you're not scoring anything — you're making judgment calls, which is faster.

The hardest discipline is keeping P2 short. The moment you add 12 items to P2, you've recreated the chaos you were trying to escape. Three items max. When number four arrives, something else moves to P4.

The Real Bottleneck Isn't Prioritization — It's Input

Here's the uncomfortable truth: most solo founders don't fail at prioritization because they use the wrong framework. They fail because they don't have enough signal. They're prioritizing in a vacuum, which means they're really just ranking their own assumptions.

The P1–P5 system above helps you organize what you know. It doesn't help you know more. That requires talking to users, watching sessions, reading support tickets, and understanding what the market actually rewards — not what you imagine it rewards.

This is where Omentoo fits. It's built specifically for indie B2B SaaS founders who need to understand what problems are worth solving before they start ranking solutions. Think of it as the research layer that populates your P2 and P3 with real signal instead of guesswork — so when you do sit down to prioritize, you're working with actual demand, not vibes.

The framework is the skeleton. Good input is what makes it useful.