“mistaking “making stuff” for making progress, and mistaking shipping features for being done”
Josh Seidan

A friend posted a question on LinkedIn: "Why do software companies focus on shipping new features rather than making their products better?" The conversation hit a nerve with me. I fired back with "it's a combo of being measured by outputs, not outcomes and a lack of connecting outcomes (goals, objectives) to features, so everyone knows what they're trying to accomplish. Gotta keep shipping even if these features aren't helping." We often take for granted that shipping features is the same as shipping business value but are they? How do we know we're succeeding if we're focussed on outputs?

I've yet to meet a product team that doesn't buy into being focussed on outcomes, but often some headwinds prevent them from getting the rest of their organization to buy-in. Here are three proven methods that will not only help focus on outcomes, but it will also help you make better product decisions:

  1. Impact Mapping from Gojko Adzic. A lightweight method for aligning stakeholders and teams around delivering the highest value features that achieve a business outcome.
  2. Impact to Outcome Mapping from Jeff Gothelf. If you're struggling to get execs and stakeholders aligned on the features that will move the needle on the things they care about (e.g., revenue), this simple technique is for you.
  3. Opportunity Solution Trees by Teresa Torres. This framework encourages teams to document ways solving problems, framed as opportunities, can positively affect a strategic objective. Teresa's framework promotes an in-depth exploration of possible solutions as well as documenting experimentation and decision making.

If you've heard Teresa Torres speak (and if you haven't, you should!), you've probably listened to her reference the work of Anders Ericsson, who studies the science of expertise. Anders asserts that what sets experts apart from novices is the use of mental models. Much of his work examines chess players. When shown a chessboard captured from midway through a game, expert players could recognize patterns and deduce the play that led to the board's state and even predict which player would win the game. Novices saw the boards as random setups, and we're unable to deduce the moves that led to the current state of play. Ericcson claims, "The key benefit of mental representations lies in how they help us deal with information: understanding and interpreting it, holding it in memory, organizing it, analyzing it, and making decisions with it."

Notable computer science researchers Ray Kurzweil and Kevin Ashton have developed similar theories highlighting the importance of patterns for learning and decision making. Kurzweil argues that AI and machine learning is a series of pattern detections that build on one another. For example, when you read, you first recognize letters, groups of letters as words, the context of a series of words together that express concepts as sentences, and finally, greater meaning as paragraphs. Ashton builds on this concept noting that experts can quickly think because they make on a series of patterns formed in their brains. "Advanced thinkers think in advance. The expert's first impression is not the first impression at all. It is the latest in a series of millions."

Product is a team sport. As a community of practitioners, designers, and product people, we have developed and refined many frameworks and approaches that allow us to collect inputs and create visual representations of experiences to communicate with our teams. User Story Mapping, Job Maps, Empathy Maps, Customer Journey Maps, Experience Maps, etc. all of these have become tools-of-the-product-trade that help us document and convey the nuance and details of our problem-space: in essence, a collection of patterns distilled to allow novices and experts to have a shared understanding of a problem. It's common for teams to debate passionately why their solution is best to discover that they're coming at the problem from different perspectives. Aggravation and stress all because we didn't have a shared understanding.


UX Mapping Cheat Sheet - Nielsen Norman Group

The point of mapping the problem space is to get agreement on the problem. Imagine a voice recognition product, without context, it could interpret a single command as two completely different things: "Recognize speech!" or "Wreck a nice beach!" both are correct depending on the greater context, and both have wildly different outcomes. That's why teams must document their objectives.

The same challenge exists for the solution space: we need a shared context of not just the user problem but also the business objectives and outcomes we as a product team expect to achieve. Just like our innate need to solve our friend's pain, our same well-meaning instincts kick-in to try to solve our user's problem. And it's no wonder - helping others triggers the brain to release oxycontin, which also elevates serotonin and dopamine. Positive reinforcements result in the flywheel effect, that the higher your oxycontin levels, the more likely you are to help. That's right, solutioning is addictive. Feature Factories are a thing because we feel accomplished and good shipping something, even if that something doesn't meet anyone's needs. But you can break the cycle, I believe in you.

The techniques summarized below all use a form of mapping to frame and share work. Mapping reduces cognitive load and taps into the human ability to recognize patterns. Maps also help communicate complex information in a form that's understandable at a glance. Soon everyone in your company will be able to read your map like the Chessmasters that Ericsson studied. I sometimes get pushback using mapping techniques. Occasionally someone trots out the quote "Tourists Follow Maps, and Explorers Make Their Own." which suggests the mapping process stifles creativity and exploration. Let me put you at immediate ease -- if anything using these techniques, your product expeditions will explore far more.

What is Impact Mapping?

Impact Maps, first developed by a design agency as a low-friction means to help teams collaborate on problems. Gojko Adzic further refined the process to help software teams map their assumptions, deliverables, and connect the desired impact on users and stakeholders. When complete, Impact Maps look a lot like mind maps.

How do you create an Impact Map?

The process itself is simple; you're going to answer four questions: Why? Who? How? And What?

  1. Why are we doing this? What are we hoping to accomplish? This is your Goal.
  2. Who can help us achieve our goals? Who can prevent us? What segment of users will use our product this way? Who will be impacted? These are your Actors.
  3. How do these people help us achieve our goal? How do they prevent us? This is their Impact.
  4. What can we deliver the encourage the Actors to do the behaviors that will help us reach our goal? You brainstorm these to document your potential Deliverables.


Example Impact Map from impactingmapping.org

In this example from impactmapping.org, push updates will help drive 'Super Fans on Mobile Devices' back to the site more often, resulting in a growth in mobile advertising. Typically teams create more Deliverables than they can deliver on. Here you need to prioritize whether that's through dot voting or using your favorite prioritization technique. If you're not sure what to use, check out the Periodic Table of Prioritization Techniques compiled by Daniel Zacarias.

Impact Mapping forces teams to think about the connection between features and the outcomes they're trying to achieve. Anytime I've done this exercise, we're left with features that don't support the outcomes. And that's the point: if we are trying to achieve a result, why are we building features that don't help what we need to succeed? Sometimes a discussion occurs that attempts to justify an orphan feature. I've even heard an exec describe their feature as an intangible benefit. That was a fun conversation. If a feature doesn't connect to an Impact and, most importantly, a Goal, the team needs to kill that feature, with fire even if it's the HiPPO's (highest paid person's opinion) pet feature.

What is Outcome Mapping?

If you're struggling to get leadership to buy into connecting features to outcomes, Jeff Gothelf has a twist on Impact Mapping that he calls Impact to Outcome Mapping. It works excellent with HiPPOs and begins by having leadership list their strategic goals, so the exercise focusses immediately on outcomes. I also love that it requires everyone to think about metrics that show if you're succeeding. I'm big on everyone understanding the game they're playing and how we keep score.

How do you create an Impact to Outcome Map?

Outcome Maps document Goals, Success Metrics, and Customer Behaviours and look like an org chart.

  1. Start by asking the HiPPO to write their most important strategic goal for the year at the top of a whiteboard.
  2. Then ask the same person to list their success metrics for each goal.
  3. For each metric, have the team brainstorm the customer behaviors that drive those metrics and place them below their respective metrics.
  4. What results, as this example below from Jeff Gothelf shows, is a map that illustrates the many ways a single outcome can be affected. Now have the execs use dot voting to identify the top Outcomes the product teams should focus on first. Gothelf recommends that you limit the number of Outcomes to the number of your product teams.


Example Impact To Outcome Map from Jeff Gothelf

What are Opportunity Solution Trees?

Tying Customer Discovery to outcomes is equally challenging. Generative research such as Interviewing customers and observing their behaviors can leave teams with too many opportunities competing for attention. That's why it's generative! Teresa Torres has been working in this space and has developed a technique she calls "Continuous Discovery" and, you guessed it, she uses mapping to tie discovery work to outcomes. Her "Opportunity Solution Trees" document the strategic Outcome you're trying to reach with customer problems, framed as Opportunities tied to an Outcome, similar to Impact Mapping or Outcome Mapping above. Then the team brainstorms potential solutions under each Opportunity and documents the Experiments that will validate or invalidate the solution. Not only does this make your work and decisions more intentional, but it also serves as an easy to consume communication tool for the rest of your company.

How do you make an Opportunity Solution Tree?

Much of the generative research we do as product people are black-boxed to the rest of the organization. Teresa's Opportunity Solution Trees are a visual way of representing what you are learning and your making decisions.

  1. Like Impact Mapping, developing an Opportunity Solution Tree starts with a single Desired Outcome, and once again, it's a strategic goal.
  2. Using your customer research outputs, place the challenges your customers face under the Output. These are the Opportunites that warrant exploration. As the name suggests, there is a tree structure that forms. Opportunities may be refined and grouped under top-level Opportunities as you learn more through generative research activities.
  3. Then the team brainstorms as many Solutions to the Opportunity as possible. It's recommended that you brainstorm for a single Opportunity going deep instead of spreading a collection of Solutions thinly across a broad set of Opportunities.
  4. Once you have your Solutions organized in the tree, you determine the experiments you want to do to validate and evaluate the most promising Solutions.

Opportunity Solution Trees are a living document that gives visibility to your discovery work and helps people immediately understand the intent of the solution, and how it is connected to your Desired Outcome. This is a deceptively, robust framework for shaping the product team's discovery work and communicating with the rest of the organization.

An example Opportunity Solution tree showing a top level Desired Outcome with linked Opportunities, then Solutions and their respective Experiments

Opportunity Solution Tree from Teresa Torres

Maps: Better Communication and Intentional Decision Making

Articulating and mapping multiple ways an outcome can be achieved is precisely the point of these exercises. Mapping our work also chronicles our decision making and encourages an intentional approach to making products. As humans, we're prone to solutioning, and we don't always take the time to explore options, especially when we've already fallen in love with our solution or been handed one to love by a HiPPO. I hope these proven techniques help you shift the focus from outputs to outcomes.

Learn More

Quick Reads:

Impact Mapping by Gojiko Adzic

Outcome Mapping by Jeff Gothelf

Opportunity Mapping by Teresa Torres


Impact Mapping by Gojiko Adzic

Mapping Experiences by Jim Kalbach

Outcomes over Outputs by Joshua Seidan


Teresa Torres' talk at Mind The Product "Show Your Work."

Gojiko Adzic's keynote from Italian Agile Days "Impact Mapping"