Whether you are a product owner, product manager, business owner, CEO, director, entrepreneur, or practically any other name-your-title in an organisation, the chances are that you have a say in product development. With that in mind, let’s start with the assumption that you are making decisions regarding your product.
Did you read the blog post about "The first mistake in your software project"?
Such decisions include what to build in the first place and consequently what not to build, which in fact, is even more critical decision. Once you have a backlog of product features, you decide which features to prioritise and which ones can wait for later sprints. Right now, let’s assume you already have a product out there in the open and that you are set to improve it by updating features and building new ones.
We as product people have high hopes of what will happen to a product once we get to launch those new features. Obviously, the use of your product will shoot through the roof.
You have a backlog full of feature ideas that will take the world by a storm. We as product people have high hopes of what will happen to a product once we get to launch those new features. Obviously, the use of your product will shoot through the roof.
However, before making life-changing decisions on what to build, let’s first analyse what happens in your product. How your customers use your product? Is every one of them using all the features all the time?
Let’s face it. That’s never the case.
Before diving head-first into prioritising your feature backlog and roadmap, thus allocating your team’s valuable time, you should analyse which features are used by what types of customers. Depending on the tools you use, this analysis might take anything from few minutes to few days. For example, a simple database query to identify feature use might take only a few minutes by technical people. On the other hand, to include additional product folks, using off-the-shelf tools such as Amplitude or Mixpanel is a sound option. We like to use such tools, since product analytics should be the concern of everyone in the product team, not just the technical people.
Feature Review
Now that you have the means in place to understand how your customers are using the product let’s discuss what you actually want to review. We like to call this exercise a feature review.
The first step in a feature review is to list all your core, value-adding features, leaving out admin features such as logging in, resetting password etc. since they don’t deliver value. Also, features that are available for only a certain group of customers (such as custom plans) should be analysed separately.
For each feature, place it on two axis: how many of your customers use it and how often it’s used. The outcome might look like this:
Features that are on the top right corner are the ones that create value for your customers. These features are the ones they signed up for.
Another way is to create a chart of what percentage of users use a certain feature, like this for a ride-hailing app:
In the dream world, you only have features that are used by most of the people most of the time. That is just not the case and in reality and the feature adoption could look more like this:
How did this happen?
How did you end up building and maintaining those rarely used features in the first place?
You might have multiple stakeholders in your organisation that believe they have a feature idea that will change the world. Sales might from time to time tell you that they’ve lost sales so many time because you don’t have this nifty little feature.
Eventually, you built it, but the data shows lousy adoption. It’s rarely used by a small number of customers. Yet you’ve spent time designing and developing it. Not to mention fixing small bugs and preserving compatibility between other features.
So your feature review reveals some features that are the essence of the product, and most likely some features that do not add much to it. Your responsibility as a product leader is to focus on the features that drive you towards the common shared goal, your North Star Metric (NSM). That might mean developing new features, but also modifying and removing existing ones that for some reason steer you away from the NSM.
Making Product Decisions
So, you’ve done the feature review. What to do with the results? You have (hopefully) identified features that drive you towards the NSM. For those features that are not your champions, you must make a tough decision whether to improve or remove them from your product.
Features on the top right corner are your champions. Protect them with all you got. When considering improving those features, ask yourself twice which direction on the graph the improvement will move the feature.
Features close to the left side with limited adoption are on the borderline cases. Do you really need them? Prepare to kill or radically improve them to increase adoption.
However, the features in between the two extremes are the most difficult to determine what to do with them. You must decide to make them incrementally better, try to get more people to use them more often, improve adoption, or make the tough decision to remove them from your product.
Deciding what to do with your current features is tough enough, but do you remember that you still have the backlog of new feature ideas. Should leave the product as it is and build new features or should you focus on streamlining current features and postpone new ones? How on earth can you prioritise all of this?
Whatever your next steps may be, your first step at this point should be the feature review.