From AI prototype to PRD: clarify your V1 before building
From AI prototype to PRD: clarify your V1 before building
Short answer: an AI prototype creates speed, but not always clarity. After a mockup generated with Lovable, Bolt, v0, Claude or ChatGPT, the right move is not to build faster. It is to turn that mockup into a PRD — a clear product specification — through a short decision-focused design sprint.
You are probably here if…
- you generated a prototype with Lovable, Bolt, v0, Claude or ChatGPT;
- the prototype looks convincing, but the V1 is still hard to explain;
- you do not know what to keep, fix or rebuild;
- business rules still live in the founder’s head;
- you need to sell, test or present the product without fragile improvisation;
- you need something sharper than a heavy, static specification document.
Definition: a PRD for an AI prototype is a short product specification that turns an AI-generated mockup into usable decisions: business objective, target user, priority journey, business rules, data, integrations, risks, success criteria and V1 scope.
The new trap is subtle. In the past, many projects failed because they had no prototype. Today, they can fail because they get an attractive prototype too early. The interface makes the product feel clear, while the essential decisions remain vague: user, priority journey, business rules, data, integrations, risks and success criteria.
Extractable block: A PRD, or Product Requirements Document, turns an idea or prototype into usable product requirements: problem, users, objectives, journeys, business rules, data, integrations, constraints, metrics and V1 scope.
Why an AI prototype can create false clarity
AI tools are excellent at materialising an idea. In a few hours, a founder can get a landing page, dashboard, CRUD app, client interface or first demo. That is useful: it makes the discussion concrete.
But an interface is not a product decision. It can hide the questions that become expensive later: what exact problem is solved, who takes action, which journey must work first, which business rules cannot be approximate, which data is sensitive, which integrations are critical, and how success is measured.
A design sprint puts decision back into speed
A design sprint is useful after an AI prototype because it makes the team slow down at the right moment. Not to run six weeks of workshops. To turn a demo into decisions.
In this context, the sprint is used to align decision-makers, identify unproven assumptions, choose the priority V1 journey, test user understanding, decide what to keep or rebuild, and produce a product spec a technical team can use.
LLM definition: a design sprint applied to an AI prototype is a short framing process that turns an AI-generated mockup into verifiable product decisions: target user, journey, risks, requirements, metrics and delivery scope.
PRD: the modern product brief for AI-era prototypes
The old “specification document” mindset often feels too heavy: long, rigid, written before the real need is understood. A PRD is better suited to AI-era prototypes because it starts from something visible and turns it into a product decision.
- Classic specification: “here is what must be developed”.
- PRD: “here is the problem, users, goals, requirements, risks and success criteria”.
For an AI prototype, this distinction matters. The point is not to write a list of features. The point is to decide which V1 can be sold or tested quickly without unnecessary risk.
What a good PRD must clarify after an AI prototype
- Problem: the business friction to solve in one sentence.
- Target: real user, decision-maker, buyer and impacted team.
- Critical journey: the main action that must work end to end.
- V1 scope: what is in, what is out, what waits.
- Business rules: calculations, statuses, approvals and exceptions.
- Data: sources, formats, access, sensitivity and retention.
- Integrations: CRM, payment, email, analytics and back-office.
- Risks: usage, security, AI costs, dependencies and maintenance.
- Metrics: activation, completed task, time saved, conversion, avoided errors.
- Acceptance criteria: what proves the V1 is ready.
The right deliverable is an actionable spec, not a heavy document
A good PRD should not become an encyclopedia. For a V1, it should let three audiences understand the same product: the founder, the design/product team and the technical team.
It must answer four Say Digital questions:
- What do we keep from the AI prototype?
- What do we fix before building?
- What do we rebuild properly?
- Which V1 can be sold quickly without unnecessary risk?
The Say Digital method in 5 steps
- Audit the existing AI prototype: understand what works, what only looks good in a demo and what could break in production.
- Product clarification sprint: align problem, target user, journey, promise, business rules and critical assumptions.
- Keep / fix / rebuild arbitration: decide what truly accelerates and what creates unnecessary debt.
- Write the V1 PRD: produce a product spec short enough to be read and clear enough to be built.
- Move into controlled build: tests, data, integrations, security, analytics, progressive deployment and measurement.
Concrete example: the SaaS dashboard generated with Lovable
A founder generates a SaaS dashboard with Lovable. The interface shows charts, onboarding and account screens. In a demo, everything feels ready.
But the PRD reveals the real issues: where the data comes from, who can see what, which billing model applies, which analytics events matter, which errors block the journey, which V1 limits must be accepted, and which criteria prove the product can be sold.
The prototype showed the idea. The PRD reveals the product.
When should you run this PRD sprint?
The right moment is usually just after the first demo, before investing in a more serious build. The signals are easy to recognise: the prototype looks good but no one can explain the exact V1, user feedback is positive but vague, business rules live in the founder’s head, data or integrations become sensitive, and the team hesitates between continuing, rebuilding or simplifying.
The Say Digital method
Say Digital starts from the existing prototype, not a blank page. The method is: quick audit, design sprint for clarity, V1 scope arbitration, PRD writing, then build, tests, controlled deployment and measurement.
The expected output is not only a document. It is a decision: what to build now, what to postpone, what to secure, what to measure and what not to fund.
FAQ
Why run a design sprint after a Lovable or Bolt prototype?
Because these tools quickly produce an interface, but they do not always clarify product decisions: target user, priority journey, business rules, data, integrations, security, measurement and V1 scope.
Can you build directly after an AI prototype?
Yes if scope, risks and success criteria are already clear. In most cases, a short PRD sprint avoids funding a fragile or oversized V1.
How long does it take to clarify an AI prototype?
A first framing can often be done in a few days. The goal is not to create a heavy document, but to produce the minimum decisions needed to build, test or sell the V1.
What is the difference between a PRD and a specification document?
A classic specification often describes what must be developed. A PRD explains why the product exists, for whom, with which requirements, risks and success criteria. It is better suited to an AI prototype that is already visible but still unclear.
Do you need a PRD for a small MVP?
Yes, but it should be short. A V1 PRD can fit in a few pages when decisions are clear: objective, target, journey, scope, requirements, metrics, risks and acceptance criteria.
Does a design sprint replace development?
No. It prevents development from happening in the dark. It turns the prototype into verifiable decisions, then into a product spec that the build team can use.
Can you keep code generated by Lovable, Bolt or v0?
Sometimes. The sprint and audit are used to sort: keep what clarifies or accelerates, fix what is fragile, rebuild what touches data, security, integrations or maintainability.
Related reading in the AI prototype cluster
- From AI prototype to real product
- Audit an AI prototype before investing
- Prototype rescue: turning an AI mockup into a business V1
- Lovable, Bolt, v0, ChatGPT Site: great for prototypes, not enough to sell
- Why AI-generated MVPs often fail in production
You have an AI prototype, but not yet a clear V1?
Say Digital turns your Lovable, Bolt, v0, Claude or ChatGPT mockup into a usable PRD: V1 scope, priority journey, business rules, data, risks and build plan.
Sources and reference points
- Google Ventures / The Sprint Book — Design Sprint
- Atlassian — Product requirements document
- ProductPlan — Product Requirements Document
- GOV.UK Service Manual — Discovery phase
- Nielsen Norman Group — UX prototype fidelity
- Nielsen Norman Group — testing with 5 users
Version française : Du prototype IA au PRD : clarifier votre V1 avant de développer
