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.
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.
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:
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:
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.
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:
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:
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:
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:
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:
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.
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:
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.
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:
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.
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.
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:
The first step in assessing initiative viability is to review your current business model and see how it would fit there:
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.
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:
A great solution helps you maintain and expand your competitive edge on the market.
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:
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.
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
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).
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.
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.
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 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.
A data product manager (DPM) is a type of PM who specializes in managing products that are heavily reliant on data.
Dan Lawyer, CPO at Lucid Software, talks about his philosophy that without autonomy, there is no leverage as a leader.
A product owner sets the direction, keeps the team focused, and ensures that the product becomes a source of value.
Suhas Reddy discusses the principles of human-centric design and its emphasis on delivering products in the context of the customer.
Learn more →
