Building the Product

When is it right to stop iterating on a feature and just kill it?

A starting point

Founders keep polishing losing features because killing something feels like admitting failure, but a dead feature is a tax on every future change. As a starting point: give a feature a fair window and a clear bar, and if barely anyone uses it after honest promotion, remove it and tell the few users why. Cutting a feature is a shipping decision too, and a smaller product you fully stand behind beats a bloated one you are quietly ashamed of.

Go deeper

Hand-picked from around the web, each with a note on why it earns your time.

2 resources 2 link-checked

Read

📄 Article
✓ Link checked Free Intermediate

Why we picked it This is the rare sunset guide that walks through a real decision, Pendo retiring its own Trends report when usage fell to about 1 percent, so you see the actual signals and the sequence, not just theory. It gives you concrete triggers (dwindling usage, a newer feature that replaced the old one, direct feedback) and a practical checklist for stopping new usage, communicating a timeline, and migrating people off. Treat it as a starting point for building your own kill criteria, then adjust the thresholds to your product's scale.

How to effectively remove and retire a feature from your product

From Pendo by Mei Luo About 8 minute read

  • Low or dwindling usage over time is the clearest signal, but pair the number with why: a feature nobody finds is different from one nobody wants
  • Sunsetting is a process, not a switch: stop new usage first, tell existing users on a clear timeline, and hand them the alternative
  • Get internal alignment across sales, success, and support before you announce anything externally
Open pendo.io →
✍️ Essay
✓ Link checked Freemium Intermediate

Why we picked it Gupta's core argument is the mental unlock most founders need: teams are wired to add because launches get rewarded and removals get punished, so bloat is the default unless you fight it. He reframes killing a feature as a growth tactic, not a cleanup chore, which is exactly the shift you need before you can pull the trigger without guilt. Note the deeper frameworks sit behind a subscriber wall, so read the free portion for the argument and decide if the paid detail is worth it.

Addition by Subtraction: The Art of Killing Features

From Product Growth (Aakash Gupta) by Aakash Gupta About 15 minute read

  • Organizations systematically over-add because shipping gets celebrated while deprecation gets no credit, so simplicity needs a deliberate champion
  • Removing the right feature can move the numbers more than building a new one, since it sharpens the core value instead of burying it
  • Frame subtraction as a strategic skill you practice on a cadence, not a one-off spring cleaning
Open news.aakashg.com →

People also ask

How do I decide what to build next? Prioritize outcomes, not output, and use a simple scoring frame like RICE, Reach x Impact x Confidence, divided by Effort, to compare ideas honestl... Intermediate 2 resources → How often should an early-stage startup ship? Ship weekly, at least, cadence is a competitive advantage because faster loops mean faster learning. You haven't really started until you launch, a... Beginner 2 resources → How do I build a roadmap without over-planning? Work in short fixed cycles with variable scope, Basecamp's Shape Up runs on six-week bets, not a rigid multi-quarter Gantt chart. Make a few bets y... Intermediate 2 resources → How do I keep talking to users while I'm heads-down building? Make discovery continuous, not a one-time phase: interview a customer or two every single week, even in a build sprint. Teresa Torres's opportunity... Intermediate 2 resources → How do product teams keep a consistent shipping rhythm as they grow? Separate your planning cadence from your execution cadence and lean on async updates instead of endless meetings. A predictable operating rhythm, w... Advanced 2 resources → How do I say no to feature requests without losing customers? Anchor every 'no' to the outcome you're chasing and the customers you're building for, most requests are solutions in disguise, so dig for the unde... Intermediate 3 resources →