You’d think the topic of value would be straightforward when it comes to agile product management and ownership. After all, early and continuous delivery of value is the first principle in the Agile Manifesto and product backlogs need to refined based on value.
And yet, value is not easily defined, qualified, quantified, or agreed upon.
With many smart, experienced folks together at the Agile Product Open last month, I decided it would be informative to propose the topic “Value: The Whats, Whys, and Hows” in the marketplace of ideas.
To start the conversation, I offered my favorite definition, borrowed from the Value Standard: fair return or equivalent, in goods, services, or money, for something exchanged. From there, our conversation grew richer and deeper.
Below is the sketch note summary Iris Febres made of our session:
As you can see, participants shared a number of value-related struggles (on the top right). And, we shared a wide variety of value-related tools and techniques (in alphabetic order):
- Cost of delay
- Economic value added
- Net present value
- Net promoter score
- Prioritization matrices
- Value considerations
- Value points
Some of these value techniques and tools require more time to prepare and use, some rely on judgment and deeper research, and others are more qualitative versus quantitative. I shared an acronym we use in Discover to Deliver to explore value from a business lens: IRACIS, which stands for Increase Revenue, Avoid Cost (e.g., operational savings and protect revenue), Improve Service (happy customers are repeat and retained customers—and can even help promote your product).
Most people consider value in terms of money, but that is not always the case. Value can be either tangible or intangible, for example, the value consideration of “trust” or “belonging”.
This discussion moved to a crucial fact about value:
Value Is in the Eye of the Beholder
When we asked ourselves, “whose value do we care about?” that bright day in Boston, our conversation got deeper. We dove into who are our product partners—what some call stakeholders. These various partners have diverse views about what they think our product’s value is. The best products evolve from collaboration among all the product partners, led by a smart and passionate product person.
Product partners come from these realms:
- Customer (users, choosers, advisors);
- Business (sponsors, product champions, business partners, subject matter experts);
- Technology (product makers who define, analyze, design, architect, develop, test, document, and support the product).
For some customers, value might be saving time from tedious tasks. For others, value might be feeling like part of a movement or being one of a product’s early adopters.
For one business, value might be brand projection. For another it might be protecting revenue from regulatory non-compliance that could result in fines and bad press. For yet another, it might be increasing revenue.
For technology partners, value could be having a product that scales as usage increases. Ideally, business partners understand the value in this, too.
To have a holistic understanding of value—and to make well-informed value-based decisions as you incrementally deliver your product—a smart agile product owner or manager needs to know:
- Who the product partners are
- What they consider valuable at this point in time
Which lead our conversation into acknowledging that:
Value Changes with Time
Using agile and lean principles to deliver the highest value increments of your product over time allows you to respond to change—in market conditions, competitor moves, business solvency, regulations, economic conditions, technology advances, and more. That’s goodness—being able to flex your product decisions based on reality, as it’s happening.
But with that flexibility comes the corresponding responsibility to constantly ask, “What is most valuable for each product partner for our next delivery cycle?” This is one of an agile product owner’s key duties: optimizing the work of the development team based on the changing landscape of value.
Balance Risks and Dependencies
Complicating all this, even if you make your product decisions based on a ranking quantification of value (e.g., the highest net present value), you still must take risks and dependencies into account.
One client we work with is in financial services. When planning their next release, the product owner decided the risk of getting hit with an upcoming regulatory change trumped working on a highly valued customer feature. It was a tough decision—to not focus on a desirable feature that would provide marketing bragging rights—but a necessary one.
Consequently, they reduced their technical debt and avoided the risk of expensive noncompliance fines. In the end, the product owner’s decision freed up the development team to deliver features smoothly later, without sapping all their time forcing more compliance changes into a cranky architecture.
Make Value Transparent
We all agreed: value is the single most important basis for making decisions in agile product management and ownership—and yet, we don’t tend to qualify, quantify, or discuss what value means nearly enough. Making value a driver for ongoing backlog refinement is essential to obtaining the promise of agile. And, we can do better by frequently and widely socializing our product’s value with all product partners.
Great agile product ownership relies on partners transparently leading value delivery by continually defining what value means for the ever-evolving product.
It was a joy to openly delve into the topic of “value” at Agile Product Open and to explore our shared–as well as diverse–perspectives of the value of value.
Learn to Reflect Value in Your Backlog
Attend our two-day Backlog Refinement Practitioner: Successful Agile Requirements Analysis training on 14-15 November. You will learn to define and refine your backlog based on value and collaboratively prepare for value-based planning.
Note: This blog originally published on the EBG blog here.
