Mastering Assumption Testing in Product Management

Every single one of us has preconceptions: at work, at home, everywhere. We’re making assumptions about things all the time. They’re easy to make and they’re even easier to internalize and believe. That’s why assumption testing is so important. 

Now, making assumptions isn’t all bad all the time. Sometimes they’re spot on because you’ve gathered the evidence to reach that assumption: 

This coffee shop has flickering lights, a low hygiene rating, and the barista just spilled cigarette ash into the espresso machine – you can assume that it’s probably not the best place for a drink.

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’s a charming dog-walking, cake-baking softie. 

As a Product Manager, we can’t 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. 

That’s where assumption testing comes in. 

It’s 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. 

Assumptions can steer you down a blind alley if you act on what you think instead of what you know. But how do you test assumptions? Let’s break down assumption testing so that you’re building on solid ground. 

What is an assumption? 

An assumption is a statement taken to be true without any real proof. It’s something we all do to fill in the blanks when we don’t have all the answers. For Product Managers, assumptions are the invisible threads woven into your ideas, plans, and product strategies. 

They’re often hidden and untested, but they’re 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.

Here’s how Teresa Torres, the authority in assumption testing, defines an assumption:

Now assumptions aren’t always obvious to find. They’re lurking in the background, and you’ll need to properly seek them out to find and understand them. Let’s use a more Product Management specific example to figure out what assumptions might be. 

Say you have a desired outcome: Increase product adoption rates. 

To achieve that outcome, one of many potential opportunities is to get existing customers to refer a friend. 

From that, you then come up with a few solutions to help users do that, like adding a referral share button in your app. 

On the surface, this all sounds like a great, logical idea and a quick win to help get more potential users to your tool. 

But have you spotted the many initial assumptions made in that quick mini-product discovery session? 

Well for starters, we’ve made the assumption that users are engaged enough with your product to want to share – we don’t actually know that. 

We’ve also assumed that customers will use the share button instead of a different alternative, like good old-fashioned word of mouth. 

Plus, we’ve also assumed that anyone receiving a referral will actually open it. 

If all of these are incorrect assumptions, this whole design solution falls, and you’re left wasting time building a new feature that has little to no impact. 

Those three examples aren’t 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.

Assumptions vs risks

Like the well-read Product Manager you are, you may have come across the idea of the four big risks, popularized by Marty Cagan. Risks are statements about your product that you want to prove are false to ensure that your solution is watertight. 

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’re the same thing. 

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. 

So a risk is:

Customers WON’T understand how to navigate to that feature. 

Assumptions are:

Customers WILL understand how to navigate to that feature. 

So they’re opposite sides of the same coin. Ying and Yang. Whatever you call them and the way you phrase them, they’re preconceptions about your product that you’ll want to find the truth about before you implement the solution they’re tied to.

What are the different types of assumptions?

Your assumptions can be grouped into five different categories: 

1. Desirability Assumption: These are the guesses we make about why we think people will want what we’re offering. It’s all about predicting whether your solution will actually appeal to your customers.
2. Viability Assumption: This is where we assume that our solution will work well for the business. Will it bring in revenue? Will it align with company goals? These are the questions hiding under viability assumptions that can be answered with statistical tests.
3. Feasibility Assumption: Here, we’re betting on whether we can actually build what we’ve envisioned. These often involve engineering, but they can also include assumptions about compliance, legal issues, or security.
4. Usability Assumption: These are the assumptions about what our customers are able to do. Can they find the right features? Will they understand how to use them? Can they follow through without frustration?
5. Ethical Assumption: This is where we assume our solution won’t cause harm. If it involves collecting sensitive customer data, we need to ask tough questions about why we need it, how we’ll use it, and whether it’s truly necessary.

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’ve found all related assumptions. 

What is an assumption test? 

An assumption test is where you go out and test the validity of the assumptions that you’ve 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’re accurate. It’s a way to see how bad your riskiest assumptions are and what the impact will be if it’s wrong. 

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. 

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. 

We’ll 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’s found to be untrue. 

Why should you do assumption testing?

Every time you propose a new design solution to achieve a certain outcome, there’s no guarantee it’s going to work. There are many factors that can impact failure. Perhaps you didn’t perform product validation, 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.

If your hypothesis or solution is riddled with assumptions – essentially guesses – you can’t 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’re betting blind.

Assumption testing lets you bet smart. You’re at least betting sensibly and giving yourself greater chances to win. 

Think of it like walking into a casino: without testing, you’re the person who throws their life savings on a single roulette number, hoping for the best. That’s what happens when you launch a feature based on gut instinct instead of insight.

By testing your assumptions, you’re stacking the odds in your favor. It’s like studying the patterns at the table, analyzing probabilities, and realizing that betting on red gives you the best chance of success.

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’t guarantee success, but it will give you the confidence to know you’ve eliminated incorrect assumptions.

Beyond eliminating your riskiest assumptions, assumption testing comes with several other benefits: 

• Saves time and resources: By identifying and addressing flawed assumptions early, you can avoid wasting time, money, and effort on solutions that won’t work.
• Improves stakeholder confidence: Testing your assumptions gives you data to back up your decisions, which builds trust with your team, leadership, and other stakeholders.
• Fosters innovation: By challenging assumptions, you might uncover opportunities or insights you hadn’t considered before, leading to more creative ideas and a more viable product.
• Encourages collaboration: Testing assumptions often involves cross-functional input, such as from Engineering, Design, or Marketing, which ensures a well-rounded approach.
• Sharpens decision-making: The process of assumption testing forces you to think critically and make more informed, strategic decisions.
• Increases customer understanding: Many assumption tests involve customer research, giving you deeper insights into their behavior, needs, and expectations.
• Reduces cognitive bias: Testing removes the guesswork and counteracts bias, ensuring decisions are grounded in evidence, not personal beliefs.

How do you do assumption testing?

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. 

• Prototype tests: Simulate user behavior to evaluate customer response to new product ideas. These tests involve creating a simple version of the product or feature to observe user interactions and gather feedback.
• One-question surveys: Quickly gather insights from customers to validate assumptions. A single, targeted question helps assess customer interest and validate ideas without requiring a long survey.
• Data mining: Analyze existing data to evaluate the risk and feasibility of an assumption. Statistical tests like reviewing past user behavior and engagement data can gauge whether an assumption is realistic.
• Research spike: Test technical feasibility through engineering prototypes. This is a quick, focused effort to explore the technical aspects of a solution, helping you determine if it’s feasible before moving forward.

Of all the potential assumption tests you can do, they’ll more or less fall within these four types. Still, let’s explore some of the standout ways you can test your assumptions.

Smoke testing

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’s like putting out a sign that says, “We’re thinking about this, are you interested?” and seeing who shows up.

ProdPad itself originally validated assumptions through a smoke test, and here we are. We had the assumption that there’d be a demand for a Now-Next-Later roadmapping tool, and a smoke test confirmed there was that demand before the product was fully built.

A/B testing

A/B testing 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.

Let’s 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.

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.

Opportunity solution tree

The Opportunity Solution Tree 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.

The beauty of the Opportunity Solution Tree is that it allows you to visualize how different solutions and assumptions interconnect. It’s 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.

Wizard of Oz testing

The Wizard of Oz test is a clever technique where you create the illusion of a fully functioning product, even though it’s not actually built yet. Typically, this involves using human intervention behind the scenes to simulate the behavior of a product or feature that doesn’t exist yet in its entirety. Kind of like what the Wizard did in the movie that gives this technique its name.

Imagine you’re 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.

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.

User shadowing

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.

This technique helps Product Teams understand the true user experience in complex, real-world environments. It’s 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.

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’s 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.

When should you run assumption testing? 

Assumption testing is a crucial part of the discovery process that helps teams compare and evaluate different solutions. It’s 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.

It’s 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’s still some risk to address. This helps teams refine their approach before jumping into development.

For teams that practice continuous discovery, assumption testing becomes part of the regular rhythm. It’s not something you only do once or at a certain stage, it’s instead an ongoing process of testing assumptions, validating ideas, and iterating based on what’s learned.

Bottom line: Assumption testing is an essential tool for making smarter, more informed decisions and keeping product development on track. It’s not a one-and-done trick, it’s something that you should be doing consistently (even if others aren’t so keen on the idea).

Why do some teams not perform assumption testing? 

A lot of Product Teams don’t test assumptions. That’s pretty absurd, especially after going through why it’s so important.  

So why do teams skip through this? 

I’ll let you in on a secret, nine times out of ten, it’s 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. 

Here are some reasons why assumption testing may not be happening, and how you can challenge them: 

Confirmation bias

One of the main reasons why teams skip assumption testing is that they often don’t realize they’re operating on assumptions in the first place. It’s easy to get attached to an idea, which leads to seeing patterns in data that confirm what you want to believe – even if the data is telling a different story.

Past success compounds this issue. If a particular approach worked well before, it’s 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.

To beat confirmation bias, you need to ingrain assumption testing into your routine. Start by actively identifying your assumptions. Ask yourself and your team, ‘What are we assuming to be true here?’ Surfacing these hidden beliefs is the first step to addressing them and making you think again about moving forward with the assumptions you have. 

Fear of invalidating assumptions 

Some teams may not want to test assumptions because they’re 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. 

Even worse, some team members may not feel comfortable questioning someone else’s assumption, due to a lack of psychological safety in the organization. It’s better to keep their mouth shut than to upset the team or rock the boat.

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.

Time constraints

For many PMs, the reality is that they feel they don’t have the time afforded to do assumption testing. 

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’s a constant push to deliver more, faster, and this often means skipping critical steps like assumption testing.

The urgency to “just ship it” 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’s easy to fall into the trap of prioritizing speed over evidence. 

The fear of slowing down and delaying deliverables can create a false sense of efficiency, leaving assumptions unchecked and untested.

It’s important to recognize that assumption testing doesn’t 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. 

You need to go from output to outcome. Instead of focusing on output – pumping out features – it’s critical to focus on outcomes. Assumption testing isn’t about slowing down, but rather about ensuring that what’s being built will actually deliver the results that matter.

Stakeholders don’t want you to test assumptions

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. 

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’s why many Product Teams simply don’t. 

This is a mindset that you’re 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? 

Easy; show them the evidence of why ignoring assumption testing is a bad idea. 

There are two ways to do this:

1. Bring up past mistakes 

If you’ve ignored assumption testing before and it backfired, bring that up the next time you’re asked to ignore it again. Say you’ve made a costly mistake where a stakeholder with shiny object syndrome 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. 

You’ll 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’t the feature customers were after. 

That leads us to option number two:

2. Appeal to return on investment

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. 

They don’t want to see that money being wasted because an assumption wasn’t checked. You can point that out, highlighting that you don’t 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’s even more valuable – all by testing assumptions and validating product ideas. This will prevent you from going ahead and making costly mistakes.

Both these points boil down to speaking your stakeholder’s language, an essential tactic when learning how to say no to stakeholders. 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.

Turning guesswork into truths

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’s realistically achievable.

If you discover an assumption doesn’t 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.

At its core, assumption testing is about backing up your ideas with real data, helping you refine your product strategy. It’s a critical part of data-driven Product Management. Much like validation and prioritization, it ensures that the choices you make are focused on what truly impacts your product’s 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.

With the assumptions in your solutions tested, you can properly prioritize them to work out which initiative has the greatest value. Learn more about the different ways you can tackle prioritization in our Product Managers Guide to Prioritization Frameworks.