📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This is the cleanest short argument that a product keeps its value by staying focused, not by accumulating features. It walks through why the feature you designed, fought for, and launched is exactly the one you defend past its usefulness, and why cutting it is part of the job. Read it when you feel guilty about removing something you built.
From
Intercom
by Ruairí Galavan
8 min read
- A product holds its value by keeping focus, not by piling on features
- The features you fight hardest for are the ones you defend past their usefulness
- Killing a feature is a normal product decision, not a failure
Open
intercom.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Des Traynor makes the case that "no" is the product strategy, and that adding a feature for one loud customer quietly costs every other user. It gives you language to defend a tight v1 against constant requests. Short, sharp, and directly about the discipline of cutting.
From
Intercom (Des Traynor)
by Des Traynor
~8 min read
- A cohesive product with clear boundaries beats a pile of tangential features.
- Every feature you add has an ongoing cost, not just a one-time build cost.
- No single customer request is worth more than a coherent product.
Open
intercom.com →
📄 Article
✓ Link checked
Freemium
Intermediate
Why we picked it
A practical checklist drawn from many product leaders on the exact question of when a feature has earned its removal. It gives you the concrete signals (low usage, high maintenance, off-strategy) and how to actually retire something without burning the few users who rely on it. This is the closest thing to a decision framework for your question.
From
Lenny's Newsletter
by Lenny Rachitsky
10 min read
- Look at usage, maintenance cost, and strategic fit together, not one alone
- Set a clear bar in advance so the call is not emotional
- Give the few remaining users a real off-ramp and an explanation
Open
lennysnewsletter.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
This is the warning label for treating every customer request as a build order. Chen shows how a team can keep shipping requested features, keep honouring the letter of promises, and still slowly die because none of it moves the business. It sharpens the short answer's point that exciting or requested does not equal important.
From
andrewchen.com
by Andrew Chen
- Building every requested feature can still lead nowhere
- Ask why behind a request before you commit to building it
- Honouring promises literally is not the same as growing
Open
andrewchen.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
A product team's honest account of the ongoing cost every shipped feature adds to engineering, design, support, and the next decision you make. It reframes a dead feature as a tax on all future work, which is the exact point of our short answer. Good for convincing yourself, or a co-founder, that removal is progress.
From
HubSpot Product Blog
by Daria Marmer
7 min read
- Every feature carries permanent maintenance and support cost
- A rarely used feature can eat a large share of your team's time
- Removing the right things speeds up everything you do next
Open
product.hubspot.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This treats unshipping as a craft with real upside, not just cleanup, and shows how to use usage data to decide what goes. It is helpful for the founder who has the instinct to cut but wants evidence and a repeatable method before pulling the trigger. Practical on how to actually communicate a removal.
From
Mixpanel
by Neil Rahilly
9 min read
- Removing a feature can improve the product, not just tidy it
- Let usage data, not attachment, decide what stays
- Plan the communication before you unship anything
Open
mixpanel.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
Written for solo and small-team founders, this makes the case that saying no and removing features is a survival advantage when you have limited hands. Arvid is direct about the sunk cost feeling and why keeping a feature alive just because you built it is the expensive choice. Grounded in bootstrapped reality rather than big-company process.
From
The Bootstrapped Founder
by Arvid Kahl
10 min read
- A smaller surface area is a gift when your team is tiny
- Keeping a feature because you built it only grows the maintenance bill
- Omission is a positioning and focus tool, not just cleanup
Open
thebootstrappedfounder.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
The step-by-step operational side of your question: once you have decided to kill a feature, how do you actually retire it without breaking trust. It covers identifying who still uses it, sequencing the wind-down, and telling those users why. Pairs well with the more philosophical pieces above.
From
Product Teacher
by Clement Kao
9 min read
- Deprecation is a process with steps, not a single delete
- Find out who still depends on it before you remove it
- Clear, early communication is what protects the relationship
Open
productteacher.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This gives you the simple two-axis map (how many people use a feature, and how often) that turns a gut feeling into a picture of what is actually dead weight. Plotting your features this way makes the removal candidates obvious and the argument easy to share. A concrete tool to set the clear bar our short answer asks for.
From
Intercom
by Des Traynor
6 min read
- Chart features by breadth of use against frequency of use
- Low-and-rare features are your first removal candidates
- The map turns a subjective call into a shared, visible one
Open
intercom.com →
✍️ Essay
✓ Link checked
Free
Advanced
Why we picked it
Doshi names the IKEA effect, how you overvalue what you built simply because you built it, which is the quiet engine behind gold-plating. It pushes you toward judgment about what matters over the reflex to keep improving your own creation. Best for the founder who suspects attachment, not need, is driving the polish.
From
Shreyas Doshi (Substack)
by Shreyas Doshi
12 min read
- You overvalue what you build, so discount your own certainty.
- More features and polish are not the same as more impact.
- Judgment about what to skip beats effort spent building.
Open
shreyasdoshi.substack.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
A short, practical answer on how to actually decline feature requests and keep the product lean, including their line that you rarely regret saying no but often regret saying yes. It is the everyday habit behind not needing to kill features later. Useful language you can borrow when you turn a request down.
From
Signal v. Noise
by Jason Fried
5 min read
- You rarely regret a no, you often regret a yes
- Most requests do not deserve to become features
- Saying no is how you protect a product you can stand behind
Open
signalvnoise.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
A punchy, contrarian classic on building a lean, sane, profitable company from the founders of Basecamp. It's the antidote to hustle-culture folklore about how startups must operate.
From
37signals
by Jason Fried & David Heinemeier Hansson
~288 pages
- Small teams, less process, and shipping beat planning theatre
- Say no to most things and protect focus
- You can build a great company without following the standard playbook
Open
amazon.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The single best thing ever written on customer conversations. It teaches you to ask about the customer's life and past behaviour, not your idea, so you can't be lied to. If a founder reads one thing before talking to a single customer, it's this.
From
momtestbook.com
by Rob Fitzpatrick
~130 pages
- Talk about their life, not your idea.
- Ask about specifics in the past, not opinions about the future.
- 'That's so cool, I'd totally buy it' is a compliment, not data, dig for commitment and evidence.
Open
momtestbook.com →
📄 Article
✓ Link checked
India
Free
Intermediate
Why we picked it
Zerodha built its products in-house rather than leaning on outside vendors, and Kamath explains how staying close to the build let the team turn deep domain knowledge into a better product. It is a strong Indian example of why owning the build compounds over time. Read it for the case that domain expertise plus hands-on building is a durable edge.
From
Inc42
by Nithin Kamath
12 min read
- Building in-house kept Zerodha close to its domain.
- Vendor products are hard to customize and own.
- Hands-on building compounds domain expertise over time.
Open
inc42.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
A practical playbook for the part founders fear most: removing a feature while keeping the few users who relied on it on your side. It covers how to identify affected users, time the change, and message it so the removal reads as care rather than abandonment. Directly supports the tell the few users why part of our answer.
From
airfocus
by Andrei Tiburca
9 min read
- Identify exactly who still uses the feature before removing it
- Give notice and, where you can, a migration path
- How you communicate the cut decides whether trust survives it
Open
airfocus.com →
