Kill your darlings

Introduction

In product, building is easy. Killing is the hard part. The best teams don’t just measure what’s working - they build systems to know when to stop. AI is accelerating everything: prototypes, feedback loops, and invalidation cycles. In the age of speed, rapid invalidation is as important as shipping.

This piece explores the often-overlooked discipline of knowing when to walk away. Not because something failed, but because it didn’t earn its place in the ecosystem. Because the best teams aren’t attached to the volume of what they build—but to the value of what remains.

The mistake that taught me the truth

Back in 2010, I was building a consumer-first communication product—a mobile, video-only messaging platform. Privacy was becoming a hot topic, and we thought we were reading the signals right. We assumed users wanted more control: invite systems, approvals, friction-heavy sharing mechanisms. We spent months building them.

But we got it wrong. Users didn’t want more control—they wanted immediacy, creativity, connection. We had interpreted caution as intention, and built an experience that discouraged spontaneity.

Engagement was flat. Sharing was slow. Growth was stillborn.

Then we did something that felt embarrassingly basic: we put users in a room and watched them. The friction was obvious. The core product was buried under layers of mechanism.

Within two weeks, we redesigned onboarding, stripped away the gates, and re-centered the app around expression and sharing. Usage spiked. Content creation surged. And the company was eventually acquired by Telefónica.

That experience taught me something I’ve never forgotten: if you’re not ready to kill what’s in the way, you’re not ready to ship what matters.

Why we keep building the wrong things

Even high-performing teams fall into the trap. In fact, the smarter and more capable your team is, the more dangerous this becomes. You can build anything. So you do. And sometimes, you keep building it long after the signs are telling you to stop.

There’s a subtle emotional trap at play here. Teams fall in love with ideas. With roadmaps. With the story they told the business six months ago. They confuse momentum with merit. And in fast-growing companies, where speed is rewarded and certainty is hard to come by, it’s easy to believe that continuing is safer than questioning.

There’s also fear. No one wants to admit they were wrong. No one wants to pull the plug on a feature their team spent two quarters on. No one wants to be the person who stops the train - even if it’s headed in the wrong direction.

And so we keep building. We keep maintaining. We keep spending. Until the cost of continuing quietly outweighs the benefit of stopping.

Why?

• Sunk cost fallacy: You’ve invested months, maybe years. Killing it feels like waste.
• Vanity metrics: Surface-level engagement masks deep disinterest.
• Team attachment: Someone poured their soul into this idea. Now it’s personal.
• Internal politics: Killing a feature can create tension—or cost someone political capital.
• Hope: The classic trap. “Let’s just give it one more sprint.”

Without clear decision-making frameworks and a culture that normalizes sunset decisions, teams default to inertia. And when that happens, innovation dies under the weight of unchallenged assumptions.

Measuring what matters

One of the biggest myths in product is that measurement is objective. It isn’t. Measurement is interpretation. And the stories you choose to tell with your data - what you amplify, what you ignore—can either help you kill the right things or protect the wrong ones.

Great teams understand this. They don’t just collect metrics; they design them. They decide, early and deliberately, what success looks like - and more importantly, what failure should trigger. They don’t measure to prove they were right. They measure to decide what to do next.

To kill effectively, you have to measure rigorously. But not all metrics are created equal. The best teams define impact upfront and create feedback loops that inform - not justify - their investment.

Pre-launch tools:

• Fake-door tests: Gauge intent before writing code.
• Customer discovery: Validate demand through problems, not features.
• AI-enabled research: Rapidly scan the market, analyze sentiment, generate synthetic personas.
• TTV estimates: If it takes weeks for a user to realise value, rethink the flow.

Post-launch metrics:

• Activation: Are users getting to their "aha" moment quickly?
• Retention: Do they come back? And do they come back for the right reasons?
• Engagement depth: Are they actually using the product—or just opening it?
• Expansion impact: Does this feature create ripple effects elsewhere?

In an AI-accelerated environment, measurement becomes more powerful—and more dangerous. It’s easy to drown in dashboards. Great teams focus on signal, not noise.

The sunset playbook

Sunsetting a product or feature isn’t the glamorous part of building - but it might be the most important. It’s the final act in the lifecycle, and too often, it’s the one we neglect.

Endings in tech tend to be quiet, ambiguous, and poorly communicated. Users are left confused. Teams move on without closing the loop. And over time, these ghost features linger - creating debt, distractions, and drag on future work.

But great teams treat endings with the same intention they give to launches. They approach them not with shame, but with clarity. They design the final experience with the same care as the first click.

When do you kill a feature, product, or investment? When it’s no longer earning its keep. But that answer requires context.

Trigger points:

• Growth has plateaued, and retention is declining.
• Users are confused or indifferent.
• The maintenance burden outweighs the upside.
• It no longer fits the strategic narrative.

Principles for a clean kill:

• Start with learning: Every sunset is a chance to document hard-earned insight.
• Be decisive: Draw a line. Don’t half-retire it.
• Close the loop: Let users know. Let stakeholders know. Let your roadmap reflect the decision.
• Celebrate the discipline: Sunsetting is not failure. It’s momentum with judgment.

In his book Ends, Joe Macleod talks about the systemic lack of designed endings. In tech, this shows up as forgotten features, silent shutdowns, and user experiences that just fade without closure. But great product teams design intentional endings. They see the end as part of the journey—not an afterthought. They create clarity, not confusion. And they give teams room to grow by freeing them from legacy weight.

What changes in an AI-first world

AI is changing the tempo of product work. What used to take months to validate can now be prototyped and tested in hours. The speed of iteration is no longer bottlenecked by engineering velocity or bandwidth. Instead, it's constrained by judgment—by how quickly you can read the signal, make the call, and shift direction.

This isn’t just about acceleration. It’s about what acceleration enables: cheaper tests, more frequent bets, faster invalidation. AI makes it possible to kill faster - but only if you’re willing to let go of the illusion of certainty. In a world of high-speed decision loops, perfection is a liability.

The real competitive edge isn’t building more. It’s killing better.

What used to take months of development can now be prototyped in days with AI tooling. Market feedback is instant. Behavioral analysis is automated. Sentiment clustering, workflow tagging, anomaly detection—it’s all happening without the team lifting a finger.

Which means:

• You can test more.
• You can measure faster.
• And you can pivot without breaking stride.

But here’s the danger: more tests mean more noise. More dashboards. More justifications to keep something alive. The best teams in this new world won’t be the ones that build the most—they’ll be the ones that kill the fastest with the clearest reasons.

Rapid invalidation is the new superpower.

Final thought

There’s a cultural bias in tech towards motion. If something’s moving - even slowly - we hesitate to stop it. But the reality is: most of the things holding teams back aren’t dramatic failures. They’re the slow drags. The almosts. The "it might still work" ideas that consume time, energy, and attention without earning their keep.

Killing work is a creative act. It’s an act of focus. It signals that your team has the discipline to choose what matters over what’s familiar. And it’s that discipline that creates room - for new bets, better ideas, and bigger impact.

You don’t scale by saying yes to everything. You scale by saying no, decisively and with purpose. Whether it's a feature, an initiative, or a bet that just didn't land - killing it is a mark of clarity, not failure.

In product, just like in writing, the most enduring advice is still the most uncomfortable:

Kill your darlings.

What’s the hardest thing you’ve killed in your product career? Hit reply or share it with me. I’d love to hear the story.