Killing a feature is also important

When it comes to adding a feature to your product, there are countless ways of doing this – and we still mess it up. However, when it comes to killing a feature there isn’t much out there.

As product managers we get excited to take the product to the next level with new features. But deep inside we know there are some features in your product that simply don’t work anymore. You are tracking your product with countless KPIs and metrics to see the health of your product, and its right on the dashboard when a feature isn’t getting clicks or for that matter appreciation (feedback). We either ignore them or simply stop tracking them.

Features that don’t work cost money to support. Worst, just by being present in the product they complicate workflows and risk distracting your users from their core tasks.


You may have heard your customers complain at times: “Your product is to complicated or bulky”. There is a high likely hood that there are features sitting in your product that isn’t being used that’s adding to this bulk and complexity.


Removing a feature isn’t simple. You can’t simply release a new version without a feature. You have to treat removing a feature the same way as adding a new feature to the product:

  • does the existing feature align with your overall product vision & strategy.
  • deprecating a feature needs user search, interviews and analysis.
  • deprecating a feature needs planning, included in the roadmap, and communicate with your users.

To decide if a feature needs to be deprecated:

  • check with your users what are they using to solve their problems instead of your feature.
  • did the feature miss the market?
  • the feature may solve a user problem but its unsustainable for you.
  • the feature solves a problem for a very small set of users, but its not a problem worth solving for you.

When deprecating a feature, communication and transparency is key. Ensure you have two set paths, i.e. End of Life (EoL) and End of Support (EoS) and there is sufficient time for the users (if any) to move to other options if they are using this feature.

To ensure a successful EoL and EoS,

  • remove the feature so that new users do not have access to this
  • de-emphasize the feature in the UI – out of sight out of mind.
  • suggest alternatives and help your users migrate

Lastly, make sure this is part of your continuous onboarding strategy, where you are communicating this to your users and helping them migrate through the EoL and EoS timeframe.

Product vs Feature teams

Marty Cagan writing about Product vs Feature teams:

In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.

When I talk and write about how tough it is to be a true product manager of an empowered product team, it’s precisely because it is so hard to ensure value and viability. If you think it’s easy to do this, please read this.

The lack of giving up control and delegating to your product team is probably the biggest reason I see very few product empowered teams.

Feature teams are set up similarly, but with a stark difference:

However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap.

If they say they need you to build feature x, then they believe feature x will deliver some amount of value, and they believe that feature x is something that is viable for the business.

Whichever way you see it; they both are squads but the differences run deep, but I’ll leave you with that I think is the most important

Let’s start with the role of the product manager. In an empowered product team, where the product manager needs to ensure value and viability, deep knowledge of the customer, the data, the industry and especially your business (sales, marketing, finance, support, legal, etc.) is absolutely non-negotiable and essential.

Yet in a feature team, that knowledge is (at best) dispersed among the stakeholders.

Controversial topic but an essential read.

Avoid feature bloat and deliver your product strategy

Even the best products including your favorite product (can) suffer form feature bloat. In my last article Measuring Feature Adoption – I talked about measuring feature adoption. Tracking feature adoptions will help you avoid feature bloat.

A product filled with non-performing features causes

1. accumulation of technical debt,
2. increased maintenance costs,

leading to a lower customer satisfaction (NPS score) and a lack of market differentiation.

Features too have an iceberg problem. They may seem to be small features but turn out to have huge costs. This can happen when you decide to ship a feature for a specific customer or a use case instead of shipping new products.

Avoiding feature bloat

One way to avoid feature bloat is to have a strategic approach on the bigger picture. Focus on outcomes instead of output.

Avoid focusing on shipping features. Product teams should focus on the number of problems solved and the positive impact on their customers – this directly results in a better NPS score.

When you focus on the outcomes, it allows you to gather feedback from customers, talk to them more often to test your hypothesis for a new feature. Tracking your feature allows you to decide if you should either iterate or pull out this feature.

Finally, doing a feature audit will also help understand how features are being used. Looking at your feature adoption and usage metrics will allow you to decide to to kill an underperforming feature or work on increasing adoption.

Delivering a Product Strategy

As your product evolves and becomes mature, typically in the growth phase – you attempt to serve everyone. In this phase, products can be disrupted by the one big customer’s specific needs or by smaller niche markets.

Segmenting your product based on customer needs, jobs and personas will allow you to bundle your product to different tiers at different pricing options and avoid feature bloat.

It’s Roadmap season

The (fiscal) year is coming to an end and most of us are recharged coming back from the holiday season. It’s the time of the year when product managers are the busiest, emotions run high and frustration sets in. It’s time to make the roadmap for the next year.

Within the organization Roadmaps are a fearcly debated topic. It’s not the principle of a product roadmap; it’s the misunderstandings they bring.

Google “What is a product roadmap” and you will be treated with a variation of definition (classic):

1. A high-level visually summary that maps out vision and direction: What is a Product Roadmap?

2. A high-level, visual representation of the direction your product offering will take over time: What is a Product Roadmap? | Customer Success Software | Gainsight

3. Plan for how your product is going to meet a set of business objectives: Product Roadmap Examples and Definition | Aha!

I like to call product roadmaps as a strategic document or in Gibson Biddle words “The roadmap is an artifact — an expression — of your product strategy”.

Reading Gibson Biddle’s artilce on The Product Roadmap

When I share a roadmap, I express confidence about the next quarter’s projects but highlight that the content and timing of the subsequent quarters are highly speculative. There’s lots of near-term learning that will cause plans to change.

This is extremely important. The classic mistakes we all make is try to set the roadmap in stone at the beginning of the year or if you are flexible enough we try to put in delivery dates for each item.

Having such a roadmap is important. Keep in mind, its the one thing that you can share with your customers to let them know if the direction your product is headed works for them and how by how much.

Remember, a product roadmap is NOT a project plan, its not permanent and most importantly its not a list of features or requirement.

For your product roadmap to express your product strategy focus on outcomes, understand your audience (your stake holders), keep it simple and stupid (KISS), state your product vision and most importantly keep it updated.

I personally follow Gibson Biddle’s quarterly format for my roadmap. Focus on themes its always helped me in aligning teams behind a common goal. It allows for healthy discussion and alignment and it helps to keep the teams focused.