The problem
Founders are praised for creativity, but startups are not saved by idea volume. They are saved by disciplined elimination.
The real bottleneck is not generating another concept. It is choosing what deserves time, code, narrative, and emotional commitment — and killing the rest before they quietly drain the company.
Why it fails
Killing ideas is hard because ideas attach to identity.
A founder starts protecting the concept instead of evaluating the evidence. Teams hedge with “maybe later.” Roadmaps accumulate ghosts. Nobody wants to be the person who says the exciting thing should die. So weak bets stay alive long enough to become expensive.
A concrete method
Make killing a job
Public survival criteria — Traction, willingness to pay, service cost, strategic fit, risk. If an idea fails minimums on two axes, it is a stop candidate.
Regular kill review — Monthly or quarterly, dedicated agenda: active initiatives, recent data, explicit continue / pivot / stop.
End-of-life budget — Plan the cost of a clean shutdown: customer comms, migration, docs, technical deactivation. Messy kills cost more than planned ones.
One-in-one-out rule — Major new idea only if another leaves the portfolio. Forces relative value conversation.
Zombie hunt — Find what burns support or infra with little usage: scheduled sunsetting beats eternal maintenance.
Idea graveyard — Short log of killed ideas with reason and optional reopen date. Stops endless debates with old ghosts.
Named decider — The kill has an owner, not “the team decided.” Clarifies accountability.
Anti-patterns
“Pausing forever,” roadmaps without real capacity, and features kept for one loud customer without a contract reflecting the cost.
“Small hack” policy — Ad hoc requests either pass survival criteria or get a standardized alternative; otherwise the product becomes a patchwork of exceptions.
Lightweight scoring template — Shared vocabulary for PMs: traction, cost, risk, fit; stops incomparable debates.
Sunsetting on the roadmap — Name end-of-life as a deliverable, not a surprise blog post.
Train GTM — Teach support and sales the difference between a temporary workaround and a permanent product promise.
Example
A SaaS team keeps an “experimental AI” module open to beta users for eighteen months. Usage is low, support explodes, the core roadmap suffers. A kill review enforces thresholds: active adoption, tickets per account, margin after customer success cost. The module fails; the team announces sunset with guided migration and credit for early adopters. Morale rises: less noise, more focus on billed core. A second case: a marketplace pursues three verticals in parallel to avoid disappointing partners. The CEO applies one-in-one-out: two verticals freeze, resources double on the segment showing strongest repeat usage. Unhappy partners get an honest timeline; growth accelerates because the team finally ships a complete experience in one slice. A third pattern: a feature exists for a single enterprise account; the kill is replaced by an explicit services contract instead of hidden product debt. The “job” of killing here is financial as much as strategic. A fourth lesson: sunsetting a free tier that attracted the wrong users improved conversion quality even though top-of-funnel numbers dipped—proof that killing can improve economics, not just workload. After the kill, the team noticed fewer escalations and clearer NPS commentary because customers stopped discovering half-maintained corners of the product. The graveyard also prevented a recurring pitch to revive a failed concept every budget season. Training reduced implicit promises that resurrect zombies.
What to do now
List five live ideas or initiatives that fail a simple survival test: recent usage, link to revenue or retention, marginal cost. For each, choose continue, pivot, or kill with a date and owner. Schedule a kill review within fourteen days; invite finance and customer success to avoid a product-only lens. Write a graveyard entry for every stop, including the metric that decided it. If you use Lumor or a blunt peer, ask: “What would you cut if you had to remove thirty percent of product surface tomorrow?”—use the answer to prioritize real kills, not theory. Communicate internally that a kill frees capacity, not punishment. Revisit in thirty days: the right indicator is not ideas launched, but hypotheses invalidated cleanly. Add a team rule: every new epic states what it replaces or why the portfolio expands despite capacity limits. Before your next planning cycle, print the survival criteria and score the backlog in public; discomfort now prevents expensive drift next quarter. Pair each kill with a capacity statement: hours per week returned to core work, not vague optimism. Review whether your instrumentation actually measures usage for the features you debate; many kill fights happen because nobody trusts the analytics definitions. Track time in review meetings for low-signal initiatives: if it exceeds time on the core, your culture still favors weak survivors. Re-run the survival test after major hires or a new segment push, because fresh enthusiasm often reopens old portfolios without new evidence.
Related reading
Lumor was built for this exact job: 13 AI roles challenge weak assumptions from different angles so founders can kill faster, preserve focus, and back stronger bets with more conviction.