The Economic Value of a Feature
Read on my website / Read time: 5 minutes
"Not every backlog item can be attached to revenue."
Today, let's talk about how to assess the economic value of a feature.
I've argued before how customer satisfaction is not the #1 metric for product management.
The assumptions here are:
(1) Happy customers will make for a successful product. So if we just focus on making customers happy, everything will work out.
(2) Product management has little to no influence over revenue or financial outcomes. Only Sales and Marketing can do that.
Here's the thing, though...
If those happy customers don't pay for the product at a price that's profitable, it doesn't matter if they're happy - there won't be a business. Which means no growth, no payroll, everyone go home.
Think about all the products out there that we make fun of for their poor user experience, yet continue to make money every year. Healthcare, education, and government are littered with these.
I'm not advocating for a poor user experience. Quite the contrary. Of course, we want happy customers. Unhappy or disgruntled customers = no business at all.
Often I see product managers prioritizing things simply because "lots of users have asked for it" or simply because they believe it will make users happy. But satisfied customers who don't deliver value back to the business are unprofitable customers.
That's why product management's true job is delivering monetizable customer value.
The thinking we need to have in product management is: what return does the business get by investing in improving X?
Or, said differently, if we have $1 extra dollar, will we get more bang for the buck by improving X or Y?
That's the kind of thinking we're being held accountable for.
Take UI, for example. If Design wants to do a complete overhaul of the existing UI, it's very likely to look and feel better, but is it really worth the investment? If it's going to take 3, 6, 9 months of dedicated effort at the expense of everything else, will it help drive more sales? Retain and upsell existing customers? Justify a price increase? Win more market share? Drive efficiencies downstream and improve margins?
Maybe the answer for your product is yes. Then it's worth it. Maybe it's not. What's important is that we ask the question. This is the rigor we need and are expected to apply as product managers.
Rich Mironov published an excellent article called "Business Cases Are Stories About Money". 100%. So let's talk tactically about how you can make economic arguments about your product proposals.
Ways to assess economic value
Calculating the potential revenue impact or economic value of a new product or a priced feature is straightforward since a price is directly attached to the new product or feature. There are a number of financial analyses we can perform for this, such as breakeven analysis, payback period, contribution margin, net present value (NPV), and internal rate of return (IRR).
But most of the time we're working with items that aren't priced or directly attributable to revenue. What to do in those cases?
Here are 8 strategies we can use:
1. Align it with moving a key metric.
This works when you have a well-laid out strategy. For example:
Since the metrics are tied to achieving specific product goals, which are themselves tied to top-level organizational objectives, features and enhancements that move one of those metrics would get priority.
Additional examples:
- Reducing churn – the feature would reduce churn, the $value of that.
- Increase conversions from trial to paid or free to paid – $value of the % increase
- Increase customer lifetime would increase from 18 months to 24 months - the $value of that.
2. Use Reach and Impact.
Examples:
- 1000 of our user base opens this page every month and, from that, 20% of users will use this feature. So the total reach is going to be 200 users.
- Every customer who uses this feature each quarter will see this change. So the reach is 2,000 customers per quarter.
- 20 accounts that are renewing this year ($25.5M total ARR) have requested this feature; 10 accounts renewing next year ($13.2M ARR) have also requested it. So, the total reach is 50% of all accounts, impacting 75% of total ARR.
- This is the #1 requested feature in pipeline deals; #1 deal loss reason; and requested in 75% of sales qualified leads (SQLs).
Note that we're not pulling numbers out of a hat. As much as possible, we want to use real measurements from our product or sales metrics.
We can then add a confidence score. So, if we think a project or feature or enhancement could have a huge impact but don’t have the data to back it up, Confidence lets us control that.
Examples:
- We have quantitative metrics for reach, user research for impact, and an engineering estimate for effort. This project gets a 100% confidence score.
- We have data to support the reach and effort, but we’re unsure about the impact. So it gets 75% confidence.
- The reach and impact may be lower than estimated, and the effort may be higher. So it gets a 50% confidence score.
3. Use Lifetime Value (LTV).
This is especially useful when it comes to new sales, renewals, and churn.
In the example below, if we know the average LTV of a new customer is $1,000, and we have a sense of the reach of a new feature, we can then compare its estimated economic value to that of others.
4. Use sales velocity.
Sales Velocity is how quickly customers move through the sales pipeline in a given timeframe – i.e., dollars per day/week/month/quarter.
It's calculated as:
Sales Velocity = (# opportunities in the pipeline ✖️ average deal size ✖️ win rate) ➗ sales cycle length
Where:
- Win Rate = the % of opportunities won
- Sales Cycle Length = average number of days or weeks to win a deal
Using sales velocity can be especially useful when acquiring new customers is a priority - e.g., for a startup or new product.
For example, let's say the there are currently 100 opportunities in the pipeline; the win rate is 24%; the average deal size is $100k; and it takes 100 days on average to close a deal. The current sales velocity is $24,000.
Let's say a feature could win us 10 more deals = 34 deals won = 34% win rate. That gives us a sales velocity of 100 * $100k * 34% / 100 days = $34k. A 42% increase in sales velocity.
We can also use this to compare product opportunities:
- Win 10 extra deals with Feature A * $100k average deal size = $1M
vs.
Win 6 extra deals with Feature B * $100k average deal size = $600k
- Feature A: win 10 deals * $100k deal size * 30% win rate / 100 days = $3,000 value
vs
Feature B: win 7 deals * $100k deal size * 30% win rate / 100 days = $2,100 value
Note that if you use this method be sure to validate the approach with your Sales leadership.
5. Use revenue acceleration as your business case.
This is especially useful if the feature or improvement will enable you to deliver or implement your product more quickly for customers, because it could mean the business can recognize that revenue more quickly. Revenue recognition occurs when a product or service has been delivered to a customer. (Your Finance department cares about this.)
Examples:
- An improvement in the sales ordering process that allows products to be shipped out to customers faster.
- An improvement in the ability for the Customer Implementation team to more quickly configure the product for the customer, allowing the customer to "go live" with the product sooner.
6. Cost savings or efficiency.
In some cases, this may be easy. For example:
- Today, our packaging costs $X. This project will reduce it to $Y.
- Doing this will reduce our product manufacturing costs by Z%.
- We currently run our machine learning algorithm on servers that cost $X per hour. Switching to these other servers will reduce the cost to $Y per hour.
In other cases, it may require a bit of calculation. For example:
- Let's say UI improvements could alleviate 25% of support tickets. It's easy enough to work with the Support team to calculate the cost of those tickets, and if they outweigh the development cost, it may be worth doing the UI improvements.
- Allowing our sales team to configure customer demos on their own, no longer requiring an engineer or product manager to do so, resulting in a savings of $50,000 per quarter or $200,000 per year at $1000 per demo.
7. Use customer value as a proxy.
Counting the number of customers requesting a feature is nice. More meaningful is the $value those customers represent.
For example, in an enterprise B2B company where customers often sign multi-year contracts, any one account can represent tens of thousands to millions of dollars:
You could also use the lifetime value of those customer accounts or the MRR (monthly recurring revenue) they represent.
If any of those customers are up for renewal or at risk for churning, they are definitely worth calling out.
8. Compare across different economic benefits.
It's not uncommon for different opportunities to have different economic values. It's ok to compare items with each other.
When doing this, it's important to keep in mind the product strategy and business objectives.
For example, at one company I worked at, acquiring more customers was business priority #1. In that case, you can imagine that features Beta and Epsilon would get more attention (regardless of the ranking score).
At another company, improving NPS and customer engagement were declared as top company priorities. In that case, Alpha and Gamma could get the priority, even though they ranked lower.
Your next steps
- Go through your backlog. Identify the items best aligned with your product strategy, business objectives, and customer needs.
- Group similar items into themes.
- Calculate an economic value for each theme using any of the strategies above.
- Does that change how you would prioritize things? Does it change how you'd advocate for certain initiatives over others?
