Assumptions – "I would do as a user"…

It has happened to you that you are creating new functionality, or just the whole product, and someone will come up with the statement: "I would need or appreciate this as a user." But be careful with these sentences.

Michal Voják

Co-founder / userUP Leader

Why is this such a big problem?

When creating a new functionality or an entire product, it is extremely important to know that what you are creating is based on the real needs of your users.

Let's start with a story. Martin is a manager responsible for developing a platform for selling theater tickets. Martin comes to a meeting and says: "I often look at older information, such as made payments or older articles in magazines, etc. So I would appreciate, as a user, if I could search in the history of performances on our platform. How can we design it in our application?"

And now a question for you: should a team immediately start creating a new functionality? Or is something wrong with this example?

What if our manager Martin is looking for different information in the history but does he do it in this case as well? What if Martin doesn't buy tickets through our platform and only projects his general behavior into it? And even if he was in our target group, can the behavior of one individual, who is also very immersed in the problem, be applied to the behavior of the entire target group?

And that's exactly what you can't say. I am not saying that our manager Martin can't be right. But it is necessary to verify whether this is really the case. It is not appropriate to consider our own assumptions as generally valid. The fact that I, as a user, would welcome something specific does not mean that it corresponds exactly to the behavior of the other users.

During development, you can consider user behavior, the comprehensibility of the information you communicate, business potential or functionality, and technical complexity. However, all these considerations need to be understood as assumptions, and it is necessary to work with them accordingly.

The story of manager Martin is not a description of an existing project but a description of real situations.

Assumption, opportunity, and solution – what is the difference?

Assumption

It is a situation in which you expect something to work in some way. For example; that your users behave in a particular way. It is advisable to talk about assumptions whenever you are unsure that it is a proven fact. You can expect/assume that your website users need to filter published blog articles by date. In case if it is not a verified fact, but only as a precondition, it is necessary to talk about the importance of this functionality or the truth of this assumption.

Example of an assumption: Users need to search for already played performances by date.

Opportunity

We are talking about an opportunity for already proven needs of the users. So we know that we are not talking about our own assumption as we have verified this information directly with users during user research, or it is a previously verified assumption.

Example of an opportunity (a user told us): "I would like to find the show we have been to, to see how much the ticket cost."

Solution

When it comes to specific functionality in an application or website, we are talking about a solution. If we propose a solution, we should ideally know that this solution is based on a real opportunity that makes sense for the project. It is good not to stick to only one solution that comes to mind as there might be other solutions that may be better from a business perspective. Whether it's a benefit directly for users, business, or advantages in terms of ease of creation, you can learn more about this topic here.

Example of a solution: We will create a performance history with a filter „the date from – to“.

How to work with assumptions

The first team meeting takes place before we start working on a project. And here is room for assumptions. We write down all the assumptions on the individual tickets to be able to work with them. The most common form of creating as many prerequisites as possible is brainstorming.

To create tickets:

  • put only one assumption on each ticket,
  • the assumption should always be an understandable statement; it should never be written as a question,
  • try to avoid entries like "need a filter," but rather "users need to find already played performances by date,"
  • don't debate whether this is the right or wrong assumption; write down everything the team can think of. 

Assumptions are not just what users do. We can divide them into several groups according to what we expect and what we want to verify.

Basic types of assumptions

  • Disability – it will bring benefits to the company
  • Viability – it meets the needs of users
  • Feasibility – we can create it
  • Usability – users can use it (used especially when we want to verify the usability of a wireframe or prototype)

It is helpful to use different colored tickets when writing assumptions to know what type of assumption it is.

Assumption map

Assumption mapping is a method of working with assumptions and then prioritizing them. It is possible to use this method during the entire product, opportunities, or various solutions.


You take individual tickets and place them on a chart.

The X-axis shows how confident you are that the assumption is valid. In other words, you have evidence for this assumption to be true.


The Y-axis shows the importance of the given assumption. It's okay if every ticket is important to you, but it's good to learn how to compare them to place them accordingly.

Thanks to this, you can prioritize individual assumptions well. The second method for determining importance is to rank the assumptions based on how much this assumption threatens you or how much money it earns you.

What does each quadrant mean?

Plan (top left)

These are important things that we have already verified. These assumptions can be processed immediately. You should compare them with your roadmap and backlog. It can also be said that there are no assumptions in this quadrant but only true findings (project opportunities).

Evaluation (top right)

Important and unknown. This is a quadrant in which we should invest the most effort. These are assumptions that need to be verified. Verification is performed by Value Proposition testing. These include A / B testing, Fake Door Tests, or Solution Interviews.

Defer (bottom left)

You will find unimportant and familiar assumptions there. It's best not to pay attention to these.

Generate (bottom right)

The last quadrant contains unimportant and unknown assumptions, which could show something important. If you have the time and have already created the Evaluation quadrant, you can generate new and interesting findings from them with the help of user research (usually a Solution Interview, which focuses on understanding the problem).

Prerequisites for a new product

Prerequisites are also an excellent tool for validating the information you use to validate your product. We often talk about assumptions or hypotheses if we use Value Proposition Canvas or Business Model Canvas. Therefore, it is appropriate to build on these methods by mapping the assumptions to validate what types of information we are working with, whether we need to research or validate them more, or on the contrary, we have enough information that can be seen as an opportunity.

While Value Proposition Canvas serves to verify user benefits, Business Model Canvas offers assumptions for users, feasibility, or corporate benefits.

Conclusion

Talking about assumptions, opportunities, and solutions is very beneficial. And it doesn't matter if you are creating a new functionality or a whole new product. You will find out if you have enough information to decide how to develop it correctly.

Prerequisites are a suitable tool for all important phases. Whether you are talking about validating an idea for a new product, you need to achieve new goals, look for a new opportunity on an existing project, or verify the functionality of one of your solutions.

Resources

userUP helps you with

About the author

Michal Voják

Co-founder / userUP Leader

Michal is a pioneer in product discovery! He is behind the idea of this tool.

Related articles

Do you find yourself sitting with a client or at a team meeting where you discuss users' problems…

Focus on understanding the problem, not on the…

An in-depth interview is primarily used for a more detailed examination of a research problem…

How to conduct an in-depth interview

Product Discovery is a collection of methods that help to create quality products with a strong…

What is Product Discovery, and how to create…