You validate an app idea without building it by talking to people who have the problem. Five to seven conversations with the same kind of person is usually enough. Ask them what actually happened the last time they ran into the problem, and keep your idea out of it completely.

You don't need a prototype, a landing page or a developer for this part. You need to know who to talk to and what to ask.

What does it mean to validate an app idea?

It means replacing your guesses with evidence.

Until you talk to people, everything you believe about your idea is an assumption: who has the problem, how painful it is, what they do about it now, and whether they would pay for something better. Early on, your goal is to find out whether a meaningful problem exists at all, and whether people care about it enough to change what they are doing to solve it.

You are studying the problem, not pitching the solution. If you tell people about your app, it biases the way they respond to you. They start reacting to your idea, and being polite about it, instead of telling you what really happens in their life.

Can I skip validation if I have the problem myself?

No. If you only build from your own experience, you are building for a target market of one person.

This happened with my own app idea. I learned to code because I was a nanny and we had a book we wrote in with the parents, and I thought, this could be an app. I assumed the problem was communication: the book is cumbersome and you can't carry it with you. When I did the research, the first thing I found that both parents and nannies desperately needed help with was working out how much the nanny gets paid each paycheque. Schedules change, so one day might be four hours and the next day twelve.

I also hadn't been a nanny in 10 years. What was important back then might not be what's important now.

How do I validate an app idea, step by step?

1. Know who your user is. You can't interview people until you know who you are looking for. Think about what someone is doing when the problem happens, not just their age or their job title.

2. Recruit with the problem, never the idea. When you ask someone to talk, give them the high-level problem you are researching: "I'm researching how I can help with a problem I've identified, that parents have a hard time getting daycare spots." Say nothing about your app. If you tell them you are building billing and scheduling software, they will never tell you the other things that are going wrong.

3. Talk to five to seven people. Some people will tell you to talk to 50 or 100. I don't think you need to. After about five people who are the same kind of person, you start hearing the same problems repeated. By seven, about half of each conversation is a repeat of what you have already heard. If you only manage three, that is enough to keep going, and you can come back for more later.

4. Don't lean on friends and family. If one of them fits your user, interview them. Just keep in mind they might not feel comfortable telling you something that makes them look bad.

5. Ask for their story, not what they want. Start with "Tell me about..." or "Walk me through..." and let them talk. People don't know what they need. If you ask them, you get surface answers. If you listen to their story, you start hearing the problems: it's such a pain when the pool schedule changes and I have to redo everything. That's a problem. Nobody says "I need a scheduling tool".

6. Ask about the last time, not what they usually do. Ask someone how they eat and they will tell you it's mostly meat and veggies, a bit of sugar sometimes. Ask what their last meal was, and the one before that, and the one before that, and the reality is different. It works the same way for any problem you are researching.

7. Listen for workarounds and trade-offs. What have they tried? Where does it break down? What are they putting up with, and why? A parent might accept a slow manual process for getting photos from their nanny, because photos sent over WhatsApp get compressed and print badly. That is the real reason, and you only get it by asking why.

8. Look for repetition. When different people describe the same problem, even in different words, you have found something real.

What counts as a good validation signal?

What people do is the signal. What they say they would love to do is not.

Signals worth trusting:

• Different people describe the same problem without you prompting them
• They have already built a workaround, like a group chat, a shared album or a paper book
• They are disappointed when they hear it isn't available yet

Signals to take with a grain of salt:

• "That would be so helpful"
• "I would totally use that"
• A gap in the market that nobody is talking about, because sometimes there is a gap because there is no market there

If you describe a solution and ask whether it would help, people will often say yes. If you build it, they might not use it.

What if the research kills my idea?

Then it did its job. One student in my class had their idea disproven during the research week. That saved them months of time and stress, plus whatever they would have spent on tooling or on hiring someone to build it. All it took was a few days of research.

What comes after validation?

Once you know the problem is real, you can start sketching solutions, and then test those too, before you pay anyone to build anything. There are usually several ways to solve a problem, and the first one you think of might not be the one people will actually use.

Keep reading

How to Validate a SaaS Idea Before Writing a Single Line of Code

How to Talk to Users When You're a Developer, and Find It Deeply Uncomfortable

Is My App Idea Good Enough? Here's How to Actually Find Out

Learn this with me

Validating without building is most of From Passion to Product, my free six-week live course. Class 2 is the online research, class 4 is talking to real people, class 5 is the competition, and class 6 is testing a solution before anyone builds it.

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

Join the waitlist to hear when the next free cohort opens. The App Strategy Workbook is the same six weeks written down, with the exercises, if you want to start today.