Why do a lot products fail, and why do some of them succeed and do so well? What is it that kickass Product Managers do that makes them get such high output in less time, that average PMs would otherwise take large amount of time, and features to achieve?
The usual process for a product manager before building a feature is the identification of the problem the user is facing through various qualitative/quantitative means(the WHAT), moving on to find the possible solutions(HOWs), and then the execution of some of the features from the list of features that they think are higher priority features. But what they pay very little/no attention to is spending on predicting which solution shall work the best. The third step doesn’t have to be a subjective, but a very objective call to achieve high output.
Apart from design, analytics, UX, business and technical specifications, this strategizing of picking the right features is a very important skill for a Product Manager to know.
The next few steps going to serve as your kickass guide, which should help you predict the impact of features well before building them. Use this guide to build impactful features, in interviews, to impress people, whatever works best for you 😉
Know your funnel
To be able to get a good and broad understanding of the user journey in your product, it is important to know the various stages of your user and the number of users in each stage. A very basic user funnel in any product can look like:
Visitor -> Lead -> Activated -> Converted
For instance, on an ecommerce platform, a user funnel can look like the one below:
Knowing the number of users in each step of the funnel will let you know where your users are actually dropping off, do the analysis on why they’re dropping off and then build your tasks accordingly.
As you can see in the funnel above, one such prominent problem is that only 3% of the users complete a purchase even after adding the item to cart. It, hence becomes an important problem for the ecommerce company to solve.
Bucket features
Before you build a feature, try to bucket them on the following lines:
Necessary: Is there a feature that has high financial impact? Is there a usability issue for the user that I need to solve? Is there a feature that will significantly reduce the effort of my sales team? If there is a feature that solves any of the problems on these lines, they need to be picked on highest priority.
Experiments: There are features that you think can make it big, because of various reasons(because of data backing it, because you’ve spoken to the users who feel there is an issue with the product, it is a hunch based decision), but are not very sure of how well they shall perform.
For features like these, it is important you perform experiments to validate the impact.
For instance, say you think launching an offers section in your app will result in higher number of people making a purchase on your app. You think so because your competitor has had offers on their app for quite a while, and have in fact given them high visibility. But because you are not sure, an experiment can help you validate this hypothesis. Showing your app with the offers section to half of your users, and without the offers section to the remaining half will let you know what upside the offers section brings to your app, and whether you should have offers in your app or not.
(Experiments can be done through A/B testing, you can read about it further here)
Hygiene features: These are features that have to be present in the product, and will most probably not have impact metrics attached to them. For instance, my account page, terms and conditions, cancellation policy, uniform design guidelines in the product, research on a new analytics tool etc. in the product. Their impact doesn’t need to be quantified, but the validation can be simple on how many users actually use the feature.
A good mix of these features usually makes a good roadmap for building a product. I typically distribute necessary, hygiene and experiments as 60, 20 and 20%. Going extreme on any of the three verticals in a given timeline is usually not recommended. Why, you ask? Say for instance, you only pick 100% validated necessary financial tasks in a quarter, because you aren’t picking any experiments. In this case, your company isn’t doing any innovation and hence won’t have a USP in the long run. Also, because you haven’t picked the hygiene tasks, a lot of priority user problems will end up staying unsolved.
Similar argument can be given for other cases.
Quantify features
Before building any feature/product, try to come up with the following statement about the feature:
“This feature will improve the X Block by Y% in the next Z months”
For instance,
“This feature will improve the Visitor to lead % of the product by 0.5% in 2 months”
Remember, there is no feature in product that does nothing. If it actually does nothing, you shouldn’t really be picking it in the first place. Quantifying the impact of a feature gives you a good sense of whether you should really pick, and which ones you shouldn’t.
Looking at the impact of the features after you’ve built them will always have bias on what impact metrics you should be looking at. You’ll only end up looking at the metrics that have improved to self-justify yourself, and not at the blocks that actually matter. You don’t do this on purpose, you do it because it is human nature to really like what you’ve built and think what you’ve built is successful.
Once you’ve quantified the impact before building a feature, there’s no scope for you to do sales, even to yourself. Because you can now be very objective in the impact of the feature, and do its root cause analysis.
Most importantly, quantifying the impact helps you prioritize and pick the right features before building them.
Benchmark the impact of the features
But wait, the immediate next question that comes up is, how do I predict the impact of the features that haven’t been built? Yes, it’s a tough task, but it can be practiced and learned with experience and hard work. I use the following techniques to benchmark a feature:
1. Identify what are the metrics you’ll impact: For instance, if you change the color of your chat head to give it more visibility in your app, it’ll result in more number of message sends which might eventually result in more number of conversions. The former is called lead metric, and the latter are called lag metrics.
2. Predict how well your features will perform: You can use any of the following techniques to be able to do so:
a. Previously launched features: If you have the learnings of the impact of a similar feature that was launched previously, or the same feature launched on a different platform, you can use them to predict how your feature shall perform.
For instance, you can use the learnings of how well the offers section performed in your android app, to better place the feature on your desktop/mobile site/iOS app.
b. Competitor analysis: If you want to introduce an offers section in your product, the placement of this feature can well be decided where your competitors have placed this feature, and why.
c. Experiment: If an impact of the feature is not known, try and experiment your product with and without the feature. I’ve explained experimentation before, but the success/failure of the experiment shall help you gauge on how the feature shall perform if it is fully rolled out.
d. Guesstimate: Do a plain guesstimate of how well your feature shall perform, if it’s an absolutely new feature, or space that you have no idea of. Remember the questions they used to ask us in interviews? Estimate the number of cabs in India? Similarly, try and do a rough estimate of how many users, which user segment shall use your product and why.
Make sure, keep in mind variable factors like seasonality, varying tax policies etc. that aren’t in your control, but affect the impact your feature shall bring while you do your predictions.
A snapshot of how a roadmap can look like basis the techniques above is given below:
Validate
Needless to say, once you’re done launching a feature, spend time validating the impact of the feature/product you’ve built.
Once you’re done validating, you should have an answer as to why your feature achieved what it was intended to achieve, or why did it underachieve/overachieve.
Use these learnings in the next feature/product you build. Repeat!
Phew, long read, wasn’t it? But I really hope you learnt an important aspect of strategizing and prioritizing in building impactful products. 🙂