You validate a SaaS idea before writing code in two parts. First you find out whether the problem is real, by talking to five to seven people who have it. Then you deal with the part research cannot answer: whether anyone will pay you.

That second part is the one people skip, and for a paid product it is usually the assumption the whole thing rests on.

Why willingness to pay is the hard one

You cannot determine whether people will pay for something through research. Payment is one of those things that either happens or it doesn't. People might say they will pay and then not. They might say they would spend a hundred dollars on it, and when it comes to it they only want to spend twenty.

So treat it as a key assumption and write it down as one. If your product relies on an assumption you cannot validate, you are going to have a hard time, and you need a different key assumption or a different way to test this one.

Here is how I put it for my own app idea: if they will not pay for it, the product dies. There is no way I can do this for free, I would have to flood it with ads, and that is not the product I want to build. Knowing that is what makes it worth testing properly.

Test the problem first

Before any of the payment tests, do the basic work:

• Decide exactly who has the problem
• Recruit people using the problem, never your idea
• Talk to five to seven people who are the same kind of person, because after about five you start hearing the same things repeated
• Ask about their story and about the last time it happened, not what they want

If your buyer and your user are different people, which is common in SaaS, you need both. Talk to the person who will use it and the person who will pay for it, and know which is which.

Four ways to test whether people will pay, without building

1. A concierge version. Do the job by hand. Groupon started this way: instead of an app where people found deals, the founders talked to people about the deals they wanted, went and found them, and brought them back. Another company ran a WordPress blog with the founders checking emails and sending out PDFs by hand saying what was available that day. It would have been really expensive to build all that infrastructure, so they proved the business manually first. If people will not pay you to do it by hand, you are going to have a really hard time getting them to pay for an app.

2. Wizard of Oz. People think they are using a product. There is actually a person on the other side answering, or driving the screens. Same idea, different disguise: real value delivered, nothing built.

3. A coming-soon page. Put the offer up, with a price, and don't build it until someone actually wants to buy it. It also makes you look more legit while you are talking to people. Setting up a waitlist page before you start building is standard idea-validation behaviour in business, and it works for software too.

4. The disappointment test. Mention the thing, then mention that it isn't available yet, in a way that leaves people a bit disappointed. Then watch who is the most disappointed. Those are your first customers.

What counts as a real signal

What people do, not what they say they would love to do. A stranger who calls you and asks for it. Someone who has already built themselves a spreadsheet to cope. Someone who hands over money before anything exists.

"I would definitely use that" is not in this list.

When you have your answer

If the problem is real and someone has paid you, or pre-paid, or done something that costs them something, you can start scoping the first version: the smallest thing that is worth paying for. If nobody will pay, you have learned that for the price of a few conversations rather than a year of your life.

Keep reading

How Do I Validate an App Idea Without Building It?

MVP vs. Prototype vs. Proof of Concept: What's Actually the Difference?

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

Learn this with me

From Passion to Product is my free six-week live course and it runs this whole sequence: online research in class 2, a persona in class 3, interviews in class 4, competitive work in class 5, and shaping and testing a solution in class 6. Nothing gets built until you have been through all of them.

You do it on your own idea, and the course costs nothing.

I also run the same material for small teams, from a one day workshop up to the full six weeks, which is the version for a company that keeps shipping features nobody asked for.

Join the waitlist, get the App Strategy Workbook, or look at the team programs.