Most early-stage SaaS founders approach prioritization as a features question: which feature matters most? The actual question is different: which customer signal is strong enough to act on? These two framings produce completely different roadmaps.

A features question can be argued indefinitely. Enterprise wants integrations. Design partners want reporting. The sales team wants a competitor feature.

All three requests are valid. None of them is self-evidently more important than the others.

A customer signal question has a concrete answer. How many customers said this? Were they in the ICP?

Did it appear across sales calls, support tickets, and churn interviews, or did it surface in one loud conversation? Either the signal meets a threshold or it doesn’t.

The Three-Gate Prioritization Framework gives founders a structured way to run roadmap candidates through customer evidence, ICP alignment, and deferral cost before the meeting starts. This article is for the founder whose team relitigates the same roadmap decisions every quarter.

Why Early-Stage Prioritization Gets Relitigated Every Quarter

The obvious failure mode: the roadmap discussion takes two hours and lands on roughly the same decision it made last quarter. Everyone in the room has a different mental model of what customers want most. Nobody agrees on which signals deserve the most weight.

The less visible failure is that good-faith disagreements about priority are almost always disagreements about whose customer data to trust. One person heard three enterprise customers ask for better reporting. Another heard two churned customers say onboarding was the real problem.

Both signals are real. Neither has been compared against all the signals the team has collectively gathered.

The deepest failure is decisions made without an explicit threshold. Any customer request raised in a meeting has a chance of making the roadmap, regardless of how often it was heard. Any competitive feature spotted by sales gets immediate attention, regardless of whether it appeared in won or lost deals. When any signal can move the roadmap, no signal is meaningful.

The Three-Gate Prioritization Framework

The Three-Gate Framework runs each roadmap candidate through three gates in sequence. A candidate that fails any gate is deferred or sent back for more evidence. Nothing reaches the build queue without passing all three.

Gate 1 evaluates the customer signal strength

Gate 1 asks: how many distinct ICP customers raised this concern, and through how many channels?

The threshold is not fixed. It scales with the size of the investment. A large feature requiring months of engineering needs a stronger signal than a small UX improvement. But the threshold must be explicit before the meeting, not negotiated during it.

Before: “Customers keep asking for better reporting.” (one person’s impression, no count, no channel data) After: Gate 1 confirms: six ICP customers cited reporting gaps across sales calls and support tickets in the past 90 days.

An explicit signal count is not a veto on smaller or strategic features. It is a forcing function that separates customer-driven priorities from internal assumptions.

Gate 2 tests ICP alignment

Gate 2 asks: which customer type is driving this request? Is it the current Layer 3 ICP, or customers outside it?

A feature driven by customers outside the current ICP may be worth building. But that is a strategic decision about ICP expansion, not a product prioritization decision. The two should not be run through the same process.

Gate 2 prevents segment drift. Teams that build for whoever is loudest end up serving a different customer than the one they positioned for. The ICP definition from The ICP Definition That Goes Deep Enough to Be Useful, Article 03, is the reference Gate 2 runs against.

Gate 3 assesses the cost of deferring

Gate 3 asks: what happens if this decision is deferred 60 days? Three outcomes are possible.

Option A: deferring is harmless. The feature would be useful but its absence is not causing churn, blocking deals, or creating competitive exposure. Gate 3 returns it to the queue.

Option B: deferring is costly. Active deals are stalled. Churned customers cited this gap.

A competitor just shipped a version of it. Gate 3 flags this as time-sensitive.

Option C: deferring is irreversible. A customer has given a deadline. A market window is closing. Gate 3 requires a direct yes or no now.

Gate 3 prevents the common failure of deferring high-cost decisions while building lower-urgency features. The quarterly roadmap that looks reasonable in planning often looks costly in retrospect.

How the Conductor Surfaces the Evidence Before the Meeting

The week before roadmap planning, the founder pulls up Kiluma instead of relying on whichever feature request shouted loudest in the last sales call. Ask the Conductor: “How many distinct ICP customers cited this feature request in the last 90 days, and across which channels?” The answer is a count, not an impression.

That count is possible because the Library has been gathering what this query needs: customer interviews, support tickets, and sales conversation notes. They no longer live in scattered documents. The Conductor, the query layer over that body of knowledge, reads across them and returns the signal grounded in real customer interactions.

So the prioritization meeting opens on evidence. The room argues about what to build with a shared count in front of it, rather than relitigating whose anecdote was most recent.

Apply the Framework to Your Last Five Decisions Before the Next Meeting

Before using the Three-Gate Framework prospectively, apply it retroactively. List your last five roadmap decisions and the primary reason each one was made. Then run each one through Gate 1: was the signal count explicit at the time, or was the decision made on impression?

If fewer than three of the five decisions had explicit signal counts, the prioritization process has been running on impression. That is useful information. It identifies where the input gap is.

Do not try to fix the prioritization process before completing this audit. The audit reveals whether the gap is in signal collection, signal aggregation, or signal threshold: three different problems requiring three different fixes. Start there.

Decisions Built on Signal Counts Stop Getting Relitigated

If you pulled up your last five roadmap decisions right now, how many of them would be traceable to a specific customer signal? The ones that are traceable tend to stay decided. The ones that aren’t tend to resurface in the next planning meeting. Try Kiluma free for 14 days at kiluma.ai.