How We Decide What Not to Build This Quarter

The feature graveyard is a good thing

Most engineering teams measure output: stories shipped, velocity points burned, features launched. Few teams measure what they chose not to build. That second number matters more.

Every quarter we generate more feature candidates than we could finish in a year. The default path is to rank them, stuff the top ones into sprints, and hope prioritization holds. We tried that. It doesn't hold. Halfway through the quarter, half-built features compete with urgent requests, and the team ships nothing well.

So we moved the hard decisions earlier. Way earlier — before a feature candidate ever touches a sprint.

Kill criteria, not prioritization

Prioritization assumes everything on the list deserves to exist. Kill criteria assume the opposite: most ideas should die, and the survivors earn their place.

Our kill criteria are five plain questions applied to every feature candidate during a single review meeting at the start of the quarter. A candidate must survive all five. One "no" is enough to shelve it.

1. Does this serve someone who is already paying us?

Ideas that target hypothetical future customers are speculation. Speculation belongs in a discovery backlog, not a delivery plan. If nobody using the product today has asked for this — directly or through their behavior — it doesn't pass.

2. Can we describe the outcome in one sentence a customer would repeat back to us?

If the team can't state the benefit without jargon, the feature is either too vague or too internal. "Exports finish in seconds instead of minutes" passes. "Improved pipeline orchestration layer" does not.

3. Does it make an existing workflow shorter, or does it create a new workflow?

New workflows carry adoption risk. They require documentation, onboarding changes, and support load. We don't refuse them outright, but a new workflow needs a stronger case than an improvement to something customers already do daily.

4. Can a single team finish it within the quarter without borrowing people?

Cross-team dependencies are where timelines go to die. If a feature requires coordination across three teams and a shared planning ceremony, the cost isn't just engineering hours — it's calendar drag and context switching for everyone involved. We break the idea into smaller pieces or kill it.

5. What do we stop maintaining if we ship this?

Every feature is a maintenance commitment. If the team can't name what they'd deprecate or simplify to make room, the long-term cost hasn't been considered. Surface area grows in one direction unless you force the question.

Why five questions beat a scoring matrix

We used to score candidates on impact, effort, strategic alignment, and customer demand — a weighted matrix with decimal precision. It felt rigorous. It wasn't. People gamed the scores to champion their favorite ideas. A candidate with an impact score of 7.3 versus 7.1 created arguments that consumed hours and resolved nothing.

The five questions are binary. Yes or no. The meeting is short because there is nothing to negotiate. A feature either has a paying customer behind it or it doesn't. It either fits in one team's quarter or it doesn't.

Binary decisions made early are cheap. Nuanced debates made late — after design work, after technical spikes, after someone has become emotionally attached — are expensive.

What happens to the dead ideas

Killed candidates go into a holding list with the date and the question that stopped them. We revisit the list next quarter. Sometimes circumstances change: a hypothetical customer becomes a real one, a dependency gets resolved, a team finishes a deprecation that frees capacity.

About fifteen percent of killed ideas come back and pass on a later cycle. The rest stay dead, and that is fine. The holding list also serves as institutional memory. When someone new proposes an idea we've already evaluated, we show them the reasoning instead of re-litigating it.

The compounding effect

The real payoff isn't the time saved in any single quarter. It's the shift in how the team thinks about proposals over months and years.

Engineers who sit through a few kill-criteria meetings start self-filtering. They stop bringing ideas that obviously fail question one or question four. Candidate quality goes up. The meeting gets shorter. People spend creative energy on ideas that have a real chance of shipping and surviving.

This is the compounding part: discipline at the idea stage reduces waste at every downstream stage — design, implementation, testing, documentation, support. You cannot recover that time with faster sprints. You can only recover it by not starting the wrong work.

The uncomfortable truth

Saying no to a feature feels like lost opportunity. It is actually preserved capacity. A team that ships four things well will outperform a team that ships eight things halfway — not just in product quality, but in morale, in customer trust, and in the ability to respond when something genuinely urgent appears mid-quarter.

The best quarter we ever had, measured by customer outcomes, was also the quarter where we killed the most candidates. That is not a coincidence. It is the whole point.