Assumption mapping is writing down every assumption under your idea and scoring each one on two things: how badly you need it to be true, and how easily you could find out. The ones that score high on both are what you go and research first.

It takes about an hour, and it replaces the much worse method, which is researching whatever you happen to think of first.

The two axes

The first one is the risk axis, and you can think of it as the key assumption axis. High means the product is going to fail if you are wrong.

The second one is how easy the assumption is to validate. High means you could find out this week, usually by asking people.

Score each assumption one to five on both. I use five and five for something I can settle by simply asking someone, because it is that easy.

What you are aiming for

You want the ones that score high on both axes: the assumptions that would sink the product, and that you could settle this week. That corner is where research pays for itself fastest.

Low risk is not a problem. It is not something that will make or break your app, so finding out about it does not change any decision you are going to make. Skip it, even though it is comfortable and easy.

Risky and hard to validate is the corner to be honest about. You cannot ignore those, but you also cannot answer them with a conversation, so they need a different plan: a concierge test, a prototype, a pre-sale, something where you watch behaviour instead of asking a question.

A worked example

For the school reminder app, my assumptions went like this.

We can use an app to solve this problem. Super risky, because if I am wrong the product fails.

Parents are the ones getting the kids to school. I could be wrong about that. It could be that the kids are getting themselves to school, in which case the problem needs to be solved with the kids instead, and that changes everything.

Parents want their kids to get to school on time. Super low risk, because of course they do. Easy to verify, middling, because we can just ask people if they care. Low risk means it does not go to the top of the list regardless.

The ones that decided what I researched first were the risky ones I could actually ask about.

Write down your reasoning, and do it with someone

When I place something on the map I say out loud why I put it there. You always have to think about your reasoning.

This is an activity that is best done with more than one person, because you want to hear other people's reasons. They are going to be thinking about things you did not think about, and on your own idea you are the least reliable person in the room.

Cover more than one kind of assumption

You could have an assumption about the problem. You could have an assumption about the people. You could have an assumption about the solution. Try to come up with the kinds of assumptions you would need to validate across all of those, rather than five versions of the same belief.

You will drop this step eventually

As you get more familiar and practised, you will find you start to drop certain parts of the process. You might not actually do the mapping, because you can look at your list of assumptions and just see which one matters.

That is fine, and it comes after doing it the long way enough times that the judgement is real.

Keep reading

What Are Key Assumptions and How Do I Find Mine?

How Do I Validate an App Idea Without Building It?

Validation Before Building vs. Building Then Pivoting: Which Is Less Expensive?

Learn this with me

Assumption mapping is class 1 of From Passion to Product, my free six-week live course. It comes in the very first class, alongside problem statements and the Five Whys, because the assumptions are what the next five weeks of research go and check.

You map the ones under your own idea that night, and the riskiest of them are what your research is pointed at.

Join the waitlist for the next free cohort. The App Strategy Workbook carries every step of the course with its exercises, if you would rather work through it alone.