The purpose of validation is not to prove that your idea is good. It is to create opportunities for reality to tell you that it is wrong while changing direction is still cheap.
Short answer: identify the riskiest assumption, observe how people solve the problem now, ask for a meaningful commitment and deliver the result manually before automating it. Build software only when the evidence shows which part deserves to become repeatable.
1. Write down the assumptions
Separate facts from beliefs. “Three repair shops told me they lose customer approvals in messaging threads” is evidence. “Repair shops would pay €49 per month for a portal” remains an assumption until someone makes a meaningful commitment.
2. Find the riskiest assumption
An idea normally depends on several things being true: the problem occurs, it matters, the audience can be reached, the proposed result helps and somebody will pay. Test the assumption most capable of killing the idea—not the easiest one to confirm.
3. Ask about the past
People are poor at predicting what they might do. Ask them to describe the last occurrence. Look for dates, actions, workarounds, spending and consequences. Avoid leading questions such as “Would you use an app that…?”
4. Test access to the audience
A useful product that cannot economically reach its users is not yet a useful business. Try to recruit interviews or trial users through the channel you expect to use after launch. Difficulty reaching ten people is important evidence.
5. Deliver the result manually
If the app promises a report, produce the report manually. If it coordinates appointments, operate the coordination through a simple form and calendar. If it recommends something, create the recommendation yourself. The user cares about the result—not your database.
6. Ask for a costly signal
A compliment is nearly free. Better signals include booking a trial, introducing a colleague, sharing real data safely, signing a letter of intent, paying a deposit or using an inconvenient manual version twice.
7. Prototype only the uncertain part
Do not prototype sign-in screens and settings if the uncertainty is whether a specialist calculation can work. Build the smallest technical experiment that resolves the biggest unknown.
A simple evidence ladder
- Someone says the problem sounds familiar.
- They describe a recent occurrence.
- They already spend time or money on a workaround.
- They agree to test your manual result.
- They return or refer somebody.
- They make a financial commitment.
Not every product needs to reach the final rung before a prototype. But the lower you are, the smaller and cheaper the build should be.
When development becomes sensible
Build when the problem is repeated, the first user is identifiable, the proposed outcome has survived contact with reality and software removes a known constraint. If the process is still changing weekly, keep it manual.
If you have direct knowledge of a worthwhile problem but lack a technical background or conventional development budget, consider the Awkward Idea Fellowship. JMS Foundry will select two projects for product advice, a validation plan and up to 40 focused development hours.