How to validate a startup idea before building it
“An AI assistant for agencies” leaves almost every important choice unresolved. Which agency, doing what, with which alternative? Validation starts when the idea becomes specific enough that evidence could make you abandon it.
Write the failure condition before running the test. Otherwise every result can become a reason to keep building.
Name the customer and the costly moment
Choose a group you can actually reach. For our fictional product, that is a project lead at a small design studio who has just handed work to a client. “Small businesses” is too broad to recruit from or learn much about. The moment matters because it gives the conversation a real event to examine.
Ask how the last handoff worked. Where did feedback arrive? Who reconciled conflicting comments? What happened when approval was unclear? Record what the person did, including a workaround that works well. A customer who is satisfied with email is evidence against your proposed switch, not a bad interview.
Hypothesis · illustrative, not a finding
Project leads at small design studios lose time reconciling client feedback before handoff. They will try a shared approval record on an upcoming job if it works without moving their entire project into a new tool.
Choose the uncertainty that could kill the idea
A client may enjoy clicking through an approval prototype and still prefer email on their next job. A waiting-list signup leaves usability untested. SVPG's four-risk framing separates value, usability, feasibility and business viability. Choose which question you need to answer before choosing what to build.
For the handoff tool, start with value if nobody has agreed the problem matters. Test a rough approval screen if customers want the result but the interaction is unclear. Check integration feasibility before promising automatic access to a client's tools. A manual pilot can be useful while the software is still small, provided participants know what is manual.
- Value: will the project lead use this on a real handoff?
- Usability: can a client approve the right version without help?
- Feasibility: can the required files and permissions be handled?
- Viability: is delivery and support sustainable at the proposed price?
Ask for behaviour, not a compliment
Decide who qualifies for the test, what you will offer and what action counts before recruiting. You might ask a studio to schedule a trial on its next real handoff. That is a stronger commitment than “sounds interesting”, although it still does not prove retention or willingness to pay.
If you use a landing page, make the offer and button match what happens next. A pilot request should lead to a pilot request, not a fake checkout. Record where visitors came from and whether they match your target. A conversion number without a denominator, audience or acquisition source is difficult to interpret.
Example decision rule · choose your own before testing
Invite eight qualifying studio leads. Continue to a manual pilot if at least three agree to use it on a named upcoming project. If fewer agree, review the objections before writing more code. These numbers are a planning example, not a statistical benchmark or proof of market demand.
Keep the result separate from your interpretation
Write down invitations, responses, commitments and reasons for refusal. Then state what they support. Three scheduled trials support trying the pilot; they do not justify “the market is validated”. A small, convenience-based sample may reveal a problem without estimating how common it is.
In Symbiont, put the hypothesis, the evidence you already have and the failure condition into the project brief. Ask the research to challenge that specific hypothesis. After the test, add the observed result and request a revised recommendation: proceed with a bounded pilot, sharpen the segment or stop this version of the idea.
Before you move on
- I can name and reach the first customer group.
- I know what they use instead today.
- The test addresses one important uncertainty.
- The offer is honest about what exists.
- The success and stop conditions were chosen in advance.
- The conclusion does not claim more than the sample supports.
Source notes
Prepared with AI assistance from Symbiont’s product workflow. Examples are illustrative; interface captures use demonstration data. About these guides.
Put the next decision in your project
Bring your brief, evidence or review question into one conversation.
Open your workspace