The 2017 version of the Scrum Guide states, “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” But what does value mean anyway? The easy answer is to equate it with a monetary value, however, it is much more subjective than this. I found a dictionary definition of value as, “the regard that something is held to deserve; the importance, worth, or usefulness of something.”
The words “regard”, “importance”, “usefulness” do not strike me as terms that directly correlate to monetary value, though I do concede that people are prepared to pay for the derived “regard”, “importance”, “usefulness” of something. However, what some may deem to be valuable, others may regard as worthless. For example, as an amateur musician, the appreciation I would have for a Gibson Les Paul Custom guitar would justify its hefty price tag, but to other people, it’s usefulness is similar to any other plank of wood with 6 strings nailed to it.
There is also the perception of what value means to the organisation as well as for the customer. For some companies, calculating Cost of Delay (considering the impact of time on the outcomes we wish to achieve, e.g. how much does it cost us if we delay by 1-month) or Return of Investment (the ratio between net profit and cost of investment) to determine monetary value can be useful guides. For other organisations though, value is not about revenue. The immediate goal could be to grow the customer or user base. In their early days, Facebook wanted to get people to sign-up for an account - generating revenue from it was to come later.
Value can be in intangible things such as building company brand awareness, increasing employee or customer satisfaction and retention levels. Money as a measure of value moves further out of sight when we think of government agencies, NGOs, academic institutions and charities where the notion of value is completely different. Value in this sense depends on the context and the organisational mission. And then there are the mindsets from the likes of the Lean UX and Lean Startup movements that value is in learning about what is currently unknown (Will people like our idea? Will they buy it? Can we build it? etc) and validating or disproving hypotheses regarding our products or services.
Value then really is in the eye of the beholder. One of the main ways that a Product Owner can maximise value is in the ordering of the Product Backlog, yet value is such an open and context specific construct. Which makes ordering Product Backlogs extremely difficult and why there is no one-size-fits-all silver-bullet technique (if such a technique does exist, please let me know and let’s write a book about it!). Every context is going to be unique and policies for ordering Product Backlogs that work well in one environment may be disastrous in others.
It really helps to make it clear what the goals or outcomes that are trying to be achieved are. This can be a business outcome, such as a reduction in shopping cart abandonment rate if you are an eCommerce site, and a benefit to the users/customer that results in a behavioural change. This could be the customer having all of their questions about buying a product answered and so goes on to complete a purchase.
Achieving these outcomes could have desirable impacts as a side effect; e.g. an increase of revenue for the organisation, or the customer’s life becomes easier and they have more time to do other things. Where I have seen teams and organisations struggle is when they make these sorts of things the goal. And where they struggle even more is when the focus is on output - i.e. the amount of stuff done, such as the number of features or story points delivered. These are things that are much easier to measure, and yes it is important, but we may be kidding ourselves that value is being delivered by measures of output alone, especially where knowledge work is concerned.
To truly maximise value then, the first step is to define what it means in context. And to do that, we need to define the goals in terms of desired business and user outcomes, as well as the associated benefits that our effort should achieve.