Bart Krawczyk Learning how to build beautiful products without burning myself out (again). Writing about what I discovered along the way.

4 types of product assumptions and how to test them

7 min read 2148 102

4 Types Of Product Assumptions And How To Test Them

Understanding, identifying, and testing product assumptions is a cornerstone of product development.

To some extent, it’s the primary responsibility of a product manager to handle assumptions well to drive product outcomes.

Let’s dive deep into what assumptions are, why they are critical, the common types of assumptions, and, most importantly, how to test them.

Table of contents

What are product assumptions?

Product assumptions are preconceived beliefs or hypotheses that product managers establish during the product development cycle, providing an initial framework for decision-making. These assumptions, which can involve features, user behaviors, market trends, or technical feasibility, are integral to the iterative process of product creation and validation.

Assumptions guide the prototyping, testing, and adjustment stages, allowing the team to refine and improve the product in response to real-world feedback.

Leveraging product assumptions effectively is a cornerstone of risk management in product development because it aids in reducing uncertainty, saving resources, and accelerating time to market. Remember, a key part of a product manager’s role is to continuously challenge and validate product assumptions to ensure the product remains aligned with consumer needs and market dynamics.

Whatever you do, you don’t do it without a reason. For example, if you are building a retention-focused feature to drive revenue, you automatically assume that the feature will improve your revenue metrics and that it’ll deliver enough value for users that they’ll retain better.

In short, assumptions are all the beliefs you have when pursuing a particular idea, whether validated or not.

Why are assumptions important for product managers?

You can’t overemphasize the importance of assumptions in product management. For PMs, they are the building block of everything we do.

Ultimately, our job is to drive product outcomes by pursuing various initiatives we believe will contribute to the outcome. We decide which initiatives to pursue based on the beliefs we hold:

Product Assumptions Diagram

If our assumptions are correct, the initiative is a success, and there should be a tangible impact on the outcome. If they turn out wrong, we might fail to drive the impact we hope to see. We may even do more harm than good.

Because one initiative is often based on numerous assumptions, and various solutions can share the same assumptions, testing individual hypotheses is faster and cheaper than testing whole initiatives:

Validating Product Assumptions About Potential Solutions

Moreover, testing an initiative with multiple unvalidated assumptions makes it hard to distinguish which hypotheses contributed to its success and which didn’t. Testing shared assumptions can help us raise confidence in multiple solutions simultaneously.

In most cases, you’re better off focusing on testing individual assumptions first than jumping straight into solution development.

4 types of product assumptions

There are various types of assumptions. However, as a product manager, there are four important assumptions that you must understand and learn how to test:

  1. Desirability assumptions
  2. Viability assumptions
  3. Feasibility assumptions
  4. Usability assumptions

1. Desirability assumptions

When you assume solution desirability, you are trying to answer the question, “Do our users want this solution?”

After all, in the vast majority of cases, there’s no reason to pursue an initiative that isn’t interesting for your end-users.

Desirability assumptions include questions such as:

  • Does this problem solve a painful enough problem?
  • Is the problem we are solving relevant to enough users?
  • Is our proposed way of solving the problem optimal?
  • Will users understand the value they can get from this solution?

2. Viability assumptions

Viability determines whether the initiative makes sense from a business perspective.

Delivering value for users is great, but to be truly successful, an initiative must also deliver enough ROI for the business to grow and prosper. Of course, you might work for an NGO that doesn’t care about the revenue.

Viability assumptions include questions such as:

  • Will we see a positive impact on business metrics?
  • Does this initiative fit our current business model?
  • Does the solution align with our long-term product strategy?
  • Can we expect a satisfactory return on investment?

3. Feasibility assumptions

Even the most desirable and viable solutions are only relevant if they are possible to build, implement, and maintain.

Before committing to any direction, ensure you can deliver the initiative within your current constraints.

You can assess feasibility by answering questions such as:

  • Does our current technology stack allow such an implementation?
  • Do we have the resources and skillset to proceed with this initiative?
  • Do we have means of maintaining the initiative?
  • Can we handle the technical complexity of this solution?

4. Usability assumptions

Even after you implement a desirable, viable, and feasible solution, it won’t drive the expected results if users don’t understand how to use it.

The more usable the solution is, the more optimal outcomes it’ll yield.

Focus on answering questions such as:

  • Are our users aware that the new solution exists?
  • Do they understand what value they can get from it?
  • Is it clear how to find and use the solution?
  • Is there friction or needless complexity that might prevent users from adopting the solution?

How to use an assumption map

An assumption map is a powerful technique that can help you identify, organize, and prioritize assumptions you make with your initiatives.

Check out our assumption mapping article for more details if that sounds valuable.

For the purpose of this article, I’ll assume you’ve already identified and prioritized your assumptions.

Testing product assumptions

Now let’s take a look at some ways you can test your assumptions. While the best method depends heavily on the type of assumption you are testing, this library should be a solid starting point:

Testing desirability

There’s no way to test desirability without interacting with your users. Get out of the door, one way or another, and see if the solution is something your users truly want.

Techniques for assessing the desirability of a solution include:


One of the fastest and most insightful desirability validation techniques is to interview your target users.

You don’t want to ask users upfront because doing so produces skewed answers. Instead, you want to understand the user’s problem, how they describe it, and the most significant pain points they have. You can then look at your proposed solution and judge whether it could potentially solve the problems users mentioned.

Landing pages

You can create a product landing page even if you don’t yet have the product. By monitoring the engagement on the site, you can gauge the overall interest in the solution; if users bounce from
the site after a few seconds, they are probably not interested.

You can take it a step further and include the option to subscribe to a waitlist. Signing up would be a powerful signal that users are genuinely interested.


If you are building a B2B solution, you can try to actually sell it to potential clients. There are three ways to approach this:

  • Mock sales — A sales simulation when you try to sell the solution but don’t commit to an actual sale
  • Letter of intent — You ask your potential client to sign a letter of intent to buy the solution once it’s live
  • Actual sale — In some cases, you might be able to finalize the sale before the product is even live, with an option to revert the sale if you decide not to pursue the direction after all

If people are willing to pay for the solution before it is even created, the desirability is really high.


Crowdfunding is a presale option for mass B2C consumers. However, it’s viable mostly for brand-new products.

By promoting your idea on sites like Kickstarter, you can not only gauge overall desirability but also capture funding to improve the viability of the idea.

Alpha and beta testing

The most powerful yet expensive way of testing desirability is to build a minimal version of the solution. You can then conduct alpha and beta tests to see actual user engagement and gather real-time feedback on the further direction.

Due to the cost, this method is recommended after you have some initial confirmation with other validation techniques.

Testing viability

You can test the viability of assumptions by taking a closer look at the business side of things to evaluate whether the initiative fits well or contradicts with other areas.

Techniques for testing the viability of your product include:

Business model review

The first step in assessing initiative viability is to review your current business model and see how it would fit there:

Business Model Review Template

Does the solution connect well to your current value proposition and distribution channel? Do you have key resources and partners to pull it off? Does it sync well with key activities you are performing?

Ideally, your initiative will not only not disrupt your business model but also contribute to it as a whole.

Strategy canvas

A viable solution helps you build a competitive advantage in the market. One way to evaluate viability is to map a strategy canvas of your competitive alternatives and judge whether the initiative will help you strengthen your advantage or reduce your weaknesses:

Strategy Canvas Example
Source: rrgraph

A great solution helps you maintain and expand your competitive edge on the market.

Business case

With basic viability tested, it’s worth investing some time to build a robust business case.

Gather all relevant input and try to build well-informed projections:

  • How many people can you reach?
  • How expensive the solution is going to be?
  • What’s the expected long-term revenue gain and maintenance cost?
  • What is the anticipated ROI over time?

A strong business case will also help you pitch the idea to key stakeholders and compare the business viability of various initiatives and solutions to choose the most impactful one.

Testing feasibility

Validating whether a solution is possible to implement usually requires a team of subject matter experts to do a deep dive into potential implementation details. Two common approaches are

Technical research

This step includes researching various implementation methods and limitations to determine whether a solution is feasible.

For example, suppose you are considering a range of trial lengths for various user segments in your mobile product. In that case, you might need to review app store policy and limitations to see if it’s allowed out of the box or if any external solution is necessary.

If an external solution is needed, you might investigate whether there’s an SDK supporting that or it requires building from scratch (thus increasing complexity and reducing the viability of the solution).

Proof of concept (PoC)

For more complex initiatives, you might need to develop a proof ofconcept.
One could call it a “technical MVP”. It includes building the minimal version of the most uncertain part of the solution and evaluating if it even works.
Proof of concept might vary from a few lines of code for simple tests to a fully-fledged development for the most complex initiatives.

Testing usability

Usability is the most straightforward thing to test. You want to put the solution in front of the user to see if they understand how to use it and what potential friction points are.

There are two common ways to do this:


Prototypes are at the forefront of usability testing. Build a simulation of the experience you want to provide, ask the user to finish a specific task, and observe how they interact with
the product.

Depending on the level of uncertainty and the investment you want to make, prototypes can vary from quick-and-dirty paper prototypes to fully interactive, no-code solutions.

Analytics review

If you are already at an MVP stage, you have the benefit of having actual data on how the solution is used. Analyze this data closely to evaluate how discoverable the product is, how much
time it takes for users to complete specific tasks, and what are the most common dropout moments.

Combining quantitative data review with qualitative insights from prototypes will help you validate most of your usability assumptions.


Every initiative you pursue is based on a set of underlying assumptions — that is, a set of preconceived beliefs we have when deciding which direction to pursue.

Validating these beliefs is a critical part of product management. After all, it’s easier and cheaper to test individual assumptions than to test solutions as a whole.

Make sure you identify your main desirability, viability, feasibility, and usability assumptions and test them before committing to a fully-fledged solution.

I recommend you store the insights from assumptions tests for future reference. Many solutions tend to share similar assumptions, so the insights might help you speed up your validation process in the future.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

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.

Bart Krawczyk Learning how to build beautiful products without burning myself out (again). Writing about what I discovered along the way.

Leave a Reply