I’ve been working on and teaching customer centric product management methods for more than 20 years. Some things, like the outcome-centered approach to product roadmaps, have been a part of my workshops and keynotes for nearly 7 years. I teach or speak about these ideas on a weekly basis, usually multiple times per week, and yet, every now and again someone, hearing these ideas for the first time processes it in a way I hadn’t thought of before. This is exactly what happened in a product management workshop I was teaching with a client last week.
“This is value-based delivery”
The class was filled with delivery managers (sometimes called technical product owners or release train engineers or a thousand other job titles) so the focus was less on the inception of product work but more on an outcome-focused approach to product delivery. We had identified our target audience using proto personas. We then came up with our goals in terms of customer-centric objectives and key results. This is where things got particularly interesting for this group. The next step in our process was to identify potential solutions to build and phrase them as hypotheses. A hypothesis is a user story in the scrum sense of the phrase with one significant difference – the definition of done is not “works as designed” but rather a meaningful change in the behavior of our target audience, in other words an outcome.
These delivery managers found this interesting because they don’t currently get measured on whether the feature they shipped was desirable or viable, only if it was feasible. Changing the measure of success to an outcome meant that deciding if this deployment was successful was no longer a binary question. It was an ongoing process of optimization, sensing and responding in order to ensure their customers were getting value from the new feature.
We then took the hypothesis they selected and created a user story map for it. The idea here was to map out the customer journey for their selected idea and visualize all the various ways we may end up developing it. Finally, using Jeff Patton’s value slicing technique, we created a release strategy. Our initial launches would have light scope and be designed for a subset of our target audience. As more data came in confirming we were on the right track, we’d release more functionality to more people. And that’s when it happened. A student in the class raised her hand and said, “This is value-based delivery.”
Making the obvious even more so
I was stunned into silence for a moment. She was spot on. What this manager was able to do was take the material I’ve been teaching for more than two decades and summarize it in a way that, not only had I not thought of, but that made it obvious to this audience – technical PO’s – what this new way of working actually implied. She continued, “We normally do feature-based delivery. We deliver what we’re told, make sure it works as designed at scale and then move on to the next ticket. This forces us to check if what we shipped was actually worth doing in the first place and how good of a job we did.”
If you ever watched the A-Team in the 1980’s you know that Hannibal’s catch-phrase at the end of each show was, “I love it when a plan comes together.” That’s how I felt. We hadn’t changed anything in our class but exposing it to a different audience brought out a new angle on the same material. The material resonated and we learned a new way to talk about this evergreen material.
Deliver value, not velocity
It’s not like we don’t use the word value in our classes but we always tie it back to outcomes as the goal of each delivery. It may seem subtle but this change to value-based delivery provides another path for this conversation to take. When we’re working with product managers and designers the idea of an outcome resonates clearly. However, when working with more technical folks, they don’t always feel that close to the customer. Helping them understand how each release is supposed to deliver value to a specific customer and how we can figure out if we did, means that more of the people involved in getting a product out to market are keeping the customer in mind. All this, from the unique perspective of a student in class. This is why I love teaching.
