Killing Product Features With?Tact

After almost 1 year of silence, I had to think quite carefully what would trigger my comeback in writing again frequently about topics that matter.

So while preparing for the ProductTank Rotterdam panel discussion, I decided to take the time and actually write a piece about “Killing Product Features”, sharing my learnings, since this is something that product people come across and usually feel quite stressed with handling it.

Personally, I think being open in realising when a feature has taken a toll is an art and unfortunately few teams depict the benefits behind it.

Killing features is as sacred as building new functionalities and should be taken seriously as it will prevent you from turning your products into graveyards

In this article we will look at certain important elements that will hopefully shed some light when coming across those type of decisions.

How do features build up anyway?

There are numerous reasons that may lead your product backlog looking like an endless feature list and you not really knowing if all those are truly necessary and will eventually bring value.

Below are four of the most common ones:

1. Quick competition copy

This one is one of my favorites. Being a product manager means you are looking at both direct and indirect competitors often, watching their moves carefully to understand some customer needs that probably you have not figured out yet. It can save you some precious time on research, AB testing etc.

Looking at your neighbour’s garden though does not mean that you should also plant a look- alike lemon tree despite the fact that you are allergic to lemons

One thing is looking and another thing is copying. Before you make a move, spend some time in carefully understanding why they made this move, do you have the same business model, a comparable value proposition, an identical customer segment focus and many more?

2. Very specific customer need aka focus on a niche

How often do you conduct qualitative research and interview customers? How often do you talk to 6 people, 2 of which struggle with basically everything you asked them and since they also happen to be frequent customers, you jump to extrapolating that outcome into “our users cannot find products on our platform”.

Now this, right there, is a trap. You should recognise it and instead of directly writing a user story for the upcoming sprint rather generate more insights to validate this initial hunch.

3. Stakeholder request

All time classic that will never settle. Do you also have those stakeholders that represent your customers? That ask for certain features because this is what the customer wants? Are you also one of the product teams where 80% of your roadmap or sprint is a stakeholder wishlist?

Yup, you got that right, another trap. Stakeholder ideas are very much welcome but you, as a product person, need to bring them in the right context, match them with your strategy and roadmap, take them as potential “to dos” in your next interaction with a customer to validate them. So many things you can do before you actually go ahead and build something.

4. Team member idea

This one is a tricky one and I will explain why. If you have reached a phase where you as the PM are not the “what we work on” and the team is “how we do it” but rather have a team that actively shapes the product, congratulations.

This is very rare, comes after lots of effort in really being a team and you should hold on to it as long as you can.

Careful though, you should do your job as a PM and make sure the team has the relevant context always and you still prioritize those ideas and validate them.

When Should You Kill a Feature?

This is definitely an ongoing process. There is no specific timeframe in the quarter where the PM stops and reflects “to kill or not to kill” but should continuously do so throughout the product development journey.

Remember more is not always better and with yet another addition you may make your user’s life difficult with the paradox of choice.

Below 6 clues and guiding questions that will signal whether the time has come to bury a feature:

• Product Vision: How is this respective feature contributing to the value of your product as a whole? Is this feature a liability either to new features to come or to existing tech stack?
• Feature Usage: Is anyone even using this? Who is actually interacting with it?
• Impact: Does the respective usage bring us any valuable uplift?
• Value Proposition: Does the feature deepen product/market fit? Is it maybe diluting our product fundamental value? What is the core promise of the product? Remember we do not want a product fruit salad
• Cost of maintenance: What is the amount of effort you put in a slowly deteriorating feature and how much of an uplift would you get if you were to channel this effort to something more impactful?
• User Needs: The world is changing and customer needs are different compared to e.g 2 years ago

What Approach to Follow?

Unfortunately, there is no “one size fits all” approach to this matter nor a recipe where you simply execute the steps. Course of action also highly depends on many criteria like the industry you are in, the type of product, your customer base, the maturity of the feature etc.

Below some of the options you have:

• Pull that bandaid: This is when you decide to shut down a feature completely. Probably it is easier when we are talking about digital platforms and some features that did not have big functionalities behind them or data tied to them etc.
• Strip it down a little: The haircut approach, where you apply a little trimming to give shape again, it will be visible that something changed but no groundbreaking alterations. You can think of a feature that previously had certain possibilities and now only 2 things out of 3 are possible but the feature as a whole is still there.
• Slow transitioning from old to new: This is an approach that you can see in different scenarios. Potential reasons for this could be when e.g refunds need to take place in case this was a paid feature or when introducing a completely new way of working e.g in JIRA so teams need certain time to get used to it and still remain efficient while they undergo this change.

Pro tip: No matter what happens, remember to feel good about the decision and don’t be emotionally attached to things for too long. You typically hear or think of “we had it many years, it was one of the first features we introduced, how can we remove it”. You can and you will and life will continue with other valuable features.

Communication Strategy

Time has come to discuss communication strategy, one of the most delicate parts. Your handling here can either make things much easier and smooth or turn your life into a living nightmare, so choose your steps with caution. Remember you are dealing with humans, internally or externally, which means emotions, which means limited predictability and feeling uncomfortable to any change disrupting a routine.

Having said that, all internal departments need to be informed and aligned on this effort: From Sales to Customer Support to Account Management with the intention to avoid last minute surprises, do all necessary activities prior to the change and be prepared on how to answer questions, handle potential complains etc.

Customers should also be informed in advance about upcoming changes through any means that suits your product best and there should also be guidance on what happens from now on as well as reassurance that they are not missing out on anything crucial.

Unsuccessful Launch Recovery

Even though we do everything in our power to not face an unsuccessful launch with an underperforming feature on our laps, I would be lying to you if I said this will not happen.

The important thing is to embrace the underperforming features, expect them, learn tremendously and come out stronger

My 3 tips to you:

1. See it as a learning: It happens to everyone and to very successful companies too, it is part of the journey
2. Understand what went wrong: Is it the product, is it the customer segment, was it the poor tech execution or the fact that you did not spend enough time to understand the customer needs? Look at your data and talk to your customers again till you get it right
3. Improve and return stronger: Now that you know better, apply the changes you need in the product messaging, the sales strategy, the pricing or the actual product promotion, rise from the ashes and nail it ??

Unfortunately, I have not seen product teams killing features enough. If you are a product leader, channel your energy in building the right culture to enable that. A culture that sees failure as a learning and encourages those missed shots. PMs are very often afraid of the consequences, of the fear of being perceived as failures and this needs to change if we aspire in building products that matter in the years to come.

The article was initially posted @medium. Don't miss out on previous posts.

Photos within the article are from Pexels.