One of a Product Manager’s greatest tools

Why?

A question we hear far too often from toddlers and far too little in meetings and decision making process.

We as humans are hard wired to ask for causalities. Just see the most common headlines on medium and in sensational journalism. We always want to understand the underlying reasons for things.

In customer interviews our curiosity automatically pushes you to ask the right questions.

Asking “Why” several times (Or not to become too repetitive: “How would that help you?”) helps us to determine where to focus our effort in development.

It helps us to get to the bottom of things:

• What is the root cause of an error?
• What is the underlying customer need?
• What should we really work on?

Thank you Toyota

The “5 Why” method has been applied by Taiichi Ohno, the father of the Toyota production system. He propagated the use of asking at least 5 times “why” to get from symptom to underlying cause.

This helped Toyota to focus their effort on solving problems and thereby boost their product quality.

Guidelines to make the “Whys” effective

To make sure you get the most out of your interview:

• Look for causes, not symptoms.
• Focus on process, not humans. A root cause shouldn’t be “worker’s fault”, rather it can be a fault in the design which allowed an error to occur.
• Go through the steps. Don’t directly jump to conclusions, the answers should build a logical chain or a story how the need arises or a problem occured.

Example

In a customer interaction a product manager can use the “Whys” to find out what a customer really needs — not what he says/thinks he needs.

• PM: What is your biggest need?

“I need this button on the user interface to be green”

• PM: Why is that? (1)

“I need it to be green so I can identify whether the feature is switched on”

• PM: Why? (2)

“Sometimes other teams change the settings and it messes with me when I start my shift — I need to check if something has been changed”

• PM: Why? (3)

“If the feature can be activated/deactivated by anyone, my dashboard sometimes show a different value for the same metric”

• PM: Why? (4)

“To be able to consistently monitor the performance of my process”

• PM: Why? (5)

“The performance is what I communicate to my superiors. If the numbers are messed up I might deliver wrong information which can be quite embarrassing”

• Conclusion: “So it’s really about being sure that the right performance value is shown and sent over to your superiors?”

“YES!”

Conclusion

So, instead of rushing to the design department to change a button’s color you can put several actions in place that attack the root problem the customer is facing.

For example, Engineering and Design can now focus on:

• Which user has which rights and how do one user’s settings influence the experience for others?
• If settings influence the general user experience — How are users notified if other team members changed settings?
• Can we ensure that one metric always has one meaning which the user doesn’t need to interpret differently?
• Are metrics the best way to allow a user to monitor process performance?
• Is there a way to make the crucial performance metric easily accessible to superiors?

This allows for a much more sustainable improvement of the product, just by using “Why?”.

Daniel Sontag connects the bots: As Industry 4.0 lead and manager for connected products, he does what he loves — tying business to tech, and theory to practice.

Hi, great you enjoyed the article! Feel free to give the applause button a few good clicks or leave a short response below, thanks.

Stay tuned: On The Industry 4.0 Blog and on LinkedIn