How we put a value on every feature in our backlog
Helping the prioritization discussion with some numbers people can relate to
One of the first things I spoke to my CTO about when I started one of my roles was what it actually cost us for each hour of a developer’s time.
Not the amount we pay the developer, but the actual cost of that developer being in the business, when you take into account not just their salary, but their pension contributions, their training, their equipment, their share of the heating and lighting, and a host of other things.
I was lucky, in that the CTO knew what the number was.
From this we had our Average Hourly Cost, which we could use alongside our estimations of time to deliver, in order to give us a rough cost of delivering the feature.
This was going to be useful in helping us determine the value that we could deliver for the business with a particular feature, but it was only half of the equation.
(Before we move on, yes, I know we’re estimating in time and that’s not the way many people do it but you need to do something to figure out whether the effort v reward calculation works in your favour. It’s just a finger in the air estimate to help us work out how to plan where the work sits)
Every time a stakeholder asks for a new feature there is a reason behind it, and it’s the product team’s job to determine what that reason is so that we can deliver the suitable solution that delivers on their goal.
It might be that they want to save time, reduce costs, increase revenue, or stay within the law, but they know what they want.
What they don’t always know is how much value they think can be delivered by the introduction of this feature, which is where the product team comes in with questions designed to tease out the information needed to complete the equation.
If a feature is to save time, then how much time is going to be saved in a week, in a month, in a year? What is the cost of this time to you (e.g. what is the average hourly cost in your area of the business? what is the opportunity cost of this time?)
If a feature is to save money, then how much money is it going to save this month or this year? What are we not going to pay for that we would otherwise be paying for?
If a feature is to increase revenue, then by how much is revenue going to grow and over what time period?
Once you have both sides of the equation you can have some sensible discussions about what is worthwhile doing and what simply doesn’t stack up as something that’s going to deliver enough value.
If something will cost you approximately $300 to build but only deliver approximately $200 of time savings, you can use that information to make a decision. You still might do the work because there are always more factors in play, but at least you’re doing it from a position of knowledge.
Isn’t it better to know that delivering Feature A will cost you $1,000 in development resource, but that it will have a high probability of delivering you $50,000 of increased revenue?
You’d be amazed how less important a feature becomes when the stakeholder is made to consider the cold hard numbers involved in what they’re asking for.
Get content like this direct to your inbox
If you’d like to receive more product management focused content like this then subscribe to my newsletter to get it delivered straight to your inbox.
Clicking the image will take you to Getting Started In Product where you can sign up to the newsletter
Rob was a footballer, cinema manager and recruitment consultant before getting in to software products. He’s been looking after products and hiring product teams for 20+ years, is currently product owner at luxury watch retailer Watchfinder and writes about how those who want to get into product can go about doing so, as well as how to do the job when they get there.