The Drop column: killing what you're attached to
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.
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 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."
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.