Playcode School / Test a business idea
Test the problem before you build.
People are kind about an idea, especially to the person who had it. That kindness does not show that they need what you plan to build.
Ask what they already do instead. How someone handles the problem today shows whether it is real, and what solving it would be worth to them.
Ask about the last time it happened.
Ask for one real, recent occasion: when the problem last came up, what they did, how long it took and what it cost them. Then ask what they have already tried, and why they stopped.
These questions follow Rob Fitzpatrick's book "The Mom Test" (2013): talk about their life instead of your idea, and ask about specific past events instead of opinions about the future.
Example: instead of asking a recruiter whether she would use an app that writes candidate summaries, ask when she last wrote one for a client, and let her walk you through it.
Keep what they did apart from what they said.
"Testing Business Ideas" (2019) by David J. Bland and Alexander Osterwalder ranks what people do as stronger evidence than what they say. So write your notes in two lists. A compliment, or a promise to buy, stays on the second list until someone acts on it.
- Evidence
- What someone did, paid for or showed you. Example: she retyped four applications into her client's template last Tuesday evening.
- Assumption
- What you still believe without proof. Example: recruiters would pay to have summaries written for them.
Test the assumption that matters most.
After a few conversations, read both lists together. A problem that people raise without being asked, and already spend time or money on, is worth working on.
Then pick the assumption that would hurt most if it were wrong, and find the cheapest way to test it. Example: if every recruiter retypes applications but none has paid for help, offer to prepare next week's summaries for a fee and see who says yes.
If nobody has tried to solve the problem, it may not hurt enough yet. It is better to learn that now than after you build.
Write down one conversation.
Fill this in after each conversation, or edit the example below. Your answers stay in this browser until you choose to start a project. Copy or download your notes, or use them to start a Playcode project.
This is an editable example, not research about recruiters. Describe people by their role, not their name, and keep private details out of your notes.
Turn the problem into one task.
When the same problem keeps coming up, name one task a first version could handle: who does it, and what happens when it works. The next lesson turns that task into a short build brief.