Why a scoring framework produces the wrong answer here
Scoring models are ratio arithmetic. Every one of them divides some estimate of benefit by some estimate of cost, and the ranking they produce is only as meaningful as the numbers you feed in. With a live product, reach comes from instrumentation and impact comes from past releases, so the estimates are anchored to something. With no users, reach and impact are both invented, and the model becomes a machine for converting a guess into a number that looks like evidence.
That would be merely useless if it were visible. What makes it harmful is that the output is durable and the inputs are not. Three weeks later the spreadsheet is what people refer to, the reasoning behind each score has evaporated, and nobody re-examines the estimate that drove the whole ordering, because it no longer looks like an estimate. This is the specific failure to name if an interviewer asks you to apply a framework to a pre-launch backlog: not that scoring is bad, but that scoring hides which of your inputs is load-bearing.
Rank by what would change your mind
The useful reordering is to stop asking which item is most valuable and start asking which belief, if false, would waste the most subsequent work. That gives you a sequence rather than a ranking, and a sequence is what you actually need before launch.
Write the idea down as a short chain of things that all have to be true. For a tool that lets independent letting agents handle tenancy renewals, the chain might be: agents currently lose money on renewals; they handle enough of them for a tool to matter; they would let software send documents to tenants on their behalf; they will pay per property rather than per user; and we can obtain tenancy data from the systems they already use.
Now ask of each link how confident you are, and how much of the plan collapses if it is false. The data-access link is the interesting one, because if the incumbent systems will not export tenancy records then almost nothing else on the backlog has a purpose. The pricing-model link is uncomfortable but survivable; you can change the pricing model without discarding the product.
So the first thing to work on is not the highest-value feature, it is whatever settles the data-access question, and that is very often not a feature at all. It might be two phone calls and reading a public API's documentation. A backlog whose first three items are integration spikes and pricing conversations is not an unfocused backlog, it is a correctly ordered one.
Separate the cost of learning from the cost of building
The move candidates miss is that each assumption has two prices: what it costs to test and what it costs to satisfy. Ranking on both together is what produces the sensible order.
| Assumption | Cost to test | Cost to build properly if true |
|---|
| Tenancy data can be extracted from incumbent systems | Two days reading docs and one call | Six to eight weeks of integration work |
| Agents will let us send documents to tenants | Four conversations | Already in the design |
| Agents will pay per property | Ten pricing conversations, or a landing page with prices | Nothing to build |
The pattern that emerges is nearly always the same: the assumptions that are expensive to satisfy are cheap to test, because testing is a question and satisfying is an engineering programme. That asymmetry is the whole argument for sequencing this way, and stating it explicitly is what makes the answer sound like experience rather than a recited method.
What you build regardless
Not everything is subject to learning, and pretending otherwise is its own failure. Some work has to happen because the product cannot exist without it, because it is a legal condition of operating, or because retrofitting it later costs several multiples of doing it now. Authentication, an audit trail in a regulated workflow, and the data model for the core entity all fall into this group. So does whatever is needed for anyone to see the product at all, which is easy to forget when the backlog has been written by people who already understand it.
Keep that group small and name it as a group, because it is where zero-to-one backlogs bloat. Every engineer has a defensible reason why some piece of infrastructure must come first, and the honest test is whether the cost of adding it after the first ten users is more than about twice the cost of adding it now. If it is not, it waits.
The failure mode you will not see coming
What sinks a pre-launch backlog is rarely insufficient rigour. It is rigour in the wrong direction — spending a fortnight producing a defensible ordering of forty items when the product will be unrecognisable after the first fifteen real users, and then defending that ordering because of the effort it cost. Sunk analytical cost behaves exactly like sunk engineering cost and is harder to spot, because the artefact looks like diligence.
Two habits guard against it. First, attach an expiry to the ordering: this sequence holds until the integration spike reports, and we re-rank then. Second, keep the list short enough that re-ranking is cheap. A backlog of a dozen items in a stated order that everybody can hold in their head survives contact with evidence; a scored register of forty items does not get re-scored, it gets worked through.
And when a founder or an executive arrives with the order already decided, the answer is not to produce competing scores, which invites an argument about numbers neither of you has. It is to agree the sequence and attach the assumption to it: we will build it in that order, and it rests on agents being able to export tenancy data, so let us spend two days confirming that before we spend six weeks assuming it. That framing costs nobody any face and it puts the falsifiable thing on record, which is the only part that matters afterwards.
With no users, the ranking criterion is not value but the cost of being wrong. Sequence the work that most cheaply tests the belief the rest of the plan depends on, and attach an expiry date to the ordering so evidence can reorder it.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).