Design Thinking in Action: Problem Tree Analysis for Clarity

When the causes and the effects of a particular situation or problem are getting jumbled in our minds, it can be helpful to get the jumbled stuff out of our minds and down on paper. One method of assessing the causes and effects of a problem or situation is to execute a Problem Tree Analysis. This exercise, credited to Paulo Freire’s work in education in the early 1970s (Freire Institute, 2022), uses the visual of a tree as a metaphor, as previously outlined in Hour 3.

How do we start? Draw a simple tree like the one illustrated in Figure 9.1. We will use this simple visual to help us see a relationship between our problem (as we understand it today) and the problem’s causes and effects. To run a Problem Tree Analysis solo or with a group:

TIME AND PEOPLE: A Problem Tree Analysis exercise requires 1–5 people for 30–60 minutes per problem (and can extend much broader and longer depending on the nature and complexity of the problem).

• Draw a simple tree on a whiteboard like the one illustrated in Figure 9.1.

  

• Label the tree trunk with the overall problem or situation we are seeking to understand and define.

• Label 5 to 10 of the tree’s roots with the systemic or other “root” causes of the problem as we understand that problem today (and consider how the Five Whys covered later in this hour can help us further explore these roots now or shortly after this exercise concludes).

• Label the 5 to 10 branches shooting off the tree trunk. Each branch is a unique realized or possible effect or consequence of the problem being analyzed.

Round-robin through a team to focus first on causes (roots) and then later on effects (branches), giving everyone the chance to participate and draw on the tree. After adding a root or a branch, focus back again on the tree trunk to recenter the team on the problem.

Don’t be afraid to re-create the tree based on a new understanding of the problem. Similarly, don’t be afraid to add branches to other branches, or smaller roots connected to larger roots. The value of this exercise lies in the visual nature of the outcome, the tree. Working through a Problem Tree Analysis is like creating a situation-specific Mind Map or cause-and-effect diagram useful for exploring what has happened, why it might be happening, and what might happen next.

But if we are having problems fundamentally understanding a problem (or agreeing on and prioritizing that problem), turn to a Problem Framing exercise, described next.

Design Thinking in Action: Problem Framing

When a simple visual approach like Problem Tree Analysis fails to bring together a team in agreement on a problem or its prioritization among many problems, consider another exercise called Problem Framing. Derived from the research that Getzels and Csikszentmihalyi performed in 1976 on the need to understand problems as a precursor to creativity, Problem Framing helps us understand and prioritize a particular problem over a set of other potential problems. And it gives us much-needed context.

The value of a Problem Framing exercise is its ability to

• Force a discussion.

• Arrive at a shared understanding.

• Drive unity and buy-in around that shared understanding.

• Connect the past and present context with future goals or hopeful outcomes.

• Explore if the problem is indeed the right problem to tackle.

• Determine if the problem is even worth tackling.

• Validate that the team has the right skills or abilities to actually tackle the problem.

• Create clarity around a potential set of next steps.

• Define the problem as it is understood today and create a draft problem statement.

The steps of a Problem Framing exercise help frame a problem, hence the name. And through the outcomes outlined here, Problem Framing helps establish the “next best steps” in a team-oriented kind of way. The exercise therefore brings people together in important ways at exactly the time they probably need to be brought together.

To run a lightweight Problem Framing exercise with a group, follow these steps:

TIME AND PEOPLE: A Problem Framing exercise requires 2–5 people for 30–60 minutes per problem (and can extend much broader and longer depending on the nature and complexity of the problem).

1. Review the proposed problem. Give everyone the opportunity to weigh in with what they know about the problem, including background and assumptions.

2. Link the problem to its source. Identify other connected or related problems and discuss their relationships to this problem.

3. Consider the ideal outcome. Identify what the team wishes to see happen and discuss the broader future in question or broader goals at play.

4. Consider the users, stakeholders, and other people surrounding the problem and situation. Revisit what is known about the broader environment, the people involved, and how they’re involved. Turn to Stakeholder and Empathy Maps, Journey Maps, “Day in the Life of” findings, and so forth to put people (back) at the center of this problem.

5. Ask and agree if the problem as identified is truly worth thinking about and solving. Through consensus, the team needs to decide whether this is the right problem to tackle, whether this is the right time to tackle it, and whether the problem is even worth trying to tackle.

6. Agree whether to proceed or stop. With the problem now framed and better understood in several different ways, and the team aligned, it should be possible to make a next-step decision.

As a result of this exercise, a team can better identify and subsequently tackle the problem, if indeed that’s the next step. Problem Framing makes it clearer if an expert needs to be brought in next too, or if other problems need to be solved first. Problem Framing importantly gives us the ability to create a definitive problem statement too, covered next and used across Hours 10 through 14 as we ideate and explore problems to find potential solutions.

Design Thinking in Action: Problem Stating

One of the outcomes of Problem Framing is the ability to create a draft problem statement. With a reasonably good understanding and framing of the potential problem and how it differs from its causes or effects or other aspects of an ambiguous environment, we can now identify the likely problem. And this is a really big win.

Sure, our understanding of the problem will mature as we work through additional problem-related exercises (and later, thinking and solutioning-related exercises). But being able to turn a potential problem around and over a bit to help ensure it’s indeed the right problem is critical to creating our problem statement. Why is this important? Our problem statement provides a crisp shared understanding, which in turn helps rally others around what’s needed to solve that problem.

Attributes of a good problem statement include

• It is formed as a statement and a single sentence.

• This single sentence addresses the “what,” “for whom,” and the “need.”

• It is written in simple, crisp, and understandable terms.

• It therefore precisely informs our understanding of the problem (knowing that our understanding will be clarified further through this and other exercises shared this hour).

• It sets the stage and serves as input for “How Might We?” questioning and other ideation and solutioning techniques we will turn to later.

To run a simple Problem Stating exercise with a group, follow these steps:

TIME AND PEOPLE: A Problem Stating exercise requires 2–5 people for 15–30 minutes per problem (and can extend much broader and longer depending on the nature and complexity of the problem).

1. Share the outcomes of previous problem identification exercises including Problem Tree visuals and draft problem statements coming out of Problem Framing exercises.

2. Ask the team to answer these questions:

   • What is the primary problem?

   • Why is this a problem?

   • Who has this problem?

   • When does this problem occur?

   • What seems to be missing or needed?

   • How is this problem worked around or addressed today, if at all?

3. As a team, review the answers and vote on which ones (the “top answers”) are most true or valid given what the team has previously learned and is seeing now.

4. Copy or rewrite the draft problem statements that best define the gap between the current state of affairs and the desired outcome, constructing a single sentence in the form “<the what> for <the who> does(do) not satisfy <the need>.”

Thus, a good and simple problem statement might look like these examples:

• The portal interface for our users with visual impairment does not satisfy their need to enter sales orders.

• Our team communications methods for our remote employees do not satisfy their need to be heard and represented.

• Our end-to-end warehouse management system for users working from home does not satisfy their real-time performance expectations.

To directionally validate a problem statement, we might flip it into a “How Might We?” question. Begin combining these top answers to construct a mirror to the problem statement in the form “How might we change <the what> for <the who> to better satisfy <the need>.”

After we’ve worked through the details together, a “How Might We?” mirror response to a good problem statement might look like these examples:

• How might we change the portal interface for our users with visual impairment to better satisfy their ability to enter sales orders?

• How might we change our team communications for our remote employees to better satisfy their need to be heard and represented?

• How might we change our end-to-end warehouse management system for our home-based users to better satisfy their real-time performance needs?

And with our problem statement in hand, if needed we can turn to one or more problem validation methods before we earnestly start thinking, problem solving, and solutioning. Four of these techniques or exercises are covered next.

Design Thinking in Action: Verbatim Mapping

Useful in many different ways, a smart first step for validating the problems underpinning a situation is to listen to people and document what they say. Called Verbatim Mapping, this technique is a staple of interviewing and represents a great way to listen while we compile a set of beliefs or statements useful for later providing context.

Verbatims, like the word implies, are the word-for-word direct quotes, stories, and other feedback spoken by a person that describes or documents that person’s perspectives. When we think of verbatims, we usually think about negative feedback, challenges, or pain points. But verbatims include good news, insights, and positive feedback too. Buried in these verbatims are the underlying themes that might explain why, when, where, how, and with whom we have a problem.

Pull verbatims out of meetings, stories, and what you hear through Supervillain Monologuing and Silence by Design listening sessions. And if you have access to history (old stories or meeting notes, for example), use previously documented verbatims to help understand how a problem or situation has evolved over time.

With all of this information, run a Verbatim Mapping exercise by following these steps:

TIME AND PEOPLE: A Verbatim Mapping exercise requires 1–3 people for 15–30 minutes per person or meeting being assessed (and can extend longer depending on the availability of source documents).

1. For privacy reasons, ensure that the person or team is informed beforehand that we are conducting such an exercise.

2. Pay attention to the repeated words/phrases you hear and see and document these verbatim (word for word).

3. If the event is real time (versus researching past events using meeting notes and meeting minutes), consider clustering trends or themes as the exercise progresses.

4. After the meeting or event concludes, group the repeated words and phrases into logical groups or themes (using Affinity Clustering, for example, covered briefly in Hour 3 and in more detail in Hour 13).

5. Create a personal hypothesis explaining what we think explains each cluster.

6. Identify a set of “next best steps” and specifically call out what needs to be further explored, what needs to be learned or further understood, and where we have enough information to begin taking preliminary or remediating actions.

7. Plug these verbatim clusters into our Stakeholder+ Maps and Empathy Maps as speech bubbles, mapping each verbatim cluster to the appropriate people or teams as a way to enrich our existing maps.

In the end, as we see in Figure 9.2, verbatims help us learn something new and perhaps even corroborate our understanding of a situation and its underlying problems. And verbatims give us a rich and more complete picture of our users and other stakeholders, helping us learn more about the people as well as the problem or situation at hand.

Design Thinking in Action: AEIOU Questioning for Rapid Review

Sometimes a simple set of questions can help ensure we are thinking about the right things or focusing on the relevant dimensions of a problem. Created by Rick E. Robinson (2015), use the AEIOU Questioning exercise to rapidly review a situation and mentally tick off a set of key dimensions as we validate a problem, question and interview others, run a meeting, perform DILO exercises, execute Journey Mapping, conduct an Empathy Mapping exercise, engage with users in Empathy Immersion, and more.

AEIOU stands for Activities, Environment, Interaction, Objects, and Users. The simple AEIOU acronym and five-step exercise can be injected into other exercises to quickly structure a situation or validate a problem. And because it’s a mnemonic, AEIOU is easy to remember and therefore easy to follow.

If we are exploring and validating a problem around effectively prioritizing a backlog, for example, we might run an exercise where we think about and explore this backlog prioritization problem in terms of the following:

TIME AND PEOPLE: An AEIOU Questioning exercise requires 2–5 people for 5–15 minutes per problem.

1. Set the Stage. Share the problem statement or issue.

2. Activities. Are we doing the right things and executing the proper Agile ceremonies (or other methodology-specific tasks) at the right time?

3. Environment. Do we have the right forum or space for effectively doing this work of backlog prioritization?

4. Interaction. Do we understand the steps necessary to prioritize the backlog? Are we executing them properly and in the right sequence?

5. Objects. Do we have the right tools for collaborating in-person or remotely? Do we have an effective DevOps tool for documentation, transparency, and accountability? Are we using the right tool and processes to map epics to features to user stories?

6. Users. Do we have the right people involved? Do we understand the personas at stake? Are we engaging early enough or at the right time? Who are we missing? Who is being inadvertently or otherwise marginalized?

7. Warnings or Patterns. Do we need to return to a particular area and further explore it?

The AEIOU Questioning process is circular, as we see in Figure 9.3. The idea is to validate our understanding of the problem and identify those areas or themes that might need further exploration and iteration. Iterating might explain what we’re missing or inadvertently ignoring.

Design Thinking in Action: The Five Whys for Root Cause Analysis

Highlighted briefly in Hour 3 and developed years ago by Sakichi Toyoda, the Five Whys are used for discovering the root cause or reason behind a particular situation, line of thinking, decision, and problems in general. This technique helps us understand a person’s or team’s motivations, values, and biases as well.

The technique is deceptively simple, but it’s usually organized around an exercise rather than the simple technique of asking “why” again and again, five times. The key is to pivot the questioning based on the previous response, going beyond the obvious to explore the hidden.

The Five Whys is akin to following a rabbit trail to discover what lies around the corner or beneath what’s visible. In the end, you should arrive at the root cause. No, addressing the root cause will not always solve the problem in and of itself, but understanding the root cause is a good start toward better understanding the problem itself. As we saw in the Problem Tree Analysis exercise, simply separating the causes from the effects provides clarity and therefore great value. This exercise should help us better define the true problem statement while thinking in new ways.

TIME AND PEOPLE: A Five Whys exercise requires 2–5 people for 5–15 minutes per problem (and can extend much broader and longer depending on the nature and complexity of the problem).

To run a Five Whys exercise:

1. Share the problem statement.

2. Ask “Why?” five times, taking care to evaluate the previous answer before asking more about it. Consider the following example:

   1. Why did we miss our deployment date? (“Because we completed development and testing late.”)

   2. Why did we complete development and testing late? (“Because the business process was more complex than we estimated.”)

   3. Why was the business process more complex than we estimated? (“Because our DevOps T-shirt estimation technique maxes out at Extra Large, or XL, and this particular business process was actually Extra Extra Large, or XXL.”)

   4. Why did we characterize this business process inaccurately in our DevOps system as XL rather than XXL? (“Because our DevOps estimation system does not accommodate anything beyond XL—we can enter in only four sizes, and XXL is not one of those sizes.”)

   5. Why is our DevOps estimation system limited to only four sizes? (“Because the current DevOps template is hard-coded for four sizes.”)

In the example here, as illustrated in Figure 9.4, the root cause started becoming evident at the third Why, but we might never have known of the DevOps template limitation had we not finally gotten to the fifth—and clearly very important—Why.

The Five Whys is by no means foolproof, though. This exercise takes us down a pretty narrow path and doesn’t really give us the latitude to explore other problems that might surround the one we’re seeking to validate. Thus, it’s up to the questioner to discern that proper path (or run a series of Five Whys exercises to explore multiple paths).

Also, this exercise itself can stir up other issues along the way. For example, the process of asking why, why, and why again and again can put people on the defensive, leading to people shutting down or seeking a target to blame. Alternatively, try the Probing for Understanding or Supervillain Monologuing techniques to help us drive out more clarity and validate a problem. And consider a final exercise for problem validation, Pattern Matching, covered next.

Design Thinking in Action: Pattern Matching for Themes

Looking for recurring patterns to learn something new is an age-old technique used in every part of life. For our purposes here, though, Pattern Matching can help us uncover repeating themes or threads of meaning that validate our problem or tell us something about how we are thinking or executing. For the purpose of validating a particular problem statement, consider these questions:

• Does the way we tend to see something contribute to how we react, which in turn leads to the same problems over and over? Do we have a perspective problem getting in the way of understanding the real problem at hand?

• Does our problem reflect a singular pattern (our deployment cycles are always late for one reason or another) or a stepwise pattern (our use cases are more complex than we expected, leading to longer development times, longer test cycles, and therefore late deployment cycles)?

TIME and PEOPLE: A Pattern Matching exercise requires 1–5 people for 15–60 minutes per problem (and can extend much broader and longer depending on the nature and complexity of the problem).

To execute a simple Pattern Matching exercise:

1. Remember that pattern matching is difficult without good data. Gather together the data from which the patterns and themes will be derived. Data can come from documented issues, previously completed interviews and Verbatim Mapping exercises, observations, listening exercises, risk reviews, meeting notes, and so on.

2. Group like items together. Start with big groupings (such as positives and negatives, or input and outputs, or symptoms and outcomes, or causes and effects—whatever makes sense).

3. Further sort these groups by themes. If you don’t see obvious patterns related to actions or consequences, start by looking for the nouns (time, deadlines, work, confidence, self-esteem, turnover, retention, meetings, communications, names, education, image, day, night, money, schedule, bills, security, escalations, activities, and so on) or verbs (stressed, depressed, hate, rushed, drive, think, spent, talked, and so on), and go from there.

4. Now we should start seeing patterns and themes emerge. Label each group by its theme.

5. Identify the outcomes associated with each group (positive, negative, uncertainty, budget overruns, high quality, schedule implications, team attitude, group performance, poor focus, unhealthy peer pressure, healthy competition, high stress, and so on).

6. Work as a team to further consolidate and refine these outcomes. You might wish to prioritize these as well, creating a top-five list of patterns and themes, for example.

For each theme or pattern, be sure to include separate data points that reflect positive sentiment as well as negative sentiment (such as good quality and poor quality or coming in ahead of schedule and delivering behind schedule). It’s through these polar extremes that we might identify patterns that provide special insight or help us drill down further into specific groupings.

Case Study

Consider the following case study and questions. You can find the answers to the questions related to this case study in Appendix A, “Case Study Quiz Answers.”

Quiz

1. What are two different Design Thinking exercises known to be useful in creating problem statements?

2. How does a Problem Tree Analysis provide clarity?

3. What are four different Design Thinking techniques or exercises useful in validating a particular problem?

4. How is the Executive Committee misunderstanding the power of Design Thinking for starting and learning fast?