5 Why’s
Why? Find the root cause. Why?…
Start with Why
I was first turned onto this framework when I went through my Six Sigma certification course with Accenture. The reason I was drawn to it was the power of what happens after you get through the questions. To determine the root cause before using this approach I would normally use a brainstorm. The problem here is that I would often only get 1 or 2 layers deep. When I switched to 5 Why’s I was forced to go deep.
I find this approach helpful in a number of contexts including:
- Understanding customer needs for product development
- Understanding why business results out/under-performed
- Understanding why a process is broken
The Approach — Using the Hawaii Missile Alarm Incident
This is a pretty simple framework. You just ask “why” five times. The hard part is what to do with the data you find. In a video referenced in the footer of this post you’ll see a video with Eric Ries that shares some similar ideas. Here are a few next steps:
- Be prepared to invest. To make improvements will require investments / trade-offs to be made. This could be that you forego revenue to improve the customer experience to offering a specific service.
- Identify the human problem. Often the problem will be that system X did something it wasn’t supposed to. Take the Hawaii Missile Alarm incident where an individual clicked the wrong link.
- Map out the process. 5 Whys comes from the Toyota Production System which is largely a process improvement approach. After you have identified the human problem map out the process. In the Missile example there was a pop-up message that just asked whether the individual wanted to post the message, which of course he wanted to send the “test” message.
- Design improvements. One of the principles I was taught in engineering was to make it easy to the right thing and hard to do the wrong thing. If there is a potentially dangerous solution that could result from an action you’ll probably want to design in redundancy and make it very clear that the action will have major consequences.
Here is a great Twitter post after the Hawaii crisis on how you could poorly design a ‘seat ejection’ button for a plane:
Example — Improving marketing spend
I’ll share an example that we worked through a couple years ago on our affiliate marketing program. The context is that we had recently put in place a new monitoring system and had found that we were significantly over budget for a segment of our customers. For this example I’ll stick to a simple model without branching trees
- Why did we buy excess affiliate leads?
The signal we had was that their was unlimited budget - Why was their an unlimited budget signal?
When a customer cancelled their final budget signal was left static - Why didn’t the system know the customer had cancelled?
The system had a bug in the code that only looked at budget available - Why wasn’t this bug caught in previous releases?
It might have been occuring, but given the new affiliate that was added was ~10x the size of the next largest it was a much more pronounced error - Why weren’t controls in place?
The controls were in place at a nationwide level and thus we controlled total spend, just not at an individual market level
After going through this analysis we were more equipped to tackle the problem. We first identified the system bug and quickly put in a place that stopped the unique overspend from happening. We still had the “human problem” in this old model that our marketing team would set a budget at a national level, but that meant some markets would be over-served and our economic model was not aligned. Over the course of a year we made a number of changes including:
- Launched a new business model that charged based on transactions vs. a subscription model
- Setup our system to only buy from affiliates when we have a need
- Removed the likelihood that humans can cause error by limiting control to basic inputs
- Put in place improved monitoring at an individual market level to alert when we were out of threshold
Like any system there are still areas for potential failure, but because we defined the constraints from which we were willing to accept we are in a much better place. Since launching this system we have continued to go through analyses like the above to strengthen the system. While we aren’t to the Toyota levels we are on a path towards a “kaizen” mentality.
In Closing…
Using the “5 Whys” after you experience a defect in your process or product is a great tool for continuous improvement. I would also recommend using this line of questioning before launching a new product or process as part of a pre-mortem. Having this mental model has been helpful for me to spot issues before they arise and ensure that we can move fast without making unnecessary mistakes. Finally, this type of questioning can be useful in user research as you are looking to understand customer needs.
As we continue to go through topics to create a Dynamic Strategy, 5 Whys is a great mental framework to ensure that the strategy system we are building is dynamic.
References:
An overview with Eric Ries of “Lean Startup” fame:
A few additional articles that describe the process and origin in more detail:
