How to Prioritize Features When You Have No Data

You've got a list of thirty things to build and enough time for four of them. Every framework you find online tells you to score each feature by how many users it reaches. You have nine users. Two of them are your friends.

That's the real problem with feature prioritization advice for first-time founders. The frameworks themselves are fine. They were just written by product managers at companies with analytics dashboards, support ticket volume, and someone whose full-time job is user research. You have a Notion board, a Slack channel with three customers in it, and a hunch.

So here's how to prioritize features when the inputs those frameworks want don't exist yet. We'll cover the four frameworks worth knowing, which one fits your stage, and the move that beats scoring anything at all.

Why is prioritizing features so hard before you have users?

Because prioritization frameworks are compression tools, and you have nothing to compress. They take a large pile of evidence and squeeze it into a ranked list. With no evidence, scoring just launders your existing opinion into a number that looks objective.

Here's the cost of getting it wrong. Pendo's 2019 Feature Adoption Report analysed usage across 615 SaaS products and found that 56% of features were never used at all, another 24% were rarely used, and only 12% were used frequently. That 12% drove roughly 80% of daily usage. The Standish Group's earlier research landed in similar territory: 45% never used, 19% rarely.

Read that again. Those are shipped features. Somebody scoped them, argued for them, built them, tested them, and launched them. Most of it was waste, at companies with far better information than you have.

The point isn't that prioritization is pointless. It's that being wrong is the default outcome, even with good data. Your job right now isn't to pick correctly. It's to pick cheaply and find out fast.

What are the main feature prioritization frameworks?

Four frameworks cover almost everything you'll run into: RICE, ICE, MoSCoW, and Kano. They answer different questions, which is why people argue about which one is "best" when they aren't actually substitutes for each other.

RICE came out of Intercom in 2018, written up by Sean McBride when he was a product manager on the growth team. The formula is (Reach × Impact × Confidence) / Effort. Reach is how many people the thing touches in a set period. Impact is how much it moves the needle per person. Confidence discounts the whole score by how much you're guessing. Effort is person-days or person-weeks. It was built to settle internal arguments about which experiment to run next.

ICE is RICE with Reach taken out: Impact × Confidence × Ease. Faster, rougher, and much better suited to a solo founder triaging a long list in an afternoon.

MoSCoW is older than both. Dai Clegg created it at Oracle in 1994 and it became a core technique in DSDM. You sort work into Must have, Should have, Could have, and Won't have this time. DSDM's guidance is that Musts should eat no more than 60% of your effort budget, with Coulds sitting around 20% as a contingency buffer. If everything is a Must, nobody has made a decision.

Kano doesn't rank anything. It classifies. Basics are expected and only noticed when they're broken. Performance features are the ones where more is better. Delighters are unexpected and create loyalty. It answers a different question: not "what next" but "what kind of thing is this".

Framework	Question it answers	Needs real data?	Best for
RICE	What returns most per unit of work?	Yes, especially Reach	Post-PMF teams with analytics
ICE	What should I look at first?	No	Solo founders, fast triage
MoSCoW	What gets cut when time runs out?	No	Fixed deadlines and launches
Kano	What kind of value is this?	Some, via user research	Deciding what to research next

Which prioritization framework should a first-time founder use?

Use ICE for triage and MoSCoW for scoping, and leave RICE alone until you have real usage numbers. RICE's entire advantage over ICE is the Reach term, and Reach is the one input you can't estimate before launch without simply inventing it.

Try it and the failure mode shows up in about four minutes. Two features, both reaching "all users", both scored Impact 3, both at 80% Confidence. The formula collapses down to Effort, and you've built an elaborate way of saying "do the easy one first". Which is often the right answer. It just doesn't need four variables and a spreadsheet.

Here's what I'd do under 100 users:

1. Dump everything into one list. No editing, no judgement, ten minutes.
2. ICE-score it fast. One minute per item, first instinct, no debate.
3. Take the top ten and force them through MoSCoW against your next real deadline.
4. Delete the bottom half of the list. Permanently.

That last step matters more than the scoring does. A backlog you never delete from turns into a guilt archive. You'll re-read the same forty dead ideas every planning session for a year and feel worse each time.

Where you keep the list matters less than keeping one at all. A spreadsheet is fine. So is a Linear backlog, a Notion database, or a planning tool like Foundra that walks first-time founders through the roadmap and go-to-market pieces in the same place. Pick whichever one you'll actually open on a Monday morning.

How do you score features when you don't have user data?

You substitute observed behaviour for measured behaviour. Not opinions. Not feature requests. Things people actually did.

Directional evidence you can collect this week without any analytics:

• Repeat volume. Count how many separate people raised the same thing unprompted. Five different humans beats one loud customer, every time.
• Workarounds. If someone built a spreadsheet, a Zapier chain, or a manual weekly ritual to route around your product, that's a feature request written in effort instead of words. It's the strongest signal you can get for free.
• Lost deal reasons. Write down why each deal died, in the customer's language, not yours. Do it for a month and a ranked list falls out of it.
• Churn exit answers. Even a single "why are you leaving" text field beats guessing.
• Trials that came back. Someone who bounced and returned is telling you exactly what changed their mind. Go ask them.

Then be brutal on the Effort side. This is where founder plans quietly die. The research on software estimation is grim and remarkably consistent: developers estimate roughly 20% to 30% below actual, mean effort overrun sits near 30% and hasn't improved in decades, and when engineers report 90% confidence in an estimate, the real hit rate is closer to 60% to 70%.

So double whatever number you're given. If you're a non-technical founder estimating someone else's work, double it again. An ICE score built on an optimistic Effort figure will systematically rank the wrong things first, because that error sits in the denominator where it does the most damage.

Should you fix the scope or fix the time?

Fix the time. It's the highest-return change most small teams can make to how they plan, and it sidesteps the estimation problem instead of trying to solve it.

Basecamp's Shape Up, written by Ryan Singer and published free in 2019, calls this an appetite. Instead of asking how long a feature will take, you decide how much time it's worth: a small batch of one or two weeks, or a big batch of a full six-week cycle. Then you cut scope until it fits. Fixed time, variable scope.

Why does this work better than estimating when you're a team of three?

Estimates are predictions, and you've already seen how badly those perform. Appetites are decisions, and you can make a decision correctly today. "Search is worth two weeks to this business" is a claim about your priorities that you can defend. "Search will take two weeks" is a claim about the future that's wrong most of the time.

It also changes the conversation with whoever's building. "Can you get this done in two weeks?" invites a yes and a broken promise. "We have two weeks. What's the version that fits?" invites design work. Those are completely different meetings.

You don't need six-week cycles at your size. Two weeks is plenty. What matters is that the number comes first and the scope bends to meet it, not the other way around.

How do you turn customer feedback into a priority order?

Segment the feedback before you count it. All feedback is not equal, and averaging it is how products turn to mush.

Rahul Vohra's approach at Superhuman is the cleanest version of this I've seen. He used Sean Ellis's survey question: how would you feel if you could no longer use this product? Very disappointed, somewhat disappointed, or not disappointed. The common rule of thumb is that 40% "very disappointed" means you've found product-market fit.

The prioritization move is what he did with the three groups:

• Very disappointed users are your fans. Their feedback tells you what to reinforce.
• Somewhat disappointed users are on the fence. Their feedback tells you what's stopping them from becoming fans. This is your growth segment.
• Not disappointed users get ignored. Not politely deprioritized. Ignored. They aren't your customer, and building for them will break the product for the people who are.

Superhuman then split the roadmap roughly 50/50 between reinforcing what the fans loved and clearing what held the fence-sitters back. Their score moved from 22% to 58% in under a year.

The uncomfortable part is that third bullet. Every founder I've watched run this survey wants to fix the complaints from the "not disappointed" group, because those complaints are the loudest, the most specific, and the easiest to act on. Resist it. And if you can't tell yet who your fans even are, that's your actual priority this month, not the feature list. Start with product-market fit before you write another line of code.

What makes feature prioritization go wrong?

Four failure modes account for most of the damage, and all four are behavioural rather than analytical.

Everything becomes a Must. MoSCoW only works if the Must bucket hurts. DSDM's 60% effort cap exists precisely because teams inflate that bucket until the exercise means nothing. If your Musts are 90% of the plan, you haven't prioritized, you've written a wish list with better formatting.

Scoring theatre. A number computed from three guesses is still a guess. It just feels harder to argue with, which is worse, because now the loudest person has arithmetic on their side. Keep the confidence multiplier honest and let low-confidence items score badly.

The customer with the biggest logo wins. One enterprise prospect asks for SSO and it jumps the queue on the strength of a deal that hasn't closed. Sometimes that's right. Usually it's a roadmap being written by someone who isn't paying you yet.

The backlog never expires. Ideas have a shelf life. A feature request from eleven months ago was made about a product that no longer exists and a market that has moved. Put a date on every item and delete anything untouched for a quarter. Nothing valuable is ever lost this way, because good ideas come back on their own.

Key takeaways

• Roughly 80% of shipped software features are rarely or never used. Being wrong is the base rate, so optimise for finding out quickly rather than for picking perfectly.
• RICE needs Reach, and Reach needs users. Under 100 users, use ICE for triage and MoSCoW for scoping.
• Double every effort estimate. Developers run 20% to 30% low on average, and that error lands in the denominator of every score you calculate.
• Set an appetite instead of taking an estimate. Decide what a feature is worth in weeks, then cut scope to fit.
• Segment feedback before you count it. Build for the people who'd be very disappointed to lose you, and ignore the people who wouldn't care.
• Delete aggressively. A backlog with no expiry date becomes a guilt archive that slows down every planning session.

FAQ

What is the best feature prioritization framework for a startup?

For pre-product-market-fit startups, ICE for quick triage plus MoSCoW for scoping a release. RICE is better once you have analytics good enough to estimate reach, which usually means a few hundred active users at minimum.

What's the difference between RICE and ICE?

RICE adds a Reach term and divides by Effort: (Reach × Impact × Confidence) / Effort. ICE is Impact × Confidence × Ease. RICE is more rigorous and slower. ICE takes about a minute per item and is usually enough when your feature list is under 30 items.

How many features should be in a Must have bucket?

DSDM's guidance is that Must haves should consume no more than 60% of your available effort, leaving roughly 20% for Could haves as a buffer. If your Musts exceed 60%, you've over-classified and no real trade-off has been made yet.

Should I build what customers ask for?

Build what they need, which is often different from what they ask for. Customers describe solutions; your job is to find the problem underneath. Watch for workarounds and repeated complaints from multiple people rather than acting on single feature requests.

How do I say no to a feature request without losing the customer?

Tell them what you're doing instead and why, with a date. "We're not building that this quarter because we're fixing onboarding, which three of you flagged. I'll come back to you in October." Most people accept a clear no with reasoning. What they hate is silence.

How often should I re-prioritize?

Every two to six weeks, tied to whatever cycle you build in. Any more often and you never finish anything. Any less and you're acting on stale information. Re-scoring mid-cycle is usually a sign the appetite was set wrong.