But other times, assumptions can miss the mark. Ever judged someone too harshly after a bad first impression? Like thinking a big, tattooed guy rolling up on a motorbike MUST be rough around the edges, only to discover that he\u2019s a charming dog-walking, cake-baking softie. <\/p>\n\n\n\n
As a Product Manager, we can\u2019t afford to operate on guesswork, even educated ones. Assumptions that go unchecked about our product, capabilities, and our customers can lead to you building the wrong feature, solving the wrong problems, and disappointing your customers. <\/p>\n\n\n\n
That\u2019s where assumption testing comes in. <\/p>\n\n\n\n
It\u2019s about challenging your gut instincts and getting the facts about your hypotheses – much like walking up to that intimidating biker and having a conversation to learn the truth about them. <\/p>\n\n\n\n
Assumptions can steer you down a blind alley if you act on what you think <\/em>instead of what you know. <\/em>But how do you test assumptions? Let’s break down assumption testing so that you\u2019re building on solid ground. <\/p>\n\n\n\n An assumption is a statement taken to be true without any real proof. It\u2019s something we all do to fill in the blanks when we don\u2019t have all the answers. For Product Managers, assumptions are the invisible threads woven into your ideas, plans, and product strategies<\/a>. <\/p>\n\n\n\n They\u2019re often hidden and untested, but they\u2019re the foundation of whether your product decisions will stand tall or crumble. Knowing how to identify and challenge these assumptions is the key to avoiding wasted effort and creating solutions that actually work.<\/p>\n\n\n\n Here\u2019s how Teresa Torres, the authority in assumption testing, defines an assumption:<\/p>\n\n\n\n \u201cAn assumption is a belief that may or may not be true. For product teams, we are talking about the assumptions that need to be true for your idea to succeed. As a general rule, the more specific your assumption, the easier it will be to test.\u201d Now assumptions aren\u2019t always obvious to find. They\u2019re lurking in the background, and you\u2019ll need to properly seek them out to find and understand them. Let\u2019s use a more Product Management specific example to figure out what assumptions might be. <\/p>\n\n\n\n Say you have a desired outcome: Increase product adoption rates<\/strong><\/a>. <\/p>\n\n\n\n To achieve that outcome, one of many potential opportunities is to get existing customers to refer a friend. <\/p>\n\n\n\n From that, you then come up with a few solutions to help users do that, like adding a referral share button in your app. <\/p>\n\n\n\n On the surface, this all sounds like a great, logical idea and a quick win to help get more potential users to your tool. <\/p>\n\n\n\n But have you spotted the many initial assumptions made in that quick mini-product discovery<\/a> session? <\/p>\n\n\n\n Well for starters, we\u2019ve made the assumption that users are engaged enough with your product to want to share – we don\u2019t actually know that. <\/p>\n\n\n\n We\u2019ve also assumed that customers will use the share button instead of a different alternative, like good old-fashioned word of mouth. <\/p>\n\n\n\n Plus, we\u2019ve also assumed that anyone receiving a referral will actually open it. <\/p>\n\n\n\n If all of these are incorrect assumptions, this whole design solution falls, and you\u2019re left wasting time building a new feature that has little to no impact. <\/p>\n\n\n\n Those three examples aren\u2019t even all the potential assumptions of this scenario. This is why assumption testing is so important, to first find your preconceptions and then discover the truth about them.<\/p>\n\n\n\n Like the well-read Product Manager you are, you may have come across the idea of the four big risks<\/a>, popularized by Marty Cagan. Risks are statements about your product that you want to prove are false to ensure that your solution is watertight. <\/p>\n\n\n\n Assumptions and risks are actually pretty heavily linked, as both are used to note down expectations and preconceptions about customers, your product, or the market. Depending on who you ask, they\u2019re the same thing. <\/p>\n\n\n\n The main difference between the two is that one is phrased as a negative, while the other is more positive. One needs to be false, while the other needs to be true. <\/p>\n\n\n\n So a risk is: Assumptions are: So they\u2019re opposite sides of the same coin. Ying and Yang. Whatever you call them and the way you phrase them, they\u2019re preconceptions about your product that you\u2019ll want to find the truth about before you implement the solution they\u2019re tied to.<\/p>\n\n\n\n Your assumptions can be grouped into five different categories: <\/p>\n\n\n\n These categories can be helpful in guiding your process when it comes to finding your riskiest assumptions. When going through your potential solutions, you can work down these types like a checklist to make sure that no stone is left unturned, and that you\u2019ve found all related assumptions. <\/p>\n\n\n\n An assumption test is where you go out and test the validity of the assumptions that you\u2019ve identified. Are they actually true, or have you missed the mark? An assumption test is a structured activity to test the risk in an assumption and to see if they\u2019re accurate. It\u2019s a way to see how bad your riskiest assumptions are and what the impact will be if it\u2019s wrong. <\/p>\n\n\n\n There are so many ways to test assumptions, and ultimately the choice is yours on how you want to go and find the truth. Some types of assumptions work best with certain tests. <\/p>\n\n\n\n For example, desirability and usability assumptions can be tested best by looking at customer behavioral data – looking at how users interact with your product and learning what that says about their engagement. On the other hand, feasibility assumptions can be tested by simply having a discussion with your Design and Engineering Teams. <\/p>\n\n\n\n We\u2019ll go into more detail on some of the best ways to conduct assumption testing, but for now, all you need to know is that an assumption test not only checks if an assumption is true, it also showcases the risks if it\u2019s found to be untrue. <\/p>\n\n\n\n Every time you propose a new design solution to achieve a certain outcome, there\u2019s no guarantee it\u2019s going to work. There are many factors that can impact failure. Perhaps you didn\u2019t perform product validation<\/a>, or maybe a step was missed in your product discovery process. One of the biggest culprits, however, is the hidden assumptions baked into your proposal.<\/p>\n\n\n\n If your hypothesis or solution is riddled with assumptions – essentially guesses – you can\u2019t be confident that an idea is going to lead to a viable product. Launching a new feature or making a change to your product without addressing the riskiest assumptions is like taking a gamble without knowing the odds. In essence, you\u2019re betting blind.<\/p>\n\n\n\n Assumption testing lets you bet smart. You\u2019re at least betting sensibly and giving yourself greater chances to win. <\/p>\n\n\n\n Think of it like walking into a casino: without testing, you\u2019re the person who throws their life savings on a single roulette number, hoping for the best. That\u2019s what happens when you launch a feature based on gut instinct instead of insight.<\/p>\n\n\n\n By testing your assumptions, you\u2019re stacking the odds in your favor. It\u2019s like studying the patterns at the table, analyzing probabilities, and realizing that betting on red gives you the best chance of success.<\/p>\n\n\n\n Of course, no amount of preparation can eliminate risk. The ball might still roll into a black pocket. But assumption testing ensures your bets are informed, calculated, and sensible. It won\u2019t guarantee success, but it will give you the confidence to know you\u2019ve eliminated incorrect assumptions.<\/p>\n\n\n\n Beyond eliminating your riskiest assumptions, assumption testing comes with several other benefits: <\/p>\n\n\n\n Testing assumptions is so important in making better, more informed product decisions. While the list of activities to test assumptions is endless, the most effective tests generally fall into one of the following four categories. <\/p>\n\n\n\n Of all the potential assumption tests you can do, they\u2019ll more or less fall within these four types. Still, let’s explore some of the standout ways you can test your assumptions.<\/p>\n\n\n\n A smoke test is a lightweight way to gauge interest in a new product or feature before you fully commit to building it. The idea is simple: create a mock version of the product or feature (often through a landing page or placeholder) and test it to see if it sparks any real-world interest. It\u2019s like putting out a sign that says, “We\u2019re thinking about this, are you interested?” and seeing who shows up.<\/p>\n\n\n\n ProdPad itself originally validated assumptions through a smoke test, and here we are. We had the assumption that there\u2019d be a demand for a Now-Next-Later roadmapping tool<\/a>, and a smoke test confirmed there was that demand before the product was fully built.<\/p>\n\n\n\n A\/B testing<\/a> is one of the most effective ways to test assumptions about what works with users by comparing two variations of a feature or experience. This method involves showing two different versions (A and B) to separate user groups and measuring the difference in user behavior or outcomes.<\/p>\n\n\n\n Let\u2019s say you assume that changing the color of a CTA button will improve click-through rates. With A\/B testing, you can test the original color (A) against the new color (B) to see which one gets more clicks. This data allows you to make decisions based on actual user behavior, rather than assumptions or guesses.<\/p>\n\n\n\n A\/B testing is particularly useful when you have an existing feature or product, and you want to improve specific aspects or validate small tweaks. It helps you make incremental changes with confidence, backed by solid user data.<\/p>\n\n\n\n The Opportunity Solution Tree<\/a> is a framework that helps you map out various possible solutions to a particular opportunity. Although not originally designed to test assumptions but to instead prioritize solutions, it can be used to organize assumptions around customer needs, business goals, and technical feasibility, making sure you test all the variables that could impact your solution.<\/p>\n\n\n\n The beauty of the Opportunity Solution Tree is that it allows you to visualize how different solutions and assumptions interconnect. It\u2019s an excellent tool for teams to collaborate and align on what needs testing first, ensuring that the most critical assumptions are evaluated early on. This makes it easier to prioritize the right solutions based on the risks associated with each assumption, helping you make smarter decisions.<\/p>\n\n\n\n The Wizard of Oz test is a clever technique where you create the illusion of a fully functioning product, even though it\u2019s not actually built yet. Typically, this involves using human intervention behind the scenes to simulate the behavior of a product or feature that doesn\u2019t exist yet in its entirety. Kind of like what the Wizard did in the movie that gives this technique its name.<\/p>\n\n\n\n Imagine you\u2019re testing a chatbot feature, and you want to see if users find it helpful. In a Wizard of Oz test, you might set up a fake chatbot interface where a real person responds to user queries instead of an automated bot. This gives you valuable insights into how users engage with the feature, without having to build the fully automated solution upfront.<\/p>\n\n\n\n This method is particularly useful when you want to test the feasibility of a new feature, concept, or service without committing to full development. It helps you validate assumptions about user needs, behaviors, and interactions before you invest in the technical complexity of building the feature.<\/p>\n\n\n\n User shadowing involves observing users as they interact with your product or similar products in real-time. The goal is to uncover implicit assumptions you may have about how users behave or what they need. By stepping into the user’s shoes (without interrupting them), Product Teams gain valuable insights into pain points, workarounds, and behaviors that might otherwise go unnoticed.<\/p>\n\n\n\n This technique helps Product Teams understand the true user experience in complex, real-world environments. It\u2019s like being a fly on the wall while users interact with the product, which can reveal a wealth of information about how features are used, or where assumptions about usability or desirability fall short.<\/p>\n\n\n\n User shadowing is particularly effective when you want to test usability assumptions or observe specific behaviors that are difficult to capture in a survey or structured interview. It\u2019s also an invaluable method for seeing how a user navigates through a system or process, which can often provide better insights than simply asking them about it.<\/p>\n\n\n\n Assumption testing is a crucial part of the discovery process that helps teams compare and evaluate different solutions. It\u2019s especially useful after identifying a target opportunity and picking a few potential ideas to explore. By testing the assumptions behind each idea, teams can uncover risks, validate their hypotheses, and decide which direction is worth pursuing.<\/p>\n\n\n\n It\u2019s also a great tool to use after narrowing down to a final solution, particularly if there are lingering questions about how the solution will work or if there\u2019s still some risk to address. This helps teams refine their approach before jumping into development.<\/p>\n\n\n\n For teams that practice continuous discovery,<\/a> assumption testing becomes part of the regular rhythm. It\u2019s not something you only do once or at a certain stage, it\u2019s instead an ongoing process of testing assumptions, validating ideas, and iterating based on what\u2019s learned.<\/p>\n\n\n\n Bottom line: Assumption testing is an essential tool for making smarter, more informed decisions and keeping product development on track. It\u2019s not a one-and-done trick, it\u2019s something that you should be doing consistently (even if others aren\u2019t so keen on the idea).<\/p>\n\n\n\n A lot of Product Teams don\u2019t test assumptions. That\u2019s pretty absurd, especially after going through why it\u2019s so important. <\/p>\n\n\n\n So why do teams skip through this? <\/p>\n\n\n\n I\u2019ll let you in on a secret, nine times out of ten, it\u2019s not the Product Manager deciding to ignore this. Instead, there are plenty of external factors that could be leading to assumption testing not being a desirable option, with teams instead plowing on without knowing if what they hope to be true is actually true. <\/p>\n\n\n\n Here are some reasons why assumption testing may not be happening, and how you can challenge them: <\/p>\n\n\n\n One of the main reasons why teams skip assumption testing is that they often don\u2019t realize they\u2019re operating on assumptions in the first place. It\u2019s easy to get attached to an idea, which leads to seeing patterns in data that confirm what you want<\/em> to believe – even if the data is telling a different story.<\/p>\n\n\n\n Past success compounds this issue. If a particular approach worked well before, it\u2019s tempting to assume it will work again. But things change, especially in tech, where market dynamics, user behaviors, and expectations evolve rapidly. What worked yesterday may fail spectacularly tomorrow.<\/p>\n\n\n\n To beat confirmation bias, you need to ingrain assumption testing into your routine. Start by actively identifying your assumptions. Ask yourself and your team, \u2018What are we assuming to be true here?\u2019 Surfacing these hidden beliefs is the first step to addressing them and making you think again about moving forward with the assumptions you have. <\/p>\n\n\n\n Some teams may not want to test assumptions because they\u2019re scared of the consequences of finding out that the assumption is wrong. Many would rather go through the development cycle oblivious, than have their faults pointed out. <\/p>\n\n\n\n Even worse, some team members may not feel comfortable questioning someone else\u2019s assumption, due to a lack of psychological safety in the organization. It\u2019s better to keep their mouth shut than to upset the team or rock the boat.<\/p>\n\n\n\n This is a mindset issue and one you should try to address. You need to try and reframe this viewpoint and make it clear that questioning and testing assumptions is super important.<\/p>\n\n\n\n \u201cYou need to make sure that your team feels comfortable speaking up, and that they’re not worried about the consequences of invalidating an assumption. If a Sales Team comes to them and says, \u2018We really need this feature<\/em>\u2019, your team needs to be able to speak up rather than just go and build the feature anyways.\u201d For many PMs, the reality is that they feel they don\u2019t have the time afforded to do assumption testing.\u00a0<\/p>\n\n\n\n In fast-paced environments, PMs are often under intense pressure to keep moving, releasing new features as quickly as possible to hit output targets. There\u2019s a constant push to deliver more, faster, and this often means skipping critical steps like assumption testing.<\/p>\n\n\n\n \u201cPeople aren\u2019t testing assumptions because of time constraints. They don\u2019t have time to test assumptions, so they skip it.\u00a0 The urgency to \u201cjust ship it\u201d can overshadow the importance of validating the assumptions behind a feature or solution. The mindset becomes about checking boxes, rather than checking the data. With so many stakeholders breathing down the neck of the Product Team, it\u2019s easy to fall into the trap of prioritizing speed over evidence. <\/p>\n\n\n\n The fear of slowing down and delaying deliverables can create a false sense of efficiency, leaving assumptions unchecked and untested.<\/p>\n\n\n\n It\u2019s important to recognize that assumption testing doesn\u2019t have to be a lengthy process. In fact, it can save time in the long run by preventing teams from getting too far down a path that may not work. But it requires a shift in mindset. <\/p>\n\n\n\n You need to go from output to outcome<\/a>. Instead of focusing on output – pumping out features – it\u2019s critical to focus on outcomes. Assumption testing isn\u2019t about slowing down, but rather about ensuring that what\u2019s being built will actually deliver the results that matter.<\/p>\n\n\n\n Assumption testing is so important, but not every stakeholder in your organization is going to know that. This can lead to a lot of outside pressure for you to skip this stage and get cracking with building the product. <\/p>\n\n\n\n This puts you in a tricky situation. You know deep down that you should be validating assumptions, but you could be seen as a timewaster if you suggest doing it. That\u2019s why many Product Teams simply don\u2019t. <\/p>\n\n\n\n This is a mindset that you\u2019re going to have to challenge as a Product Manager if you want to ensure your future product development meets the mark. So how do you make the case for assumption testing? <\/p>\n\n\n\n Easy; show them the evidence of why ignoring assumption testing is a bad idea. <\/p>\n\n\n\n There are two <\/strong>ways to do this: If you\u2019ve ignored assumption testing before and it backfired, bring that up the next time you\u2019re asked to ignore it again. Say you\u2019ve made a costly mistake where a stakeholder with shiny object syndrome<\/a> wanted a new feature out and was sure that customers would want it, only for it to be shipped and not get the feature adoption the stakeholder wanted – talk about that. <\/p>\n\n\n\n You\u2019ll strengthen your argument if you can quantify it with hard numbers. Something like: That effort cost us $90,000 in development hours and marketing spend that we could have saved if we ran assumption testing to find out that it wasn\u2019t the feature customers were after. <\/em><\/p>\n\n\n\n That leads us to option number two: Stakeholders might want things done quickly, but the most important thing is getting a return on investment in your efforts. They want to see that the money going into an initiative is being turned into a financial return. <\/p>\n\n\n\n They don\u2019t want to see that money being wasted because an assumption wasn\u2019t checked. You can point that out, highlighting that you don\u2019t know what the return on investment is expected to be. By testing assumptions, you could prove how valuable the idea is, or even find something that\u2019s even more valuable – all by testing assumptions and validating product ideas. This will prevent you from going ahead and making costly mistakes.<\/p>\n\n\n\n Both these points boil down to speaking your stakeholder’s language, an essential tactic when learning how to say no to stakeholders<\/a>. Find out more on how to calculate the ROI of risk-reduction activities like assumption testing in our free eBook: How to Prove the ROI of Product Management.<\/p>\n\n\n\n Assumption testing is key to strengthening your solutions and gives you the clarity needed to prioritize new features and ideas based on solid, fact-driven insights. By testing assumptions, whether you find them to be true or false, you position yourself to make more informed decisions – ones that align with customer needs, business goals, and what\u2019s realistically achievable.<\/p>\n\n\n\n If you discover an assumption doesn\u2019t hold up, you can pivot and explore alternatives that are more likely to succeed. On the other hand, if the assumption proves accurate, you can confidently move forward with your plan.<\/p>\n\n\n\n At its core, assumption testing is about backing up your ideas with real data, helping you refine your product strategy. It\u2019s a critical part of data-driven Product Management<\/a>. Much like validation and prioritization<\/a>, it ensures that the choices you make are focused on what truly impacts your product\u2019s success. In fact, the insights you gain from assumption testing can directly inform how you prioritize features, ensuring that what you build aligns with both customer needs and business objectives.<\/p>\n\n\n\nWhat is an assumption? <\/h2>\n\n\n\n
Teresa Torres<\/strong><\/a>, Product Discovery Expert<\/strong><\/p>\n<\/div><\/div>\n<\/div>\n\n\n\nAssumptions vs risks<\/h3>\n\n\n\n
Customers <\/em><\/strong>WON\u2019T<\/strong> understand how to navigate to that feature. <\/em><\/strong><\/p>\n\n\n\n
Customers <\/em><\/strong>WILL<\/strong> understand how to navigate to that feature. <\/em><\/strong><\/p>\n\n\n\nWhat are the different types of assumptions?<\/h2>\n\n\n\n
\n
![\"Five](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2025\/01\/Five-Types-of-Assumptions-1-1024x687.png\")
<\/figure>\n\n\n\nWhat is an assumption test? <\/h2>\n\n\n\n
Why should you do assumption testing?<\/h2>\n\n\n\n
\n
How do you do assumption testing?<\/h2>\n\n\n\n
![\"the](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2025\/01\/Four-Assumption-Test-Types-1-1024x723.png\")
<\/figure>\n\n\n\n\n
Smoke testing<\/h3>\n\n\n\n
A\/B testing<\/h3>\n\n\n\n
Opportunity solution tree<\/h3>\n\n\n\n
Wizard of Oz testing<\/h3>\n\n\n\n
User shadowing<\/h3>\n\n\n\n
When should you run assumption testing? <\/h2>\n\n\n\n
Why do some teams not perform assumption testing? <\/h2>\n\n\n\n
Confirmation bias<\/h3>\n\n\n\n
Fear of invalidating assumptions <\/h3>\n\n\n\n
Janna Bastow<\/strong><\/a>, ProdPad Co-Founder & CEO<\/strong><\/p>\n<\/div><\/div>\n<\/div>\n\n\n\nTime constraints<\/h3>\n\n\n\n
There\u2019s often a company-wide sense of wanting to push forward and the feeling that they can\u2019t check their validation efforts as it will slow things down. The pressure to deliver can overshadow the want to test assumptions.\u201d
Janna Bastow<\/strong><\/a>, ProdPad Co-Founder & CEO\u00a0<\/strong><\/p>\n<\/div><\/div>\n<\/div>\n\n\n\nStakeholders don\u2019t want you to test assumptions<\/h3>\n\n\n\n
1. Bring up past mistakes <\/strong><\/p>\n\n\n\n
2. Appeal to return on investment<\/strong><\/p>\n\n\n\n![\"\"](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2024\/11\/NEW-ROI-BLOG-BANNER-1024x240.png\")
<\/a><\/figure>\n\n\n\nTurning guesswork into truths<\/h2>\n\n\n\n
![\"The](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2023\/07\/ProdPad-Prioritization-Framework-eBook-1024x240.png\")
<\/a><\/figure>\n","protected":false},"excerpt":{"rendered":"