The goal in product work is not to build products. It’s to create value—value for users and, ultimately, for the business. This is done by changing the environment in ways that allow for new, value-adding behavior.
These changes could be coded product, or redesigned workflows, or improved policies, or…whatever you can think of. (Why limit yourself?) The behavior changes you’re after, the OUTCOMES, are why you’re doing whatever you’re doing (Seiden, 2019).
Delivery is never a good measure of success (see Perri, 2019).
So, What’s the Problem?
It sounds so logical, doesn’t it? The trouble is, even when teams TRY to focus on outcomes over output, or value over velocity, they’re often met with challenges. First, they may not be in an org that meaningfully allows them to take such an agile, empirical approach to the bets they’re placing. (SAFe, anyone?) Second, even when given the freedom to focus on outcomes, teams often get cold feet.
You mention “outcomes” and people start acting like you just sprang a pop quiz on them. You put them on the spot—there’s a right answer, they don’t know it, and they don’t want anyone to find out they don’t know it. It’s OK though. There is no one right answer, but there are lots of GOOD answers. The trick is to change people’s thinking to be more lateral.
If you go about it wrong, eliciting outcomes can be like pulling teeth. In fact, a point made in the world of counseling is that it’s EASIER to focus on problems and solutions. Getting people to focus on outcomes often requires good facilitation and coaching (Tompkins & Lawley, 2006).
Mike Burrows, in his excellent book, Agendashift (2018), describes a process for eliciting outcomes using Clean Language, an interview technique that came out of NLP. This inspired me to search for other techniques from counseling that could be applied to product work. In this post we’ll discuss one, based on Values Elicitation (also from NLP). Lots of coaches have talked and written about it. I first learned it from hypnotist Mike Mandel and base my take on his description.
The original technique focuses on increasing a person’s conscious awareness of deeply-held values, as well as the criteria she uses to know when her behavior is in line with them. The key here is that the outcomes are not the values—they’re elicited as the CRITERIA. Knowing WHY it’s doing the work it’s doing can be powerfully motivational for teams. Crisping this up and making it salient opens beneath it a lateral space for innovation. It increases adaptability. Ready to learn some magic?
The Elicitation Technique
So how do you this? It’s all about facilitation. You can create magic simply by asking the right questions. You’re the facilitator. You’re talking to a product team. First, inquire about WHAT the team is working on. Teams find it much easier to talk about the WORK they’re doing, so here’s your first magic trick: To get after important outcomes, inquire about import work.
Behind a team’s opinions about what work is the most important will be its assumptions about outcomes and value. What does the team think are its blue-chip activities? Ask some variants of, “Out of everything you’re working on right now, what’s one of the most important things you’re doing?” The team mentions a feature. Feature X.
Now ask, “What is important about Feature X?” Someone says, “It will enable users to add filters to their searches.” You follow up, “And what, specifically, does that achieve?” You’re after deeper answers. Someone replies, “The filters refine searches so users can more quickly find what they’re looking for on the intranet.” You keep going, “And what does that do for them?” Someone says, “Well, if users can find information faster, they’ll spend less time creating reports and prepping for meetings.”
Good. Now uncover some more: “What else are you working on that’s important?” “Feature Y.” “And what’s important about Feature Y?” “It allows users to add metadata to their uploads.” “And what does that achieve?” “Blah, blah, blah.” “And what does that achieve/do for them/enable/etc.?” “Blah, blah, blah, blah, blah.” You get the idea. Keep going until you’ve gone through at least three important things the team is working on, three “blue-chip items.”
On your notepad (yes, you need a notepad—do NOT use a laptop), write down every answer that sounds like an outcome. These will be statements that give you the “So what” of the work, that state HOW the world will be different as a result—the value-adding behavior changes the work will enable. For each outcome, if you kept digging you’d eventually end up with a value statement, likely something around reducing or avoiding cost or increasing or protecting return. This can be valuable, but for present purposes isn’t necessary.
The Ranking Technique
Combine the outcomes from the different work items discussed. You might have several for each but you don’t want more than five or six total. Write them up on a whiteboard or flipchart. Take the top two and ask, “Comparing just these two statements, which would be more important to achieve?”
You want this to spark debate. Follow up to generate deeper discussion: “And what makes this the most important thing?” “How is achieving this thing more value-adding than the other thing?” Take the winner and the next outcome from your list and repeat. “Of these two, which would be more important to achieve?” “What makes this more value-adding than this?” Keep going until you’ve gone through the entire list, comparing the winner to the next item down, eliciting discussion and debate each time. Now you have what the team thinks is its most important outcome.
Remove it from the list and write it at the top of a new list, off to the right. With the winner removed, rinse and repeat, avoiding duplicates. For instance, you’ve already had them compare A and B, and C was the winner, so here you would start by having them compare A and D. Continue until the second most valuable outcome surfaces, then again move it to the list on the right, below the winner. As the list on the left gets shorter and the list on the right longer, you’re eliciting debate as you generate a RANK ORDERING of the outcomes captured.
This might take a while and that’s fine. After all, you could have just had the group vote on which outcomes are the most important, quickly producing a rank order, but it wouldn’t have generated as much discussion, as much debate, as much SURFACING of assumptions. The discussions the team has in the course of this technique are important.
The team members need to know whether they have the same understanding of the work they’re doing, of the goals they should have, of the value they COULD be going after. Sometimes you’ll find they don’t, and the sooner this is surfaced, the better. By the way, this was your second magic trick: The team just aired and debated assumptions without you having to ask them to.
The Crisper Technique
Sometimes what you’ll have will still sound more like vague goals, so now it’s time to take your new list and crisp it up. Not all the outcomes have to be stated in terms of concrete behavior change, but MOST of them should by the time you’re done. The idea is to establish UNAMBIGUOUS PIVOT SIGNALS. These let the team know how its bets are working out. When the team does some work (places a bet), if the needle doesn’t move in the right direction, it knows to try something else.
Take the top outcome—without calling it an outcome—and start doing your magic: “How will you know when you’ve achieved this?” “What needle will this move?” “How will the world be different from how it is today?” “Whose behavior will be different?” “What will they be doing differently?” “How will their behavior change?” “By how much?” By asking variants of these examples (don’t ask all of them!), you’re eliciting the behavior change the work is meant to generate as well as a target metric.
The point of crisping up outcomes is to ensure they are well-formed. Here are some recommendations for “outcome well-formedness” (another concept from NLP), adapted from Gilb (2005): The outcome is positively stated, stated in terms of whose behavior is expected to change (such as users, customers, employees, etc.), contains nothing about a design or solution (nothing about HOW it should or could be achieved), is ecological (won’t negate its value by making other things worse), is metricized, and is a needle the team can actually move.
To metricize an outcome, you need four things, a scale, meter, benchmark, and target (Gilb, 2005). The SCALE is what you’ll measure to assess the outcome. Maybe the team decides to focus on user engagement. (As Gilb would put it, if you can’t agree on a scale of measure, the outcome is out of control.) The METER is a practical way to measure things along the identified scale. Perhaps the team will go after an X% increase MAUs (monthly average users).
Then you need a BENCHMARK. A measure in isolation doesn’t mean anything. What’s the comparison? What is the current MAU rate? Finally, you need a TARGET. What MAU rate is the team going after? A 30% increase? 100%? Ask, “How much behavior change is enough?” This separation of the target from the meter is itself a magic trick: As Wodtke (2016) notes, if you have teams agree on what to measure (X% increase in Y) BEFORE deciding on the target (30%), this breaks it into two smaller decisions that are easier to make.
With each of these, you’ll apply the same general trick: Get what you need without bringing up the formal concept. In many contexts, facilitation beats explanation. Designers tend to get this backwards.
Sleight of Mouth
Now notice what all you just accomplished. You had the team discuss what of its work is the most important, surfaced assumptions about value, elicited a whole list of outcomes, ranked them, and metricized them! You did all this without even bringing up the concept of outcomes, avoiding the proverbial brick wall.
By using these techniques, you’re also dodging a lot of unfortunate baggage. In my experience, even when organizations CLAIM to focus on outcomes, they tend to mean more output dressed up as goals, which isn’t good. A comprehensive strategy is not a glorified task list. You just did some wizardry, and you should be proud. You didn’t break through the brick wall—you moved the team around it without its knowing. Congratulations.
If you want, you can keep going. Take the top outcome and ask some more magic questions: “If this is the most valuable outcome you’re trying to achieve, are you doing enough to realistically achieve it?” “What might be three other ways you could nudge this needle?” “What’s a smaller thing you could do SOONER, and without permission from anyone, to maybe move this needle, even just a small bit?” “Could you do this next week? Tomorrow?”
You get the idea. Notice also you’ve mostly been asking “What?” and “How?” questions, avoiding troublesome “Why?” questions. (Yes, I’ll do a post on why “Five Whys” needs to go away.)
Happy lateral hunting.
Andreas, S. (2012). Transforming negative self-talk: Practical, effective exercises. NY: W. W. Norton & Company, Inc.
Burrows, M. (2018). Agendashift: Outcome-oriented change and continuous transformation. UK: New Generation Publishing.
Gilb, T. (2005). Competitive engineering: a handbook for systems engineering, requirement engineering, and software engineering using Planguage. Burlington, MA: Elsevier Butterworth-Heinemann.
Perri, M. (2019). Escaping the build trap: How effective product management creates real value. Sebastopol, CA: O’Reilly Media, Inc.
Seiden, J. (2019). Outcomes over outputs: Why customer behavior is the key metric for business success. USA: Sense & Respond Press.
Tompkins, P. & Lawley, J. (2006). Coaching for P.R.O.s. Clean Language UK. Retrieved on October 28, 2018 from: https://www.cleanlanguage.co.uk/PRO.html.
Wodtke, C. R. (2016). Radical focus: Achieving your most important goals with objectives and key results. cwodtke.com.