3 analysis techniques for mastering the 'Why?'

As business analysts or product managers, we’ve got one primary responsibility - to understand the 'Why?' behind a solution. And while it might sound somewhat philosophical, the ability to find out ‘Why?’ can be taught. There are very concrete and logical methodologies out there that, once mastered, elevate the business and process analysis to completely new heights. And mastering all of them can make you indispensable, the lynchpin in your organization's success.

Here are my 3 favourite and recommended techniques to master the ‘Why?’

• The 5 whys
• Problem-Solution Mapping
• Universal Process Notation

In this blog I will explain each method and highlight use-cases for their application. Let’s begin.

The 5 whys

The 5 whys technique originates from Toytoa’s lean manufacturing method and is a way of discovering the root cause of the problem by asking ‘Why?’ 5 times.  

"The basis of Toyota’s scientific approach is to ask why five times whenever we find a problem … By repeating why five times, the nature of the problem as well as its solution becomes clear."

Taiichi Ohno

The rationale behind the 5 whys is this: the root of the problem usually causes issues and pains down the stream, often many steps later in the process. If you focus on addressing the immediate symptom you might stop the bleeding, but not cure the underlying sickness. As a result, the same issue will reoccur again. 

Let’s demonstrate it with an example:

If we only attempted to address the symptom (machine broke) then we would have settled for simply replacing it or fixing it. And the issue would eventually come up again. By doing the 5 whys we discover a lot of problems and the root problem, all of which need to be addressed. Yes despite the name, you don’t really have to ask ‘Why?’ only 5 times. I prefer to think that you should ask ‘Why?’ as many times as it takes to discover the root issue. Ask ‘Why?’  until there is no‘Why?’ left! Although admittedly, it is rarely ever more than 5.

The beauty of this technique is that it is extremely simple with a wide range of applications. Let’s review a few examples:

• Bug fixing: let's imagine an automation (e.g. Salesforce flow) failed and threw and error. The first reaction might be to add a fault-handling mechanism to ensure issues are processed correctly. But a deeper investigation might reveal that users are consistently failing to provide all the required data on the record because of the lack of proper validations OR confusing user experience (or both!)
• Feature request discovery: 99.999% of all requests made by either stakeholders or customers come in the form of a feature request. Nobody ever says 'I've got this problem'. And most of those people usually have incomplete (to put it generously) knowledge of the systems. Asking the 5x 'Why?'  will help us understand the actual need and come up with the best solution to address it.

The 5 whys is such a fundamental concept in business analysis (and is so easy to do) that I would argue any business analyst or product manager that is not familiar with it and does not use it in their practice is negligent in their duties.

Problem-Solution mapping

Problem-solution mapping is a far more advanced and superior variation of the 5 whys. In recent years, thanks to advocacy of Teressa Torres, under the name of Opportunity Solution Trees, this technique became the must-have in every product managers’ toolkit. In business analyst circles it is still widely unknown, can seem intimidating at first, but once learned transforms one’s analytical capabilities.

In traditional 5 whys technique we have a linear discovery path:

In problem-solution mapping we start from the 1st symptom and also ask ‘Why?’ to discover the reason for the issue. But then, rather than asking for the ‘Why?’ behind the‘Why?’, we ask‘Why else?’. The rationale is that often there isn’t just one primary issue causing the problem. There are multiple different, separate issues. By asking ‘Why else [is the problem occurring]?' we force ourselves to expand our horizon and not focus on the first thing that comes to mind.

Once we feel there are no more ‘Why else?’ questions to ask, we then take the 1st root issue we identified and repeat the exercise.

We repeat the process until we have exhausted all questions and cannot come up with anything else. This then becomes our ‘problem tree’. Unlike with the 5 whys, we end up with much expanded understanding of the problem space. The biggest value of this technique, I found, is that it eliminates the false notion that solving a problem solves the problem. What I mean by that is if the problem we want to fix has 5 roots, then solving one of the roots helps, but does not completely alleviate the issue.

The ‘solutioning’ starts when we finalized the problem tree. And we being by identifying the root problems, at the bottom of the problem tree, as addressing those will ultimately address the problems above. And we begin, traditionally, by asking ‘How could we solve it? This is easy. We usually have no trouble coming up with an idea for a solution or a feature. And if we have done our problem-analysis well, we have gone so many levels down the problem hierarchy the problems we deal with a pretty granular and therefore easy to solution against.

However, the challenge of the technique is that it then requires you to ask ‘How else could you solve it? And you are supposed to ask this question as many times as you can come up with completely distinct solutions.

The rationale for doing this is simple. You can only pick the best idea if you have something to compare it against. It is actually fairly common sense: is AMR23 (Aston Martin) formula 1 car fast? Sure seems so on its own. But compare it to Red Bull's car - and it turns out it does not compete. It is the same story with our ideas. The first idea we come up with is usually our ‘brain child’ and we tend to be quite attached to it. By forcing ourselves to come up with separate solutions we can properly judge and pick the best idea.

Photo by Brian McCall on Unsplash

I am a big fan of problem-solution trees. They are irreplaceable when dealing with several types of problems:

• New jobs to be done: They are irreplaceable when dealing with completely new problems we have never dealt with before. This is extremely common for product managers who try to build commercial products or for business analysts and architects who are tasked with a strategic initiative. Problem-solution mapping allows to understand the entire problem space and pick and prioritize which problems (and which solutions) need to be built.
• Brainstorming: Sometimes, before I engage in stakeholder or customer discovery interviews, when dealing with a new and unfamiliar problem, I like to do problem-solution mapping as a form of documenting assumptions and hypotheses.

 However, problem-solution mapping can be time consuming. So I tend to use it for 'big' projects. 

Below is an example of my own problem-solution tree (and I have even bigger ones!) I made for trying to understand why Salesforce admins have issues with making sure correct users have access to the right information:

If you would like to learn more about this technique and its applications, I would recommend you buy and read the book Continuous Discovery Habits by TeresaTorres.

Universal Process Notation

Universal Process Notation is a standardized diagramming methodology officially endorsed by Salesforce for business analysis. The notation has 3 unique features:

• It is the simplest diagramming notation that utilizes only one shape
• It is a hierarchical notation
• It emphasizes capture of verifiable outputs of each step (the 'Why?')

The entire UPN notation can be summarized in the following image:

There is a lot of value and nuance to good use of UPN which I won't cover in this article. But you can read my deep-dive breakdown of UPN here. I do want to focus on how UPN is designed to help us understand the 'Why?' in business processes. Whereas the 5 whys and problem-solution mapping are designed to help us uncover the root causes for the problems we want to solve, the 'Why?' UPN is designed to answer is one of business outcome. 

Every activity/step in the process must have a verifiable, distinct business outcome. Let's break it down:

• Verifiable: Outcome cannot be vague or one that we cannot verify was actually accomplished. For instance, the customer cannot be merely 'informed', we need to capture what information will be sent to the customer and where that communication will be documented to signal successful completion, for instance : "Customer sent the Quote; Email logged in Salesforce against account".
• Distinct: A distinct outcome is one that is different from the activity itself. Why do we cook meals? To cook meals? Or to have a delicious meal? Or maybe to have a healthy meal? Cooking for cooking sake tells us nothing, while understanding the outcome we wish to accomplish tells us why we engage in the activity in the first place (and indeed if it is worth doing the activity at all!)
• Business outcome: In Lean methodology we define waste as any activity in the business processes that consume resources (like people's time, money, equipment etc.) but bring no value whatsoever (or rather don't bring value to the customer). If we cannot justify why we perform a certain activity through business outcome it helps us to accomplish, then we have found waste in our business.

Let's take a look at an example high-level sales process. Notice how outcomes (circled in red) are all verifiable, distinct from the activities themselves, and all point to a business outcome we want to accomplish by engaging in those activities: 

Universal Process Notation is an extremely powerful and versatile diagramming technique with many applications:

• Business processes: UPN is the best notation for capturing and analyzing internal company ways of operating.
• Job to be done diagrams: UPN can be used to capture job to be dones and how they get executed.
• User journey diagrams: UPN can be used to design the desired user journey through the product / application.
• Automation flow diagrams: UPN can be used to design and document the desired automation logic. 

In each of the listed use-cases UPN's emphasis on capturing the 'Why?' of every step would allow us to find suboptimal and wasteful activities. 

What's next?

While I could teach you more about problem-solution mapping, the reality is this is the brain child of Teresa Torres from whom I learned this technique, so if you would like to learn more about it, please visit her site and her courses.

However, I am one of the experts in Universal Process Notation, having mapped thousands of business process diagrams myself over the last 6 years. If you would like to learn more, I would like to recommend my masterclass in Total Story Visualization.