Business Cases where product owners have to justify investments by presenting the benefits in financial (monetary) terms are toxic. They create two significant problems that prevent a customer focused agile approach to product development:

1. They remove the need for executive decision makers to learn about business value metrics.
2. They create a big batch development mentality rather than a desire to create a continuous flow of value and learning about the customer.

Many executives embark on an agile transformation with the intention of becoming more responsive to customers needs. Unfortunately executives want to change their product organisations but retain practices that stifle agile transformations. The worst of these is the business case expressed in financial (monetary) terms.

The Business Case

An Agile product owners identifies an opportunity to invest in the product. Traditional organisations insist that the product owner justify the investment in financial terms. The product owner then has to explain the investment idea in monetary terms.The conversation goes something like this:

• Product Owner: I want to build a purple widget.
• Executive: What is the business case?
• Product Owner: This spreadsheet model shows that if we build the widget we will make £1,800,000.
• Executive: How did you come up with this model?
• Product Owner: We hired some consultants who used the data from one of our other products.
• Executive: The return looks good so go for it.
• Product Owner: Great so if we deliver a purple widget, we get to claim the £1,800,000 benefit? After all, there is no way to check that we have actually delivered the £1,800,000.
• Executive: That makes sense.

To make this approach work, the product owner describes the solution in terms of functionality and then translates that into a financial amount. The executives then agree that building the solution will deliver that amount of financial benefit. Given the complexity of most organisations, it is impossible to directly attribute any financial outcome to an individual investment. As a result, the product owner gets to claim success simply by delivering the solution.

It is even worse when the translation to a financial amount is limited to those translations supported by existing data. This is equivalent to searching for you car keys under a street light when you dropped them in a field.

A further consequence is that the product owner knows what they need to do for success and seeks to minimise the effort to build it. Rather than build the solution incrementally, learning about the customers and their needs as they build it, the product owner builds the whole thing in a big bang waterfall or water-Scrum-fall development. There is no point building it incrementally as the Product Owner already knows what they have to do in order to be successful.

The Metrics based Approach

In the metrics based approach that modern, customer centric organisations use, the Product Owner identifies an opportunity to invest and expresses it in terms of a metric.

The product owner and the executives should engage in a conversation to agree the exchange rate between the metric and a monetary amount. For example, the product owner has identified an opportunity to improve the conversion rate of the customer acquisition funnel. The conversation might go something like this:

• Product Owner: Currently our conversion rate is 35%. I think we can do some things to get that closer to 50%. What is that worth?
• Executive: I’m not sure, lets work it through.
• Product Owner: We currently get 100,000 potential customers a month into the funnel and 35,000 sign up as customers, or a conversion rate of 35%.
• Executive: Our existing one million of customers generate £10,000,000 in revenue which means £10 per customer.
• Product Owner: Therefore a 15% increase of conversion means 180,000 extra customers a year.
• Executive: Or £1.8 million, which is a good deal based on the proposed investment.
• Product Owner: And a 10% increase of conversion is worth £120,000.
• Executive: So every 1% increase is worth £12,000, or lets keep it simple and say £10,000 per 1%.
• Product Owner: I can work with that. Do you want to know what we intend to build? I have the specs for the purple widget here.
• Executive: Only out of interest and to ensure that the investment is coherent with the outcome. It is your responsibility to ensure the conversion rate moves, after all, you are the one with all the detailed knowledge.
• Product Owner: So if you agree with what I suggest and I build it, I’m a success?
• Executive: You are only a success if you increase the conversion rate regardless of whether I agree the purple widget sounds like a good idea. The responsibility stays with you.
• Product Owner: In that case I build what I want, how I want, as long as I improve the metric you agree to, in this case the conversion rate?
• Executive: That’s the deal. That what autonomy means.
• Product Owner: What about the coherence thing you mentioned?
• Executive: I’m responsible for a wider set of metrics. The only challenge I will make to your investment is if what you intend to do is not coherent with the metric you intend to move. For example adding Adverts to the funnel to improve conversion.
• Product Owner: Got it, because Adverts increase revenue but will possibly harm conversion. So Adverts should be aligned with a revenue metric directly rather than the conversion metric.
• Executive: You got it.

In this example the Product Owner retains responsibility for moving the conversion metric. The Product Owner needs to build something that moves the metric and cannot claim victory simply by implementing the purple widget. The success of the Product Owner can be easily determined from whether they moved the conversion metric. The Product Owner and Executive have agreed an exchange rate between the conversion metric and the “financial return” so that the executive can judge whether the investment is sound or not. The exchange rate can change based on the sentiment of the executive. For example if churn is high and customers are leaving, they may prefer an investment to reduce churn rather than conversion which simply on-boards customers who leave.

The First Investment

The first investment that a competent product owner makes is to establish the baseline values for their metrics. This allows them to determine whether their investments are working or not. If you do not know your starting point, there is no way to know whether the things you are doing are improving the product or otherwise. Without your baseline metrics, you have no way of learning whether the things you have built are a success or not.

A culture of Metrics versus Features

When your goal is to move the metrics instead of building features, you have to learn about your customers and their needs. If you do not study your customer, the features you build are a big gamble, nothing more than a wild bet.

Building features is hard, however it is CYNEFIN.complicated problem which can be solved by experts or analysis. Moving metrics involves building features which is CYNEFIN.complicated, and it is also hard because understanding what your customers need is a CYNEFIN.complex problem to solve. Poor quality Product Owners will ask their executives to turn their CYNEFIN.complex problem (Move the metric) into a CYNEFIN.complicated problem (Build a feature). It is the responsibility of the Executive to prevent the product owner from doing this.

A simple trick for Executives is to get their product owners to move the metric to claim success, and give no credit for simply building the feature. In short, ditch the business case and embrace metrics.