Your Team Needs a Kill List

Last quarter, my team shipped 14 features. The one I'm most proud of is the one we killed in week two.

We'd already built the data model, mocked the UI, and had a Figma prototype that the CEO loved. But three customer interviews in, nobody could tell us when they'd actually use it. Not "I wouldn't use it" — they literally couldn't place it in their workflow. So we pulled the plug, reallocated the sprint, and shipped a notification improvement that drove 12% more daily active usage.

Most PMs will tell you prioritization is the hardest part of the job. They're wrong. Killing things is harder. Prioritization is additive — you're picking winners. Killing requires you to look at something your team invested time, energy, and identity into and say: this isn't worth continuing.

#The Kill List as a Living Document

Here's a practice that changed how our team operates: every two weeks, alongside sprint planning, we review what we call the Kill List.

It's not a graveyard. It's an active document where any team member can nominate a feature, project, or initiative that might need to stop. Each entry has three fields:

The exit condition is the critical piece. You define it before you start building — "If activation doesn't hit 5% after two iterations, we stop." This isn't pessimism. It's intellectual honesty baked into process.

Without predefined exit conditions, every struggling feature enters what I call the "maybe zone" — endless iterations justified by "we just need one more sprint." The maybe zone is where engineer morale goes to die, and where your roadmap quietly fills with projects nobody believes in anymore.

#Why Teams Can't Pull the Trigger

Sunk cost is the textbook answer, but it barely scratches the surface.

The deeper issue is identity. When an engineer spends three weeks building a recommendation engine, that becomes their recommendation engine. Critiquing the feature feels like critiquing the person. PMs feel this too — something you championed in the roadmap review, now getting axed in front of the people whose trust you need most? That stings.

Then there's the organizational web. Sales already promised the capability to a prospect mid-contract negotiation. Marketing wrote it into next month's launch blog. The VP mentioned it in the board deck as evidence of innovation velocity. Now you're not just stopping code — you're creating uncomfortable conversations across three departments, and every one of those departments has someone who'll push back.

This is exactly why the exit condition matters so much. When the decision was made collectively at kickoff, and the data triggers the outcome, nobody's getting overruled. The engineer isn't losing a political fight. The team isn't voting against itself. The number simply said what the number said. You're honoring an agreement, not making a judgment call.

I've watched teams debate struggling features for six, eight, ten weeks. Sprint after sprint of "let's give it one more try." Every week, the opportunity cost compounds silently — the thing you could be building instead just sits there, waiting for bandwidth that never frees up.

#Making the Conversation Survivable

The worst thing you can do is surprise people.

If your engineering lead finds out a project is dead in a Slack message after standup, trust is broken in a way that takes months to repair. Three practices that actually work:

Narrate the journey, not just the verdict. Don't walk into the room with "we're stopping Project X." Walk in with "here's what we learned, here's where the signal pointed, and here's what the exit condition told us." People can disagree with a conclusion but respect a transparent process. Share the customer interview quotes. Show the funnel numbers. Let the evidence do the heavy lifting so you don't have to.

Redirect energy the same day. Nothing feels worse than having your project cancelled and then... nothing. No next thing. Just a void where your purpose was. Have the next allocation ready before you announce the decision. "We're shifting this effort to the notifications overhaul — here's why it matters more right now, and here's specifically where we need your expertise." Redeployment isn't just logistics; it's how you show people their work still has a home.

Celebrate good stops publicly. We started doing a "Best Stop" shoutout in monthly all-hands. Sounds counterintuitive, but it fundamentally changes the team's relationship with discontinuing projects. The narrative shifts from "we failed" to "we made a sharp resource decision and freed up capacity for something better." After three months of this, people started volunteering exit condition data instead of hiding it.

#The Maintenance Tax

Here's the math nobody wants to confront.

A mid-complexity feature in a typical SaaS product quietly eats 10-15% of one engineer's time indefinitely: bug fixes, compatibility updates, edge case handling, support escalations. Ship 20 features a year without stopping any, and within three years your entire engineering bandwidth is consumed by upkeep. Zero capacity for new work.

The "just ship it and see" mentality is fine at small scale. At 50+ live features, it's a slow death.

#When Stopping Is Wrong

Short counterpoint: not every underperformer deserves the axe.

Platform investments — APIs, integrations, data infrastructure — often show their value only when other capabilities build on top of them. The right question isn't "is this performing today?" It's "given everything we now know, would we greenlight this from scratch?" If yes, keep going. If the answer is "only because we already started" — that's sunk cost bias doing the talking.

The best product teams aren't the ones that ship the most. They're the ones with the shortest gap between "this isn't working" and "we stopped doing it." That gap — measured in days, not quarters — is where real competitive advantage hides. Set your exit conditions early. Review them regularly. And when the signal says stop, stop.