Anywhere you turn these days, people discussing agile development are talking about “delivering value.”  The value mantra resonates with customers and product managers, who want more of it, and developers, who would like to deliver more of it.  But wanting to deliver more value and actually delivering value consistently are two separate things.

As an industry, we work very hard at finding ways to improve our processes.  But sometimes improving the process isn’t enough; sometimes new insights are needed that introduce fundamentally different processes.  For example, TDD (Test Driven Development) went beyond how developers wrote code and how testers then tested that code.  It evolved the process by asking how a developer could know that their code would pass the necessary tests and reordered the sequence of activities (test, then code).

Similarly, I’d like to propose a fundamental change in how we engage customers and product managers to define product requirements.  If we shift from ‘what should we build?” to asking “what we need to build to show value was realized?”, then we will start:

  • Driving the customer conversation, and hence the software, towards the realization of value
  • Creating more innovate software and providing clearer product vision

Consider a registration website for an event.  As the primary outcome, I want to know that the event has a place reserved for me.  Filling out a form with my information and hitting submit is the mechanism I use to do that.  Nobody likes filling out registration forms; it represents a cost I’m willing to pay to get the benefit of being welcomed at the event.  And if, as happened to me recently, I can’t tell whether or not I was actually registered, I won’t know that I have a place waiting for me at the event.

We talk about features delivering value, but under the covers there are two different aspects of any technology:  the realization of value (the bang) and the apparatus or mechanism provided to create the value (the buck).  To complicate matters, in most technology the bang is invisible and ambiguous success fails to deliver the bang.  This gives rise to the third aspect of technology that augments the bang:  a mechanism to clearly indicate that the value was realized.

Another example would be the pause button on my DVD remote.  I know it works when I see the movie stop.  In addition, I am provided a ‘paused’ icon that appears on the screen to help me know the value was realized (as opposed to a movie halting because it is scratched and can’t be read).  The button and the remote and the infrared and the mechanism within the DVD player that bring about that result are pieces of technical functionality that add cost both to the user, in terms of steps that must be taken, and to the manufacturer, in terms of technical infrastructure that must be created and maintained.

In an ideal world, infinite value would be delivered unambiguously with zero mechanism, meaning there would be no need for technology other than to convert intent into value.  With our event registration, zero mechanism means that I could just show up at the event.  Infinite value means that I would not only be expected, but also greeted by name, have a seat waiting in my preferred location, have the order of sessions tailored so I don’t miss the ones I want, lunch would be served with my dietary needs taken into consideration, and so on.

The demands of the real world cause additional technology to arise because either a mechanism is required with which the user must interact to signify intent, or the value realization needs to be made demonstrable. In this model, the goal of technology is to provide clear indicators that maximum value has been delivered with minimum mechanisms to achieve that value.

The problem with the current process is the focus on asking the customer what mechanism should be built to provide the value. The top priority needs to be asking what needs to be built to show that the value was realized.  Ignoring the mechanism liberates the value conversation to focus on creating more of what is valuable and promotes innovation and vision.  Asking “how will the customer know they received value?” generates insights on delivering more value and focuses attention on how the attainment of value is demonstrated and communicated to the user.  Customers and product managers are free to be experts in value, not forced to be designers (or pick from a tired menu) of software mechanisms.

And, just like with TDD, it makes much more sense to define what value realization is before we attempt to create a mechanism whose purpose is to create that value.  The mechanism, for example ‘register for event’, is irrelevant to having a conversation about what constitutes confirmation and how that needs to be delivered (confirmation web page, email, etc). Focus on demonstrating value drives the interface of value:

Getting value out of features in no longer a trial-and-error process, features are first bounded by the ‘test’ of realized value (the test in this case is just deployed as a valuing-adding part of the software):

Also note that we are now motivated to minimize the mechanism that gets used to create the value. If our event registration can pull information from Facebook, Twitter, LinkedIn, etc. in lieu of presenting a registration form, we make the user’s life better and likely lower our costs as well.

If you only use the above techniques to drive better conversation, I think your requirements or user stories will improve.  However, there is a much bigger opportunity here to structure the order of activities so that we can use realized value to test drive our products.