The product manager and 5 why's..

As a product manager, one of your key responsibilities includes building a culture of analyzing the root cause of the problems that have maximum impact on your software. Developing a deep understanding of the root problem is a critical step in building new features, mitigating potential bugs and also predicting software behavior in edge use cases.

Why do i need to do a root cause analysis?

The primary goals of any root cause analysis is to take a problem and find the root cause so that it can be addressed for the future. If done properly, it can help organization save money, customers, and possible embarrassment as well. Most enterprises have come to the conclusion that while it may be faster to identify a problem and put in a fix for it up front, in the long run it is much better to identify the true root cause of the issue. Seeking a root cause solution rather than just addressing the symptoms provides companies with many long term benefits.

In software, sometimes things don’t always go as planned. There could be an issue with the code, servers, or a newly introduced feature is not achieving its intended success. Solving such issues requires a deep understanding of the reasoning behind why its happening. Moreover, asking the right questions and finding the root cause can help prioritize and build new features that add value to your customers.

The 5 Why’s

The “5 Whys” is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem. The technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies.

As a general rule of practice it is good to follow the below three steps to effectively sue the methodology in your daily lives:

- Write down the specific problem - this will help with describing and formalizing the problem.

- Ask why the problem happens and write the answer down below the problem.

- If the most recent answer does not help identify the root cause, ask why again and write that answer down.

- Loop back to the previous step until the team is in agreement that the problem’s root cause is identified.

*This may take fewer or more times than five whys.

Example 1 - Delayed release

- Why is the feature release be pushed?

Because our engineering teams could not finish the development.

- Why could the engineering teams not finish development?

Because they ran into unexpected issue during development.

- Why did they run into unexpected issues?

Because they were working with programming language X for the first time.

- Why were they working with X for the first time?

Because we have not had any training to X.

- Why have we not had any training in X?

Because the budgets for training has been exhausted on another technologies.

Hypothesis:

Anticipating training needs and providing employee with the right set of knowledge would help reduce delivery time.

Example 2 - Production outage in product X

- Why did we have a product outage?

Because the platform was performing poorly.

- Why was the platform performing badly?

Because there was a bad cluster in the database.

- Why was there a bad cluster in the database?

Because some of the nodes had stopped responding.

- Why did some of the nodes stop responding?

Because there are not enough health checks done to validate node health.

- Why are there few health checks?

Because the nodes are supported by a lower version of our cloud software.

- Why are the nodes supported by a lower version of the software? Because we have not had the budget to upgrade our system health softwares last release.

Hypothesis:

Re assessing budget needs for system health upgrades and softwares might help reduce production outages.

Example 3: Evaluating the “Share” feature

- Why do we need a “Share” feature?

Because users have been asking for it .

- Why have the user been asking for it?

Because users want to be able to share their designs with their colleagues.

- Why do they want to share their designs?

Because building their final design is an iterative process of peer feedback and refining.

- Why does the final design require iterative feedback?

Because the final design is a collection of moving parts with different complexities.

- Why are the moving parts different in complexity?

Each part is designed by an expert with niche skill sets and knowledge.

Hypothesis:

We can provide additional features where each set of users are allowed to make notes of design complexities and best practices. A checklist to see if the user has met design standards can also be valuable.

References:

https://www.adb.org/sites/default/files/publication/27641/five-whys-technique.pdf

https://www.mindtools.com/pages/article/newTMC_5W.htm

https://open.buffer.com/5-whys-process/

https://www.isixsigma.com/tools-templates/cause-effect/determine-root-cause-5-whys/