The 5 Whys

One of the hardest parts of software development, and one of the things I most enjoy, is figuring out the problem you’re trying to solve. Software developers solve problems using software, that’s the core of our jobs. Unfortunately a lot of the time when we’re handed a problem to solve it comes across as more of a solution than a problem. A good example is “we need to integrate with SalesForce”. A technique like “5 Whys” is a good way to figure out the root cause of a problem.

The basic idea of 5 Whys is, ask “why” 5 times. Let’s stick with the salesforce example:

Original Problem: We need to integrate with SalesForce.

  1. Why? Because it offers reporting tools
  2. Why (do you need reporting tools)? Because we want to track conversion rates on our website
  3. Why? Because our sign up numbers are lower than expected (ACTUAL PROBLEM!)
  4. Why? Because we launched a new website design maybe?
  5. Why? Because we wanted to update our branding

Now there’s a whole bunch of information we normally wouldn’t have, all because we said “why” 5 times. Not only did we uncover the actual problem, but we also have a LOT more context around the problem. Just integrating salesforce as requested in the original problem statement may have caused a developer to not even look at the conversion rate module. Or maybe there’s a problem with the signup form on the new website. Or maybe we need to run some A/B testing to up our conversion rates.

(From wikipedia) It’s important to note that the last response in a 5 whys questionaire usually points to a process. This is one of the most important aspects in the 5 Why approach – the real root cause should point toward a porcess that is not working well or does not exist.

Using the 5 whys can be the difference between wasting thousands of dollars on an incomplete solution and actually delivering what the client wants. This can change and educate an “I want facebook!” client to someone who actually realizes how complicated and indepth a social media presence can be, or move a department from “this vendor told me to integrate this software” to understanding the root problem is their processes and workflow.

Problem discovery is an important part of a software developer’s job and separates us from the “just implement this” code monkeys. As professionals we provide software solutions for a large number of problem areas, but it’s just as valuable helping our clients realize what their problem actually is.