As product managers and product owners, we make a myriad of decisions—from shaping the product strategy and determining the product roadmap to deciding the detailed functionality of our products. But do we make all these decisions effectively? And do we always secure the necessary buy-in? This post helps you make better decisions. It discusses six common decision rules and explains when to apply them.
“Is everybody OK with changing the release goal for Q3?”, asks Julie, the product manager. As nobody says anything for a few seconds, she assumes that everyone agrees, thanks people for attending, and closes the meeting. But in reality, most people are still thinking about the change proposed. To make things worse, it’s not clear who has the final say on product roadmap changes. Is it the product manager, the people present, or the management sponsor?
If it’s unclear how a decision is made and whose input is required, people will be unsure if a decision has actually been made and if it should be actioned. Some people will start to implement the decision, while others ignore it instead of following it through. But if you want people to move together in the same direction, you need to give them a clear indicator if a decision has been made: you should clearly state how the decision is reached and whose input is required. In other words, you should apply the right decision rule.
There are six common decision rules, unanimity, consent, majority vote, product person decides after discussion, delegation, and product person decides without discussion, which I explain below. I base my description on the books The Facilitator’s Guide to Participatory Decision-Making and We the People.
Deciding by unanimity means that everyone required to make the decisions supports the proposed solution or idea. A unanimity decision creates strong buy-in and shared ownership, and it leverages the collective creativity and knowledge of the people present—everybody involved contributes to the decision. It is particularly helpful when the stakes are high and you make a strategic product decision, for example, if you should pivot, create a product variant to address new market segment, or change the goal of the next major release on the product roadmap.
The drawback of this approach is that it can take a comparatively long time to reach unanimity within a group, as it requires developing a mutual understanding and evaluating competing ideas. You may even have to schedule several meetings to come to a conclusion, particularly if you test different ideas as part of the process.
Watch out that an unanimity-based approach does not degenerate into design by committee where people agree on the smallest common denominator and broker a weak compromise. This is unlikely to result in a sustainable agreement and translate into a successful product. As the saying goes, “a camel is a horse designed by a committee.” Similarly, don’t allow an individual to dominate and high-jack the decision-making process. Unanimity does mean that everybody is happy with the decision and fully supports it.
When applying this decision rule, you will benefit from an experienced facilitator who guides everyone through the decision-making process and helps people reach agreement. Your ScrumMaster or agile coach might be able to help you with this.
Consent is the absence of objections: A decision is made when nobody disapproves. Deciding by consent requires that a proposal has been created—either as part of the decision-making process or by delegating the task to another group. Once the proposal has been discussed and a shared understanding has been established, ask the participants to clearly state if they object or consent to the proposal. If there are any objections, investigate their causes and ask why people object. Then amend the proposal or ask a group of people to rework it. Iterate the steps above until everyone involved in the decision-making process can live with the proposal and has no longer any meaningful objections.
Applying this decision rule is beneficial when you don’t have the time to decide by unanimity or a good-enough solution is sufficient. Remember the product roadmap scenario from the beginning of this article? Using consent would have been a great way to understand if the development team and stakeholders agree with the proposed roadmap change. The drawback of the decision rule is that does not give you the same degree of buy-in as unanimity: Not objecting to a proposal does not necessarily imply that people are happy to support it.
When deciding by consent, be careful not to shortcut the decision-making process by subtly pressurising people to agree or not considering all meaningful objections. For consent to work, everyone involved in the decision-making process must be OK with the proposal—no matter which role the person plays or how junior the individual might be.
As its name suggests, majority vote means that more than half of the people required to decide agree with the proposed solution or idea. Applying this rule is simple and comparatively fast. But it creates a win-lose situation that can leave the minority frustrated and unwilling to support the decision.
I therefore recommend that you use this rule only if the stakes are not high. Asking the key stakeholders to vote on a major strategy change would probably not be appropriate; using consensus or product manager decides after discussion would be more helpful.
If, however, you cannot agree on a lower-impact issue, for instance, if a technical or user-related risk should be addressed in the next sprint, then you may want to the Scrum team members to cast their vote. This speeds up the decision-making-process and gets sprint planning done within its allocated time box; and it’s acceptable as the decision’s impact is likely to be limited: you’ll find out at the end of the next sprint if you’ve addressed the wrong risk, and in the worst case, you will have lost a sprint.
Decide after Discussion
This decision rule requires you to discuss an idea or solution with the right people and poll them for their opinions as well as any data that backs them up. Once enough discussion has taken place or the time is up, you decide. A good example would be deciding how to evolve the product backlog. You may ask the stakeholders and development team for their input, but after some discussion you might decide if new stories are added or not, and how to prioritise them.
The benefit of this approach is that it involves people in the decision-making process, but you retain control over the decision. It can also speed up the process by limiting the time spent looking for an inclusive decision. But the decision rule’s drawback is that people may not support your decision—or worse, they might be frustrated and oppose it if their suggestions were not taken on board. And if the decision turns out to be wrong, then people may regard it as your mistake and your problem. Consequently, they may be reluctant to help you. The rule also requires that you do have the authority to make the decision, which might not the case particularly for high-impact decisions that affect revenue and other business goals.
Apply this rule when you need to involve the development team and stakeholders to benefit from their knowledge or make them feel valued but at the same time, you must make the decision rather than allowing the group to reach agreement. This can be case when the key stakeholders don’t have the knowledge or willingness to come to a meaningful consensus or when speed is more important than reaching a sustainable agreement and generating strong buy-in, for instance, in a crisis.
Delegate a decision if others are better qualified to decide or if your input is not needed. As the person in charge of the product, you would typically expect that the development team takes care of all technical decisions. But you might also delegate decisions about how to write or refine user stories to the team, if the team members have enough knowledge about the users and the product.
Delegation helps ensure that the best qualified people decide, and it frees up your time: you don’t spend more time making decisions than necessary. When applied correctly, it also sends a positive signal to the appointed decision makers: it shows that you trust them and value their expertise.
But don’t use the rule to avoid difficult decisions. It can be all too easy to delegate a decision that you don’t want to be responsible for. And do not try to influence the group tasked with making the decision, for example, by saying, “you decide, of course, but I think we should build our own data access layer,” as this is a sign of mistrust. If you need to be involved in the decision, then do not delegate the decision to others.
Decide without Discussion
As the person in charge of the product, you don’t have to involve others in all your decisions, of course: There are lots of low-impact decisions that you can and should make on your own. For example, should you invite the sales rep required to the next sprint review meeting? Should you start breaking down some of the larger epics in the product backlog or hold off for another sprint? Should you move from monthly strategy and roadmap reviews to quarterly ones (or vice versa)?
Be aware, though, that this decision rule will only be appropriate if you have the right knowledge to make the decision and you don’t need the buy-in from others. Take the last example from above where you decide to change the frequency of the product strategy reviews. If you are confident that the stakeholders will agree with your decision and if you don’t need their input or advice, then just decide.
But if you use the approach for important decisions, people may regard you as an autocratic leader and oppose your decisions. If in doubt, use consensus or product manager decides after discussion instead.
Choose the Right Decision Rule
Each decision rule discussed above has its benefits and drawbacks. No single approach is always appropriate. For guidance on how to choose the right decisions rule, download the infographic below by clicking on the image.