Product Management: What’s the ROI of this Feature?

Have you been in a situation where your management team came up with a suggestion for a new feature without any field knowledge, as if he heard about it somewhere or had a dream about it last night? Have you ever been questioned by engineering team on why deploy resource for your feature or prioritize it over other products? Have you been asked by your management team to substantiate the brilliant feature you came up with? OR you keep hearing simple and direct question of what’s the ROI of the feature?

All these scenarios are calling for one thing back your opinion with data. Product manager needs to be data driven (you must have heard it, read it several times and wondered what it means). It means, arguments put forth for feature selection or prioritization should be backed by data and in most organizations they refer to it as ROI (Return on Investment). Now instead of turning to your management team and telling them their idea is not good, you should be able to explain them the idea suggested will cost $10000 and company may end up making attributed revenue improvement of $5000 over a 6 month period, that’s like negative ROI of (50%) would you like to fund and approve it?

Although it sounds good, the moment one starts to derive an ROI is when we start to encounter the problem of lack of information. And we end up spending most of our time trying to figure out the best way to make a case out of the feature than building the feature itself.

Most might feel ROI for a feature does not make much sense to be done before hand, because it is inherently based on many assumptions rather than a true measure. Which leads to following set of questions.

• How do you go about deriving ROI for a feature?
• Do all features have a ROI associated with them?
• What if the feature is distributed or has dependency on various teams, how do I provide the ROI for my part of the feature?

The premise for ROI calculation starts with, feature is built to address a pain point and solving such pain point will result in business benefit. But benefit itself might not be very evident in monetary terms in all situations, so we need to break up the benefits in terms of the metrics that can be measured. Tying these metrics together we will be able to determine the impact on end goal and in most cases in monetary terms. Analogy for this in analytics world can be drawn in terms of minor goals and major goals.

Let us take an example of fine-tuning the search in your product (app or web). Product manager needs to make a business case as to how this search will help the business. In this case returns expected might not directly substantiate the cost so we step into the mode of minor goals and even some non-tangible results.

• Number of times search is used
• Number of people using search
• Number of times people use assisted search
• Clicks on the results of assisted search
• Number of pages people browse in search results
• Number of cart additions resulting from assisted search
• Number of conversions resulting from assisted search [Major Goal]
• ROI calculation will help you define the metrics, which can be used to measure the success of the feature once it has been implemented.

Next question that pops up is should I measure the improvement that happens over next 15 days, 30 days or 90 days? And this one does not have one-size fits all answer because it depends on various factors like install base, activities and any periodicity associated with activities. To make an inference we need to have statistically significant number of data points and if you get it in 30 days then its good enough.

“Do all features have a ROI associated with them?”, thats something we will take up in next post.