Deciding which features and fixes to prioritize is one of the most difficult parts of being a product manager or app owner. The reality is that there’s a lot of guesswork involved.
To say product managers “wing it” isn’t true—any good PM relies heavily on user data to steer things in the right direction. But as you probably know all too well, the inputs that go into product roadmap decisions aren’t so neat and tidy. There’s an endless onslaught of competing ideas and requests from executives, team leads, customers—even your competitors can influence the game plan.
Building any product is ultimately a highly subjective and iterative process. In the early days, even your concept of your own app’s core product value can change in an instance. Even for a well-established product, roadmapping is never a one and done event. Your plan for the future of your app can (and should) evolve.
Most of the top companies eventually figure out an important fact: You can’t please everyone with your mobile app—nor should you try. The best apps fill a specific niche and specialize in solving one clear problem:
Uber: getting a ride, anywhere anytime
Spotify: delivering a personalized, unlimited music library
Caviar: restaurant quality food, delivered to your door
As your app evolves, you may find yourself with a lot of feature baggage—features that seemed like a great idea at the time, but never quite struck the right cord with your users.
You need to cut features that are no longer contributing to your app’s core value or risk bogging down your app’s ability to thrive. But how exactly do you determine which features to cut? And how do you go about killing a feature?
Identifying the right features to cut
“If you let too many features creep into your product, the core value proposition and vision can easily get diluted. The product will start to seem “big” and “complex”, and does not easily solve the problem the customer had in the first place.”
Allowing deadweight, leftover, or non-contributing features to exist within your app is harmful for many reasons. Feature creep can kill your app over time by:
Diluting your core value: Your app exists to solve a problem. Features that exist on the fray just add fluff, and hinder the user’s ability to clearly recognize your app’s core value. Even worse, too many features will ultimately spread your teams thin and make you a master of nothing.
Draining resources: Even a minor feature needs to function properly and this means dedicating time and resources to maintaining it and squashing bugs as they arise (and they always arise).
Wasting money: Having a laissez-faire attitude towards deadweight features can directly impact your bottom line. There is a cost to maintaining every part of your app, and it adds up quickly for non-performing features.
Of course, if you’re reading this article, you probably already know that keeping low-performing features afloat is bad for your app. But choosing which features to cut can be hard—even if you know it’s necessary. There are a plethora of questions you can ask yourself during this process, but for simplicity’s sake we’ve narrowed it down to the 3 most important questions.
Does this feature contribute to my app’s core value? Make sure the feature directly relates back to your app’s core mission and value.
Is anyone using it? And does it contribute to user success? Stay true to your PM roots and let the user data drive your feature decisions. Take a close at how many users are actually using a feature, and whether these users are likely to stick around.
Is it worth the cost to maintain? Just because an app feature is expensive to build and maintain doesn’t mean it’s a useless drain on finances. Likewise, just because a feature is “cheap” to keep around doesn’t mean it’s worth holding onto past its expiration date. That’s why you need to look at the total picture—does the feature contribute enough to your MRR? Do customers that adopt this feature have a higher lifetime value?
If you answered “no” to any of those questions, it may be time to clean house. Just make sure you get the right buy-in first. Co-founder of Mind The Product Janna Bastow explains:
“Before you go slashing apart your product, create a ‘kill list’ of items you’re thinking you’d be better off without. Get a second or third set of eyes on the paper, and discuss why you’d like to sunset each item. Most will likely be obvious, but be ready to talk about the cost of upkeep vs. the benefit of keeping a small fraction of your users happy, or whatever else you’ve got to qualify your call.”
How to kill an app feature
Now let’s assume you’ve identified which feature needs to go. How do you sunset a feature smoothly? Let’s take a look at 3 key steps to saying goodbye to a feature that’s outlived its value.
The biggest concern when it comes to killing an app feature is customer backlash. Tackle this head on by:
Letting customers know ahead of time about the feature change
Gradually deprioritizing the feature within your app
You should allow users to migrate off the doomed feature in the weeks and months before things go dark. Choose a prominent in-app messaging UI pattern (like a modal or slideout) to point users down an alternate path so that they can gradually wean themselves of the feature in overtime.Be prepared to support users with additional customer success and support resources during this time.
If you absolutely must kill a feature quickly, make sure you have something superior to offer them in its place—whether that something is a new-and-improved feature or simply a more streamlined workflow. Never delete stored user data or content without advanced notice.
And above all, you should be communicating with your customers throughout the process. Use a combination of in-app messaging, email, and CS outreach to make sure customers feel like they’re in the loop.
For example, when GrooveHQ realized their Live Chat app was a lost cause, diverting both revenue and resources away from their core values, they knew it was time to kill the app. It was a very difficult decision, but they chose to be open and honest with their users, which paid off in the long term. CEO Alex Turnbull’s email is a great example of what your customer communication should entail:
2. Perform a gut check
It’s nerve-wracking making any big product change, let alone chopping off an entire part of your product. That’s why it’s important to lead with the data, rather than emotions. You should follow up with data, too. Use the data that you gathered pre-cut as a benchmark for analyzing user behavior after the fact. Keep a close eye on things like engagement, number of support tickets, and NPS scores to ensure that app users are adjusting to the change and adopting whatever new feature you have in its place (if any).
When HubSpot overhauled their social media tools, they actually had the old and new versions running simultaneously until customers became acclimated with the update. They measured the user opt-out rate (those users who chose to switch back from the new social media UI in favor of the old) until it was down to the single digits before completely killing the product. Why?
“[This approach] made sure that we’d addressed most of the concerns our users had with the new interface. It also meant that most users were comfortable using the new tools before we took the option to use the old ones away.”
3. Make peace with your decision
You’ve made the call and done your due diligence to ensure it was the right one. Now it’s time to move on. Use that extra headspace to innovate and come up with fresh ideas about how to take your app to the next level. Put your newly freed up resources back to work on the features that matter most and the backlog that’s been piling up.
Look forward and move ahead. You’ll be amazed at what you can accomplish when you’re not bogged down by unnecessary features.
A product prioritization framework offers a clear path forward
After you’ve made the hard decision to shed the extra product weight, you need a solid plan in place to ensure you stay on track for the future. A product prioritization framework can help ensure that everyone on your team is on the same page and has a common goal in mind.
There are many different product prioritization methods to choose from. One simple method is story mapping, which emphasizes the user experience over internal stakeholders:
Another useful framework is the Value vs. Complexity Quadrant, which can help you identify the projects with the highest ROI for both you and your users:
Credit where credit’s due, we also like the RICE method originally developed at Intercom. The RICE model ensures their team ships the features that make the biggest impact.
All of these frameworks work by taking the emotion of building features (or at least organizing that emotion into quantifiable measures) and lets the data determine the best path forward.
Cutting features is part of growing up
When you build software, killing your darlings— aka cutting your beloved non-contributing features—is a necessary and normal part of growing up. The things that made sense a couple years ago might not be a good fit for your company today.
That’s why it’s not enough to just do it once. You should make killing app features a regular part of your product strategy. Your goal as an app product owner is to figure out what your users really want and need most— and then build the best version of that possible.