Solutions Versus Features
Everyone on that conference call had an immediate and visceral appreciation of the value of making the beeping stop. That’s the power of solving a problem. The methods of solving the problem – mute the offender, replace the battery, throw the alarm out the window – do not have implicit value. They have an indirect value, in an “end justifies the means” kind of way. But not direct value.
The same sort of thing applies when talking about prioritizing features. Eric Krock (@voximate) just wrote a really good article, Per-Feature ROI Is (Usually) a Stupid Waste of Time, where he does two great things, and (barely) missed an opportunity for a hat trick.
The first great thing Eric did was look at the challenges of determining relative (ordinal or cardinal) value of “several things.” He points out several real world challenges:
- When you have a product with several things already and you want to determine the value of yet another thing – how do you allocate a portion of future revenue to the new thing versus the things you already have?
- When thing A and thing B have to be delivered together, to realize value, how do you prioritize things A & B? Relative to each other?
- The opportunity cost of having your product manager do a valuation exercise on a bunch of things is high. She could be doing more valuable things.
- You won’t perform a retrospective on the accuracy of your valuation. So you won’t know if it was a waste of time, and you won’t get better at future exercises.
The second great thing Eric did was reference a Tyner Blain article from early 2007 on measuring the costs of features. I mean “great” on three levels.
- As a joke (for folks who don’t know me, figured I’d mention that I’m kidding, just in case you get the wrong idea).
- There is some good stuff in that earlier costing article about allocation of fixed and variable costs (with a handy reminder.
- Eric’s article gives me an opportunity to shudder at the language I was using in 2007, see how much some of my thinking has evolved in four years, and improve a bit of it here and now.
What Eric slightly missed is the same thing I completely missed in 2007 – features don’t have inherent value. Solutions to problems do have value. He only slightly missed it because he got the problem manifestation right – it takes a lot of effort, for little reward, to spend time thinking about what features are worth. I also missed the opportunity in an article looking at utility curves as an approach to estimating benefits, written two days after the one on cost allocation. We were both so close!
People don’t buy features. They buy solutions. Valuing Solutions Instead of Features
Estimating the value of solutions addresses a lot of the real problems that Eric calls out. It also has a side benefit of keeping your perspective outside-in versus inside-out. Or as others often say, it keeps you “market driven.”
Anything that you’re doing, as a product manager, that has you focused on understanding your market and your customers and their problems is a good thing. It may even be the most important thing. I would contend that it eliminates objection 3 – the opportunity cost of estimating the value of solutions is minimal or zero. There may be activities with more urgency, but off the top of my head, none that are more important, for a product manager.
Comment if I’m missing something (it’s late and I just got home from another week on the road).
The way I approach determining the value of a solution is by developing a point of view about how much incremental profit I will get when my product starts solving this additional problem. Revenue can increase from additional sales, or from the ability to increase prices. Cost can increase if new marketing and other operations (launches, PR campaigns, etc) are required to realize the incremental revenue.
I start with a customer-centric market model.
A given solution, or improved solution (as in “solves the problem better,” or “solves more of the problem”) – which only applies to some problems – is interesting to some customers, in some market segments.
A solution has value when it brings in incremental customers, in a targeted market segment. It also has value when it reduces or prevents erosion of your current customer base (in a SaaS or maintenance-revenue model) to competitive solutions.
The time you spend thinking about buyer and user personas, the problems they care about, and the nature of those problems (which varies by persona) is not time wasted – or even spent “at the cost of doing something else.”
To make this useful, you have to have a forecast – without solution A, we will sell X; with solution A we will sell Y (and to whom). A good product manager will be looking at sales, and will be able to reconcile the sales with the projections. That helps with objection 4 (but doesn’t completely address it – you don’t know if your projections were accurate, so you can’t really know if your estimation is accurate).
This also helps you deal with challenge #1. You’ve got a model that says “the current product works great for high school students, but not college students, because they also have problem A, which they solve today by…” Your intention is to create solution A, making your product viable to college students. Allocate the incremental profits from college-student sales to solution A.
My approach to challenge #2 is a little more tactical.
Coupled Solutions
There are a couple ways that Eric’s “must deliver A and B” scenario are interesting, when looking at the value of solutions.
Scenario 1: Solution A solves part of problem X for persona M. Solution B solves part of problem X for persona M. Combined, they solve more of problem X for persona M.
This makes sense for “more is better” problems – where “more” solution yields “more” value.
In this case, I have a forecast (the more time I spend on it, the better it will be) that maps incremental sales to improved solutions. The “first” solution to be released will have more value than the second. If they are being released together, then I don’t care about the allocation – I combine them.
Scenario 2: If, however, the two solutions are valuable to different personas, then I treat them separately – even if they solve “the same problem,” it is not the same problem (for the same person).
Conclusion
Prioritization by “Bang For the Buck” is worth doing.
Just make sure you are prioritizing solutions, not features.
Also note: this article talked about valuation – what you do with that valuation, prioritizing by market, can be trickier.
Reference: Don’t Prioritize Features! from our JCG partner Scott Sehlhorst at the Business Analysis | Product Management | Software Requirements blog.
