Validation is not a vote on whether an idea sounds exciting. It is a way to reduce uncertainty before you invest in code. Start by learning how someone handles the problem today, then test whether your proposed first version changes that behavior.
Start with the last real occurrence
Choose one specific person and one moment when the problem actually happened. Ask what they did, what they tried first, what took the most effort, and what they did next. Past behavior is more useful than asking someone to imagine whether they might use a product someday.
Use a short, non-leading conversation
- “Tell me about the last time you needed to do this.”
- “How did you handle it? What tools or workarounds did you use?”
- “What was frustrating, slow, or easy to get wrong?”
- “Have you tried to solve it another way or paid for help?”
- After listening, show one simple promise and ask what feels unclear or missing.
Avoid pitching before you understand the story. “Would you use my app?” usually earns a polite guess. Ask for examples, steps and trade-offs instead. Do not treat a compliment, survey response or waitlist signup as proof of a future purchase.
Read behavior, not just enthusiasm
“That sounds cool.” The person is being kind, but has not described a real recent problem or taken a next step.
They recognise the situation, explain a current workaround and can describe when it last happened.
They volunteer time to test a prototype, introduce you to another affected person, try the workflow, or ask a concrete question about price or availability.
These are practical clues, not a scoring formula. A strong conversation can still lead to “not now”; only real usage or payment confirms demand.
Run a small test before building more
- Write one sentence naming the person, problem and outcome.
- Choose the smallest first version that could deliver that outcome.
- Show the promise to five relevant people individually, not a random audience.
- Ask them to take one real next step: describe their workflow, try a prototype, or join a clearly explained test.
- Review what people did and said before adding features. If the evidence is weak, revise the audience or promise.
Where Palm fits
Palm helps organise an early idea into an audience, promise, first-version scope and launch plan on your Mac. The free brief generator below gives you a starting point; neither it nor Palm can validate demand for you. The evidence comes from conversations and behavior outside the app.
Download Palm for Mac and shape an idea into a product brief.
Palm Pro is a $49 one-time unlock for the product-planning and launch workflow.
Write down what would change your mind
Before the conversations, name the evidence you are looking for. For example: several people in the intended audience independently describe the same costly workaround, can show how often it happens, and agree to try a small prototype. Also decide what would make you narrow the audience, change the promise, or stop. This guards against interpreting every polite reaction as confirmation.
Keep a simple evidence log
- Observed problem: what happened, and when?
- Current workaround: what does the person do now?
- Cost of the problem: time, money, risk, or repeated frustration?
- Next action: did they try something, introduce someone, or return to the conversation?
Do not treat five interviews as statistical proof or a waitlist as a purchase. Use the notes to choose the next experiment, then keep checking behavior after the prototype exists. For a structured starting point, see how to turn one sentence into an app direction.
Signals, ranked by strength
| Signal | Strength |
|---|---|
| "Sounds great, I would use that" | Weak |
| They describe the problem unprompted | Moderate |
| They show you the workaround they built | Strong |
| They ask when they can have it | Strong |
| They pay or pre-order | Strongest |
Questions people ask
How many conversations are enough?
Five to ten with the right people usually shows a pattern.
What if nobody has the problem?
You have saved months. Change the audience or the idea.