Value: The Lynchpin in Agile Product Management
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 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); and 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. 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.
Let’s keep the conversations going!
P.S. Join our Agile Product Open Meetup to stay tuned to more events and gatherings.
Great post Ellen. Totally agree that value is subjective and “in the eye of the beholder” … question then is how do you make value transparent if it’s not concrete? One way we try to do this is to have clear traceability between people and requirements so that if you’ve got questions about a requirement then you know who to go to talk to and you’re talking to the person who really values that requirement.
Hey Ellen,
This is so good! Just sent it to the whole team I’m working with. All the best!
Elena
Thanks Tom.
Certainly trace matrices (as in a classic backward trace from story or requirement (in whatever form), back to the stakeholder with the need can be used).
We like to streamline the conversations by having reps from customer, business and technology clarifying who those partners are (stakeholders in that vernacular) and what their value considerations are for the next planning horizon. The Product Owner/Champion needs to have a clear understanding of the ‘who’ and the value for all relevant ‘who’ to make investment decisions. If the team is doing the delivery work close in time to the discovery work, and are involved in the conversations, there is less tracing infrastructure needed.
You surface a key point: requirements exist for a reason that must be well understood–and valuable!
Thanks Elena!
[…] value is a mantra recited as the rationale for using agile and lean. And yet, it’s often not well understood. [1] To make smart product decisions, value needs to be clear, explicit, testable, and […]