Deprecating is unglamorous, hard work

Adding features into a product is really hard. features from a product (or placing features in an “end-of-life” or EOL state) is really, really, freaking hard. When you *add* a feature, you worry about if a customer will use it. When you *remove* a feature, you worry about that one customer still using it. a feature also has the burden of mismatched expectations — because even if rationally we know this isn’t true, it *feels* like deleting code should be a lot easier than code.

Sadly, removing a feature is not just “deleting code,” and this is a myth that product managers need to dispel both for themselves and for their stakeholders. It’s actually extremely similar to adding a new feature and all the work that entails. Removing a feature requires as much planning, time, and hard work as building a feature — and sometimes, it requires even more from you than adding that very same feature to the product.

It’s all about value

We should not be thinking about *adding* features and *removing* features as separate tasks. Logistically, we may only be able to do one task at a time, but adding and removing are two sides of the same coin and you should always be thinking about the interactions if you do one or the other. In other words, when adding a new feature, you should be thinking about redundant pre-existing functionality and if there needs to be a migration plan as part of the launch. If you’re removing a feature, your users should still be able to get their work done using other features, or you should have an explanation for why that particular feature no longer fits in your product’s overall strategy.

Removing or EOLing a feature is similar to adding a feature because it is *adding* value. Some common examples of parts of the product that we want to deprecate and the value it brings:

  • Removing a little-used feature reduces the burden of configuration and adds value in a simplified user experience
  • Removing a bug-ridden v1 feature that was released too early (and never iterated upon) adds value in a higher-quality, more stable product
  • Removing legacy support of old frameworks, databases, operating systems, you-name-it makes it easier for your engineering team to develop new features unencumbered and adds value in quicker time-to-market of New Stuff

As product managers, we don’t really think about tasks in terms of adding features — we think about tasks in terms of adding value. It’s important for us to remember that there are more ways to add value to a product, and sometimes that might mean deleting that part of the codebase that was last touched ten years ago.

If removing or deprecating features adds so much value, why don’t we we it happen more often?

The product management discipline within software organizations are continuing to evolve. More and more people *not* within the product organization are acknowledging that product management isn’t just about writing specs and building features, and recognize that discovering, planning, and enablement will take just as much (or more) time as the build phases.

This same transformation of thought needs to happen with removing features. Killing a feature is just as hard as creating one (if not harder!), and requires just as much discovery, planning, communication, and enablement. Here are a few challenges that product managers may run into when removing a feature:

  • A minority (sometimes just one!) of customers are relying heavily on the feature
  • Other parts of the product has a hard dependency on the feature and removing it may break something else
  • Removing a feature sometimes takes a significant amount of time and effort

Customer concerns, technical hurdles, and a finite amount of time to apply to the solution — Sounds suspiciously like the challenges a product manager faces when creating a feature! Releasing a feature is celebrated with a launch party, and killing a feature should be celebrated and recognized in the same way since both tasks provide value and both tasks require a lot of blood, sweat, and tears.

How do we solve this problem?

The best way to EOL a feature or product is to go through the exact same planning process as if you’re creating a new feature. That means going through a discovery, customer validation, planning, executing, enabling, and a ‘launch.’ Most importantly, a product manager needs to be able to set aside the time (our most precious and scarce resource!) for these projects and have the support of the business to focus on all of this. If your business is wholly focused on building new features to acquire new revenue and you can’t convince them on the value of maintenance via EOL, than removing any feature is likely a pipe dream.

Let’s take a closer look at these similarities through the lens of every product manager’s favorite tool: The roadmap! Whether we like it or not, the roadmap is simultaneously used to set expectations on what’s coming, to sell a dream to our users, and enable or prepare downstream organizations such as support or customer success.

If we maintain that adding features is extremely similar to removing features, then it makes sense to create a roadmap for all the features we might end-of-life:

A completely fictional and highly ambitious EOL roadmap plan.

And for each item, there should also be a project plan as well. For example:

Now, it looks like we doubled the product manager’s workload by creating two different types of roadmaps — and this isn’t very far from the truth. Focusing too much on adding features gets in the way of your ability to remove features and vice versa. In an ideal world, a single roadmap should include both additions and deprecations and properly allot the time and resources for each item.

If you’re thinking about deprecating a feature, here are a couple other things to keep in mind:

  • Make sure you have both qualitative and quantitative reasons for removing a feature. Being able to explain the value of deprecating a feature in terms of numbers (i.e. amount of maintenance time saved, operational costs saved, or security risks addressed) will make it easier to get buy-in from your stakeholders and allow you to dedicate substantial time to planning the deprecation
  • You’ll get a lot of questions throughout the process, so keep an FAQ document that you can refer the organization to as you notify them about the deprecation. And update it as you’re asked more questions
  • Find an EOL buddy! These types of projects are always easier when you have some support. I like to find a buddy within design, support, or customer success since they can provide valuable insight on how a deprecation might impact the customer experience
  • Maintain your EOL roadmap, even if no one else sees it. It’ll help keep you focused on the next project and keep you disciplined in following through on an activity that’s entirely too easy to ignore when you’re crunched for time

Remember your A-B-EOLs (Always Be EOLing)

We make the fallacy of believing that removing features should be quick and easy and when it’s not, we avoid it. As we add new features, we incur a ‘tax’ in terms of maintenance. If we avoid removing features, the tax only grows and we drop further into product and technical debt. The debt eventually slows our ability to innovate and the pain is passed to our customers. The best strategy to creating a great customer experience is a thought-out strategy that balances time between adding and removing features.

Source link


Please enter your comment!
Please enter your name here