Assumption Prioritization Canvas: How to Identify And Test The Right Assumptions
You can’t test everything. And you can’t test what you’re unaware of.
Hey, Paweł here. Welcome to the free edition of The Product Compass.
Each week, I share actionable tips and resources for product managers.
Not a subscriber yet? Here are a few posts you might have missed:
Also, see 85+ posts in the archive.
Consider subscribing and upgrading for the full experience:
In product management, most of our ideas are not going to work.
It’s essential to test our assumptions before the implementation.
But you can’t test everything. And you can’t test what you’re unaware of.
So, in today’s newsletter, I want to explain how to identify and test the right assumptions:
Traditional Assumptions Mapping Techniques
The Assumption Prioritization Canvas
How to Identify Hidden Assumptions
Summary and Takeaways
Let’s dive into it right now.
1. Traditional Assumptions Mapping Techniques
The original Assumptions Mapping technique was developed by Jeff Gothelf and Josh Seiden, co-authors of Lean UX.
David Bland, co-author of Testing Business Ideas (from Strategyzer), who worked with them, developed his own approach.
The goal of both techniques is to identify and test the riskiest assumptions before the implementation.
But the details of the two approaches differ significantly.
Let’s break them down with some critical comments.
1.1 Assumptions Mapping by David Bland (Strategyzer)
Strategyzer’s approach aims to answer the question, “Which assumptions to test.”
Each assumption represents an identified risk. Let me quote three main risk areas suggested by David Bland:
Desirability: Does the market want this idea?
Feasibility: Can we deliver at scale?
Viability: Is the idea profitable enough?
While David emphasizes a cross-functional collaboration, according to him:
Desirability risk is primarily the responsibility of Designers, not Product Managers.
Feasibility risk is primarily the responsibility of Engineers.
Viability risk is primarily the responsibility of the Product Manager.
Steps you take in order to identify and perform the right experiments:
Step 1: Create a Business Model Canvas and (later) a Value Proposition Canvas if you haven’t already.
Step 2: Write down assumptions related to Desirability, Viability, and Feasibility. You can use sticky notes and place them around the canvases:
On his website, David Bland has also shared a list of questions you can ask yourself when mapping assumptions.
Step 3: For each assumption, assess its importance and how much evidence you have.
Next, focus your experiments on the top right corner, share assumptions in the left-right corner with your team (and internal stakeholders), and defer testing everything else:
Step 4: Perform an experiment to test the riskiest assumption(s), learn from it, and repeat. It’s an iterative process.
Assumptions mapping by David Bland (Strategyzer): A critical look
While I love the Strategyzer book series, I have a few doubts related to the 2x2 Diagram and their recommended workflow.
It’s clear to me that David’s Assumptions Mapping was highly influenced by Design Thinking and long-term research projects performed primarily by UX Researchers.
But the notion that Designers own the entire Desirability risk contradicts the responsibilities explained by Marty Cagan in Inspired, where:
The Product Manager focuses on Value risk,
The Product Designer focuses on Usability risk.
It also doesn’t match how most product teams work. In my experience, and I discussed it with hundreds of professionals, while Product Discovery is teamwork, it’s usually the PM who leads and facilitates the discovery.
Also, David's approach focuses on working with new products (aka Product Innovation or Initial Product Discovery).
I'd argue that it’s not well-adjusted to Continuous Product Discovery, where you do not start with the Business Model.
Another issue is that summarizing Desirability risk as “Does the market want this idea?” might not be clear enough for product teams.
Why?
Imagine you created a landing page to validate the market engagement by collecting preorders. The fact that the market wants your idea doesn’t mean users will figure out how to use it. It doesn't mean that the idea will actually deliver the value promised as part of your Value Proposition. And it doesn’t mean you know how to market that idea (Go-to-Market).
While theoretically, you can collect all those questions under the “Desirability” umbrella (and David does this), people might not remember to ask those questions.
For all those reasons, I prefer:
Marty Cagan’s Value, Usability, Viability, and Feasibility risks for existing products.
Add a Go-to-Market risk as a separate category for new initiatives.
I explained this, together with the extended risk classification in How to Manage Risks as a Product Manager.
Finally, while the horizontal axis (the amount of evidence) is clear, the “Importance” is ambiguous. What does it mean for an assumption to be important? Some might assume it’s related to Risk, but in Jeff Gothelf’s approach (from which it was adapted), the Risk is on the horizontal axis.
The framework should clarify how to interpret the labels to streamline the communication.
1.2 Assumptions Mapping by Jeff Gothelf (Hypothesis Prioritization Canvas)
What’s different about Jeff’s canvas (the original one that David adapted):
It answers two questions, not one:
Which assumptions to test,
Which ideas to build.
It assesses the “Risk” instead of the “Amount of evidence.” This is not the same. The risk involves both probability (related but not the same as the amount of evidence) and effort (negative consequences in the form of waste if the risk materializes).
It assesses a correlated “Value” (of building a product of a feature) instead of the “Importance” of an assumption.
A free template:
Assumptions mapping by Jeff Gothelf: A critical look
First, none of my doubts about David Bland’s framework apply to Jeff Gothelf’s approach.
The Lean UX, a fantastic book Jeff co-authored, perfectly explains the workflow. In particular:
It emphasizes the importance of cross-functional research and discovery but doesn’t specify how competencies in the team relate to specific risk areas.
It doesn’t even mention a specific risk taxonomy. It gives you the freedom to classify the risks how you want.
It emphasizes the importance of Continuous Product Discovery and explains how to integrate assumptions mapping practices with Agile and Scrum.
What I also like is that Hypothesis Prioritization Canvas uses unambiguous labels on the axes.
At the same time, here are a few details I’d like to improve:
We build ideas, not assumptions. And we have better ways of prioritizing ideas. Thus, I'd like to focus on answering which assumptions are worth testing.
I’d like to explain what the risk is for those who might struggle with the term.
I’d like to recommend risk topologies and questions to ask depending on the discovery type (new vs. existing products).
I’d like to demonstrate how to combine Jeff Gothelf's prioritization with the RICE/ICE scoring so that it works with other techniques.
2. The Assumption Prioritization Canvas
Let’s look at the Assumption Prioritization Canvas, which combines elements of the two approaches:
The key changes made compared to the Hypothesis Prioritization Canvas:
It focuses on which assumptions to test because we can’t indicate whether we should build an idea just by looking at a single assumption.
It clarifies that Risk = (1 - Confidence) * Effort, where Confidence and Effort are known from RICE/ICE. This helps you use assumptions mapping together with popular idea prioritization techniques.
The term “Value” was replaced with “Impact,” known from ICE. This emphasizes the importance of including not just the value you can create but also the number of customers affected.
It explains when it makes sense to run tiny experiments (low cost and short time.
As a rule of thumb, each experiment shifts your assumptions to the left but can also influence the estimated Impact and Risk as you learn more.
2.1 How to use the Assumption Prioritization Canvas
The entire cross-functional team (aka the “Product Trio”) must work together.
It typically includes a Product Manager, Designer, and at least one Engineer. While everyone has unique core competencies, there are no silos, and anyone can contribute to any risk area. For more information, see Product Trio: Beyond the Obvious.
Whether you are performing Continuous or Initial Product Discovery, your team needs to:
Start with a clear goal, either in pursuit of the Product-Market Fit or a meaningful problem to solve with clear desired outcomes. For more information, see Business Outcomes vs Product Outcomes vs Customer Outcomes and Product Team Principles from TRANSFORMED.
Explore the problem space (e.g., customer interviews, data analytics, market research, interviewing stakeholders).
Define your knowledge about the specific problems you are going to tackle (Opportunities or Jobs-to-be-Done). A common approach when working with existing products is using the Opportunity Solution Tree.
Ideate on how you can solve those problems and prioritize those ideas based on the Opportunity Score and other factors (e.g., value for the business). A simple approach that can aggregate different factors is ICE scoring. I explained this in How to Prioritize Ideas as a Product Manager,
Identify assumptions related to Value, Usability, Viability, and Feasibility risks for an existing product. For a new product, consider also the Go-to-Market risk. I presented detailed questions you can ask for each risk category in the extended risk classification. An excerpt:
The extended product risk classification (excerpt) Test: Focus on testing the riskiest assumption first. As a rule of thumb, conduct 1-2 experiments at a time. Learn from it and repeat. It’s a continuous, non-linear process.
Once there are no more assumptions to be tested, you can select an idea for implementation - Product Discovery results in a validated product backlog.
The entire workflow (the Double Diamond of Product Discovery and the Triple Diamond of Product Management) can be visualized as:
3. How to Identify Hidden Assumptions
You can't prioritize and test what you are unaware of. I recommend two ways of identifying hidden assumptions.
3.1 User Story Map
One of the best ways to identify assumptions related to Value, Usability, and Feasibility is to use the User Story Map.
Identify the steps a user takes to derive value from your product and consider the three risk areas for each step.
I also include system steps to help identify Feasibility risks easily.
A free template:
3.2 ChatGPT prompt
Another effective approach is to use one of the LLMs, like ChatGPT.
In “Top 9 High-ROI ChatGPT Use Cases,” I presented a template that allows you to identify hidden assumptions with a case study.
For more information, see point 3.2, Identify hidden assumptions (premium).
4. Summary and Takeaways
In product management, most of our ideas are not going to work.
It’s essential to test our assumptions before the implementation. But you can’t test everything, and you can’t test what you’re unaware of.
In this post:
I explained how to identify hidden assumptions.
I discussed two popular assumptions mapping approaches and provided critical comments.
I presented the Assumption Prioritization Canvas, which:
For every assumption, assesses the Impact and Risk.
Focuses on prioritizing and selecting assumptions to test.
Can be applied to both Initial and Continuous Product Discovery.
Aligns with idea prioritization techniques like RICE/ICE, which also work well with Opportunity Scoring.
I also referenced to how to use the canvas in a way that aligns with what we discussed in the previous posts: empowering teams, cross-functional collaboration, product discovery as a non-linear process, prioritizing ideas, and extended product risk classification.
Hope this will help you identify the hidden assumptions and test the ones that matter the most.
P.S. I’d love to get your feedback in the comments.
Thanks for reading The Product Compass!
It's great to learn and grow together with you.
Enjoy this?
You might also like:
Have a fantastic weekend and a productive week ahead,
Paweł
This is a great way to proactively fix customer experience issues. Thank you for the assumption prioritization framework and examples!
Loved it! 😍 Thanks so much for sharing this, Pawel. I was using this SEO article: https://www.mural.co/blog/intro-assumptions-mapping. Your framework addresses the GTM risks much better than David's. I will restack this immediately.