Making better decisions faster


decisions -- all for one and ...

As I wrote recently, a lot of what Product Managers do is make decisions that impact the business. Given the nature of these decisions, it’s important to define a method that helps facilitate these decisions and get buy-in from all parties as clearly and effectively as possible.

At my current company, we have a simple, but very useful means of facilitating discussions and moving them forward to closure. The mechanism revolves around the use of 5 terms:

  • agreement
  • alignment
  • proposal
  • declaration
  • scale

As we all know, decisions can be made and reached in many ways. One of the key requirements of most decisions is to ensure that the parties impacted by those decisions buy-in to them. For example, pricing and licensing changes will impact the sales team and they need to know about them well before they are implemented. Product changes are another obvious place where decisions have significant cross-team impact.

While it is possible for a Product Manager to make these kinds of decisions in isolation and then communicate those decisions out to the affected parties, it’s not likely that those parties will always agree with the decisions nor will they view you — the Product Manager — as someone who they particularly want to work with.

The best approach is to solicit input from whomever you need, involve those internal teams who are most impacted in the process and then when decisions are made, ensure those parties buy-in to those decisions.

This is where the terms above come in. First let me define “proposal” and “declaration”.

A proposal is any plan or idea that is the topic of discussion and that needs a decision made on it by a group.  Note that for Product Managers, this would usually be in the context of a cross functional team, that would include representatives of other teams such as sales, marketing, engineering etc.

A proposal can be a formal detailed idea presented via a document or slide deck, or it could be simply a topic of discussion raised at a meeting. By using the word “proposal” and language such as “I propose …“, the message to the audience is clear: this is a topic that is meant for discussion and on which a common decision needs to be reached. i.e. need to get buy-in from other teams or individuals.

A declaration is essentially a statement or defacto decision made by someone with the authority to do so. While it is good to get consensus or a mutually derived decision, that is not always possible. In some cases, when a decision cannot be reached by the team, or to put some boundaries on a proposal, someone with positional authority can declare what the decision is, or that certain limits are in place for the context of the discussion or decision.

For example, a CEO or a business unit manager could say something like:

I’m declaring that any pricing changes must be made at least 45 days before the end of a quarter.

While it may sound a bit formal to say it that way, it sends a very clear message as to the importance of what is being conveyed.

Declarations are not used that often — managing by positional authority has it’s limits — but when they are used, people take note. There is usually little debate around declarations, unless the person making the declaration has exceeded their bounds of authority.

Now, let’s get into agreement and alignment.

Agreement is a binary action. Either one fully agrees with a proposal or they don’t. In most cases, it is very difficult to get 100% agreement on all aspects of a proposal. What happens often when people try to reach full agreement on a proposal is that the discussion devolves into very specific issues of objections and efforts to change the proposal to address those issues. A lot of time is spent arguing points back and forth and forward progress is hindered.

To work around this problem, the concept of Alignment is very useful. Alignment can be viewed as a form of general agreement or agreement in principal. One can be aligned with a proposal or not, but unlike agreement, being aligned does not mean full agreement to all aspects of the proposal.

For example, if the topic of discussion is an upcoming pricing and licensing change for a product, being aligned means agreement on the many assumptions or aspects of the change, but not every one of the details.

For example, one could say:

I’m in alignment with the timing of the changes, but not with the proposed percentages of the price increase.

Now at this point, how do you proceed? In this model, it’s not sufficient to simply disagree with a proposal or not be aligned. You need to make a counter proposal to continue to move the process forward. e.g. in the example above, the speaker would need to propose alternative percentages for the price increase, and ideally support their reasoning for those specific percentages.

Scale is used to make a discussion more general or more specific. When trying to reach alignment, it can be easier to scale up — make the context more general — reach alignment there, and then scale down — move to more specific issues — and then try to reach alignment on those.

Some people will explicitly use the word “scale” in their statements. For example:

On the scale of the entire company, I can see why this proposal makes sense, but on the scale of our team, it has problems.

Other people will imply a change in scale in their statements but not use the word explicitly. Think of the term “scale” as a tool that can be used to help facilitate the discussion.

One of the nice things about this type of dialog is that is requires specificity on the part of the speaker, and it encourages a positive discussion where the intent is to reach alignment. As discussions progress, the scope of the misalignment amongst the group will shrink until at some point, everyone is in alignment.  At that point a decision is reached.

The objective is not the reach full agreement — that is not always possible — but to quickly zero in on the points causing misalignment amongst the group and work to resolve them. If the meeting leader asks if everyone is in alignment with a proposal, and no one explicitly states they are not, then the decision becomes final and they cannot pipe up later that they are not aligned with the decision. Yes, there may be some small areas of disagreement, but unless someone can propose an acceptable alternative, those areas are left as is.

As you read this, you might wonder what I’m smoking. The terms may sound artificial or overly formal. I thought that at first as well when I was introduced to this approach. But as we’ve used it at work, I’ve come to like it. These five terms not only define a simple, common vocabulary that we use, but the process, of repeatedly narrowing down the areas of misalignment really works.

Given how much time we spend in meetings, discussing topics and trying to reach common ground, using a common set of terms gives us a common frame of reference and thus a common toolset to move forward together.

Try it at your office and let me know what results you get.

Saeed

Advertisements

3 responses to “Making better decisions faster

  1. Saeed, yep – it sure does sound rather formal. However, if you can everyone to play along then more power to you!

    What I think was missing from your post was just how this got implemented (the devil is always in the details!). If the top rung of your executives buy-in and start to use this approach, then yes, I could see it being successful.

    However, I’m thinking that it would be hard to do in a bottom-up fashion. Everyone is already moving so quickly that I’d think that they’d just stare at you, scratch their head, and move on not trying to figure out why you had suddenly started using the Queen’s English in the workplace!

    – Dr. Jim Anderson
    Blue Elephant ConsultingThe Accidental PM Blog

  2. Jim,

    It was introduced top down, by the head of the business unit. He described where it originated from, but I don’t recall. The senior leadership team is very consistent in their usage of it, and it flows down from there. And you’re right, it is something that would be more difficult to get adopted from the bottom up.

    Saeed

  3. Everyone is basically correct in their approach to decision-making. You have to make decisions every day. In Chapter 5 of my book, The Product Manager’s Desk Reference, I dig into this area – Refer to: “Decision Making: What’s Next?”

    Decision making is how we solve problems. However, the overall portfolio of decisions that have to be made should be put into perspective. For example:

    1) What is the importance of the problem?
    2) Do you have enough data to address the problem?
    3) What are the potential outcomes
    4) Would a possible outcome cause problems elsewhere?
    5) How will others learn from your experience

    Some techniques you could use include (these are used from The Product Manager’s Desk Reference with permission – from me).

    a) Combining options – If you have only two options, it’s critically important to consider the possibility that they aren’t mutually exclusive, that is, they can both be executed without working against each other in any noticeable way. In many cases when problem solving, the choice of whether to execute two or more options simultaneously comes down to one of marginal cost
    and marginal value.

    b) Using a morphological box – In the late sixties, Fritz Zwicky, a Swiss astronomer, developed a way to simplify problems that were too complex for making a simple decision. It’s called the “morphological box,” a digestible, easy-to-evaluate form for analyzing the problem and evaluating its possible solutions. The goal is to simply choose the aspects of the problem that each
    option truly impacts.

    c) Using a decision matrix- Sometimes options can’t be easily reduced by either combination or morphological analysis, usually because every remaining option has some level of desirable impact on every problem characteristic, that is, they’re all good choices. That’s where a decision matrix can be helpful. The decision matrix is constructed similar to a morphological box, with one very important difference: it assigns a weight to each solution characteristic and asks you to evaluate, on a simple numerical scale (e.g., 1 to 5), how much each option contributes to each characteristic.

    d) Using a decision tree – An effective decision analysis technique used to clarify and visualize decision options (alternatives) and possible outcomes is called decision tree analysis. It uses a diagram that looks like a tree with branches (outcomes)
    and nodes (decision alternatives). It’s a good technique when the
    decision analysis is serial, that is, one decision and alternative leads to another set of alternatives.

    Sometimes, the more options you have, the worse your decision—or you might not make a decision at all. Curiously, over-analysis, or analysis paralysis, is easy to fall into when the possible negative impacts of a bad decision (the opportunity cost) seem much greater than the potential gains made by deciding.

    Another deadly sin of decision making is rational ignorance,
    which, in some cases, is actually useful. When it’s very expensive or difficult to gather facts for an informed decision, you need to consider the possibility that an informed decision might cost more than any benefit you’d gain from getting the facts. Rational ignorance can also hinder decision making, usually when people (or cross-functional teams) feel their voices won’t be heard.

    In short, if you want to make better decisions more often, you must
    ensure that your team does not fall into an unbalanced focus on negative consequences (analysis paralysis), but also ensure that negative issues are not unduly suppressed (rational ignorance). You can’t succeed as a Pollyanna or an Eeyore in the Product Management role—the glass is neither half full nor half empty, simply something that must eventually be washed.

    This brings us to an important point: the product manager and the team he or she leads continues to earn greater credibility by having a higher percentage of better decisions than worse decisions.

    – Steven Haines
    President, Sequent Learning Networks
    http://www.pmdeskreference.com