Expert Q&A: Identifying Assumptions in Product Development
insightsoftware is the most comprehensive provider of solutions for the Office of the CFO. We turn information into insights, empowering business leaders to strategically drive their organization.
Every product leader goes into a new project with untested, hidden assumptions. It’s important to identify and test these unconscious assumptions before you start validating (or invalidating) your product ideas—but how do you do this? Laura Klein, product leader and author of Build Better Products and Lean UX for Startups, recently answered this question and more in an on-demand webinar with Logi Analytics.
How do you define an assumption as it relates to product development?
Laura Klein: An assumption is something that we assume to be true. It is something that we take for granted. We make assumptions about a lot of things when we’re developing a product. We make assumptions about the problem we’re solving, the user we’re solving it for. We make assumptions that our solution is the best one. And some of those assumptions are perfectly fine. We might assume that everybody who is going to use our product has access to the Internet.
The important thing to understand is that assumptions aren’t all the same, and you deal with them very differently. I generally split them into three different types: problem, solution, and implementation. Is there a problem? Is my solution a good way to solve that problem? Can I actually implement that solution?
4 Types of Market and Product Fit Assumptions
Understanding the market and product fit is crucial to developing a successful product. These assumptions focus on ensuring that your product meets real customer needs and fits within the broader market context.
Customer Assumptions
This involves defining who your target customers are and what their needs and pain points are. It’s essential to understand your customers deeply to ensure the product is designed with their specific needs in mind.
Questions to ask:
Who is the target audience for this product?
What are their primary pain points?
What do they value most in a solution?
Problem Assumptions
These assumptions focus on the specific problems your product is designed to solve. It's important to ensure that the problems are significant enough for customers to seek out a solution.
Questions to ask:
What specific problem does this product solve?
How pressing is this problem for the target audience?
Are customers aware of this problem and looking for solutions?
Solution Assumptions
This involves determining whether your product effectively addresses the identified problems. The goal is to validate that your solution is the best way to solve these issues.
Questions to ask:
How does our product solve the identified problem?
Is our solution better or different from existing solutions?
How will customers benefit from this solution?
Market Assumptions
These assumptions relate to the broader market environment, including competition, demand, and market trends. Understanding these factors helps in positioning your product effectively.
Questions to ask:
What is the competitive landscape like for this product?
Is there sufficient demand for this type of solution?
What market trends could impact the success of this product?
4 Types of Product Feasibility and Validation Assumptions
These assumptions focus on whether the product can be successfully developed, brought to market, and effectively used by customers. They help in validating the practical aspects of product development and execution.
Desirability Assumptions
This involves assessing whether customers actually want the product. Even if a problem exists, it’s essential to confirm that the proposed solution resonates with the target audience.
Questions to ask:
Do customers express a strong desire for this product?
How does the product align with customer wants and needs?
Are customers willing to pay for this solution?
Viability Assumptions
These assumptions focus on whether the product can be financially sustainable and profitable. It’s crucial to ensure that the business model behind the product makes sense.
Questions to ask:
Can the product be produced and sold profitably?
What is the pricing strategy, and is it competitive?
How will the product generate revenue?
Feasibility Assumptions
This involves determining whether the product can be developed and brought to market with the available resources and technology. It's about assessing the practical challenges of product development.
Questions to ask:
Do we have the necessary resources and technology to build this product?
What are the potential technical challenges?
How long will it take to develop the product?
Usability Assumptions
These assumptions relate to how easy and intuitive the product is for users. Even the most innovative product can fail if it’s not user-friendly.
Questions to ask:
Is the product easy to use for the target audience?
Have we conducted user testing to identify usability issues?
How can we improve the user experience?
What’s an example of a problem assumption?
I want you to think back to the dark ages before Dropbox. What was the initial problem that they had to validate? They’ve had to make sure that a large number of people had this very specific problem—that they had multiple devices where they wanted to access the same files. Now before you roll your eyes and you say, “of course that was the problem,” I want you to try to imagine a time or a place where that wouldn’t be a problem.
Once upon a time people really only had one device (if they even had that), or they’d have their work computer and their home computer and they just did not share documents. The problem assumptions that Dropbox actually did need to go out and validate—because these were not obvious at that point—were that people have multiple devices and people want to access the same files across those devices. And this is hard for them to do currently. All of those needed to be true to make sure that this particular problem existed.
What about an example of a solution assumption?
I’m thinking back to the beginning of Dropbox again. What was their solution risk? Once you validate the assumption that people do indeed have multiple devices, that they want to access the same files across all of those devices, what do you need to validate about how you’re going to solve that problem? The assumptions they had to validate were that people were willing to download something onto their computers, phones, tablets, etc. And then just trust that those files would be safe in an account in the cloud. It seems really obvious now that it’s done, but it was not originally.
How about an example of an implementation assumption?
In this case, Dropbox had a really interesting challenge. Namely, could they sync files across multiple devices and operating systems quickly and accurately enough to make customers happy? Unlike many products where implementation details might not be merely this hard, this was a fairly non-trivial task, technically speaking. As with the other assumptions, if they hadn’t been able to validate this, Dropbox would not have been nearly as successful.
The implementation assumptions that had to be validated were, the product could not just be built, but built in a way that was quick, accurate and secure across multiple kinds of devices. Also, there’s that last one—that’s the human one and it often gets ignored. Even if you can build the magical syncing software and you know people need it, can you get them to download the software and start using it? Can you get people to upgrade to the paid tier? Can you get people to adopt it? Can you get them to change their behavior?
How do you identify these assumptions?
Here’s a surprisingly easy way to identify assumptions. I want you to fill in this blank: “For my product to succeed, blank must happen.” Or, if you prefer more dire things: “If blank doesn’t happen, my product will fail.” Write down at least 10 assumptions about your product. Each assumption goes on a sticky note. Then you’re going to categorize your assumptions. Write a “P,” “S” or “I” on each of the sticky notes just to indicate what type of assumption it is. Make sure you’re not assuming the solution when you’re stating the problem.
After you’ve figured out what all of your assumptions are, I want you to divide them into a “Will kill” pile and an “Other” pile. “Will kill” means, if this is true, it will literally kill your product. Next, I want you to take all of the “Will kill” items and rank them into the most to least risky. You’re going to have to make some hard decisions here. Here’s the other trick. If you’re resource-constrained, I want you to destroy the “Other” pile. If it will not kill your product, don’t worry about it yet. It’s not important yet. It will be, but it’s not your riskiest assumption.
What makes a product assumption risky? And why does it matter?
The invalidation of one of these assumptions can kill your product or feature. That’s why it matters. If that is not a valid assumption, there is no use for this product. It is gone. Sometimes your riskiest assumption is going to be about the problem you’re solving. Sometimes it’s about your solution for it. Sometimes it’s about the actual implementation. I don’t know which one it is for you. That is something you need to answer for yourself. That is different for every single product, at every single different phase of its creation.
The goal here is to design some way to decrease the risk that you’re building on top of a shaky assumption. And that means testing just how shaky that assumption actually is.