In every business, decision-makers wrestle with the same question: “How do I know if I know enough to make this decision?” Being too hasty might lead to mistakes, but more investigation will result in higher costs and longer timelines.
In my years as a design consultant, I have had the pleasure of working with great product owners who excelled in making decisions, as well as some that struggled. Often, what defines the difference is a clear decision framework.
The challenges of product management
Product development has never been an easy undertaking. In recent years, with the advent of digitalization and globalization, the speed and the stakes have amplified. Today’s sophisticated customers punish bad decisions with relentless feedback — or, worse, move to the next best competitor.
Product owners are under constant pressure to weigh options and make decisions — and face the consequences of those decisions. Often, the decision is not just about being right or wrong. Timing and context play a significant role in the acceptance of the decision. Knowing when to move forward and when to investigate further is crucial for the product owners and the product’s success.
Think about the selection of the initial features from a product vision to create a minimal viable product (MVP), or determining the most suitable option of a feature to evolve a product already in the market.
The product owner must determine their knowledge state and their level of confidence with the information they have. These two aspects create clarity and trust in making decisions.
Determine the right moment
The logarithmic diminishing-returns curve illustrates the point at which increasing effort is required to increase understanding. It provides a model to know where you are in the process and how much effort will be needed to get to the next level of understanding. Given that knowledge is infinite, how does it measure against a scale of 100%? How does this help to understand when your knowledge plateaus? How can this help us to determine the right moment?
The decision model: knowing when to say when
Key to acting in the right moment is to understand your knowledge state and your level of confidence in the information at hand.
Assessing your own knowledge requires self-reflection. Metacognition — in simple terms, “thinking about thinking” — describes the awareness of what you know and don’t know. The best tool to help you become more aware of your knowledge state is the Known-Unknown Matrix.
The Known-Unknown Matrix clusters our knowledge into four states:
- Known knowns. Everything that is factually known and proven to us
- Known unknowns. Everything we assume but have no proof of evidence
- Unknown knowns. All of our and peoples’ relevant biases and prejudices
- Unknown unknowns. Everything that could happen but is unidentified
If we take the diminishing-returns learning curve and apply the quadrants from the known-unknown matrix, we can start to clarify the usage.
The known knowns and known unknowns make up all of the knowledge you can possibly attain. Understanding this, you can objectively determine how much knowledge you need to make good decisions. Coming back to the learning curve, you’ll see that from 60–70%, the required investment might outnumber the gains.
The unknown unknowns encompass everything you really can’t define. They can’t be qualified or adequately evaluated. Unknown unknowns represent the infinity of all knowledge and bear risk. Futurecasting is a great technique to identify some unknown unknowns, and transform them into known unknowns, or even known knowns. If you want to know more about it, here is an excellent introduction from my colleague Prima Sung.
What’s left are the unknown knowns, the influences of outside factors and past experiences. They determine the threshold of how much knowledge is enough. The biases and agendas of stakeholders are important factors in the level of certainty it takes to create a trustworthy case for your decision.
For example: A key decision-maker may be risk-averse after past failures, and require strong evidence before trusting a new product decision. Or a designer may be excited to innovate on a product they use themselves, but this bias introduces the risk of overlooking other user needs. A thorough data-driven investigation is needed to mitigate such inherent risks.
The framework for assessing knowledge
Now that we have a model, we need a method to assess our knowledge. Understanding the state is a self-reflecting process. As earlier pointed out, it is difficult to make this assessment. Our brain might trick us, via various biases. You can read more about this in Daniel Kahneman’s book Thinking, Fast and Slow.
The following method is one I’ve used in projects with various stakes and team sizes, from small start-ups to international organizations. It is applicable for all industries and all stages of the product design process, from conception to development.
The table below enables you to externalize what you know and don’t know and assess your current information state. Excluding the unknown unknowns, the horizontal axis allows you to evaluate the knowledge type: biases (unknown knowns), assumptions (known unknowns), knowns (known knowns).
The vertical axis helps you to look at three different angles, usually crucial during the product development process: requirements, internal context, and external context. Each of these needs to be considered from the angle of the different teams involved. This usually means a product team, development team, and design team, but there could be more.
Let’s walk through those angles in detail.
Requirements, as the label says, look at what will be needed to make this a success. Think about your users, business goals, and technical specifications.
- What user needs are we trying to cover?
- How does this benefit the business?
- What requirements will the development team need to enable?
Internal context focuses on the already existing frameworks and knowledge within the organization concerning the decision.
- From the business point of view: Think about the vision, mission, and business model. How does your project relate to them?
- From a design point of view: Think about existing personas and user journeys. What drives your users? What do they do before and after interacting with your product?
- From a technical point of view: Think about the existing architecture, frameworks, and libraries. What opportunities and restrictions do they offer?
- From an organization’s point of view: Think about prior solutions to similar problems. What made them succeed or fail?
The external context goes beyond your organization and concentrates on the already established expectations and patterns that will have an impact.
- From a business point of view: Think about the competitive landscape. What is the effect on the position within it? Is there something you can learn either from success or failure?
- From a design point of view: Think about users’ expectations. Are there existing best practices that can be used? What impact have other apps had on users’ habits and mental models?
- From a technical point of view: Think about existing benchmarks. What do users expect in terms of performance, caching, or touchpoint support?
Keep in mind that these topics and questions are only a few examples of what could be relevant, but I hope it gives you an idea of the approach. You will need to adapt it to your decision, but in my experience, these are a good starting point.
Foster stronger decision making in your team
Self-reflection takes time. Creating and maintaining such an overview takes effort. It is tricky to keep it up while leading a fast-moving product development process.
But considering the high stakes of product decisions, it is worth the investment.
To mitigate the effort, you can leverage your team. Invite key stakeholders to add their knowledge and split the work among roles like product, design, and development. Implement the outline structure right from the beginning. Ask people to write down the biases, assumptions, and knowns of the project- relevant requirements, internal and external context, each from their speciality. It takes a bit of extra effort, but it is always ready when needed.
There are great collaboration tools to help keep one consistent version at all times. When you are still in the concept phase, consider tools like Trello and Google Sheets to capture valuable knowledge collaboratively. During the actual development phase, teams already use tools like Jira. Besides helping you to make decisions, adding this kind of visibility to your documentation can have a tremendous impact on your team. It will bolster decision buy-in. Speed up discussions to reach an agreement. And increase organizational trust with more transparency into decisions.
Matthias Dittrich is a Creative Director at argodesign, seasoned design leader, and expert in interaction design and user research. His 15-year career spans his work at Raft, which he co-founded, and frogdesign, serving such clients as ING, MasterCard, and Elsevier. A native of Berlin, he now calls Amsterdam home.