Val Workman

The opinions expressed by the bloggers below and those providing comments are theirs alone, and do not necessarily reflect the opinions of Ryma Technology Solutions. As they say, you can't innovate without breaking a few eggs...

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Archives
    Archives Contains a list of blog posts that were created previously.
Posted by on in Product Management
  • Font size: Larger Smaller
  • Hits: 31680
  • 1 Comment
  • Print
  • PDF

The 5-Why's of the Problem Statement

 

Yes, we derive the problem statement from the market evidence gathered. Hopefully that evidence has been grouped and categorized. There's nothing more disruptive than having to shift mental thinking back and forth between evidence that hasn't been preprocessed.

The 5-Why is a questions-asking method used to explore the cause/effect relationships underlying a particular problem. Ultimately the goal of applying the 5-Why method is to determine the root of a defect or problem. Other methods similar to this one would include Failure Mode and Effects Analysis, along with the Cause-and-Effect matrix of QFD. I'll probably address these methods of problem definition as well some time.

The 5-Whys can contribute to the focus of a brainstorming session, especially encouraging the divergent thinking of the group.

An example of the basic process might be the following:

Presented as market evidence: “I don't have the authority I need to make my product successful.”

First Why: “I can't target different product configurations to different segments with different prices.”

Second Why: “I don't have data to verify my intentions.”

Third Why: “I haven't completed market sensing for the products I'm responsible for.”

Fourth Why: “I don't have time.”

Fifth Why: “I'm too busy putting out fires created by making poor decisions.”

IF I had the authority I need to make my problem successful THEN I'd define multiple configurations of my product offered to different market segments, each with a different price, BUT I'm too busy putting out fires created by making poor decisions.

The questioning for this example could be taken further to a sixth, seventh, or even greater level. There's nothing magic in the fifth level. They say, (whoever they is) that five levels are normally enough to get at the root cause. I would suggest that in many cases, the product management team might not want to get to the root cause. In the example above, I could have stopped at the fourth level of Why, resulting in the following problem statement.

IF I had the authority I need to make my problem successful, THEN I'd define multiple configurations of my product offered to different market segments, each with a different price, BUT I don't have time.

The point is, that by asking a series of Why's, I'm able to choose what problem I want to address. My problem selection depends on things like size of opportunity, available resources, and investment availability. If I want to get to the root cause, then I look for things that suggest a broken or nonexistent process or an alterable behavior. Using the 5-Why approach, the root cause should point to a process.

Those new to the 5-Whys, may end up with things like "not enough time" as in my example, or "not enough investment", or "not enough manpower". These answers may sometimes be true but in most cases lead to answers out of our control. You might consider going deeper with "Why did the process fail". Keep in mind: "People don't fail, processes do."

There are two primary techniques used to perform the 5-Whys: the fishbone diagram, and a hierarchical tabular format. These tools allow for analysis to be branched in order to provide multiple root causes to be solved.

For a live example of a fishbone diagram, check out this post. I've included a generic template here that might help.

Things to look out for when using this method include the following:

 

  • There is a tendency for the product management team to stop at a symptom rather than going on to lower level root causes.
  • There is an inability to go beyond the current knowledge - can't find causes that the team doesn't already know.
  • There is no support to help the team ask the right "Why" questions.
  • Results aren't repeatable - different people using the 5-Whys come up with different root causes for the same initial problem.
  • The tendency is to isolate a single root cause, whereas each question could elicit many different root causes.

 

Modifications to the basic 5-Why method can address these issues and be very useful in defining robust problem statements.

 

Rate this blog entry:
0

Comments

  • Guest
    Abhay Tuesday, 28 February 2012

    Good stuff. having clarity in product statement is must to understand opportunity. I like the punch "encouraging the divergent thinking of the group". Product Manager here acts as enabler and ensure that groups open up to discuss various options.

Leave your comment

Guest Wednesday, 23 April 2014