Can you calculate your Feature ROI?
We were sitting on the campus of the University of Miami several years ago. It was the perfect chance for me to ask the same question to something like 40 different product owners. It was a technology conference, one of the country's largest, focused on WordPress. The product owners were all folks that were building WordPress plugins.
What I heard from them, on that day, I have since heard over and over. And not just from plugin developers but also from all sorts of developers – including those who build SaaS products.
What question did I ask?
Can you calculate the return on investment (ROI) on each feature you've rolled out in the last year?
In other words, I was looking for the ever-elusive and constantly-challenging “feature ROI”. The problems with doing the ROI calculation are several:
- You have to be able to isolate the cost of building the feature
- You have to handle product sales attribution (did that feature drive the sale?)
- You have to be tracking and capturing support for that feature specifically
- You likely have to monitor attrition / churn because of the feature
So is it really possible to pull that off?
Many of the folks I spoke to on that day said it was too hard. Or that they simply didn't have the tooling to do the tracking that would be required.
A couple said they didn't care. They were going to build the feature anyway, regardless of the ROI.
I'll be honest. It's hard. Worse, if you find that you're not seeing a return, killing a feature (after it's been in the market) is even harder.
I want to tell you about two different experiences, as I try to make the case for how you can possibly think about ROI calculation. You can also check out the math here for how they suggest calculating it.
But first, I want to share my highly opinionated insight that you may hate me for.
Most of your feature effort is a waste
See, I told you that my opinion may cause you to hate me. But give me a few seconds to make my case.
Let's say you've already created a software product – be it a plugin, a SaaS, or something else. One of the reasons it's hard to calculate feature ROI is because every additional feature you create doesn't actually drive additional (attributable) sales. In fact, it's mostly just going to introduce more cost.
Hear me out.
Imagine you have a plugin for testimonials. You have a core set of customers. You get feedback from them and a handful of them ask about adding some cool artificial intelligence to your product. It sounds really cool to your engineers.
The idea is to leverage sentiment analysis that's available via some Microsoft APIs so that you can sort the testimonials by the strongest sentiment. After all, “you were great,” is not as amazing a testimonial as, “I can't recommend him enough – our profits are soaring because of his work.”
Will that feature get you new customers? Maybe. It will be hard to know if the single feature drove new business.
But we know for certain that there will be a certain amount of cost associated with the feature – either in support, or in the upkeep of the code as Microsoft (potentially) changes their APIs.
Every feature brings the cost of support and upkeep. Not every feature brings new customers.
Hence, most of the feature work you're doing is a waste. And I've already told you, more features is rarely the answer.
This is what brings me to my strong opinion about features and calculating feature ROI.
Feature ROI is only possible if your features open up more segments
Maybe I am overstating the reality. It's maybe possible to do if you handle all the challenges I listed above. But the best way to do the attribution is if you start getting a customer that you didn't use to get. That's what I mean by opening up adjacent markets or expanding to more segments.
I told you that I would tell you two stories.
That one time when we created a Facebook integration and then killed it.
The first was when we added Facebook integration with an Outlook solution for real estate agents. We tracked every bit of effort – from development to specific feature support requests. But when it came to the attribution model, it was hard to know if the feature had ever really delivered new customers.
Most importantly, we tracked additional investment. Features take upkeep, as I told you. And when it comes to Facebook APIs, man – that was a crazy investment.
The feature ROI was murky because of revenue attribution, but one thing was clear. The cost of upkeep was so high that we only had one call.
Kill the feature. And that's what we did.
The other time where we created a feature and then focused it on a new market.
The other day I told you about a new feature we built at Nexcess, called StoreBuilder. It's an AI agent that builds pages for a new store from scratch. And every store is unique. It works with WooCommerce. So logically we will add it to several of our Managed WooCommerce hosting plans, as a feature.
But the real work to calculate the feature ROI was to pivot it to a different audience. A down-market audience that doesn't know or can't spell WooCommerce. To them, it's a…wait for it… Store Builder.
And guess what happens when you focus on a different customer?
- You have to create content that isn't written for that other “insider” audience.
- You have to use language and different value propositions than when you sell WooCommerce.
- You have to market to this audience in different places, with different calls to action.
But when you do this, you really focus on a different customer. A different segment. And that's what lets you do the attribution. Because now you know if you win customers in that segment, they're not here to buy your hosting plan with a StoreBuilder feature. You know they're buying StoreBuilder directly, without thinking about hosting or WooCommerce.
The only way to (easily) do feature ROI, is to create features for new segments and adjacent markets so that you can do the math correctly.
And when you do it right, and you regularly use your features to expand your market, you can get better and better at knowing when to invest in features and when not to. But that's a completely different post for another day.