Authors Note: All frameworks have moved to a new home at Strategy Umwelt. Please join me at this new platform for a revised list of mental models, strategy frameworks and principles.

Getting to the root cause of something can be difficult, but it is a necessary requirement when developing strategy or addressing problems. Unless you narrow down to first principles, you have the potential to introduce risk or irrelevancy.

A deceptively simple strategy to combat this is the Five Whys technique, originally created out of the Lean Startup Methodology by Eric Ries. In this essay I will outline two use cases for this technique, firstly, as a way to run root-cause analysis of problems as they arise (as a defense strategy) and, secondly, to find the emotional insight at the center of products or campaigns (as an offensive strategy).

Root-Cause Analysis

The methodology behind Five Whys is simple - ask a ‘Why?’ question five times in a row. By the time you answer the fifth question, you should be very close to the deeper insight behind the problem at hand.

Ries uses the following as an example in relation to a technology product.

A new version is released, which caused a key feature to be disabled and in turn a ton of customer complaints. Five Whys are then answered in the following order:

A new release disabled a feature for customers. Why? Because a particular server failed.
Why did the server fail? Because an obscure subsystem was used in the wrong way.
Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
Why didn’t he know? Because he was never trained.
Why wasn’t he trained? Because his manager doesn’t believe in training new engineers because he and his team are “too busy”.

What was initially believed to be a pure technical fault is actually revealed to be a very human management issue, which as a root cause may have been masked from the outset.

Proportional Investments

In startups or newer agile focused organizations, the goal is to move the business through the build, measure, learn feedback loop as fast as possible to drive validated learning.

A paradox exists here however - while we strive to get an MVP in the hands of customers as fast as possible, shortcuts taken in product quality, design or infrastructure today may wind up impacting on learning in the future. If we have bugs, missing features or poor design, we may not be getting honest feedback.

Ensuring that these missteps don’t appear requires both discipline and process & procedures, but agile organizations either won’t have time to have defined these due to speed to market requirements, or will try and keep these as loose as possible to automatically adjust over time.

The analogy here is an engine. We put the pedal to the floor and speed up, but as we go faster and faster discipline slips. Problems start to appear which compound upon each other, and we rapidly come to a grinding halt.

A solution to this is to use Proportional Investments to build process and procedures as we drive the engine forward that don’t allow for costly over-investment or over-engineering. The Five Whys root-cause analysis can be a cornerstone of this strategy.

From the example above, there are several tiers of response as we go deeper - fix the server, change the subsystem to make it less error-prone, educate the engineer, and have a conversation with the manager about lack of training. On paper it looks like going straight to the root cause ‘conversation with the manager’ is the most obvious fix - however stopping everything to develop a training program could eat up time and money that just aren't there.

Using a Proportional Investment mindset, the right fix is actually closer to just fixing the server or similar as this will be the fastest response. Everyone is now aware of the deeper problems, so hopefully they slowly compound this into more disciplined processes and procedures organically - as future root-cause meetings occur it will become obvious if the deeper issues are making headway in being addressed, or if they are systemic and need deeper action.

Focusing on this strategy will hopefully then become what Ries calls a speed regulator to our engine metaphor. You start running too fast, disciple slips, and problems occur. Things slow down, but continued root-cause meetings force the team to automatically invest in some protection (albeit the lowest possible). As more problems arise, more prevention occurs and pays off, eventually reducing the rate of crisis and pushing the pedal down again.

Avoiding the Five Blames

The precursor to the Lean Startup Methodology was the Toyota Lean Production System that revolutionized manufacturing. One of the central items in their process was the Andon Cord, a pull cord that empowered any employee to yank down and immediately shut down production rather than wait for management’s permission if they spotted a defect (stoppages could cost over $10,000 a minute).

Previous to this, production rarely stopped, meaning that defective pieces would roll off the assembly line even if noticed, and then separate teams would need to backtrack to dismantle and fix these problems. Solving root problems early drove a significant competitive advantage.

It would make sense then that other manufacturers should have been able to install their own Andon Cords to achieve the same results. Sadly, this turned out to be far from the truth.

Toyota helped develop a joint factory with GM called NUMMI, featuring a similar Andon Cord system. However, costly defects continued to roll out, managers were found to be yelling at any workers who pulled it, and worst of all some workers started intentionally sabotaging the process by pulling the cord.

Why did it work for Toyota and not for others? The answer lies in Toyota’s focus on mutual respect and empowerment, codified in their key tenet of “Respect the People”. The underlying culture in the organization granted their workers the obligation to stop defects, wherever they saw them.

Much like this example, if the Five Whys isn’t approached with the same focus on mutual respect and empowerment, it can quickly escalate into the Five Blames. Instead of attempting to understand root causes, it becomes a means to vent frustrations or finger point at other staff.

The Five Whys is a systems thinking approach, so it needs to have the mindset that we are searching for bad processes, not bad people. Problems arise due to flaws in the system itself.

Ries outlines a couple of points to keep in mind to help run more effective Five Whys sessions:

Ensure everyone affected by the problem is in the same room, no matter how large the group. Whoever is left out will invariably become a scapegoat or target for blame.
Repeat the mantra of “shame on us for making it so easy to make that mistake”. It will help with the blame game by grounding the fact that if a process is fragile enough to be broken, it is a system wide problem. We are all responsible for letting it be this easy.
Be prepared for the process to turn up unpleasant facts about the organization, especially in the beginning. There will be hard truths, so lets focus on meeting them.
Start out small at first until the sessions are normalized. Tackling too big a problem until everyone is comfortable may cloud the process.
Consider having a neutral party act as Five Whys Master to administer the proceedings, and ensure the meeting doesn’t fall off into tangents.

In an environment of mutual trust and empowerment, Five Whys should flourish and deliver exceptional results.

Emotional Insights

We have covered utilizing Five Whys as a defensive strategy, now its time to look at the other side of the coin: utilizing it as more of a proactive tool to generate insights.

In Nir Eyel’s book Hooked: How to Build Habit-Forming Products, one of the key insights is that the products that most often succeed are the ones that elegantly solve problems. We use products because they offer a solution to our issues.

Often these problems are described as ‘pain points’. Rather than being a tangible pain, more often than not these are better described as an itch. Humans naturally search for anything to scratch that itch to relieve the stresses and emotions of our daily lives.

When we are bored, we seek excitement in dramatic news headlines or click bait. When we are stressed out, we seek escape in visual “down the rabbit hole” sites like Pinterest or Tumblr. When we feel lonely, we turn to Facebook or Twitter for social connection. When we are uncertain about something, we turn to Google for answers. Lastly, email tries to fill the void on a huge number of daily agitations, from validating our importance by reaffirming if someone needs us, through to providing a general escape from the mundane.

Building great products and experiences, therefore, is about laying claim to a particular feeling or emotion by understanding the itch the user wants to scratch. Not a feature list, but the emotional “user story” at the heart of the problem.

As any good UX specialist or Strategist will tell you, we hit a snag when we ask people what they want. Often their ‘declared preferences’ are not in fact their ‘revealed preferences’, the deeper truths that may lay hidden.

Henry Ford is famously (and probably falsely) credited with saying that if he asked his customers what they wanted, they would have said a faster horse. Using the Five Whys, we can try and create a root-cause analysis of the deeper emotional insights behind the need for our products.

Let’s take an example from Hooked. Imagine we are building email for the first time. We are targeting a busy middle manager named Julie as our persona. We would ask the following, moving through the Five Whys template:

Why would Julie want to use email? So she can send and receive messages.
Why would she want to send and receive messages? Because she wants to share and receive information quickly.
Why does she want to share and receive information quickly? So she can know what’s going on in the lives of her co-workers, friends and family.
Why does she need to know what’s going on in the lives of friends and co-workers? So she can understand if someone needs her.
Why does she care if someone needs her? Because she fears being out of the loop.

From this analysis, Fear is the primary emotion we need to leverage in this product, more specifically FOMO, or the Fear of Missing Out. With this in mind, we can generate better triggers and hooks as we craft features and behaviors, and create better validation on our eventual MVP to see if it solves the deeper itch.

So what sort of emotions should we be leveraging? A good start are the twin sides of the following three examples:

Seeking pleasure or avoiding pain
Seeking hope or avoiding fear
Seeking social acceptance or avoiding social rejection

As we can see, the Five Whys is a deceptively simple technique to uncover root causes to issues, and has interesting applications in both solving problems or developing insights. Add it to your toolkit of mental models for the next time you need to do a root-cause analysis.