3.11.1 Exercise 1: Define Your Objective
Conventionally, in many companies product planning happens in a Waterfall fashion: the leader defines the vision and a 3–5 year product roadmap, and his or her leadership team translates that into each of their respective team’s goals. The problem with this approach is that it doesn’t take into account the inherent nonlinearity of product development, caused by the iterative nature of building, testing, and learning from users as well as changes in the market that might come from new regulations or the entry of a new competitor. Teams need a way to navigate these challenges without being constrained to any particular solution, but are provided enough guidance that they can remain focused on delivering their target user outcome. This can be accomplished with a well-defined Objective statement, which describes the outcome to be achieved but not how the team will achieve it (Gothelf and Seiden 2017) (Table 3.2).
3.11.2 Exercise 2: Identify Target Users
Imagine you were going to give a talk at a conference. When preparing, you might ask yourself, “Who is my audience?” Similarly, we need to understand our audience—our user when developing a product. In this workshop, we provide the following simplified user persona as part of our scenario:
Frail 85-year old after surgery
I just had surgery and am returning home. Because I’m frail, I might have worse health outcomes. My goal is to recover as quickly as possible and to return to my previous state of health.
Participants should reference this user persona for the remaining exercises.
3.11.3 Exercise 3: Define Users’ Needs
Participants are asked to brainstorm desired outcome statements for the target user persona defined above. For example, these statements might be:
Desired outcome statements
Minimize the time it takes to recover from my surgery
Minimize the likelihood I’m injured when exercising
Maximize the amount of fat I lose when exercising
In reality, a user might have 100–200 desired outcomes, but for the purpose of this workshop, participants are asked to generate as many as they can in 5 minutes. Facilitators are urged to read Ulwick’s book (Ulwick 2016) for more detail on this methodology.
3.11.4 Exercise 4. Prioritize Desired Outcomes
In Outcome Driven Innovation, user need statements are assembled into a survey, which is then fielded to hundreds of target users to provide more quantitative evidence to help teams understand which needs are most unmet. This is achieved by asking survey respondents to rank on a Likert scale their level of agreement with two key questions for each desired outcome:
When [doing the job or activity], how important is it for you to [achieve desired outcome]?
When [doing the job or activity], how satisfied are you with the way you currently [achieve desired outcome]?
When recovering from surgery, how important is it for you to recover quickly?
When recovering from surgery, how satisfied are you with how fast you’re currently able to recover from surgery?
By aggregating responses to these two questions, teams can visualize each desired outcome as a coordinate in a two-dimensional plot of Importance vs. Satisfaction. Those desired outcomes that rank very important but very dissatisfied reveal key opportunities for innovation (Fig. 3.4).
In lieu of conducting a large survey to collect quantitative data on users’ ratings of satisfaction and importance, we use a quicker, easier method during the workshop. First, facilitators ask teams to force rank the desired outcomes they brainstormed in order of estimated importance to the user, from high to low. The facilitator records the rank order of each outcome, then asks the team to re-order the outcomes by estimated user satisfaction, from low to high. By adding together these two rank orders, and using the importance rank to break any ties between two equal sums, teams can approximate a relative “Opportunity Score.” The desired outcome statements can now be placed on the Outcome Map in ascending order, where the smaller the Opportunity Score, the greater the users’ unmet need, and the higher on the map the outcome will be placed. If they haven’t already, facilitators ask the team to write the desired outcome statements on sticky notes and then place them on the left side of the Outcome Map in one vertical line.
At this stage, the participants have defined their user’s needs and estimated the opportunity for innovation for each need based on how important and dissatisfied the user is in achieving that need. Next, we take these results and brainstorm features that might meet our user’s needs.
3.11.5 Exercise 5: Brainstorm Features
What features will help our users meet their desired outcomes? Facilitators should remind participants to develop features that would help the user achieve their desired outcomes—not just the features they like. This section is broken down into three key exercises, adapted from the Design Sprint method developed at Google (Knapp et al. 2016), and described in more detail in the accompanying slide deck:
Brain dump: write down anything that comes to mind on a sheet of paper
Crazy 8’s: rapid low-fidelity sketches of eight concepts, or a user flow of 1–2 concepts
Solution Sketch: more detailed sketch of a single concept.
Once the Solution Sketches are complete, facilitators ask teams to place them on the Outcome Map next to the desired outcomes they help achieve. If a feature achieves more than one desired outcome, then move that outcome statement into the same row.
3.11.6 Exercise 6: Decide
Time permitting, facilitators can setup a “Gallery Walk”, where participants observe each other’s features, then “dot vote” on the best ones. In this way, teams can narrow down the number of potential features they’ll need to consider in the remainder of the workshop (and later, build during product development). This workshop does not detail this method, but readers are referred to Chapter 10 in the Sprint book (Knapp et al. 2016) for an explanation of this process. In this workshop, participants simply present their Solution Sketches to team members and vote on which one or two designs to move forward with.
At this stage, teams have defined their user’s needs and brainstormed potential solutions for the most significant unmet needs given their estimated Opportunity Scores. The result of this exercise is to build a shared understanding of other team members’ Solution Sketches, and to decide which one or two designs will become the focus for the remainder of the workshop. For instance, if a team of five produces five Solution Sketches, the team will vote to move forward with only one or two of the designs. In this way, teams can focus their efforts for the remainder of the workshop, where they exhaustively identify their assumptions, prioritize those assumptions by risk, and outline a research plan to test these assumptions.
3.11.7 Exercise 7: Identify Assumptions
As a group, have participants discuss the risks associated with delivering their chosen design(s). These risks might include:
Participants record assumptions on sticky notes and place them on the whiteboard, then force rank each assumption by risk. To rank by risk, ask: “How bad would it be if we got that assumption wrong?” For example, if your feature relies on access to user data, can you feasibly gain access to this data, and if so, how? How bad would it be if the technical approach you planned to use to access this data didn’t work? If access to user data is critical to the functioning of your application, then this is a high risk and should be prioritized towards the top of your list. If your team also planned on a particular revenue model, but have not yet tested it, then that presents another risk. However, in comparison to the technical risk of your product not functioning if your team is unable to access user data, then this revenue model risk would be prioritized lower. In this case, by addressing that particular technical risk first, at least your team would have a functioning product, and perhaps could find a new revenue model if the one originally planned did not work out.
3.11.8 Exercise 8: Define the Research Plan
There are a plethora of user, market, and product research methods available to the team to validate their assumptions. Participants are asked to write one experiment per sticky note to address each assumption on the whiteboard. While the details of these methods are out of the scope of this book and workshop, a number of methods are listed in the accompanying slide deck for this exercise (Moses 2018). For example, teams might need to better understand their users, and could decide to run an ethnographic study or diary study to learn more about how their target users work. If a team needs to learn more about their product offering, they might build technical prototypes to investigate technical feasibility, or design a clickable prototype of screens to test the usability of a new product workflow.