"What should we build next" sounds like one question. It's actually three, stacked on top of each other: what's urgent right now, what moves the strategy forward, and what you can actually prove is worth doing. Most teams answer whichever one shouted loudest that week, then call it a roadmap. Separate the three and the real decision gets a lot smaller.
Why "what should we build next" never has one clean answer
Ask five people on a five-person team what to build next and you'll get five defensible answers. The support lead wants the thing that stops the ticket volume. The salesperson wants the thing that closes the deal stuck in the pipeline. The founder wants the thing that matches the eighteen-month vision. None of them are wrong. They're answering different questions and calling it the same one.
That's the actual trap in "what should we build next": it collapses three separate decisions into a single sentence, so whichever voice is loudest in the room that week wins by default, not because it was the strongest case. A support ticket spike feels urgent because it's happening today. A strategic bet feels important because a founder said so in a planning doc six months ago. Neither of those is evidence that the thing is worth building. They're just evidence that someone cares about it.
The fix isn't a better ranking framework bolted on top. It's separating the question before you try to answer it.
The three questions hiding inside "what should we build next"
Every "what should we build next" conversation is secretly asking three things at once. Naming them separately is what makes the decision tractable.
Is it urgent? Something is breaking, churning, or costing you deals right now, and the clock is the argument. Urgent items get their case made in days, not quarters, and the evidence is usually a specific, dated incident: three cancellations citing the same gap this month, a support queue that tripled after a competitor's launch.
Is it strategic? This doesn't fix anything broken today. It moves you toward a market position, a customer segment, or a category claim you've decided matters over the next year or two. Strategic bets don't have urgent evidence behind them by design, because the case for them is about where you're going, not what's on fire.
Is it provable? You have a specific, countable signal, not a vibe, that says this will move a number you care about. Three independent customers describing the same gap in their own words is provable. One founder's hunch, however good the founder's instincts usually are, is not, until it's tested.
A request that's urgent but not provable is a fire alarm you haven't verified yet. A request that's strategic but not provable is a bet you're choosing to make on faith, which is sometimes the right call, but only if you're honest that it's faith and not data. The mistake is treating any one of the three as if it settles the question alone.
| Question | What answers it | What it does NOT tell you |
|---|---|---|
| Is it urgent? | A dated, specific incident: cancellations, a ticket spike, a lost deal this quarter | Whether it matters in twelve months |
| Is it strategic? | A stated market position or category bet you've already committed to | Whether customers are asking for it today |
| Is it provable? | Three or more independent signals (calls, tickets, behaviour) pointing the same direction | Whether it's urgent or strategic, only whether it's real |
What counts as customer signal, and why one loud voice isn't it
Customer signal is any observable evidence, direct or behavioural, that tells you what a customer actually needs, wants, or is struggling with, as distinct from what a single person in the room believes they need. A support ticket is a signal. A drop-off point in usage data is a signal. A sales call where a prospect describes their workaround in detail is a signal. A founder's strong opinion, however well-informed, is not a signal until it's checked against something observable.
The distinction matters because "what should we build next" conversations run on whichever voice is most confident, and confidence has no relationship to whether the underlying signal is real. The person who talks most in the roadmap meeting isn't necessarily closest to the evidence. Sorting requests by who argued for them hardest is a popularity contest wearing a prioritization framework's clothes.
How much signal is enough before you commit
The honest answer is: it depends on what kind of decision you're making, and pretending otherwise is how teams end up either building on a single anecdote or stalling forever waiting for certainty that never arrives.
A cheap, reversible change, an onboarding tweak, a copy change, a small UX fix, is reasonable to ship on a single strong signal plus your own judgment. The cost of being wrong is a quick rollback. A larger, harder-to-reverse commitment, a new module, a pricing change, a structural rebuild, needs a pattern: multiple customers, multiple channels, ideally converging on the same underlying problem described in different words. That convergence across channels is the part worth insisting on. One customer complaining in three different ways is one data point, not three.
This is also where the three questions from the section above do real work. An urgent, cheap fix doesn't need the same evidence bar as a strategic, expensive one. Matching the evidence requirement to the size and reversibility of the bet, rather than applying one universal threshold to every decision, is what keeps this from becoming either reckless or paralysed.
What this looks like with twenty customers, not twenty thousand
Most prioritization advice assumes a data volume you don't have yet. At n=20, "three independent signals" isn't a statistical sample, it's most of your active relationships weighing in, and that's exactly why it's meaningful rather than despite it. When a quarter of your customer base independently raises the same gap without prompting each other, that's not noise you need more data to confirm. It's close to consensus.
The failure mode at this scale runs the other way, too: treating your single loudest or most senior customer's ask as if it were the whole market, because at twenty customers, one voice can feel like it's carrying real statistical weight when it's actually carrying one opinion. Weighing evidence by how many independent sources it crosses, not by volume or by who's shouting, is what makes a small customer base usable instead of misleading.
The decide layer: turning three tangled questions into one answer
The decide layer is the explicit step between collecting customer signal and committing engineering time, where urgency, strategy, and evidence get weighed against each other on purpose instead of by default. Without a decide layer, the three questions from earlier stay tangled, and whichever one arrives loudest, most recently, or from the most senior voice wins the argument by default.
A decide layer doesn't need to be heavyweight. In practice it's answering three short things, in writing, before a request moves to the roadmap: which of the three questions is this actually answering, what's the specific evidence behind that answer, and what did you deliberately choose not to build instead. That third part, the explicit trade-off, is the piece most teams skip, and it's the piece that turns "we built this because it felt right" into a decision someone could audit six months later and still find defensible.
The information-gain part: what "urgent" actually looks like across support tickets versus sales calls
Here's the part a generic prioritization guide can't give you, because it requires looking at where urgency signal actually originates, not just naming it as a category. Urgent requests surface through two structurally different channels, and they carry different evidence weight even when they sound equally loud.
Support-ticket urgency is retrospective: something already broke for a customer who is already paying you, and the signal is a complaint about a gap that's costing them today. It tends to be specific, dated, and describable in the customer's own words, which is exactly what makes it strong evidence when it clusters, three tickets about the same underlying gap this month is a real pattern, not three unrelated complaints.
Sales-call urgency is prospective: a deal is stuck on a gap that hasn't cost anyone anything yet because the relationship hasn't started. It's just as loud, often louder, because a stalled deal has a dollar figure attached and a salesperson with a quota motivated to escalate it. But it's evidence about what it takes to close a customer, not evidence about what your existing customers actually need once they're using the product. Treating a single stuck deal as equivalent to a support-ticket pattern is how roadmaps end up chasing whichever prospect made the most noise this quarter instead of building for the base that's already paying.
The practical rule: weight support-ticket clusters and sales-call urgency as separate evidence streams, not one merged "customers are asking for this" bucket, because they're telling you about two different populations, existing and prospective, who don't always want the same thing.
Put the three questions to work
The next time "what should we build next" comes up in a planning meeting, don't answer it directly. Ask which of the three questions is actually being asked, urgent, strategic, or provable, and press for the specific evidence behind that answer before it goes anywhere near the roadmap. The request that survives that filter is the one worth your engineering time. The one that doesn't was never really about the product. It was about who was in the room.
This is the same discipline behind how to decide what to build next once you've already picked a direction, applied one step earlier, at the moment the question first gets asked. And it's the same reason a feedback repository alone can't make the call for you: collecting the signal and deciding what to do with it are two different jobs, and skipping straight from the first to the second is exactly how the loudest voice ends up winning by default.
