Assumption testing is at the heart of what good continuous discovery teams do week over week. It’s how we evaluate which ideas will work and which won’t.
But before we can test our assumptions, we have to identify them. That’s not always as easy as it sounds.
Assumptions are beliefs that need to be true in order for our ideas to succeed. The challenge is that we need to be able to see our assumptions before we can test them.
It can be hard to see our own assumptions. Oftentimes they are core beliefs that we rarely think to question. It’s a bit like asking a fish about water.
It can be hard to see our own assumptions. Oftentimes they are core beliefs that we rarely think to question. It’s a bit like asking a fish about water. – Tweet This
There are five types of assumptions that product teams tend to make: desirability, feasibility, usability, viability, and ethical.
To help us see our own assumptions, it helps to think about the types of assumptions that product teams tend to make. We tend to make assumptions in five different categories:
- Desirability assumptions
- Viability assumptions
- Feasibility assumptions
- Usability assumptions
- Ethical assumptions
To illustrate these five types, let’s set up a context for our examples.
To further explore the idea of assumptions, let’s imagine a product team that works for a newspaper and has the desired outcome of increasing new readers.
Suppose I work for a local paper and my product team is responsible for bringing in new readers (our outcome). When interviewing readers, we uncovered a common desire: “I know someone who should read this article.”
We’ve chosen this as our target opportunity and have generated three potential solutions:
- Add social media share buttons that allow people to quickly share the title and URL of the article.
- Add the option to email the full text of the article to someone.
- Add the option to text someone the title and URL of the article.
Each of these solutions depend on a number of assumptions that need to be true in order for each solution to succeed.
We can start with a broad assumption: Our readers want to share articles with other people.
All three of our ideas depend upon this assumption. This assumption assumes that our target opportunity (“I know someone who should read this article”) expresses a real desire.
But we can also enumerate many more specific assumptions:
- Our readers want to share this article with people on Facebook.
- Our readers will notice the option to share an article.
- We can format the full article text appropriately to be shared via email.
- The person receiving the shared article will be interested in the article.
- If the person receiving the article doesn’t have a subscription, they’ll buy a subscription to get access to the article.
- If the person receiving the article doesn’t have a subscription, they won’t be annoyed with the sharer since they can’t access the article.
- Our readers won’t share articles with people who might be offended by the content.
- Our readers will share articles via SMS with enough non-subscribers (who end up subscribing) to offset the cost of SMS.
- Our emails will get through spam filters and into readers’ inboxes.
- Our readers will know the email address of the person they want to share the article with.
We could enumerate dozens more. But this should give you an idea of what assumptions look like.
What Are Desirability Assumptions?
Desirability assumptions include why we think someone will want our solution as well as why we think our customers are willing to do what they need to do to get value from the solution.
Desirability assumptions are the assumptions we make about why we think someone will want our solutions.
It’s easy to fall into the trap of thinking there is only one desirability assumption that comes in the form of: Our customers want our solution.
Many teams try to test this assumption by simply asking customers, “Do you want this?” But long-time Product Talk readers know that this isn’t a reliable way to collect feedback. Humans (all of us) don’t know what we’ll buy/use/want in the future, even when we think we do. See this article for more on why.
Instead of asking questions that lead to unreliable answers, we can run a demand test to learn more about this assumption. For example, we might launch a landing page that explains the benefits of our new solution and ask people to sign up to be notified when it’s available. If people are willing to give us their email address, that’s a signal (albeit a weak one) that they might want our solution.
The challenge with just testing demand is that it’s not the only type of desirability assumption that we want to test. It’s not enough for our customers to want our solution; they also have to be willing to do the things we need them to do to get value from the solution.
Desirability assumptions also include the assumptions we make about what our customers are willing to do to get value from our solutions. If they aren’t willing to do the things we need them to do, then our idea is dead in the water.
For example, I might want to share an article with a friend, but if I’m not willing to look up that friend’s email address (or in a case where there’s even more friction, text my friend to ask for their email address), it doesn’t matter how much I want to share the article with them, I’m not going to do it.
So desirability assumptions include assumptions about why we think our customers want our solution and our assumptions about what we think they will be willing to do.
Desirability assumptions include assumptions about why we think our customers want our solution and our assumptions about what we think they will be willing to do. – Tweet This
From our example, the following assumptions are desirability assumptions:
- Our readers want to share this article with people on Facebook.
- The person receiving the shared article will be interested in the article.
What Are Viability Assumptions?
Viability assumptions address why we think a particular solution will be good for our business.
Viability assumptions are the assumptions we make about why a particular solution will be good for our business.
Viability assumptions are the assumptions we make about why a particular solution will be good for our business. – Tweet This
If we are an outcome-driven team, this might be as simple as enumerating our assumptions around why we think our solutions will address our target opportunity in a way that drives our outcome.
But with viability assumptions we also need to enumerate our assumptions around the economics of our solution. For example, a customer might want a solution (desirability), but they aren’t willing to pay for it. This solution won’t be viable.
We also need to evaluate the costs of delivering our solution. For example, if we are planning to share articles via SMS, we’ll need to pay carrier fees to deliver those messages. We’ll need to enumerate our assumptions around why we think the benefit of acquiring new readers will offset the costs of sending the messages.
From our example, the following assumptions are viability assumptions:
- If the person receiving the article doesn’t have a subscription, they’ll buy a subscription to get access to the article.
- Our readers will share articles via SMS with enough non-subscribers (who end up subscribing) to offset the cost of SMS.
What Are Feasibility Assumptions?
Feasibility assumptions address why we think we can build our solutions, and can include several elements like legal, compliance, security, organizational, and technical concerns.
Feasibility assumptions are the assumptions we make about why we think we can build our solutions.
Feasibility assumptions are the assumptions we make about why we think we can build our solutions. – Tweet This
The most common feasibility assumptions are engineering assumptions. Do we have the necessary skills, knowledge, and ability to build these solutions? Does the necessary technology exist?
I don’t limit feasibility to technically possible, though. I also like to examine compliance, legal, and security assumptions as part of feasibility assumptions. We can and should enumerate our assumptions around why legal or compliance will sign off on our solution. Or why our solution won’t expose any security risks.
I might even push feasibility to include assumptions around why we think this solution is feasible in our organization. Every organization has solutions they would never consider. We’ve all heard, “That will never work here.” If an organization won’t sign off on it, then in my view, it’s not feasible.
Some people argue that feasibility should be limited to technical feasibility and that these other assumptions are really viability assumptions. It doesn’t really matter how we categorize the assumptions. It matters that we generate them and then evaluate the risk that they carry.
It doesn’t really matter how we categorize our assumptions. It matters that we generate them and then evaluate the risk that they carry. – Tweet This
So regardless of how you categorize them, be sure to generate technical, legal, compliance, security, and organizational feasibility assumptions.
The following assumptions from our example are feasibility assumptions:
- We can format the full article text appropriately to be shared via email.
- Our emails will get through spam filters and into readers’ inboxes.
What Are Usability Assumptions?
Usability assumptions allow us to consider how customers will find what they need, understand what we need them to do, and be able to do those things.
Usability assumptions are the assumptions we make about what our customer is able to do. As we design our solutions, we assume that our customers will be able to find what they need, that they’ll understand what we need them to do, and that they’ll be able to do those things.
We assume that our customers will be able to find what they need, understand what we need them to do, and be able to do those things. – Tweet This
Usability encompasses accessibility, but it’s not limited to accessibility.
In our example, our solutions won’t work if readers don’t notice the option to share an article. It also won’t work if they don’t understand how it works. Every bit of friction in the process reduces the chance our customer will get value from the solution.
The following assumptions from our example are usability assumptions:
- Our readers will notice the option to share an article.
- Our readers will know the email address of the person they want to share the article with.
What Are Ethical Assumptions?
Ethical assumptions allow us to consider whether there’s any potential harm in offering our proposed solutions.
Ethical assumptions are the assumptions we make about why we think there’s no potential harm in offering our proposed solutions.
Ethical assumptions are the assumptions we make about why we think there’s no potential harm in offering our proposed solutions. – Tweet This
This is a big category and can include the assumptions we make about our ideal customer profile and our data collection and usage needs. Depending on the type of service that we offer, it might include assumptions we make about trust and safety related to user-generated content.
For example, when defining my ideal customer profile, I want to generate the assumptions I’m making about my target customer. What attributes am I prescribing to them? Who am I including and who am I leaving out (intentionally or unintentionally)?
If my solution requires that I collect personally identifiable data about customers, then I need to examine my assumptions around why I need that data, how I’ll use it, how I’ll store it, and who I’ll share it with. I’ll also need to examine my assumptions around how transparent I’ll be about those practices.
I also need to consider the social dynamics that might come into play. Sharing an article might seem innocuous, but what happens if a reader shares an article that the recipient is offended by? Are we responsible for the harm to that relationship? I can’t tell you the right answer, but we should consider these risks.
The following assumptions from our example are ethical assumptions:
- If the person receiving the article doesn’t have a subscription, they won’t be annoyed with the sharer since they can’t access the article.
- Our readers won’t share articles with people who might be offended by the content.
How Is This Different from Marty Cagan’s Four Risks?
People often ask me about the difference between the assumption types and Marty Cagan’s four risks.
Astute readers will notice that these assumption types overlap quite a bit with Marty Cagan’s four areas of risk: value, viability, feasibility, and usability.
Conceptually, we are talking about the exact same ideas. In practice, I have found that positioning these as assumption types makes it easier to know what to test.
For example, if as a product team, we talk about viability risk without getting specific, I’m not sure what I need to test or how to mitigate the viability risk.
If instead, we enumerate our viability assumptions, I can now assess the risk of each assumption and know exactly what I need to test.
Marty also talks about value risk, whereas I talk about desirability assumptions.
Marty reviewed an early copy of Continuous Discovery Habits and was critical of me using desirability instead of value. He argued that desirability conflates usability and customer value. He also suggested that B2B products don’t need to be desirable, but simply usable and necessary.
After considering Marty’s feedback, I decided to keep the language as is.
To me, desirability and usability are distinct. I can desire something that isn’t usable. Apple Home is a great example of this. I want to connect all of my smart devices in one app, but I run into so many usability issues with the app that it simply doesn’t work for me. This is a usability issue, not a desirability issue.
I agree that B2C apps have more desirability risk than B2B apps, but desirability is still important in the B2B space. Every B2B company that has made the sale but lost the renewal due to a lack of adoption understands that desirability is important.
Finally, I find that the term “desirability assumptions” is more helpful in the context of using story maps to generate assumptions. Explaining how that works is a whole other blog post that I’ll save for another day.
At the end of the day, I don’t think this language difference matters. Marty Cagan and I are mostly aligned on the concepts. I recommend that teams adopt the language that works for them.
If you want to learn more about how to generate assumptions across all five of these categories, check out our Identifying Hidden Assumptions course.
The post Evaluating Solutions: The 5 Types of Assumptions that Underlie Our Ideas appeared first on Product Talk.
Evaluating Solutions: The 5 Types of Assumptions that Underlie Our Ideas was first posted on October 11, 2023 at 6:00 am.
©2022 “Product Talk“. Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please let us know at support@producttalk.org.
