The Art of Killing Ideas: A Founder’s Focus Framework
In 1997, Steve Jobs walked back into Apple and killed 340 of its 350 products in a few weeks. He fired 4,100 people. Then he drew a 2×2 matrix on a whiteboard: Consumer / Pro on one axis, Desktop / Portable on the other. Four products. That was the plan to save a company that had 90 days of cash left.
The board thought he had lost his mind. Wall Street pronounced Apple dead. Michael Dell, asked what he would do if he ran Apple, said he would shut it down and return the money to shareholders.
Twenty-five years later that 2×2 turned into a 4 trillion dollar company.
The most underrated skill in building a company is not having ideas. It’s killing them.
I’ve sat with hundreds of founders over the last decade and one pattern shows up over and over. The ones who die do not die because they ran out of ideas. They die because they could not stop pursuing all of them. They chase the next demo, the next channel, the next vertical, the next feature, because each one looks promising in isolation. Each one passes the test of “this could work.” None of them get the focused attention required to actually work.
The graveyard is full of products that almost shipped. Roadmaps that almost compounded. Channels that almost found product-market fit. Each one died because something good was added to the pile faster than something good was removed from it.
This post is the framework I use to kill ideas on purpose, on a schedule, with criteria written down before the emotion of the moment arrives. If you have ever stared at a backlog of “good ideas” and felt your stomach drop, this is for you.
What You Will Get in This Post
- Why founders cannot kill ideas (the loss-aversion trap)
- The Kill Stack: a 5-layer framework for cutting ideas with discipline
- The Reversibility Test in practice
- How to run a 45-minute kill-criteria pre-mortem
- The Opportunity Cost Matrix for scoring 5 ideas
- The Two-Pizza Idea Diet
- Case studies: Jobs, Butterfield, and the calm killers
- The Contrarian Take: pivot hesitation kills more startups than pivot frequency
- What to do Monday morning (30-day plan)
- FAQ: 8 questions on killing ideas
The Founder Problem Is Not a Shortage of Ideas. It Is a Shortage of Subtraction.
Here is the data that should keep every founder awake at night.
Roughly 90 percent of startups fail. Of the ones that fail, about 35 to 38 percent die because customers do not want the product. Around 70 percent of failures occur between years two and five. Seven of ten failed startups had been chasing vanity metrics instead of unit economics in the year before they died. And about 92 percent of successful startups had pivoted at least once before they found product-market fit.
Read those numbers again. The single largest cause of startup death is building things customers do not want. Not “could not raise enough.” Not “outcompeted.” Not “ran out of runway.” Built. Wrong. Things.
And here is the part most founders miss. The wrong things they built were not stupid ideas. They were good ideas. Some were great ideas. They came from real customer conversations, real market data, real personal frustrations, real product instincts. The problem was not that the ideas were bad. The problem was there were too many of them, and the team did not have the discipline to pick one and kill the rest.
The cognitive science here is settled. Daniel Kahneman’s prospect theory established that losses feel roughly twice as painful as equivalent gains. So when a founder has spent six months building something, killing it does not feel like saving the next six months. It feels like losing the last six. The brain calculates “I will lose six months of work” with twice the emotional weight as “I will gain six months of focus.”
This is loss aversion. It is the gravity that pulls every founder toward keeping dead projects alive.
Stack it on top of three other forces and you get a perfect failure cocktail.
- Identity attachment. When you describe yourself as “the founder who is building X,” killing X feels like killing a piece of who you are. Most founders cannot separate “the work I do” from “the person I am.” So killing the work feels like dying a little.
- Opportunity cost blindness. Founders see the cost of stopping the dead project. They almost never see the cost of not starting the next project. Every hour spent maintaining a feature nobody uses is an hour stolen from building a feature people would pay for.
- Sunk cost rationalization. “We’ve already invested so much, we can’t just walk away now.” The argument is mathematically wrong (sunk costs are gone whether you continue or not) but emotionally compelling. So the project gets one more sprint. And another. And another.
Most founders try to fight these forces with willpower. That does not work. Willpower is a finite resource and these forces are infinite. You will lose, every time, unless you put a different system in place. The rest of this post is that system.
The Kill Stack: A 5-Layer Framework for Cutting Ideas With Discipline
The Kill Stack is the framework I use every Friday to prune what I am working on. It has five layers. Each layer is a different question, asked in a different order. If an idea passes all five layers, it stays. If it fails any one of them, it dies. Or more honestly: it goes on the “kill list” for next week’s review, so I have a 7-day cooling period before I act.
Here is the stack visualized.
Each layer answers a different question, and they are stacked in a specific order. Reversibility tells you how fast to decide. Opportunity cost tells you what you give up. Kill criteria tell you when to walk away. The 10X filter forces honest magnitude. Identity decoupling separates ego from analysis.
Let me walk through each layer, with the exact questions I ask.
Layer 1: The Reversibility Test (Bezos’s One-Way or Two-Way Door)
In his 2015 shareholder letter, Jeff Bezos described two kinds of decisions. Type 1 decisions are one-way doors. You walk through and you cannot come back. Examples: selling the company, firing a co-founder, raising at a valuation you cannot grow into. These deserve slow, careful, senior-only consideration.
Type 2 decisions are two-way doors. You walk through, you can walk back. Examples: trying a new pricing page, changing an onboarding flow, killing a feature that 2 percent of users touch. These deserve fast, decentralized, ship-and-learn decisions.
Bezos’s observation: as companies get larger, they apply the heavyweight one-way door process to almost everything, including the two-way door decisions. The result is slowness, unthoughtful risk aversion, and diminished invention.
For an early-stage founder, the bias goes the other way. We treat one-way door decisions like two-way doors. We sign equity deals on a handshake, lock into 3-year contracts with vendors, announce features publicly, all on instinct. Then we cannot back out.
The test is one question: if I do this and I am wrong, how expensive is the un-do?
If the answer is “an hour and an email,” it is a two-way door. Decide in 5 minutes. If the answer is “three months, a lawyer, and the trust of the team,” it is a one-way door. Slow down. Bring in a second opinion. Sleep on it.
The killing application: when you are deciding whether to kill an idea, ask the same question. If killing this is a two-way door (you can resurrect it in a quarter), kill it now. If killing it is a one-way door (you would lose the team that built it, the customers who use it, the relationships that depend on it), slow down. Either way, the speed of the decision matches the cost of being wrong.
Layer 2: The Opportunity Cost Audit
Founders almost always see the cost of stopping a project. They almost never see the cost of not starting the next one.
The audit is a single question: what am I NOT doing because I am doing this?
You have to name it. Specifically. “If I stopped working on this onboarding redesign, I would have 12 hours a week to spend on the enterprise sales motion that 3 customers already asked for. That motion is worth ~$8K MRR per closed deal. The onboarding redesign at best moves activation 2 to 4 points.”
When you write it out like that, the answer is obvious. But you have to force the comparison. Most founders never write it down. They feel busy on the onboarding work, and busy feels like progress.
I run this audit every Friday for one hour. I list everything I worked on that week and force a column next to it: “best alternative use of that time, and what it would have moved.” I am brutal. Most weeks, 20 to 40 percent of my time was spent on the second-best thing. That is the kill list for next week.
Layer 3: Kill Criteria (Annie Duke’s States and Dates)
Annie Duke, the former poker pro turned decision researcher, has the cleanest framework I have seen. She calls it “states and dates.” Before you start an initiative, you write down two things:
- The state the world must be in for this to be worth continuing
- The date by which that state must be true
If the state is not true on the date, you kill the project. No debate. No “let’s give it another month.” You pre-committed.
This is the inverse of how most founders set goals. The typical goal is “build X.” The kill-criteria version is “by June 15, this product must have 50 paying customers and a 30 percent month-over-month growth rate. If not, we stop and start something else.”
The hard part is the discipline to actually walk away on the date. Almost every founder will rationalize. “We were close.” “The market was unusual that month.” “If we just push for another sprint.” Pre-committing in writing, ideally to another person who will hold you to it, is the only thing I have seen work.
Run this as a pre-mortem at the start of every project. Imagine yourself 90 days in the future, looking back at the project as a failure. What is the most likely reason it failed? Whatever that is, that is your kill criterion. If the early-warning signal of that failure shows up, kill the project before it costs you another quarter.
Layer 4: The 10X Filter
Most ideas in a founder’s backlog are not 10x ideas. They are 1.1x ideas. They will nudge a metric by 5 percent or 10 percent. They are not bad. They are just not big enough to matter, given the alternative use of the time.
The filter is two questions:
- What is the magnitude of this if it works? (Be honest. Not the optimistic story.)
- Is the magnitude 10x larger than my current baseline metric, or 1.1x larger?
The death zone is “1.5x to 3x.” Those ideas are big enough to feel meaningful, so you say yes. They are not big enough to actually move the company, so the work compounds slowly. You spend a year doing 1.5x ideas and you end up roughly where you started.
The brutal truth is that startups are won by a small number of 10x or 100x bets, not by a steady stream of incremental improvements. Some of those bets fail. The ones that work pay for everything else. Founders who can resist the 1.5x death zone get the focus to make the rare 10x bet count.
Layer 5: Identity Decoupling
The last layer is the hardest. It is the layer where founders fail most often, because it is not about logic. It is about ego.
The question: would I do this if it were not “mine”?
If a friend founder pitched this exact idea to you, with this exact data, would you tell them to keep going? Or would you tell them to kill it?
If your answer is “I would tell my friend to kill it, but I am going to keep going because it is mine,” you have an identity attachment problem, not an idea problem.
The fix is to separate “what I do” from “who I am.” You are a founder. You build things. You are not the specific thing you are currently building. Killing a feature, a product, even a whole company is not killing you. It is freeing the version of you that can build the next, better thing.
I have killed two ventures in my career that I had built for over a year. Both times it felt like death. Both times, 90 days later, I was working on something that mattered more, and I could not believe I had stayed in the dead thing as long as I did.
The Reversibility Test in Practice: Five Examples From Real Founder Decisions
The reversibility test is simple to explain and hard to apply. Most founders confuse one-way doors for two-way doors and vice versa. Here are five common founder decisions, with my read on each.
| Decision | Door Type | Why |
|---|---|---|
| Picking a tech stack for the first prototype | Two-way | You can rewrite the prototype in a weekend if you pick wrong. Decide in 30 minutes. |
| Picking your co-founder’s equity split | One-way | Renegotiating after 6 months damages the relationship even if the new split is fair. Take a month to decide. |
| Trying a new pricing page | Two-way | Revert in an hour if conversions drop. A/B testing exists for this reason. |
| Announcing a product publicly on Twitter | One-way | Walking back a public announcement costs reputation. Delay the post until the product is real. |
| Killing a feature 2 percent of users touch | Two-way | Email the 2 percent. Refund if needed. The engineering hours saved compound. Kill this week. |
The pattern is that anything that affects relationships, reputation, or compounding trust is one-way. Anything that affects only product, pricing, or process is two-way. When in doubt, ask the un-do question. If you can un-do in an afternoon, decide today. If you cannot un-do for 90 days, take 7 days to decide.
Most founder paralysis is on two-way door decisions. We treat “what should the button color be” with the same gravity as “should we take this $5M term sheet.” The result is months lost to decisions that should have been made in minutes. Most founder regret is on one-way door decisions. We treat “let’s accept this strategic partner who gets 30 percent of revenue” with the same speed as “let’s change the headline.” Months later we cannot escape the deal we rushed into.
The discipline is asymmetric speed. Fast on two-way doors. Slow on one-way doors. If you can build that one habit, you will save yourself years of regret.
How to Run a 45-Minute Kill-Criteria Pre-Mortem
Annie Duke’s pre-mortem is the single highest-payoff exercise I do at the start of any new project. Here is the exact 45-minute version.
Minutes 0 to 5: Setup. Open a doc. Write the project name at the top. Write today’s date. Set a 45-minute timer. No phone, no Slack, no other tabs. This is the only thing happening for 45 minutes.
Minutes 5 to 15: Imagine the failure. Project yourself 90 days into the future. The project failed. It is dead. Write the post-mortem story. What happened? What was the early signal of failure? When did you first know it was not working? What did you keep doing anyway? Be specific. Use real numbers. “By day 30, we had only 8 customers instead of 50. By day 60, growth had stalled. By day 90, we were still pretending.”
Minutes 15 to 25: Reverse-engineer the kill criteria. Look at the failure story. What was the earliest measurable signal? That signal becomes your kill criterion. Write it as a “state + date.” Example: “By day 30, if we have not signed 10 paying customers, we kill this.” The date is in the future. The state is precise and measurable.
Minutes 25 to 35: List the obvious objections you will make on the date. Founders rationalize. Pre-list the rationalizations you will use. “We were close.” “The market was unusual.” “The signal was noisy.” “We just need one more sprint.” Pre-listing the rationalizations defangs them. When you hear yourself making one, you recognize it as the rationalization you pre-listed, not as a new insight.
Minutes 35 to 40: Commit publicly. Tell at least one person about the kill criteria and the date. A co-founder, a mentor, an investor, a friend who builds. Anyone whose opinion you care about. Public commitment increases the probability you will actually kill on the date by roughly 3x in my own data.
Minutes 40 to 45: Calendar the review. Put the review meeting on the calendar right now. Not as a tentative thing. As a hard meeting with the same person you committed to. On the date. With the doc you wrote today as the agenda.
That is it. Forty-five minutes. The output is a project that has a fighting chance of being killed if it should be killed, instead of staggering on for another six months while you tell yourself you will know when to stop. You will not know. The pre-mortem is the only thing that will tell you.
The Opportunity Cost Matrix: Scoring Five Ideas Against Each Other
When you have five ideas on the table and time for one, the opportunity cost matrix is how I pick. The math is not complicated, but writing it down forces a comparison that founders almost never make.
Score each idea on five dimensions, 1 to 5:
- Impact if it works. How much does this move the north star metric?
- Confidence. What is the realistic probability it works?
- Time to signal. How fast will you know if it is working?
- Cost. How much capital, time, and attention does it consume?
- Reversibility. Can you un-do if you are wrong?
Compute the score: (Impact x Confidence) / (Time-to-signal x Cost / Reversibility). The highest score wins. The bottom three go on the kill list. The second-highest goes on the “next quarter” list.
Here is what that looks like in practice, with five real ideas a SaaS founder might be juggling in their backlog.
| Idea | Impact | Conf | Time-to-Signal | Cost | Reversibility | Score |
|---|---|---|---|---|---|---|
| Outbound sales motion to top 50 ICP accounts | 5 | 4 | 2 | 2 | 5 | 25.0 |
| Onboarding redesign (currently 60% activation) | 3 | 4 | 3 | 3 | 5 | 6.7 |
| New analytics dashboard (asked for by 3 customers) | 2 | 3 | 4 | 4 | 4 | 1.5 |
| Replatform on a new backend framework | 2 | 3 | 5 | 5 | 1 | 0.2 |
| Build a mobile app companion (no validated demand) | 3 | 2 | 5 | 5 | 2 | 0.5 |
The outbound sales motion wins by an order of magnitude. The onboarding redesign is plausible but the impact is bounded. The analytics dashboard is the death zone (busywork that 3 customers asked for and 47 will not care about). The replatform and the mobile app are kill-list items. Either they have low impact and high cost, or they are one-way doors with low confidence.
The matrix is not a precise calculator. The scoring is subjective. What it does is force the comparison. Without the matrix, the founder is likely to pick the onboarding redesign because it feels like “the responsible thing.” With the matrix, the math points to outbound sales because that is where the highest-payoff bet actually sits.
Most weeks I run this exercise as a 30-minute solo Friday session. I list 5 to 10 things on my plate, score them, and the bottom half goes on the kill list. By Monday, I have eliminated half my work and doubled my time on the things that matter most.
The Two-Pizza Idea Diet: Concrete Pruning Rules
If the Kill Stack is the framework, the Two-Pizza Idea Diet is the daily rules I use to keep the framework working. Six concrete rules I have stolen, adapted, or earned the hard way.
Rule 1: One bet per quarter. A “bet” is the single thing you would defend in front of your investors as the most important work of the quarter. If you cannot name it in one sentence, you do not have a bet. You have a list. Lists do not compound. Bets do.
Rule 2: Cap the active project count. If you have a team of 1 (solo founder), 2 active projects max. Team of 3 to 5, 3 projects max. Team of 10 to 20, 5 projects max. New projects can be added only when an existing one is killed or completed. The cap is not a guideline. It is a hard limit.
Rule 3: Weekly kill review (every Friday, 30 minutes). List everything you worked on this week. Force a column: “best alternative use of that time.” The bottom 20 to 40 percent of your time goes on the kill list. Next Monday, those things are not on your calendar.
Rule 4: Idea queue, not idea buffet. When a new idea arrives, it does not get worked on. It gets added to a “queue” doc. Each Friday, you review the queue. Most ideas stay in the queue. A few get promoted to the next quarter’s planning. The vast majority die in the queue, never having stolen any of your time.
Rule 5: One in, one out. If you take on a new initiative, you must name what you are stopping to make room. Not “I will just work harder.” Not “I will fit it in.” Name the thing that dies.
Rule 6: 90-day project cap. If a project is not showing measurable progress within 90 days, it gets a kill review. Either the kill criteria fired and it dies. Or you re-set kill criteria for the next 90 days. No project gets to drift indefinitely without a fresh state-and-date commitment.
These rules are not glamorous. They are constraints. But constraints are what make creative work compound. Removing rules gives you a buffet. Adding rules gives you a meal.
Case Studies: How the Calm Killers Made the Calls That Defined Their Companies
The frameworks above are abstractions. The case studies are how they show up in real life. Three founders. Three kills. Three companies that exist because of them.
Case 1: Steve Jobs at Apple (1997 to 1998)
When Jobs returned to Apple in July 1997, the company had 350 products, 4,300 employees, and 90 days of cash. The product matrix included twelve versions of the Macintosh, multiple PowerBook variants, the Newton handheld, printers, scanners, and a digital camera. Each product had been added because some retailer or executive had asked for it. None had the focused attention required to win its category.
Jobs cut. In the first few weeks, he killed 70 percent of the product line. He shut down the Newton. He killed every printer and scanner. He simplified the Mac line to four products mapped onto a 2×2 grid: Consumer vs. Pro on one axis, Desktop vs. Portable on the other. iMac. Power Mac. iBook. PowerBook. Four products. That was the company.
The board thought he was crazy. The financial press declared Apple dead. Michael Dell, the CEO of Apple’s largest competitor, was asked at a 1997 industry conference what he would do if he ran Apple. His answer: “I’d shut it down and give the money back to the shareholders.”
Jobs ignored all of it. He stuck to the 2×2.
The iMac launched in 1998 and sold 800,000 units in five months. By 2000, Apple was profitable. By 2001, the iPod shipped. By 2007, the iPhone. By 2026, Apple is the largest publicly traded company on earth.
The lesson is not that Jobs was a genius. The lesson is that the company existed in 1997 with 350 products. The same exact assets, the same people, the same supply chain. The killing did not destroy value. The killing released the focus needed to create value.
Jobs said it later: “Focus is about saying no. It’s about saying no to the hundred good ideas there are. I’m as proud of the things we haven’t done as the things we have done.”
Case 2: Stewart Butterfield Killing Glitch (2012)
Glitch was a browser-based MMO that Stewart Butterfield’s company Tiny Speck had been building for over four years. They had raised $17.2 million in venture capital. They had 45 people. The game was beautiful, weird, and beloved by a small cult following.
And it was not going to be a business.
In late 2012, the metrics were clear. Glitch was not going to scale to the kind of audience that would justify the burn. Butterfield could have pushed for another year. He had the cash. He had a team that loved the product. He had investors who believed in him.
He killed it instead.
In November 2012, Tiny Speck announced Glitch was shutting down. They refunded purchases. They open-sourced the art. They gave the team the option to leave with severance or to stay and build something new.
The “something new” was the internal chat tool the Glitch team had built to coordinate the game’s development. They called it Slack. They launched a beta in 2013. By the end of 2014, the public launch generated 8,000 signup requests in the first 24 hours and 15,000 in two weeks. By 2020, Slack had been acquired by Salesforce for $27.7 billion.
Butterfield could have spent 2013 fighting to save Glitch. The sunk-cost math said keep going. The identity math said keep going. He killed it anyway. The killing was the prerequisite for the $27.7 billion company that came next.
The lesson here is subtler than the Jobs case. Butterfield did not kill Glitch because Slack was already obvious. He killed Glitch because the kill criteria had fired and continuing would steal the team from a future opportunity that had not been named yet. The killing came first. The next thing was found in the space the killing created.
Case 3: The Quiet Pivots (Pinterest, YouTube, Twitter, Discord)
Almost every name brand company you can think of is a pivot from something else. The original idea was killed. The thing that worked emerged from the space the killing created.
- Pinterest started as Tote, a shopping app. The kill was made when “save for later” turned out to be the only feature anyone used.
- YouTube started as a video dating site called “Tune In Hook Up.” The kill came when nobody uploaded dating videos but plenty of people uploaded other videos.
- Twitter started inside a failed podcasting company called Odeo. The kill of Odeo was the prerequisite for Twitter.
- Discord started as a chat tool inside a failed mobile game called Fates Forever. The game was killed. The chat tool became a $15 billion company.
- Instagram started as Burbn, a location-based check-in app with photo features. Burbn was killed. The photo feature became Instagram.
The pattern is universal. The companies that succeeded were not the ones whose first idea was right. They were the ones whose founders had the discipline to kill the first idea fast enough to discover the second one.
The data backs this up. About 92 percent of successful startups pivoted at least once before finding product-market fit. About 75 percent of successful startups had a major pivot. And pivot hesitation, the failure to kill the original idea fast enough, increases the probability of startup failure by roughly 38 percent.
If you are pre-PMF, the most important question you can ask is not “how do I make my current idea work.” It is “what is the kill criterion that tells me my current idea is wrong, and how fast can I get the signal.”
The Contrarian Take: Pivot Hesitation Kills More Startups Than Pivot Frequency
The conventional wisdom says founders pivot too much. “Focus is everything.” “Stop chasing shiny objects.” “Pick one thing and grind.”
The data says the opposite. The single largest predictor of startup failure is not pivoting too often. It is pivoting too late.
The Startup Genome resilience report (referenced across multiple 2025 founder studies) shows that pivot hesitation increases failure likelihood by 38 percent. The CB Insights post-mortems of 483 failed startups show that “no market need” is the top cause of failure (cited in 35 to 38 percent of cases). The startups that died from no market need were not the ones who pivoted recklessly. They were the ones who refused to admit the original idea was wrong, and kept building it for another six, twelve, or eighteen months past the kill criterion.
The contrarian framing is this: the founders who appear to “lack focus” because they pivot are usually the ones who survive. The founders who appear to “have focus” because they grind on the original idea are often the ones who die.
“Focus” without a kill criterion is just stubbornness. Stubbornness is the most expensive personality trait in startups.
The discipline is not “never pivot.” The discipline is “pre-commit to the kill criteria, and when they fire, kill on schedule.” A founder who kills the original idea on day 90 because the kill criteria fired is not lacking focus. They are exercising the highest form of it. They have decided in advance which signals matter. They have committed to act on those signals. They have built the infrastructure to make the call without ego.
The founder who keeps grinding on the original idea past the kill criteria, telling themselves they are showing focus, is the one who blew up the company. Their focus was on the wrong thing. Their focus was on being right about the original idea, not on being right about the customer’s problem.
I have done both. I have killed too late more times than I have killed too early. The cost of killing too late is always higher than the cost of killing too early, in my experience, by a factor of 3 to 5x. The cost of killing too early is the opportunity cost of one quarter. The cost of killing too late is the opportunity cost of a year and the demoralization of the team that pushed through the dead end with you.
If you are unsure whether to kill, the default should be to kill. Run the framework. If the framework is ambiguous, kill anyway. The mathematics of regret strongly favor early kills.
What to Do Monday Morning: A 30-Day Plan to Build the Killing Habit
If you read this post and nothing changes by Friday, the post failed you. Here is the 30-day plan I would run if I were starting from zero today.
Week 1: Audit (find the zombies). Sit down for 45 minutes on Monday. Write every project, feature, channel, partnership, content effort, side bet, and “exploration” you are currently spending time on. Be honest. Most founders find 8 to 15 things. Score each one on the Kill Stack. The ones that fail Layer 2 (opportunity cost) and Layer 4 (10X filter) are zombies. Mark them. There will be at least three.
Weeks 2 and 3: Kill (do the hard part). Schedule three calls or meetings or emails to kill the three zombies. Tell the team. Tell the customers. Tell yourself. The killing should be public, calm, and complete. Refund what needs refunding. Apologize where apology is honest. Then stop. Do not keep “maintaining” the dead thing on the side. Dead means dead.
Week 4: Compound (build the system). Now that three zombies are dead, you have 30 to 40 percent of your time back. Use 50 percent of that recovered time on your one surviving bet. Use the other 50 percent on the Friday kill review, the opportunity cost matrix for the next 5 ideas, and the idea queue setup. This is the part most founders skip. They kill once, feel relieved, and slide back into accumulation within a quarter. The system is what prevents the slide.
By day 30, you have killed 3 things, set a one-bet rule, built a weekly review habit, and converted your idea management from buffet to queue. You have done more for your company’s odds of survival in 30 days than most founders do in two years.
And here is the part nobody tells you. After about 90 days of running this system, you stop feeling guilty about killing things. The killing becomes routine. The relief becomes the dominant emotion. You realize the version of you who could not kill was the version of you who was secretly drowning. The new version is calmer, faster, and shipping the things that actually matter.
If you want to go deeper on the surrounding skills, the Founder Operating System pillar covers how this fits into the broader habits of running yourself like a startup, the Decision-Making post goes deeper on the mental models behind the Kill Stack, and the Over-Shipping piece is the companion frame for how to ship the things that survive the cut.
FAQ: 8 Questions Founders Ask About Killing Ideas
1. When should I kill an idea I’ve already announced publicly?
Almost as fast as you would kill an unannounced one. The cost of walking back a public announcement is reputational, and reputation is recoverable in a quarter if you handle it honestly. The cost of carrying a dead idea forward to avoid the announcement embarrassment is six months to a year of stolen focus, which compounds into existential damage. Write the “we are killing this and here is what we learned” note, send it, and move on. Most of your audience will respect the honesty more than they would have respected the original launch.
2. How do I know if I’m killing too early or too late?
If you pre-committed kill criteria and the criteria fired, you are killing on schedule. That is neither too early nor too late. That is correct. If you are killing without kill criteria, you are killing on emotion. Either too early (because you got scared by one bad signal) or too late (because three bad signals were not enough). The asymmetry of regret in startups strongly favors early kills. Most “I killed too early” regrets are recoverable. Most “I killed too late” regrets are existential. When in doubt, kill.
3. What’s the difference between killing and pausing?
Killing means the project is dead, the team is reassigned, the assets are open-sourced or shut down, and the founder commits to not restarting for at least 6 months. Pausing means the project is in stasis, the team thinks they might come back to it, and 30 percent of the founder’s mental energy is still on it. Pausing is almost always worse than killing. It captures the cost of stopping without the benefit of focus. If you cannot commit to killing for 6 months, you have not killed. You have flinched.
4. Should I kill my own idea if my team is excited about it?
If the kill criteria fired, yes. The team’s excitement is a leading indicator of team morale, not a leading indicator of market success. Many of the deepest team-excitement projects I have seen in my career were the ones that died slowest, because team excitement made the founder reluctant to kill. The fix is to involve the team in setting the kill criteria up front. If they helped write the criterion, they will be much more willing to act on it when it fires. The criterion becomes a team agreement, not a founder edict.
5. How do I tell investors I’m killing a feature they funded?
Directly and in writing. Email them the kill criteria that fired, the data, the decision, and the next-step plan. Investors prefer founders who kill bad bets on schedule over founders who burn the round trying to make a bad bet work. The investors who get upset at a disciplined kill are not investors you want around for the long run. The ones who respond with “good call, what’s next?” are the ones you keep close. The discipline of public, written kills is a signal that you can be trusted with future capital. Use it.
6. What kill criteria work best for pre-PMF startups?
The cleanest criterion for pre-PMF work is “paid traction by date X.” Specifically: number of paying customers, contracted ARR, or pre-orders by a specific date. Engagement metrics, signup counts, and “interest” do not work as kill criteria pre-PMF. They are too easy to game and too hard to extrapolate from. Money changing hands is the only signal that survives the rationalization phase. If you do not have a credible path to paid traction by day 90, the bet is wrong and the kill criterion should fire.
7. How often should I run a “kill review”?
Weekly for time allocation. Quarterly for the larger portfolio. Annually for the company’s core strategic bets. Weekly Friday reviews catch the slow accumulation of busywork. Quarterly reviews catch the projects that drifted past their kill criteria. Annual strategic reviews catch the deeper question of “is the company still pointed at the right opportunity, or have I been grinding on a thesis that the market moved past.” Skip the annual review and you risk grinding on a dead thesis for years. The cost of that mistake is the largest in startups.
8. Is there an idea I should never kill?
Yes. The core thesis about why you started the company in the first place, before you had pressure to ship features and chase customers and please investors. That thesis is your north star. Specific products, features, partnerships, and channels are all expendable in service of the thesis. The thesis itself should not be killed unless you have evidence the thesis is wrong, not just that the current execution of it is wrong. Most pivots are pivots in execution, not pivots in thesis. Be very careful about which is which. Killing the wrong thing kills the company.
Related Reading
- The Founder Operating System (pillar). the broader system for running yourself like a startup
- Decision-Making Under Uncertainty. the mental models that power the Kill Stack
- From Overthinking to Over-Shipping. the companion piece on shipping the ideas that survive the cut
- How to Validate a Startup Idea in 48 Hours. kill criteria for the validation phase
- The AI-Native Founder Playbook (pillar). how this fits into building with AI as your team
- The AI Opportunity Map 2026. the bets worth running through the Kill Stack right now
- The $0 to $10K MRR Playbook. kill criteria for early revenue projects
- Building a Learning System That Makes You Dangerous. the learning loop that tells you what to kill
Vikas Malpani is a 4x founder building AI-native companies. He writes about the founder mindset, AI opportunities, and the practical mechanics of building companies with AI as a co-founder at vikasmalpani.com.