Prioritize pre-PMF work by ranking each bet on how much uncertainty it retires, not by the impact score you'd use post-launch. Score every idea on confidence and cost-to-test, treat "impact" as "assumptions retired," and run the cheapest, riskiest tests first — because no baseline data exists yet to estimate real impact.
Quick answer: Don't score pre-PMF bets on projected impact — you have no baseline to project it from. Score them on confidence (how much evidence already backs this belief?) and cost-to-test, then run the cheapest high-uncertainty experiments first.
This isn't a workaround for missing analytics — it's the correct model for the stage. Traditional prioritization frameworks assume you can estimate how many users a change reaches and how much it moves a metric. Pre-PMF, both numbers are guesses dressed up as data, and scoring them anyway just launders founder opinion through a spreadsheet.
Why Impact Scores Fail Before Product-Market Fit
Impact scores fail pre-PMF because they require a baseline — usage data, conversion rates, a retention curve — that doesn't exist until real customers are behaving in a stable, observable way. Without that baseline, "impact" is just a founder's confidence dressed up as a number, which is exactly the bias frameworks like RICE were built to correct.
Every prioritization method — RICE, Kano, weighted scoring, value-vs-effort — needs an empirical anchor to convert opinion into comparable numbers. Post-PMF, that anchor is usage data: how many accounts touch a flow, what lift a similar change produced last quarter, how support tickets cluster. Pre-PMF none of that exists, so teams quietly substitute the loudest voice in the room for the missing metric.
That substitution has a name. It's the mechanic behind founder-as-HiPPO decision-making covered in our piece on why the founder is the HiPPO — and running the opinion through a scoring template doesn't neutralize it if the inputs are also opinions. A few tells that your prioritization inputs are fictional:
- Reach estimated as "most users," with no usage log anywhere to check it against.
- Impact scored at the top of the scale because the founder feels strongly about it.
- Confidence set high because of deadline pressure, not because of evidence.
- Effort estimated by the person who'll build it, with no track record to calibrate the guess against.
This matters because the failure mode is common and expensive. CB Insights' recurring post-mortem analysis of failed startups consistently lists "no market need" among the top reasons founders cite for shutting down — directionally in the 35-40% range across the cohorts it has surveyed over the years. A confidently-scored roadmap built on invented impact numbers is a fast, well-organized path to exactly that outcome.
The uncomfortable part is that the scoring template isn't the problem — the missing baseline is. A RICE spreadsheet with fabricated Reach and Impact columns produces a ranked list that looks rigorous and analytical, which is precisely what makes it dangerous. Stakeholders trust a number more than a hunch, even when the number was never anything but a hunch wearing a formula.
Reframe "Impact" as Assumptions Retired
Pre-PMF, redefine impact as the number and severity of assumptions a piece of work retires, not the revenue or engagement lift it produces. An experiment that kills a false belief about willingness to pay is high-impact even when it "fails," because it prevents months of building on a wrong foundation.
This is the same shift covered in our guide to pre-PMF discovery over delivery: the job isn't shipping features, it's retiring uncertainty as fast and cheaply as possible. Every roadmap item should answer the question "what do we now know that we didn't before?" rather than "what did we ship?"
Two well-known frameworks already point this direction. Eric Ries's Lean Startup popularized the build-measure-learn loop for exactly this reason: the deliverable of early-stage work is validated learning, not shipped code. Ash Maurya's Running Lean pushes further with the idea of a single riskiest assumption — the one belief that, if wrong, invalidates the whole business model — as the thing every sprint should attack first, ahead of anything more comfortable to build.
Translating that into RICE terms changes what each letter is measuring. The table below shows the shift.
| RICE term | Post-PMF definition | Pre-PMF definition |
|---|---|---|
| Reach | Users/accounts touched per period, from analytics | Number of target-segment people you can realistically test this belief with |
| Impact | Measured lift in a north-star metric | Severity of the assumption if it turns out wrong — model-breaking vs. cosmetic |
| Confidence | Historical hit-rate of similar past bets | How much existing evidence already backs this specific belief |
| Effort | Engineering days, calibrated against past estimates | Cost to reach a falsifiable answer — not cost to build the real thing |
Read across a row and the difference is really about evidence, not ambition: pre-PMF RICE scores a question, post-PMF RICE scores a feature. Both use the same four letters, but the unit of work being scored has changed entirely.
How to Build an Assumption Backlog
An assumption backlog is a running, ranked list of every unproven belief your business model depends on — pricing, target user, core workflow, channel, retention driver — logged with the same rigor you'd use for a feature backlog. Building the first version takes an afternoon, not a sprint.
Start by mining every "we think" and "we assume" sentence out of your pitch deck, PRD drafts, and founder conversations, then rewrite each as a falsifiable statement. Follow this sequence:
- Mine your assumptions from existing artifacts — the deck, the PRD, sales-call notes, even investor Q&A you've fielded.
- Write each as a falsifiable statement. "Users will pay $49/month for this" is testable; "pricing seems reasonable" is not.
- Tag each assumption with the job it's attached to. Our jobs-to-be-done complete guide walks through separating the functional, emotional, and social dimensions of the job a customer is hiring your product for — a useful lens for spotting which assumptions are load-bearing and which are decoration.
- Estimate confidence and cost-to-test for each item, not projected impact.
- Re-sort weekly as interviews, pilots, and sales conversations produce new evidence.
If you're a founding PM inside your first 90 days, this backlog is arguably the single highest-leverage artifact to produce before touching a roadmap — our guide to a founding PM's first 90 days covers how it fits into the broader onboarding sequence, ahead of any commitment to a feature set.
A useful backlog needs a consistent shape. Here's a minimal field set that works for most early-stage teams.
| Field | Example | Why it matters |
|---|---|---|
| Assumption (falsifiable) | "SMB owners will switch off spreadsheets for this workflow" | Forces a testable claim instead of a vibe |
| Layer threatened | Business model / value proposition / growth channel | Determines how severe it is if wrong |
| Confidence (1-5) | 2 | Captures how much real evidence already exists |
| Cost to test | 2 days, $0 spend | Cheapest falsifiable test — not an MVP build |
| Test method | 5 customer interviews using a Mom-Test-style script | Names the actual falsification method, not just "research" |
Notice what's missing from that table: an impact column measured in dollars or users. It doesn't belong yet — you're not ready to compute it honestly.
Score Bets by Confidence and Cost, Not Projected ROI
Score pre-PMF bets with a modified RICE formula that discounts the impact term and weights confidence and cost-to-test instead: rank by (assumption severity × confidence-worth-testing) ÷ cost-to-test. The bet that answers the biggest open question for the least money and time wins the top slot, regardless of how exciting it feels to build.
RICE — Reach, Impact, Confidence, Effort — was popularized by Intercom's product team as a way to force comparability across unrelated ideas competing for the same roadmap slot. Pre-PMF, keep the structure but change what each letter is doing:
- Reach becomes how many of your addressable early users or prospects this test can realistically involve, not a platform-wide user count.
- Impact becomes how much of the business model the underlying assumption props up — bold-underline anything that touches pricing or the core workflow.
- Confidence becomes the dominant term. Weight it two or three times the others, because it's the one measuring how much existing evidence actually backs the guess.
- Effort becomes the cost to reach a falsifiable answer, not the cost to build the polished feature.
Why Confidence Deserves the Heaviest Weight
Confidence carries the most weight in a pre-PMF formula because it's the only term that measures something you can actually defend under questioning. Reach and effort are estimates either way, but a low-confidence assumption that turns out wrong destroys far more roadmap time than a low-reach one ever will.
Think of confidence as answering one question honestly: "If I'm wrong about this, how would I even know?" An assumption with no answer to that question — no interview evidence, no competitor precedent, no expert opinion, nothing — should sit at the top of the test queue regardless of how reach or effort scores, because it represents pure unpriced risk sitting underneath the plan.
A Worked Example
Say a founding team is comparing two candidate bets for next sprint, both surfaced from the same pool of 40 pipeline prospects.
| Bet A: Add a Slack integration | Bet B: Test whether prospects will pay for the core workflow at all | |
|---|---|---|
| Reach | 40 pipeline prospects | 40 pipeline prospects |
| Assumption severity (impact) | Low — nice-to-have, doesn't change the model | Critical — the entire pricing model depends on it |
| Confidence (existing evidence) | Low — 2 unsolicited requests so far | Very low — zero evidence collected yet |
| Cost to test | ~3 weeks of engineering | ~2 days of 10 structured pricing conversations |
| Pre-PMF priority | Low | High |
Bet A looks appealing because it's concrete and buildable — a real trap when nothing else on the list has shipped yet. Bet B looks unglamorous because it's "just talking to people," but it retires the assumption that could invalidate the entire business if it's wrong, and it costs a fraction of the engineering time. Rank by uncertainty removed per dollar, and Bet B wins clearly.
When Kano's Basic-vs-Delighter Lens Still Works Without Survey Data
Kano's model still applies pre-PMF for sorting features into must-haves, performance features, and delighters — you just replace the satisfaction survey with structured interviews, competitor teardown, and pattern-reading across support tickets and sales calls. The category logic holds even when the input is qualitative instead of quantitative.
Noriaki Kano introduced the model in 1984 to separate features that cause dissatisfaction when absent (basic/must-be) from ones that cause delight when present but aren't missed otherwise (delighters/exciters), with performance features scaling linearly in between. The original method used satisfaction surveys — a functional-vs-dysfunctional question pair per feature — but the underlying categories are a property of how customers relate to a feature, not of the survey instrument itself.
| Kano category | Classic signal (survey) | Pre-PMF substitute signal |
|---|---|---|
| Must-be (basic) | Absence rated "dissatisfied," presence rated neutral | Category-standard features every competitor has; missing one kills first impressions in demos |
| Performance | Satisfaction scales linearly with more/better | The same request repeated, unprompted, across multiple prospect conversations |
| Delighter | Presence causes delight; absence isn't missed | Unprompted excitement in a demo for a feature nobody explicitly asked for |
| Indifferent | No measurable effect either way | A feature the founder keeps pushing for that no interview ever surfaces on its own |
Mapping where each candidate feature sits on the customer's actual journey — not just the demo script — helps separate a genuine must-be from a manufactured one. Our customer journey complete guide covers how to trace the emotional highs and lows a prospect moves through end to end, which is often exactly where a true delighter reveals itself, distinct from a feature that only looks exciting in a pitch meeting.
Where Prodinja Fits Into a Pre-PMF Prioritization Workflow
Prodinja's RICE/Kano prioritization tool computes real Reach/Impact/Confidence/Effort and Kano-category scores from the numbers you enter — pre-PMF, you can repurpose those same fields to rank assumption-tests instead of finished features, weighting confidence and cost-to-test the way this article describes rather than a speculative impact figure.
It won't invent impact data that doesn't exist — no tool honestly can, and one that claimed to would be lying to you. What it does is give you a structured place to enter your assumption backlog, weight confidence deliberately instead of by gut feel, and see the resulting ranking side by side instead of relying on whoever argues loudest in the planning meeting. As evidence comes in from interviews or pilots, you can log it and re-score, keeping the ranking honest as your uncertainty actually changes.
This is a small piece of a bigger discipline. If you're building the muscle for the first time, our founder PM complete guide covers how prioritization-under-uncertainty fits alongside discovery, roadmapping, and stakeholder management in a founding product role.
Key Takeaways
- Impact scores need a baseline you don't have pre-PMF — score confidence and cost-to-test instead of projected ROI.
- Reframe impact as assumptions retired. A "failed" test that kills a false belief is a win, not a wasted sprint.
- Build an assumption backlog before writing a roadmap — mine it from your deck, PRD, and founder conversations in an afternoon.
- Weight confidence two to three times as heavily in a pre-PMF
RICEformula, since it's the term that actually reflects the evidence you have. - Kano still works without a survey — interviews, competitor teardown, and unscripted demo reactions substitute for satisfaction data.
- Rank by riskiest-and-cheapest-to-test, not by excitement or buildability — the bet that resolves the biggest open question for the least cost wins.
- A structured tool can hold the ranking, but writing genuinely falsifiable assumptions is the step that actually removes the guesswork.
Frequently Asked Questions
How do you prioritize features when you have no user data?
Score each candidate by how much uncertainty it removes and how cheaply you can test it, not by a projected impact number you can't honestly compute. Rank the assumption backlog by severity-times-confidence-worth-testing divided by cost, and run the cheapest, riskiest test first — the same discipline RICE uses post-launch, aimed at questions instead of features.
Is RICE prioritization useful for pre-seed startups with no metrics?
Yes, if you change what each letter measures. Keep Reach, Impact, Confidence, and Effort, but redefine Impact as assumption severity and weight Confidence — how much real evidence exists — two to three times as heavily as the other terms, since it's the only one grounded in something other than a guess.
Can you use the Kano model without running a customer survey?
Yes — the basic/performance/delighter categories are a property of how customers relate to a feature, not of the survey format Noriaki Kano originally used to measure it. Structured interviews, competitor teardowns, and unprompted reactions in demos and sales calls substitute for the functional-vs-dysfunctional survey questions.
What's the single most important thing to prioritize before product-market fit?
The riskiest, cheapest-to-test assumption underneath your business model — usually something about willingness to pay, the core workflow, or the target user, not a feature. If that assumption is wrong, everything built on top of it is wasted regardless of execution quality.
How many assumptions should be in an assumption backlog?
There's no fixed count — most early-stage teams end up with 15-30 logged assumptions but only actively rank and test the top 5-10 at any time. The list should grow as you mine more sources and shrink as items get validated, invalidated, or downgraded to indifferent.