Making decisions is tough business, especially when they’re tough decisions! However, you’re faced with them every day, in life and at work. In product development especially, making a wrong decision can be catastrophic.
But in a way, the right decisions are actually made for you. All you need to do is uncover the logic and then make the decision based on it instead of on emotions, fallacies, and/or cognitive biases. To do that, you’ll need to follow some kind of decision-making process.
In this article, you’ll learn the different ways that you can carry out a decision-making process.
A decision-making process is a methodology used for making good decisions efficiently. It’s especially useful for when you have a decision to make and you don’t even know where to start.
The process entails clarification, research, synthesis, evaluation, implementation, and review, but don’t worry, it’s a lot easier than it sounds.
To help you get started with implementing an effective decision-making process, you can follow these six steps within your product team.
As an example, let’s say that you need to decide between two tools for your product team’s designers to use.
Ask yourself why you need to make this decision. What prompted it? Let’s say that it was prompted by a need to validate a risky product idea efficiently.
This reframes the decision from “which tool is better?” to “how might we validate our product idea?”
Start off by clarifying what you already know. In this scenario, you need to validate your product idea efficiently (i.e., cheaply and/or quickly) in order to minimize risk (i.e., spending too much time and/or money).
Next, clarify who should weigh-in on this decision. This would include designers, developers, and product managers. Bring them into the decision-making process before asking as many relevant questions as possible. Some questions might include:
Remember to think outside of the box. Also, for the sake of covering your bases, consider the worst possible ideas you can think of.
If you’ve made this decision (or a similar decision) before, take what happened into account when answering the questions. If you haven’t, then consider looking into case studies produced by those that have. Whenever possible, use any qualitative or quantitative insights that you can find to help you to answer the questions more objectively.
Next, you need to synthesize your research so that you can work towards making an informed decision. Methods of doing this include:
A venn diagram is a type of affinity map that depicts multiple overlapping categories and places the thoughts/ideas/concepts into the categories that they’re applicable to.
Based on the venn diagram below (which depicts our example scenario), you might think it fair to decide that option A is the best option because it fits into more categories:
If risk-reward is your main concern, then an impact-effort matrix might be more suitable. Simply put, an impact-effort matrix can help you to identify which options might have the best ROI:
If an option seems like the right choice to the majority of the group, it likely is. However, voting stakeholders must have participated in the decision-making process and therefore have access to the research that was done to avoid falling prey to many cognitive biases and fallacies.
Luckily, there are processes that involve voting on decisions privately and then ranking the votes fairly. Dot voting and the nominal group technique are two voting methods that I recommend looking into.
Once you’ve made your decision, I recommend storyboarding what you envision the end-result and key milestones to look like. For complex implementations, incorporate this into a concept map that also includes requirements (i.e., tools, etc.) and anything else that’s needed to plan more carefully.
If everything seems okay, wrap this step up by applying measurable objectives to your end-result and key milestones, for example:
“Complete [x] by [x] date” (after which the implementation is likely to become too expensive considering the risks involved).
This is the easiest step in theory, but the hardest depending on the complexity of the implementation. To ensure that the outcome remains true to what you decided, let your storyboard/concept map prevent you from accepting scope creep and possibly failing your objectives without understanding why.
You’ll want to review the outcome of your decision. This means determining whether or not it met the objectives that you defined earlier and how you’ll move forward.
Also, remember earlier when I recommended researching the outcomes of similar decisions made previously by you or someone else? Yep, that’s also what these reviews are for! Regardless of what the outcome is, it’ll always yield useful insights that you can reference when making decisions in the future.
While the decision-making process may seem a bit long-winded, productive individuals and product teams can breeze through it easily. To add to this, the decision-making process gets easier and easier every time you do it.
More importantly, it helps you to make good decisions and provides you with plenty of eject buttons in case you don’t (but let’s hope it doesn’t come to that!).
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Brad Ferringo talks about how he helped develop modern “earconography” — sound language that creates context-driven audio notifications.
Without a clear prioritization strategy, your team will struggle to tackle competing demands and can end up confused and misaligned.
Minimums allow for lower costs, increased agility, and the ability to collect feedback before too much investment has been made.
Tim Martin talks about how he structures teams as they scale and transition through the various phases of being a startup.