After the AI Prototype: A 7-Day Product Validation Plan for Builders
A seven-day plan for AI product builders to move from a working prototype to evidence: choose one user and job, observe real use, measure behavior, and decide what to build next.
Share
A working prototype answers a technical question
If your main question is how to harden a vibe-coded app for production, see From Vibe-Coded Prototype to Fundable Product. This guide focuses on validating the problem and deciding what to build next.
An AI coding tool can help you reach a working demo quickly. That is useful evidence that a workflow may be buildable. It does not yet tell you whether a specific person has the problem, whether the product fits into their day, or whether they will return after the first session.
The next step is not automatically a larger feature list. It is a short test with real users and a decision written down in advance. This seven-day plan is designed for a solo founder or small team that already has a usable prototype and needs to decide what to improve next.
It is not a promise of product-market fit in one week. The goal is to replace a vague “people seemed to like it” with a concrete observation and a sensible next action. For a broader post-launch scorecard, see our AI product-market fit guide.
Day 1: Choose one user and one job
Describe the person narrowly enough that you can find them. “Anyone who wants to be more productive” is not a usable segment. A clearer starting point might be “a solo founder who turns customer calls into engineering tasks” or “a product engineer who has to explain a technical change to a non-technical stakeholder.”
Then name one job the prototype helps them complete. Keep the first test to a single workflow. If the demo has five features, choose the one that matters most to the person, not the one that is most impressive to show.
Write a short hypothesis:
We believe [specific person] struggles with [recent, observable problem]. If we help them [specific action], they will [observable behavior] because [reason we can check].
Add the strongest alternative explanation. Perhaps the person does not need a new tool; perhaps they need a clearer template, an integration, or a faster existing process. You want the test to distinguish between possibilities.
Day 2: Define the evidence before inviting people
S
Specky Team
Writing about AI-native product development at Specky.
Pick one primary behavior that would indicate the user got through the important part of the workflow. Examples include completing a real task, returning to continue it, sharing the result with a teammate, or asking to use it on another piece of work.
Add one guardrail that would reveal a bad tradeoff, such as increased setup confusion, incorrect output, or more manual cleanup. Avoid choosing a metric just because it is easy to count. Page views and demo applause do not show that the core job was completed.
Write down what result would lead you to continue, narrow the use case, change the workflow, or stop. The threshold is a decision aid for this small test, not a universal benchmark. A few conversations can help you see whether a workflow is understandable; they cannot estimate the whole market.
Day 3: Recruit people who match the use case
Invite a small number of people who have recently done the job you selected. Ask about the task they actually completed, not whether they want to support your startup. Avoid relying only on friends, teammates, or people who have already decided to be encouraging.
A simple invitation is enough:
I have a rough tool for [job]. Could I watch you try it with a real task you already need to do? I am testing the workflow, not asking you to approve the idea.
If no one in the target group is willing to spend time on the problem, that is useful information about access or urgency. It is not, by itself, a verdict on the product. Record who you invited, why they fit, and what they agreed to do.
Days 4 and 5: Watch the real workflow
Ask the participant to bring a real task. Let them try the product without narrating every next step. Notice what they do before opening the tool, what they expect, where they pause, what they correct, and whether they can finish without you rescuing the session.
Use questions that keep attention on behavior:
“What are you trying to finish right now?”
“What did you expect this control to do?”
“What would you normally do at this point?”
“What would you need to verify before using this result?”
“What would make you come back to this next week?”
Do not treat every request as a feature spec. Ask what outcome the person is trying to reach and whether the workaround is frequent, costly, or risky. A request for a button may point to a deeper issue with the sequence, trust, or setup.
After each session, write down the observation, your interpretation, and what remains uncertain. Keep the participant's context attached so separate user types do not collapse into one imagined persona.
Day 6: Check for continued value and hidden work
Follow up after the session. Did the person use the result in their actual work? Did they return, share it, or ask to repeat the task? What did they have to fix manually? What happened when your guidance was no longer present?
Look at product behavior alongside the conversation. Useful signals depend on the workflow, but may include successful completion, repeat use, time to first useful result, correction rate, or a handoff to another person. No single metric explains why someone behaved that way, so pair it with what you observed.
Be careful with soft signals. Compliments, waitlist signups, and “I would definitely use this” can help you decide whom to contact next. They are weaker evidence than someone making time for a real task, using the result, and choosing to return.
Day 7: Make one explicit next decision
Review the hypothesis and evidence. Choose one of four outcomes:
Continue: the intended user completed the job and showed a meaningful reason to return.
Narrow: the problem appears real for one role or situation, but not for the broad group you started with.
Revise: users have the problem, but the current workflow does not solve it cleanly.
Stop or park: the test did not show enough urgency or value to justify more build time right now.
Write a short decision note with the evidence for the choice, the evidence against it, the remaining uncertainty, and the next test. If you continue, build only what resolves the clearest observed obstacle. Do not turn every interview comment into a roadmap item.
A copyable experiment brief
Use this before your next build:
User and context:
Recent job to complete:
Problem we believe exists:
Current workaround:
What the prototype changes:
Primary behavior to observe:
Guardrail:
What would change our mind:
Evidence source and owner:
Decision date:
AI tools can help organize supplied notes or draft a summary, but verify every claim against the original session. Never let generated text create a customer quote, a usage result, or a market fact that was not observed.