post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

mission statement

Deep dive: Crafting your product vision and mission

Podcast

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Assaph served in the army, speaks several languages, and is proficient in many martial arts, but promises he isn't a spy. He's also written several books, but though he learnt storytelling, editing, and marketing from publishing them they're about worlds well before computers and Product Management. Regarding this, he has filled various roles in technology for 25 years, has been a Product Manager for half that, and has been leading product teams for the past few years, so he likes to think he has a clue.

You can connect with Assaph professionally on LinkedIn, read his Substack on https://assaph.substack.com/ or find his creative efforts on Egretia.com.

Assaph Mehr

When was the last time you pissed off your users? Why so long — hurry up and do it!
Wait, what?
Today we’re going to talk about why doing so may be the best thing for the health of your product and business.
<a href="https://www.linkedin.com/feed/update/urn:li:activity:7078256436727685121/" target="_blank" rel="noopener">This started when someone posted on LinkedIn</a> about a favourite product killing a favourite feature, and tagged me to ask whyyy would someone do something like this? Whyyyy?!?
Besides conjecturing possible reasons (looking from the outside), I thought this is actually a really good example of product management, why it’s hard, and an area that is often not done well and worth inspecting.
<h2>Why kill features?</h2>
First, here are several reasons I could think of in the abstract:
<ul>
<li>No ROI. 
Generally, 80% of revenue is attributable to 20% of features. If you know a feature doesn&#8217;t resonate with users but is costing you money to maintain, then it&#8217;s slowing you down (opportunity cost as well as actual cost).</li>
<li>Change in strategy. 
If the company decides to go in a different strategic direction, it may make sense to deprecate certain features as not supporting it or actually clashing.</li>
<li>Some new executive had a Bright Idea™️. 
Let&#8217;s not discount the fact that not all decisions are rational (or at least data-driven).</li>
</ul>
Usually, consumer products have more data behind them, and the higher you go towards enterprise software the more qualitative the decisions are. The more usage data you have, the easier it is to calculate ROI. All features have a cost to maintain them, always (&#8216;every line of code will one day need to be maintained&#8217;, as the saying goes). If the feature isn&#8217;t bringing in sufficient revenue (directly monetised) and/or isn&#8217;t a consideration in buying decisions, then the cost of maintaining it isn&#8217;t necessarily worth it.
As a reminder, I and others have spoken about it before: a dev team costs roughly $1.5m per year, or $30,000 per week. YMMV, but you can estimate your costs pretty well to confront executives: “The dev team spent X number of days last year on this, which costs $Y, while the return we can attribute are $Z. This isn’t nearly the 6x returns we’d typically look for.”
It&#8217;s actually good practice to <a href="https://www.mindtheproduct.com/how-to-turn-factories-into-gardens-assaph-mehr-on-the-product-experience/" target="_blank" rel="noopener">prune the deadwood</a> out of your garden &#8212; err, application 😉 &#8212; and not enough companies do it nearly enough. Keeping the junk just because &#8216;someone is still using it&#8217; can actively slow down your ability to innovate for whole markets and move in your strategic direction. It’s something that’s seen more in consumer products (where you aren’t tied to big accounts), and almost never in enterprise software. All sorts of correlations here, between available data and business models to speed of innovation — draw your own conclusions about causation.
So why did the company kill the feature? Someone has done a calculation based on available data, estimated the amount they&#8217;ll lose from annoyed users vs the benefit of freeing resources to work on more important features, and decided it&#8217;s worth it.
Note that this discussion applied just as much to products as part of a portfolio as to features inside a product. It’s just a higher level, but conceptually the same.
<h2>Should YOU kill features?</h2>
Yes, absolutely.
WAIT! Put that shotgun back! I’m not done with you yet.
Have you ever noticed how when portions in restaurants get smaller, or quality degrades, it’s that much more annoying than the explicit “we’re sorry but we have to put prices up”? Taking something away that users have come to expect, tends to annoy them — often beyond the value of the feature.
In the same vein that we harp on “building the right thing”, understanding needs and scopes or markets and problems, and making evidence-backed decisions, we should treat retiring features in the same way.
As Marty Cagan says, “great products serve your customers in ways that work for your business.” As above, we’re assuming that the feature is killed because it no longer works for the business — either because it doesn’t solve a real customer problem (no demand) or some other consideration (directly or indirectly economic).
<h2>No demand</h2>
I’ve seen this play out a thousand times in enterprise software. There’s this feature we developed to win BigCo™️, no one else is using it, it’s complicating the product for everyone else — and yet we’re scared to remove it.
There’s a real cost in maintaining features, which is often hard to quantify — how can you demonstrate that code complexity is slowing overall development down? There is a huge volume of research showing that simplifying, ripping out the unnecessary, focusing on core value, all contribute to enhanced growth. That less is indeed more. But it’s a hard argument to win, as the organisation remembers fondly that early customer, values that logo, etc. However, those are “soft benefits”, so if you are arguing with dollar signs you’ll win the executives over.
My recommendation is to gather as much <a href="https://www.mindtheproduct.com/storytelling-and-driving-accountability-with-data/" target="_blank" rel="noopener">data</a> as you can (actual usage statistics, user interviews about real value, possible alternatives or workarounds) and pounce when the time is right: when you’re pushed to increase performance, improve UX, address a conflicting demand.
Of course, you might be lucky and working in an organisation where the data speaks louder and win the above argument to kill the feature. At that point you need to brace yourself for the customer &amp; user backlash from the loud minority. Remind yourself of the reasons and numbers, try to prepare an alternative path for them as much as possible, and just weather it. The storm will die quickly enough, when the next shiny thing comes out.
<h2>Direct and indirect economics</h2>
Direct economic considerations are monetisation returns you get from that feature (eg an add-on module, where sales have dropped but still costs you a teams’ time to maintain.
Indirect considerations are for example a change in strategy. While the feature / product may still pull its weight, the expectation is that it won’t take you where you want to go. As an extreme example, moving a server-based product to a SaaS offering.
In both those cases the impetus to kill the <a href="https://www.mindtheproduct.com/how-canva-uses-ai-powered-features-to-drive-plg/" target="_blank" rel="noopener">feature</a> arises internally within the company. Again, data — quantitative and qualitative — is your friend. Having a solid understanding of the economics backed by numbers will help you align everyone.
When it comes to communicating outwards, you will need a quantitative measure of the affected customers and qualitative idea of the solution you’re taking away. You probably wouldn’t want to disclose your economics to the users, but the same first-principles thinking that led you to building a feature can help you in decommissioning it: messaging the right customers about their specific pain-points, offering alternative, selling future value. Helping users prepare for the transition would smooth out the reactions.
As with the case of no demand, there will be an immediate negative backlash from users, but it should die out pretty quickly. You can (and should) track this as well. How many customers have taken up alternative solutions? What’s the trend in customer satisfaction surveys after a week, a month?
<h2>Chop-chop time</h2>
If you’ve done your homework, the business impact should be a short PR storm followed by improved economics.
You should do your homework and applied the same rigour to decommissioning a feature or product as you do to embarking on building a new one. It doesn’t matter if it started with “I have this idea for something new” coming from an SME or the market or a “this crap is killing us” coming from the dev team. If you understand the users’ context and business economics, you should be ready to fight for doing the right thing, whether building or killing features.

When was the last time you pissed off your users off?

Assaph Mehr

Read more

Comments