Now we have had the overview of the six step process, let’s get into the detail

The first step in decision making is defining the problem.  What is on the table?

The simple example of defining the problem is when we are presented with two or more alternatives. For example, “Do we follow option X or option Y?”  Or perhaps you have received a specific question like “Should we commit resources to this?”

This is rare and clinical – the real world is much more fuzzy.

There are usually many decision situations in every discussion. For example:

• Have you have noticed a departure from the vision, or an assumption you disagree with?
• Is the discussion going around and around without reaching any conclusion?
• Has someone has come along and demanded “we need to do X”?
• Is the time-poor product manager now feeling a bit cranky about something and they can’t lay their finger on it?

It is now a decision situation.

But what is the decision about? What is the real question or issue?

It turns out that defining the exact problem you’re trying to solve can be difficult by itself. Often there is a deeper issue that hasn’t been drawn out. If you’re finding that the questions and answers are going in circles without any resolution, then you probably don’t understand the problem and some research is required.

A sure fire way to realise this is happening is when you are getting frustrated by lack of progress and competing priorities.

One tool to identify the true issue is the ‘5 Whys‘.

This technique is to ask why five times to get to the true nature of the problem. Traditionally this is a linear exploration of the cause; A was caused by B, which was caused by C, D and then E. But usually I found that there are many causes at each level, and you can develop a bit of a tree structure of causation – sometimes displayed in a fishbone diagram. Either way the tool is used to step back and look at how we got here, and can help identify what may be the real issue. Or at least the issue with the biggest impact.

Some interesting reading on the 5 Whys methodology:
http://www.mindtools.com/pages/article/newTMC_5W.htm
http://www.isixsigma.com/tools-templates/cause-effect/determine-root-cause-5-whys/
http://en.wikipedia.org/wiki/5_Whys

A related issue occurs when you get solutions thrown at you instead of questions: “We must do X!”  While we should be encouraging people to suggest solutions instead of just problems, we have to be careful. That solution might not be the only option, nor the best. Further probing and understanding of the actual issue and decision will help you find there are more alternatives, and some may be better than the initial one proposed.  We can use the 5 Whys again to get to the bottom of the issue, though often simple open ended questions can be enough.

Overall the 5 Whys approach is something we should always be utilising.  Question everything if you can; the strategy, what is best for the product and why some techniques just seem to work better than others.  After all, the product manager should always be (internally) questioning whether they are doing the right thing.

Another tool is to reverse engineer the question from the answer

A clear question should have clear options that lead to clear outcomes.  Therefore you should be able to examine the outcomes to see if they are indeed clear, and whether they correlate to your original question.

Let’s take a simplified example; you have to decide whether or not to close a factory to save money.  The outcome would be that you might save money but the employees would be out of work.  Is your original decision about closing the factory or is it about putting employees out of work?  Would you feel comfortable that a financial decision is the only considered point that leads to this outcome?

Do a first pass on your decision question and some possible options.  Choose each option and be very clear about what the expected outcome would be.  Review all the outcomes, and reassess whether the outcomes really match the original decision.

Note that if you don’t know how the outcome will be used, then you are not addressing the decision correctly, and will be making a decision in a vacuum. 

This reverse engineering of the question will help ensure that the decision making is actionable in the right way. It can be used through the whole process to ensure you are on track.

Have you got any other tools to ensure you have a solid decision question? Please feel free to comment below to add to the discussion.

Next we’ll talk about the role people play in the decision process in part 3 or go back to part 1 to cover the process

Steve is a Product Development Manager at Telstra Wholesale.  The views expressed in this post are his only and do not necessarily reflect the views of Telstra.