This article continues the discussion from Product Anonymous back in June.  Full credit goes to the team and the attendees for providing key steps, insight and critical analysis.

In the last post we talked about defining the problem, and the clarity that comes with it.  We never really talked about the people angle.  Until now.

Let us now consider the people element when making the decision; also known as engagement.

This is probably not a big issue for a small decision or small company – you can probably skip the rest of this post.  But once you get to a medium to large organisations there are usually a large amount of people you need to convince to get something decided and implemented. Engagement becomes a necessary task to overcome the role specialisation within larger organisations.

People often shy away from engagement.  They see it as too hard, takes too long, or is just ‘airy fairy’.  Or perhap, like John Paul Satre wrote in Huis-clos, they believe ‘Hell is other people’.  Yet careful engagement is an early investment that can pay off in the longer term.

In his book ‘Extreme Programming Explained: Embrace Change’, Kent Beck wrote “no matter what the client says the problem is, it is always a people problem.”  For large organisations and large decisions this phase is a good time to think about those people, acknowledge them as important, and work out how you can get them involved and onboard quickly and easily, so that future decision-making flows smoothly.

There is a fine line between gathering consensus and playing a political game.  But if you consider that you are doing this for the decision and not for yourself then you are on the right path.

Who is going to make the decision?

Who are the right people to be involved?  Are the right people making the decision? Product managers tend to think the world revolves around their decisions, but perhaps this is a question for someone else to answer.  Perhaps this is not really in your hands.

The classic tool for clarifying roles and responsibilities is the RACI matrix (and used by most attendees of Product Anonymous). This tool is a way to work through your stakeholders and identify where they stand.

The acronym stands for

• Responsible: Those who do the actual work to achieve the task.
• Accountable: The one ultimately answerable for the correct and thorough completion of the deliverable or task.  There must be only one accountable specified for each task or deliverable.
• Consulted: Those whose opinions are sought, typically subject matter experts.
• Informed: Those who are kept up-to-date on progress.

(Refer to http://en.wikipedia.org/wiki/RACI_matrix)

The process in theory is pretty simple: Identify each stakeholder in your project and assign them a letter from R, A, C, or I.  Then work through the list and ensure that each stakeholder is being treated as required.

But it gets complicated in practice:

• Responsible and Accountable can be easily confused, so keep a careful eye on their meanings at first. Remember there can only be one Accountable person.
• The Accountable person may be your boss, the project sponsor or you.  Depending on the magnitude of the outcome it tends to go further up the chain.  Don’t escalate everything if you can avoid it.
• Almost everyone believes they should be Consulted.  The reality is they don’t need to be, and they will slow you down and cause you extra work.  Take a calculated risk and mark as many people as Informed as possible instead of Consulted.
• Is your customer / end user in the Consulted list?
• Keep it as simple as possible, with the smallest group possible.
• If the stakeholders seem to have multiple roles in the matrix, then perhaps you have a multi-part question.  You may need to break the question into sub-questions.

The RACI matrix is a simple tool that can be quite useful to bring clarity to the roles of the stakeholders.  But remember it is not a substitute for a plan.  It is only a communication tool that helps with engagement – You still need to go out and talk to the stakeholders.

We know it is decision time, we have the question defined, an understanding of the problem, we know how to use the outcome, identified stakeholders and we even a decision maker who will get us there.  Next we’ll look at what alternatives are available…

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

Go back & read part 2 on defining the problem or go forward to read part 4 on identifying alternatives

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.

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.

So what are decisions anyway?

Decisions take ambiguous information and make an outcome. Some see decisions as a set of finite cognitive steps, and some see it as part of a circle of deciding and learning. Both are true, and overall they share common ideas but with different level of detail. After all, the steps are just a framework that represents something that can happen in an instant.

My favourite is the 6 step model:

1. Define the problem

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?” But this is rare and clinical – the real world is much more nuanced.

2. Identify alternatives

You’ve got your problem identified, and you immediately think of alternatives A, B and C. Are they enough alternatives? How can we identify more?

3. Evaluate alternatives

It is time to evaluate our listed alternatives. You probably have a gut feel already, but how can we do this more rigorously?

4. Decide

So we now have some well evaluated alternatives, and finally it is crunch time. Someone has to make a decision.

5. Implement

We have made our decision. Now what?  Surely everyone will just crack on with it. Or maybe not…

6. Follow-up and evaluate the results

Learn from the outcome, but keep an eye on it too.  Is it time to course correct?

The above 6 step model is pretty simple, and only an overview.  We will spend the next few sections on each of these. We’ll break it down, explore some tools, think about some of the people issues (dare we call it politics?), and try to propose some way forward when it is not so clear which way to go next..  Please feel free to comment below to add to the discussion

Read the introduction  or go forward to read part 2 on defining the problem

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.

Decision making is hard.

Product management is about decisions every day. Snappy decisions about small features, and long drawn out decisions about expensive commitments.  Not only is each decision different, the way we make each decision is also different.  And, since we deal with people every day, there is always some added complexity.  Our methods, tools and ideas are constantly adapting to the needs of the decision.

Decision making stops being a science and becomes an art.  And in product management that art is our job.  So we need to be equiped with the right tools and ideas to be effective.  This series tries to take some of the best practice in the industry, share it and open the debate.  It’s a chance to expand our choice of tools in the process.

But why is product management different?

In product management we’re often tasked with the vision of the product. Of course this isn’t intended to be some fluffy concept, it is just a word that fits nicely. We are supposed to have some long-term goal in our minds; what it looks like, who will buy it, how it works, how it fills a customer need, etc. It has a current state, a final state, and some time in between – and it is all a bit fuzzy. And frankly the way we get from here to there isn’t always that clear either.

Product managers must have a vision, but it won’t be 20/20

And then there is the strategy. Or should we say strategies. The product strategy is how we intend to attain that mythical vision. There might also be a corporate strategy on how this fits in with the need of the organisation. And there might be even more strategies to do with customers, people and so on. Together these should offer guiding priority – the path forward and what is important.

And while product managers might have some say in the strategy and vision of the product, they are not enough. There is a long string of decisions and actions along the way that get us to the future state. And just like how every person is defined by the decisions they make, the same applies for the product. It is the decisions that product managers make that realise the product.

The enactment of the vision and strategy then becomes a set of decisions being made. Decisions by you and by your team. These decisions, in turn, lead to other decisions, based on interpretations and what you say and do. And if the decisions aren’t being made directly, then they get made somewhere else, where they might not be coordinated

Visible decision making provides guidance to you and your team. People understand the reasoning and direction, which in turn will help propagate into future decisions. Not just decisions by you, but decisions made by other people based on what you say and do.
So giving reasoning is important to decisions and to propagate your strategy and vision.

We have to be careful with decisions. Decisions are strategically important.

So what are decisions anyway?

In the next series of articles we’ll explore the process of decision making, break it down, and add in some advice from the trenches.  Please feel free to comment below to add to the discussion

Read part 2 – Defining the Problem from the Art of Decison Making series

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.

Steve Bauer recently led a session at Product Anonymous on decision making for Product Managers.  The result was an exciting discussion about some very common issues that we face every day.  Steve has turned this discussion into a series of blog posts that we are going to host here.