A key assumption is something you believe about your users and their problem that your whole product rests on. The way to tell if you have one is to ask: if I am wrong about this, is my product going to fail?

If the answer is yes, it is a key assumption. If the answer is no, it is worth knowing but it is not what you should be spending your research on.

An example of mine, including the part where I was wrong

I had an idea for an app that reminds parents about school start times. My key assumption was that parents are late getting their kids to school because they are too busy and they need a reminder.

That is a key assumption, because if I am wrong the product fails. And I was wrong. Nobody is going to get an app that reminds them about the school time, because they know when school is. That is not the problem.

Better to find that out by writing the assumption down and checking it than by building the app.

The mistake almost everyone makes

The most common thing that comes up with key assumptions is that people write down feature assumptions and call them key assumptions.

"The app must have push notifications" is not a key assumption, unless the only thing your app does is provide push notifications. That is a feature. It is a design detail. If the push notifications do not exist, the problem still exists.

The test again: would being wrong kill the product, or would it just mean you build the thing a different way? Only the first one counts.

What a real list looks like

For a freelancer invoice app, the list reads: I can solve this problem if these are true.

• Freelancers lose track of unpaid invoices
• Freelancers feel uncomfortable following up with clients
• Existing accounting tools are too complex for the simple tracking a freelance designer needs

Each one is about the problem and the people, not about the app. Each one could turn out to be false. That is what makes the list useful.

Low risk is not a problem

Low risk is not something that will make or break your app. If everything on your list is low risk, you have not found your key assumptions yet, you have found a list of things you are comfortable about.

Push yourself to write down the one that would hurt to be wrong about. That is the one worth the research time.

The assumptions you cannot validate

Sometimes you have key assumptions you cannot verify with research, especially the ones about money.

"They are ready to pay for an app" is definitely a key assumption, because if they are not, the app flops. It is also very hard to validate. People might say they will pay and then not. They might say they would spend a hundred dollars on this, and when push comes to shove they only want to spend twenty.

If your app relies on an assumption like that being true, you are going to have a hard time, because you just cannot check it. So you need a different key assumption, or a way to test the money question with behaviour instead of with a question.

Then what

Once you have the list, you rank them, by how risky they are and how easy they are to validate. That is assumption mapping, and it is what decides which piece of research you do first.

Your strategy can sound great and your base assumptions can still be wrong. You could be completely wrong about how a group of people will react. Writing the assumptions down is what turns that from a surprise into a plan.

Keep reading

Assumption Mapping: How to Decide What to Test First

How Do I Validate an App Idea Without Building It?

How to Write a Problem Statement for Your App

Learn this with me

Key assumptions are class 1 of From Passion to Product, my free six-week live course, in the first week, along with the difference between a key assumption and a feature assumption. You write yours down before you have done any research, which is the point: they are what the research is for.

Six weeks, live, free, and the assumptions are the ones under your own idea.

Join the waitlist to hear when the next free cohort opens. The App Strategy Workbook has the whole course with the exercises if you want to start now.