The Feature Request Triage Matrix

A feature request backlog that grows by whoever asked most recently, or asked loudest, ends up building a product shaped by the order requests happened to arrive in rather than a product with an actual direction. This matrix sorts by two dimensions that matter more than arrival order: how many customers actually want it, and how well it fits where the product is genuinely headed.

The triage matrix

Why demand and strategic fit, specifically

Demand captures how many customers actually asked, weighted by how much revenue or how many accounts those customers represent — not just a raw request count. Strategic fit captures whether building this moves the product toward where it's actually meant to be headed, or pulls attention and engineering time toward something adjacent but not core. A request can be loudly demanded and still weaken the product's direction if built; a request can have almost no current demand and still be exactly the right next investment if it fits where the product needs to go.

What each zone actually means day to day

Build next (high demand, strong fit): The easy case — genuinely wanted, and squarely aligned with the product's direction. These deserve to move to the top of the roadmap without much internal debate, since both signals already agree.

The hardest call (high demand, weak fit): Genuinely wanted by real customers, but building it risks pulling the product toward something it isn't meant to be. This is the zone most teams handle worst — either building it anyway and quietly drifting the product's direction one popular request at a time, or ignoring it indefinitely without ever giving customers an honest answer. A direct, explicit no — or a narrower version that fits the product's actual direction — respects the customer's time more than silence does.

A differentiating bet (low demand, strong fit): Few customers have asked for this yet, but it fits squarely with where the product is headed and could become one of the things that actually defines its next stage. These are worth greenlighting on conviction and product vision, not dismissed for lacking a current demand signal — by the time demand catches up, a competitor may have already built it.

Politely decline (low demand, weak fit): Neither widely wanted nor aligned with the product's direction. These deserve a quick, honest, polite no rather than sitting indefinitely in a backlog, quietly implying to whoever asked that it might still happen someday.

Why one loud account isn't the same as broad demand

A request repeated independently by many unconnected customers is a meaningfully stronger demand signal than the same request repeated loudly, even urgently, by a single account — however valuable that account is. Weighing demand by how many genuinely separate sources are asking, not just by how insistently one source is asking, keeps the matrix from being quietly dominated by whichever customer happens to have the founder's phone number. This doesn't mean an important account's request should be ignored — it means the request's placement on this matrix should reflect real breadth of demand, with the account's importance factored in separately as part of the decision, not folded silently into the demand axis itself.

Revisiting placements as the product evolves

A request that looked like a weak strategic fit a year ago can become a strong fit once the product's direction shifts — and the reverse is also true. The same principle that applies to reassessing pipeline coverage assumptions as conditions change applies here: a triage matrix populated once and never revisited quietly drifts out of date, quadrant by quadrant, as both customer needs and the product's own direction keep moving.

What to do once requests are placed

Give every request in the "hardest call" zone an actual answer, even when that answer is no — a request left permanently unanswered costs more customer trust over time than an honest, well-explained decline.

Protect at least one "differentiating bet" on every roadmap cycle, so the product doesn't drift into building exclusively what's already been asked for, at the expense of what's actually next.

Revisit the matrix's placements periodically, not just the request list itself — a request's zone can shift even when nothing about the request changed, simply because the product's direction moved.

The short version

Sorting feature requests by demand and strategic fit, rather than by who asked loudest or most recently, keeps a product's roadmap aligned with an actual direction instead of a reactive list of whoever spoke up last. The hardest zone — loudly wanted but poorly fitting — deserves the most deliberate handling, since it's the one most likely to quietly steer a product somewhere it was never meant to go.