What do we need to change in our product development process? This is something that keeps me busy on a regular basis. Focusing on Continuous Improvement through kaizen or retrospectives, in my world I hear it a lot and everyone seems to take it in without question. And why not? Improvement is good, right?
But before you look at what you want to improve, you should focus on why you want to improve. Is it to ‘automate everything’, be innovative or have a ‘zero bug culture’? While these things may sound like the ambitious objectives that will get us to the best of our abilities, according to Reinertsen we should focus on a much more basic metric: you improve in order to increase product life-cycle profit!
This economic view on product development struck me. When focusing on improvement or the prioritization of new features we tend to think about a lot of objectives like improved quality, shorter development cycles, elimination of waste, faster time to market. And while all of these are a means to an end, impact on profit, they are all influencing it in their own way.
Let’s take a look at an example. One team is discussing whether to push the releasedate back by three weeks in order to fix some minor bugs, The alternative will be to release right away in order to benefit from the new but immature product, solving the existing bugs in a separate release. So what to do? Do they go for the faster time-to-market or do they chose to push a mature product?
In order to make a decision from an economic stance, you need to know two things: (1) the extra cost that is accompanied with the faster time-to-market, which is the cost of an extra bugfix release; and (2) the benefits of releasing the product early, which Reinertsen defines as the cost of delay. Cost of Delay can be defined as the benefits that you mis out on every day you do not put a feature or release into production.
So if releasing a feature will improve sales by 30 a day at 200 euros of income per sale, your cost of delay per day is estimated at 6000 euros. So if the cost of a bugfix release is lower than 6000 euros, it is beneficial to aim for faster time to market.
Our primary aim in product development is to make good economic choices, the rest (innovation etc.) should be viewed as secondary. And in order to make good economic choices about what features you should build first or where you should improve, you must weigh both cost and benefit. So why do we see so much focus on cost and so little on the balance with benefits within product development teams…..
Mark Nijssen 
Hi Mark, I totally support your stance. What seems to be the problem in my experience is that we are quite good in calculating the costs, calculating the benefits of an (early) release is often quite difficult (or not possible at all). If you release a new product you can calculate the sales of that product. If you release new features to existing software, where the customer does not need to pay for the new features it is much harder. More happy customers will lead indirectly to more benefits but what is the share of this early release? If you get direct customer feedback on the release you can develop some kind of metrics to value it, but I haven’t seen it in practice yet.
Having said this, I know there is high value in early releasing software, where you can’t prove it directly in an economic way, it takes vision and believe to take the first steps. We still have some missioning to do……..
Regards, Paul
Hey Paul, I do recognize that teams find it difficult to estimate the benefits of additional features. Especially if the product they are supporting is very feature-rich. Because hey, you never know if an increase in revenue is the result of your feature addition or mine.
On the other hand: not estimating at all will surely not help. And shouldn’t we always have an understanding of (at least our hypothesis on) why our customers consider our product to be ‘great’? Or in your terms: what makes your customers ‘happy’ and in what way (even indirectly) does this effect the bottom line?