You have likely heard people on social media or in discussion at conferences talk about the importance of “digging into a problem” before jumping to a solution. It’s less likely that you’ve seen posts that explain exactly what is meant by this, why it’s valuable, or how to do it.
The notion of focusing on the problem first is one that comes from service design principles. The adage is expressed in a few ways. Proponents are urged to “fall in love with a problem, not the solution,” or to become comfortable with “sitting in the problem space.” These adages exist because it is a natural human tendency to focus on solving a problem rather than discussing the causes of the problem itself.
In the design thinking process, problem definition comes before ideation, or brainstorming, in the problem-solving process. It’s the second step in a five-stage process that starts with empathy (see below).
I have run many design thinking workshops with lawyers, law students, and legal business professionals. It’s remarkable how difficult people find it to focus on the problem instead of jumping to solve it. I often walk around the room during the define stage of the exercise, because it’s when people need support. I lean in to hear how groups are thinking about their problem and you wouldn’t believe the number of times I’ve had people say to me: “well, we’re developing an app that…”. Even with explicit instructions to explore the problem and define it, they move instinctively towards solutioning.
This happens in practice, too. I’ve worked with multiple teams whose remit included problem-solving for lawyers and legal teams. Before we had the headcount to bring on professionals who understood service design and would run the early stages of problem-solving, we frequently encountered issues with members of the team who had listened to the first complaint or report about a pain-point and launched into the development of a solution without asking any further questions. Inevitably, this led to difficulties down the track when they realized they had misunderstood the problem or hadn’t understood the nuances of it sufficiently to be able to provide a solution that worked.
Defining a problem starts with understanding the users who are affected by it (the empathy aspect of design thinking). Assumptions are often made in commercial legal environments that lawyers are all the same and experience a pain-point in the same way. Many of the people who have been hired to do the problem-solving are also former lawyers, so they believe they understand how the pain-point is being experienced, even though they practiced law at a different time and in a different context. This is one of the key reasons it’s important to have professionals on your team who come at problems from a variety of perspectives.
In fact, different people experience problems in different ways, which is why service designers develop “personas” that allow for understanding a problem from multiple viewpoints.
In order to ensure you or your team are not making assumptions, spend some time speaking with the people who have expressed the pain-point, or who are affected by the problem that has been reported. Give some thought ahead of time to the types of questions you will ask them that will show you where they’re coming from, how they feel about the problem, and exactly how they’re experiencing the issue.
It can feel awkward in a professional setting to ask about the feelings or emotional response and needs that people have in relation to a problem, but understanding these is critical.
Take, for example, a situation where a partner approaches your team to say that she needs a better way of tracking work. If you run off to solve this problem immediately, you might come back with a dashboard that gives the partner visibility of hours worked on her matters.
If you had paused to first understand what her needs were in relation to this problem, however, you may have found out that she was concerned some of the people on her team were burned out and she wanted to make sure she could distribute work to take into account people who had worked too many hours over the past weeks and reduce their workload for upcoming weeks. That need is not fulfilled by mere visibility of actual work performed. It requires a solution that demonstrates distribution of hours and the number of hours that each of her team is working overall (which may not be captured in a view of the partner’s matters alone). Had you built a dashboard without having the additional information, you would now be in a position of having to rebuild.
Asking questions like: “Why is this a problem for you?”, “What is your concern in relation to this problem?” or “Why are current reporting tools not working for you?” would have given rise to some of the details necessary for you to develop an appropriate solution.
The Five Whys Technique
There are specific techniques that have been developed to help teams dig into problems. One of these is the “Five Whys” technique, also known as the root cause analysis. Developed by Sakichi Toyoda, a Japanese inventor who founded Toyota, the original purpose of the Five Whys was to understand the root cause of a defect by iteratively asking “why” questions. In most circumstances, asking the question five times is sufficient to provide insight into the origins of the problem.
Applied to the scenario above, imagine again a partner came to you to say she needed a better way of tracking the work her team was doing. Instead of jumping to build a solution, imagine the following discussion had taken place:
You: “Why do you need a better way of tracking work?” (Why #1)
Partner: “Because the systems we have are not good enough.”
You: “Why aren’t they good enough?” (Why #2)
Partner: “Because they don’t show me enough information about my team.”
You: “Why do you need more information about your team” (Why #3)
Partner: “Because I need to understand the work they’re doing.”
You: “Why do you need to understand they work they’re doing?” (Why #4)
Partner: “Because I’m worried some of them are being overworked.”
You: “Why does this worry you?” (Why #5)
Partner: “Because I’m worried about their well-being and concerned they may leave the firm.”
In a real conversation, you may have interspersed some of these “whys” with some whats – such as “What type of information do you need about your team”. Notice, though, how the example reveals that it’s entirely plausible that the root cause of the problem will not be uncovered until you dig really deeply into it. Those Five Whys were necessary to get at the emotional need that the partner wants to resolve. Understanding that emotional need sets up you and your team for success as you go out to build a solution, because you’re armed with the right information.
The Five Whys is a good technique to practice with your team. Practicing in team meetings will get people more comfortable with the discomfort of staying with the problem even when people feel they should be moving towards a solution.
Fishbone Analysis Technique
For larger problems that affect multiple parts of an organization, the five whys technique might fall short because there are so many stakeholders. It is still a technique that can be used during stakeholder analysis and user discovery, but for larger projects that are trying to solve the root cause of a problem that affects the whole organization, the fishbone analysis technique allows for a more collaborative approach to problem definition.
Developed by another Japanese manufacturer, Kaoru Ishigawa, the fishbone diagram – also known as a cause-and-effect diagram – is a visualization tool that helps teams analyze the cause of a problem or defect within an organization. Fishbone analysis uses guided brainstorming in combination with the fishbone mindmap shown below.
The problem is written at the front end of the diagram (like the head of a fish), with a horizontal arrow crossing the line of the page to point at the head.
During a fishbone analysis session, stakeholders brainstorm the major causes of the problem, which are grouped thematically. Often major causes will involve things like the context or environment, the people, the process or method. These are drawn as the fishbones pointing to its backbone.
Stakeholders are then asked to dig deeper into each of these major themes to examine them more closely and identify all possible sub-causes related to these themes that are giving rise to the problem, which are listed along each fishbone and depicted as layered branches in the diagram.
Using the diagram allows for focused, guided brainstorming and discussion on each aspect of a larger problem, illustrating the many facets of it and allowing for solutions to be developed that are address the complexity of the problem.
Examples of problems for which you might use the fishbone technique include:
- Determining why a legal department is consistently late in delivering work to a part of the business,
- Understanding why a law firm’s business development plan is not working to bring new business to the firm from the right types of clients, or
- Uncovering the root causes of a broken process that has become a bottleneck.
While techniques like the Five Whys and Fishbone Analysis are useful, they are mere guidelines. Digging into a problem simply involves communicating more and better with relevant stakeholders to understand a problem from all sides before starting to solve it. Practicing by employing tried and tested techniques can help team members who have no prior exposure to service design become more comfortable sitting with a problem and exploring it before jumping to solve it. Doing so will ensure that you and your team operate better to solve problems together for your organization.