I had a very interesting conversation with our product manager yesterday centred around ensuring the development team is always working on the highest value functionality for our clients (and thus the business). One of the key messages I took away from the conversation was the distinction between estimates of cost for development work and estimates of value.

So what exactly do I mean by cost and value? Cost is generally fairly simple to measure, it’s the amount you have to pay for the resources used to actually develop a function. That includes developer time, office space for those developers, hardware and software etc etc. There’s a lot involved to get an accurate assessment of the cost but it’s fairly straight forward to measure it as you spend. Just ask accounts for the figures. It only gets difficult once you start taking into account opportunity cost which is generally ignored anyway.

Value on the other hand, is a lot harder to measure. The simplistic definition of value is the amount of revenue generated by a feature – roughly number of customers * purchase price. Of course, a decision to purchase isn’t made because of one function so you have to come up with some way to share the revenue between the various features, not to mention determining which features affected the client’s decision in the first place.

The profit from a feature is thus: value – cost.

Most teams only estimate development cost, generally in terms of how long it will take and then just use gut feel and relative ordering for value rather than actually estimating it. Given how hard it is to measure value even retrospectively they never really get an idea of value or profit on individual features. While that’s understandable, it does make it incredibly difficult to learn from past decisions and improve the feature selection process.

The more I think about it, the more I think it’s important to find some way of estimating value ahead of time and measuring it afterwards so you can improve your estimates over time. Better estimated value leads to better prioritisation of features and better usage of resources. What was really interesting during the discussion yesterday was the response from our product manager when I asked him to estimate value. It was exactly the same reaction you often get from developers when you ask them to estimate how long something will take. There’s so many variables and complications that they starting squirming and trying to get out of giving an estimate.

They’re right of course, estimating something complex is really, really hard and it does take a lot of time and effort to do. It’s a lot easier to just say it will be done when it’s done, or in this case, it’s worth what it’s worth. Businesses expect developers to come up with quantifiable and reasonably accurate estimates of cost and they are prepared to invest resources in getting those. On the other hand, businesses seem to shy away from investing in getting quantifiable and reasonably accurate estimates of value because it’s too hard. I’m left wondering, why is the cost so important to know, even in the absence of the value and thus the profit? Why isn’t it important to know the profit? If we put in the effort to establish and refine a system of estimating value, wouldn’t that lead to better product decisions?