Value Realisation

A primary goal of Agile is quicker product net value realisation, but how does one assess value? It depends. Let me start by saying Agile is not a one-size-fits-all methodology. In some cases, a company is not even seeking agility, so Agile is not the prescription (Rx image). Without going down a rabbit hole, this is where SAFe fails. SAFe is an OK framework, but despite the A in the acronym, there is no agility in SAFe. The name gives it away. It’s for companies that need to play it safe whilst simultaneously signally that they’re Agile. I’m not sure who can’t see through their ruse, but let’s keep moving. Nothing to see here.

Value may take several forms. I tend to think of it as:

• revenue generation
• revenue protection
• market share
• customer acquisition
• customer retention
• costs cutting
• costs deflection
• learning

These work well in a monetised setting—a consumer product. For internal projects, it’s tougher to establish where the value is and then to measure it. I’d be willing to argue that internal products are more often just projects, and they should be developed by a different methodology, even if there is a desire for agility. I recommend RAD or some such. Let’s continue.

For products, each aspect—feature, function, behaviour—should come with a value proposition and hypothesis. Why should the product include X, Y, or Z? What value is it expected to deliver and in what time frame? Of course, we need to understand any offsetting costs to arrive at a net value. It makes no sense to pay ￡100 for a feature expected to return only ￡10.

As a Product Owner (henceforth, PO), it’s up to me to make this hypothesis in concert with the requesting stakeholder. If the feature is based on customer feedback, the PO needs to do some legwork to estimate the impact. It’s good to understand the pulse of your customers, but, yet again, it makes no sense to implement a ￡10 feature that costs ￡100. Customers will ask for any number of things. You need to determine the value calculus.

But there’s more. If you implement feature functions X, Y, and Z, and each claims to bring in 10% more revenue within three months, and you increase revenue by 10% in three months, is this a success?

It could be. Firstly, the market may have moved to a place where this gain might have happened regardless. Secondly, each claims to bring to 10%, but you only see a 10% gain, so you are missing 20%. Each requestor will insist that their feature function was responsible. I can all but guarantee that’s what they’ll tell their respective bosses. But you know better—and you know it could be none of the above. This brings us to instrumentation and measurement.

Each of X, Y, and Z needs instrumentation to trace traffic and usage patterns. In an oversimplified case, track clicks. If X received all the clicks and Y and Z got none, the answer is obvious—and maybe remove Y and Z to simplify the user interface. Your customers will thank you.

But what if the value you seek is learning? Set up some A|B or MVT (multi-variate testing) and run some scenarios. In the end, you need a stated hypothesis.

Likely, more words should be here but just look at the picture. It's worth a thousand of them.