Luke Angel
The clarity-versus-evidence grid with the bottom-left Drop quadrant lit and the others faded, a vertical rust-orange accent bar at the left edge — low clarity, low evidence, the column where things go to be let go.

The Drop column: killing what you're attached to

by
#product#roadmaps#prioritization#leadership

This is the last post in The Four-Column Ask, and the hardest one. The framework sorts ideas by clarity and evidence; Drop is the bottom-left corner — low clarity, low evidence — the vague idea with nothing behind it. Describing the quadrant takes one sentence. Living in it is a come-to-Jesus moment, because Drop isn't really about the obviously-bad ideas. It's about the ideas you're attached to.

A locator showing the four-column grid with the bottom-left Drop quadrant marked with a dashed border and a downward arrow, the other three faded — low clarity, low evidence, the column where things go to be let go.

The easy drops aren't the point

Yes, the pure bottom-left exists: someone's pet theory, a competitor's shiny thing, a "wouldn't it be cool if" with no problem behind it. Those are easy — no one fights for them once you say the words. If that were the whole column, it wouldn't deserve a post.

The real Drop work is everything that's been sitting in your backlog for a year because no one will kill it. It had a champion once. It got designed, maybe. It's "a good idea, just not now" — and it's been "not now" for four quarters. It isn't low-quality. It's low-priority forever, which is a different and harder thing to admit, because admitting it means admitting the time you already spent on it isn't coming back.

The zombie tax

Here's the part teams don't price: a backlog item you'll never build is not free to keep. Every one of them is rent you pay, every planning cycle, in the currency of attention:

  • Someone re-reads it to decide if it's relevant yet.
  • Someone re-litigates it ("should we finally do X?").
  • It pads the backlog so the things that matter are harder to see.
  • It quietly anchors estimates and roadmaps that will never include it.

A hundred zombie items don't cost nothing because they're "just sitting there." They cost a slice of every prioritization meeting, forever, and they make the board lie about how much is actually in play. The most expensive backlog is the one no one ever prunes — not because of what's in it, but because of what it costs to keep reading it.

The compounding cost of zombie backlog items, drawn as a stack. A single unbuilt item is shown paying a small recurring tax each planning cycle — re-read, re-litigated, re-deferred — and a row of a hundred such items sums those small taxes into a large block labelled "a slice of every meeting, forever." Beside it, a clean short list labelled "what actually matters" is shown getting harder to see behind the padding. The caption: the build cost you didn't pay isn't the savings; the carrying cost you keep paying is the loss.

The real grooming math: value × cost × what-else-is-in-there

Killing the easy ones is triage. Killing the attached ones needs a colder lens than "is this a good idea?" — because most zombies are perfectly good ideas. The question is never "is it good?" It's "is it good enough to beat what it's competing against, given what it'll cost?" Three axes, not one:

  • Value — honestly, not aspirationally. The number you'd defend with evidence, not the one the champion hopes for.
  • Cost — build and the carrying cost of keeping it alive unbuilt.
  • Opportunity cost — what else is in the column. This is the axis people skip, and it's the one that does the killing. An item isn't competing against zero; it's competing against everything else you could do with the same slot. A 6-out-of-10 idea in a backlog full of 8s is a drop, even though 6/10 is "good."

A two-axis grid for roadmap grooming: value on the vertical axis, total cost (build plus carrying cost) on the horizontal. Items are plotted as dots. A diagonal "opportunity-cost line" sweeps across it — everything below and right of the line is shaded as Drop, because something already above the line beats it for the same slot. A high-value low-cost dot sits clearly in the keep zone; a cluster of decent-but-expensive dots, and a beloved-but-mediocre dot, fall below the line into Drop. The caption notes: the line moves as better ideas arrive, so yesterday's keep can become today's drop.

That diagonal is the whole game. It isn't fixed — it rises every time a better idea enters the column. Which means an item can be a legitimate keep one quarter and a drop the next, having gotten no worse: the bar simply moved. "But it's still a good idea" is true and irrelevant. Good isn't the bar. Better-than-what-it's-displacing is the bar.

The 80/20 of a backlog

Pareto runs straight through here: roughly 80% of your realized roadmap value will come from about 20% of the candidate ideas. The implication is brutal and freeing at once — most of your backlog is not waiting its turn; it's never getting built, and on some level you already know which. The 20% deserve real investment. The other 80% deserve an honest funeral, not eternal "someday" status that costs you attention while delivering nothing.

This is why a healthy Drop column is a sign of health, not failure. A team that never drops anything isn't disciplined; it's hoarding. The backlog that only grows is a backlog no one trusts, because everyone knows most of it is fiction.

Why it's emotionally hard (and how to make it easier)

The thing standing between you and a clean backlog is almost never analysis. It's sunk cost and attachment. "We spent three weeks designing this." "It was my idea." "The VP loved it in Q1." None of those are reasons to build something; they're reasons it's hard to kill — which is exactly backwards. The sunk cost is gone whether you build or drop; only the future cost is yours to decide.

A few things that make the cut cleaner:

  • Separate the kill from the criticism. Dropping an idea is not a verdict on the person who had it. Say that out loud, especially if it's your own idea.
  • Drop, don't bury. Move it to a genuinely archived list you don't groom, not a "someday" column you re-read forever. The point is to stop paying rent, and a "someday" column still charges it.
  • Make re-entry cheap and explicit. "This is dropped; if it acquires real evidence or clarity, it re-enters through Analyze or Test like anything else." That removes the fear that killing it means losing it forever — it can always come back, on merit, like a new idea.
  • Drop on a schedule. Put a recurring "what do we kill" on the calendar, so it's a normal hygiene act and not a dramatic confrontation. Pruning shouldn't require courage; it should require a Tuesday.

What I'd tell a team

  • Price the zombies. Every unbuilt item you keep costs attention every cycle. A backlog isn't a free storage locker; it's a room you have to walk through every time.
  • Judge against the column, not against zero. "Is it good?" is the wrong question. "Does it beat what it's competing for the slot against?" is the right one — and most beloved items lose it.
  • Name the sunk cost so you can ignore it. The three weeks are gone either way. Say it, then decide on the future cost alone.
  • A growing-only backlog is a broken one. If nothing ever leaves, the list is fiction and everyone knows it. A regular, unsentimental Drop is what keeps the other three columns honest.

That's the four-column ask, end to end: Build what's earned it, Test what's only beautiful, Analyze what's only painful — and Drop, without flinching, what you're keeping alive for reasons that have nothing to do with the work.

Keep reading

shares tags: #product · #roadmaps
product
The Build column is smaller than you think
Feb 10
product
The four-column ask: build, test, analyze, or drop
Jan 27
product
Rock Product Decisions With Data
Feb 01