Shipping and specialties
Iterate or kill
Double down, iterate, or sunset. Killing is underused. Endless polish on a bad bet is overused.
Not every theme deserves a build. After you have channels and counts, map the theme to a decision: double down, iterate or kill.
Killing is a product decision with a communications plan, not a silent delete. Dragging a zombie feature "until we have time" is how codebases and roadmaps calcify. See prioritization.
Concept
Double down when the product works for people who find it — the feature is fine, the reach is not. Iterate when people try the path and bounce. Kill when, after a fair learning window, neither engagement nor outcomes justify the maintenance tax.
Walking through the fork
Double down: improve distribution, onboarding cues, sales narrative, pricing clarity.
Iterate: redesign steps, cut scope, fix performance. This is the default healthy response to post-launch feedback. See launching.
Kill: announce an end date, offer export or migration, stop selling, then remove.
Trade-off
Iterate when retention or activation for the feature's users is salvageable with bounded work. Kill when the opportunity cost (eng hours, support macros, cognitive load in the UI) exceeds expected upside — especially if it blocks a cleaner redesign.
Warning
Roadmap-by-loudest-customer is how you build an unmaintainable product for your top five accounts. Weight reach × severity × strategic fit, then check against jobs to be done and strategy — not against who yelled in Slack.
Sunsetting without destroying trust
Treat a kill like a reverse launch:
- Confirm the data — usage, revenue, support hours, eng maintenance for two quarters.
- Map dependencies — APIs, mobile screens, contractual mentions, partner integrations.
- Align internally — sales stops selling today; support gets scripts; legal reviews data retention.
- Announce with a firm date — often 60–90 days for paid B2B; longer if migrations are heavy.
- Give a path — export, replacement feature, or partner alternative. No path = cancellation theater.
- Execute — turn off new usage first if needed; shut down on the date; archive code and write a short learning note.
Soft language ("we're evolving the experience") without a date is how sunsets drag for a year and never free the capacity you claimed.
Quarterly kill review: list features below a usage threshold (e.g. <2% of MAU in 90 days) for explicit keep / improve / sunset.
Common mistakes
- Endless polish on a bad bet. Killing is underused.
- Sunset without a date or a path. Trust and capacity both fail.
- Weighting Slack volume over reach × severity × fit.
Check yourself
A feature has <2% of MAU, high support hours, and blocks a redesign. Iterate or kill?
Kill — after a dated sunset with a migration path. Opportunity cost exceeds upside.
People who find the feature love it; almost nobody finds it. What is the move?
Double down on distribution and cues, not a rewrite.
Key takeaways
- Explicitly choose double down, iterate or kill.
- Sunsets need dates and migration paths. Soft language without a date drags for a year.
- Weight reach × severity × strategic fit, not the loudest account.
Further learning
Back to the map in iteration and feedback.
Related
Iteration and feedback loops
Turning feedback, support tickets and data into continuous improvement and kill decisions.
Launching products and features
Launch tiers, betas, checklists and measuring whether a launch worked.
Prioritization
RICE, ICE, Kano, cost of delay and opportunity cost: choosing what not to build.