The importance of pissing your users off

One of the best things you can do for your business!

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 is important to the health of your product and business. (This article was originally published on Mind The Product).

This started when Lena Stamenković posted on LinkedIn 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.

Why kill features?

First, here are several reasons I could think of in the abstract:

• No ROI.
  Generally, 80% of revenue is attributable to 20% of features. If you know a feature doesn't resonate with users but is costing you money to maintain, then it's slowing you down (opportunity cost as well as actual cost).

• Change in strategy.
  If the company decides on going in a different strategic direction, it may make sense to deprecate certain features as not supporting it or actually clashing.

• Some new executive had a Bright Idea™️.
  Let's not discount the fact that not all decisions are rational (or at least data-driven).

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 ('every line of code will one day need to be maintained', as the saying goes). If the feature isn't bringing in sufficient revenue (directly monetised) and/or isn't a consideration in buying decisions, then the cost of maintaining it isn'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's actually good practice to prune the deadwood out of your garden -- err, application 😉 -- and not enough companies do it nearly enough. Keeping the junk just because 'someone is still using it' 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'll lose from annoyed users vs the benefit of freeing resources to work on more important features, and decided it'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.

Should YOU kill features?

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).

No Demand

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 data 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 & 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.

Direct and Indirect Economics

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 feature 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?

Chop-Chop time

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.