PART 2 OF A 2-PART SERIES
Subtracting: The Role of Simplicity in Product Management
Pruning, deprecating, consolidating, sunsetting 🌆
This is Part 2 of our two-part series on simplicity in product management. Part 1 is “*Not* Building: The Role of Simplicity in Product Management”.
In Part 1, we outlined how product teams can avoid becoming feature factories. That is one big part of bringing simplicity to product management. It’s not all of it however.
Even product teams that have avoided becoming a feature factory by focusing on customer outcomes over product/eng team output sometimes ship products that fail (to meet expectations). Sometimes it’s a good idea, with poor timing or execution, and sometimes it’s just a bad idea 💩.
There are two big contributing factors to this problem:
- Product complexity naturally grows over time.
- As companies grow, and product teams splinter, it becomes more difficult to focus on the whole instead of the parts.
#1 Regardless of the value of any given feature, adding features also adds complexity to our overall product experience. Over time, that complexity grows, especially when we cater more to our power users. Yet few product teams make reviewing the naturally growing complexity of the overall UX part of their standard process. As a result, the overall user experience tends to become cluttered and confusing.
#2 Part of the root of the problem also lies in the fact that most companies have many product teams managing different “products” within the larger product.
For example, Spotify may have one product team (or “squad”) focused on ads, while another is focused on music discovery. The squads have some degree of autonomy, which is a double-edged sword. It’s necessary for development agility, but must be paired with strategic oversight across the squads. While Spotify does a great job at combining autonomous squads with strategic, customer-perspective oversight, companies that don’t do as good a job end up with local optimization instead of global optimization.
Now that we’ve identified two of the major contributing factors to increasingly confusing products, let’s look at some solutions.
How Subtracting Can Lead to a Greater Sum
In order to ensure that the overall user experience for your product remains coherent and simple, the company needs to ensure that someone is keeping an eye on the simplicity of the entire product experience, and constantly be evaluating whether each feature contributes to the holistic UX.
And when it becomes clear, through a system that we’ll outline in just a moment, that a feature should be pruned, we should go ahead and do so.
Product management is not just about addition. It’s about subtraction too, as well as deciding what *not* to build (which we covered in Part 1 of this series). We need to regularly review individual feature usage, as well as the overall user experience, and prune underutilized features. This is sometimes referred to as feature sunsetting or deprecation.
We need to make this simplification process as much a part of our monthly priorities as shipping new features. If the product team is evaluated based on the customer’s outcomes, and not just features shipped, then they’ll be as incentivized to regularly optimize and simplify existing product as they are to build new products and features.
So how can we keep an eye on the simplicity of the holistic user experience?
How-To: The problem and solution outlined above are familiar. The reason the solution doesn’t get successfully implemented more often is that it’s tricky to figure which parts to prune. We might decide that if only 5% of our users engage with a certain feature then it should be discontinued. But such a hard-and-fast guideline would come with all sorts of asterisks and caveats. One of those 5% might be a VIP power user. One of those features might be necessary for an important future development of the app.
Some practical tips that help you navigate the traps above:
Phase 1: Agree on a set of quantitative metrics that collectively define a red flag. These will typically be usage stats (adoption and engagement) falling below a predefined threshold, such as the percent of users utilizing a feature in the past X days.
For an excellent primer on adoption measurement, including the difference between adoption and engagement, read Tomer Sharon’s post here.
Phase 2: Agree on a set of more qualitative lenses to pass any red flags through. Those might be:
- Are any VIP clients heavy users of this feature?
- Is this feature a strategic stepping stone to future product capability or necessary component to some other functionality?
- Is the feature discoverable enough? Did we communicate its value enough (product marketing)?
- Is this feature helping our sales team close deals as a talking point?
- Is this feature a critical meet-comp?
- Is the feature a good idea, but executed poorly?
- Other good questions from Grant Ammons
- Does the feature suffer from product debt?
On this last point, Daria Axelrod Marmer, Product Group Lead at HubSpot, uses this helpful visual framework for “processing product debt” in her post “On Killing It by Killing Features”.
We caught up with her recently and she added:
“Whenever engineering comes to me with “tech debt” on a feature that is rarely used, I do a rough ROI calculation: The revenue from that segment of users, divided by the sum of the cost that it will take to fix the tech debt plus the opportunity cost of not building the next feature on the roadmap. If the ROI is positive, the feature lives on! If not, I start working with the marketing and support teams on how we can sunset it gracefully.”
Phase 3: Once your team passes the red flags from Phase 1 through the qualitative checks of Phase 2, you’ll end up with a list of features that you feel ready to either kill, improve, or re-educate users on. If you’re going to sunset a feature, make sure your plan takes your service agreements into consideration and you’ve consulted your legal team. You should also have a communication plan co-authored with your customer success and marketing/PR teams.
No matter how well your product team maintains a focus on outcomes over output, you will still ship products and features that fail. We can salvage some of those initial failures and we need to intelligently kill the rest. The good news is that teams that do this well will improve customer satisfaction as much as shipping instantly successful new features would.
