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.