Remove Don’t Add
Hey Ant here, I started this newsletter to share the lessons I wish someone had told me 10+ years ago early in my product career. Expect to find practical lessons on building products, business and leadership. If you prefer podcasts or videos, check out my YouTube.
Recent posts you might have missed:
- The AI Chasm
- Improve Your Influence (not clickbait, this truly did for me)
- You Don’t Need Another Prioritization Framework: Just These 4 Components
Why the best product decisions are often about what you remove, not what you add.
When was the last time you removed a feature?
What about sunsetting an underperforming product?
It’s totally normal if your answer was never - or “I don’t know”.
We have a tendency to default to more = better.
There's this fascinating study out of the University of Virginia where they ran eight experiments asking participants to improve something. Overwhelmingly participants defaulted to adding rather than subtracting.
In one experiment, participants were asked to stabilize a Lego structure where there was a simple subtractive solution; removing a block was free to do, whereas adding anything cost money. And even still, roughly 60% of people didn't even consider the subtractive option.
This is a great example of where more is not always better.
Sometimes it actually makes things worse.
But I understand the thinking. How could having more features not be better? Right!? After all, you're getting more for your money.
However Pendo's 2019 Feature Adoption Report, which analyzed usage data across 615 software products, found that approximately 80% of features are rarely or never used.
In fact, on average, just 12% of features drive 80% of daily usage - a great example of the Pareto principle in practice!
But consider what this means for a second.
The vast majority of what we build is collecting dust.
And it's not just waste. It's what I call ‘negative value’.
Negative Value
‘More = better’ thinking assumes that every idea we have is net-positive. I wish that was the case, but it’s not.
Sometimes we ship things that end up having unknown or unintended consequences.
Remember Google’s first attempt at ‘AI Overviews’?
When it used to tell you to put glue in your pizza, use your name and birthday as a password and eat rocks.
The challenge is this thinking doesn’t come naturally to us.
We are wired to add, not subtract - Leidy Klotz wrote an entire book on this; ‘Subtract: The Untapped Science of Less’.
Which is why whilst some of you would argue that the metaverse was a dumb idea to begin with. I think Meta making the call to shut it down should be celebrated.
Subtraction is hard. Many companies can’t muster up the courage to say; this isn't working, we need to stop.
This is a key skill product managers need to hone. The best products are simple. They’re not cluttered with noise. Your job is to actively prune the noise.
Building Beautiful Simple Products
It's not just unintended consequences. Every feature you add increases cognitive load for users.
There's a well-established principle in psychology called Hick's Law which states that decision time increases with the number of choices.
More features means more noise, more friction, more choices! Every new thing you add actually makes your product harder to use, not easier.
And this should be an intentional tradeoff you make every time you add something new.
I’m sure you’ve seen this picture before:
And it’s not just user experience.
On the engineering side, every feature carries a maintenance tax. It’s estimated that software maintenance accounts for over 70% of the total lifetime costs.
So that "quick win" feature from two years ago is still costing you daily.
"The road to shitty bloatware is paved with 'just one more feature because the customer needs it.'" - Des Traynor, Co-founder Intercom
Compound this with opportunity cost.
Every minute you spend maintaining and dealing with this increased complexity you could be doing something else.
"You get a great product by saying no to almost everything almost all the time." - Jason Fried, Founder & CEO at 37signals (aka Basecamp)
AI Amplifies The Mess
Unfortunately it’s going to get worse before it gets better.
I’m sure you’re already experiencing this, just about every company has been shipping AI features nobody asked for.
But it’s not just the AI hype.
It’s the fact that delivery is speeding up.
I’ve already started getting questions like;
What’s the post of discovery when you can just build it in a fraction of the time?
Do we still need roadmaps when you can build it in hours?
And I get it but again, this thinking assumes that everything is a net positive.
Throwing AI at your roadmap is a fast path to having a SaaS equivalent of a TV remote with 50 buttons nobody uses.
This is why I'll continue to do discovery, even with AI. The goal isn't speed. Faster in the wrong direction doesn’t help.
The goal of discovery is to de-risk and avoid shipping something that makes things worse. It’s to avoid negative value.
Just because you can build something doesn't mean you should (you still have desirability and viability to work out).
The Fix
As Brennan Collins commented;
"When shipping is your measurement of success, you get more features. And as we stay true to the process and cadence of building, we begin to serve the process and no longer the customer."
This is part of the root problem but I have empathy here.
If we rewind the clock back 100 years the dominate management philosophy was whats been coined "Taylorism" and the ‘division of labour’.
In practice this lead companies to analyze their workflows and look for efficiencies. Often through dividing up the workflow and giving workers very specific and narrow tasks that they could perform efficiently. Imagine building a brush. Someone might need to carve the wood handle, another person would create the brush, another person would attach them, another might paint it, etc.
Each worker would have clear KPIs and it would be the managers responsibility to maintain those targets for maximum efficiency - sound familiar to how some companies operate?
This was great for the industrial revolution, terrible for building complex software.
The problem is a lot of enterprises didn’t get the memo on that one.
So here we are with similar management philosophies being applied.
Lines of code
Designs produced
Features shipped
Story points completed
Or my favourite I heard; number of powerpoint slides produced (no joke!)
Stuck measuring outputs, not outcomes.
Which incentivizes adding not removing - when was the last time someone got promoted for removing a feature?
But as we know well, the best product teams operate differently. They focus on outcomes.
BUT…
I know what some of you are thinking. "But Ant, those features were added for a reason. You can't just rip things out."
And you're right.
I'm not saying you should remove features for the sake of removing features. That's just as mindless as adding for the sake of adding.
The real shift is:
Start considering subtraction as a viable means to solving problems
Focus on outcomes and remove anything that’s not working
When you work backwards from a clear outcome, what to add AND what to remove becomes obvious. Both become consequences of moving towards a vision, not arbitrary decisions.
This is why strategy matters so much. Without a clear picture of where you're headed, you can't make good subtractive decisions. You need to know what you're optimising for before you can decide what doesn't belong.
FYI talking about product strategy - I’m running a live cohort in June. Learn to build a product strategy, communicate it and how you can use AI to help in 3 weeks.
Enroll here.
And there's also an important distinction between "rarely used" and "never used."
Something that's “never used”? Investigate why and remove it (or pivot to improve it so it does get used).
But something that's “rarely used” might be incredibly valuable. For example, forgot password. We don’t expect that to be used frequently but your users do hope it exists (and works) when they need it.
For these you might need to triage what is genuinely useful just infrequently used vs those which are underperforming and not adding value.
And remember that removing is great but not building something that doesn’t add value in the first place is even better - this is why we do product discovery.
The "NOT Doing" List
One of the most practical things I recommend to every PM and product leader I coach is to create a "NOT doing" list.
You’ll notice this is a common theme across the real product strategy examples I have collated in here.
[insert image with screenshots highlighting NOT doing]
And it’s exactly what it sounds like. A deliberate, list of things you've chosen not to pursue and why.
"The essence of strategy is choosing what not to do." - Michael Porter, author Competitive Strategy
Warren Buffett has a version of this, the 5/25 rule where you write down 25 goals and then circle the top 5. Everything else becomes your "Avoid-At-All-Cost List." Not a backlog or “I’ll get to it later” - it’s an avoid list! Because Buffett understood the value of focus.
"The difference between successful people and really successful people is that really successful people say no to almost everything." - Warren Buffett
So here's my challenge to you.
Look at your current roadmap or backlog or product strategy (if you have one)
And ask yourself, when was the last time you removed a feature?
Strategy is as much about what you choose NOT to do as what you choose to do.
So be deliberate, not just in what you’re choosing to do, but in what you’re choosing NOT to as well.
Hope that helps.
If this resonated, forward it to someone whose product could use some pruning.
And as always, if you have any questions — hit reply, it comes straight to me.
Thanks!
/Ant
P.s. don’t forget to join next week’s live stream on ‘AI-Powered Product Strategy: My (new) Quarter Review Process’
Register here if you’d like the recording sent to your email.
Or join us live on Youtube here.
And if you’re interested in deep diving into Product Strategy further, join my upcoming live cohort.
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…