Speak It, Build It · Playbook
'Speak it, AI builds it' is built on the power of Claude Code — the tool is strong enough that you can describe what you want instead of operating it step by step. High-fidelity is the product manager's working principle for responding to needs at speed in the AI era: skip the wireframes and long docs, build something real that actually runs. This page gives you four 'scaffolds for talking to AI' and one 'high-fidelity verification checklist' — so you say it more precisely, build it more truly, and iterate faster.
First: this is not a form to fill in
A lot of methodologies want you to write a pile of documents first — PRD, spec, architecture, task list — before you can start building. That's not doaipm.
Our core is speak it, AI builds it: you describe what you want clearly, and Claude Code builds it directly. So the four "scaffolds" below are not forms to sit down and fill in — they're the shape you want your words to take when you talk to the AI. You can even let the AI fill them in for you; your job is just to confirm.
And there's only one standard for knowing whether it was built well: high-fidelity. It runs, it's clickable, the content is real, and all states are covered. High-fidelity isn't "polish it at the end" — it's the PM's working method for responding to needs at speed in the AI era: produce something real and verifiable, let people try it fast, change it fast.
Scaffold ① One-sentence spec: nail down "what do you want"
Before you start, get this sentence right. If you can't say it clearly, ask the AI to push back with questions — then start building.
I want to help [who] solve [what problem]. When it's built, users can use it to [the single most important action]. The sign that it worked is [one visible outcome]. We are explicitly NOT doing [non-goals / what's out of scope]. Known risks / assumptions: [...].
Hand this to Claude Code and add one key instruction:
This step produces no document — it produces shared understanding. If the AI repeats it back correctly and asks the right questions, it actually understood. That's the moment the high-fidelity prototype won't go sideways.
Scaffold ② Small steps: one step at a time, running after each one
Don't dump a wall of requirements and wait for it to disappear into a black box. Break it into steps where you can open a browser and see something after every single one.
How to break it down
Just ask the AI to do it: "Break this requirement into small steps where I can run it in a browser and see the result after each one. List them out — we'll go one at a time."
Rhythm for each step
- Say one step: describe only what's happening right now.
- Show me: "When it's done, start the server so I can see it in the browser."
- Give feedback on the spot: if it's right, move on; if not, "this part is wrong — it should be..."
Scaffold ③ Project taste: say it once, it remembers forever
Some preferences you don't want to repeat every session — tech stack, style, constraints, red lines. Say them once, write them into project memory, and the AI will follow them automatically from then on.
For this project, always follow these rules: · Tech taste: [e.g. use Astro, avoid heavy frameworks, static when possible] · Style: [e.g. dark, restrained, lots of whitespace, plain language] · Constraints: [e.g. no paid/third-party tracking; mobile-first] · Red lines: [e.g. don't touch production data; ask me before delete/publish/pay]
Ask the AI to save this as a "standing agreement" for the project (it'll know where to put it). This is the project's constitution — but you don't need to learn any format. Plain language works fine.
⭐ High-Fidelity Verification Checklist (the most important section on this page)
"Done building" is not the same as "built right." High-fidelity acceptance isn't looking at a screenshot — it's running the real thing and going through the list item by item.
| Check | Ask yourself |
|---|---|
| Real content | Is it real content and real data structures? Any Lorem ipsum, "sample text," or fake placeholders? |
| Four states | Loading / empty / error / success — are all four covered? Empty and error are the easiest to miss. |
| Real interactions | Do buttons actually click, forms actually submit, links actually navigate? Or do they just look like they do? |
| Critical path | The single most important user flow — does it work end to end? |
| Cross-device | Checked on both phone and desktop? At least one pass at a narrow viewport. |
| Edge-case input | Tried wrong input, empty input, very long input, weird characters — does it break? |
If it's an AI feature, add one more
An AI feature can't pass on "tried it once and it worked." Run a batch of real, adversarial inputs in a row — check for consistency, hallucination, and graceful failure. Ask Claude Code to generate a dozen test inputs and run them — this is what the industry calls an "eval loop," and PMs can absolutely do this.
Scaffold ④ Discovery questions: borrow a structure when you're stuck
If "clarify 3–5 questions first" isn't working because you don't know what to ask — borrow a classic discovery framework. Pick one and let the AI walk you through it.
- JTBD (what is the user hiring this for?): "In what situation would a user want to use this? What are they trying to accomplish? How are they cobbling together a solution today?"
- Opportunity Solution Tree: "What outcome are we trying to reach? What pain-point opportunities do users have? What solutions could address each opportunity?"
- Working Backwards: "Imagine this is already shipped and working. Write me the paragraph a user would say when raving about it — then let's reverse-engineer what we actually need to build."
Advanced: for big projects only (skip if small)
For a small prototype, the scaffolds above are enough. These techniques only become necessary when a project grows large and conversations grow long — and even then, it's still plain language.
Long context: the AI starts forgetting
In a very long conversation the AI starts to "drift." When that happens, make it research first, then draft a plan, then wait for your sign-off before touching anything — and occasionally say "summarize everything we've decided into a short doc, and let's start a fresh conversation." Keep context clean and it stays sharp.
Too much happening: parallelize
For complex tasks you can ask it to spin up parallel sub-agents (one to research, one to write, one to review). Just say "break this into parallel workstreams and consolidate a summary for me at the end."
Prototype is done: going to production
Taking a prototype to production is a separate journey: real data, security, performance, and who presses the "ship" button. Prototypes can be bold; production must be careful — irreversible actions (publish / delete / pay) are always triggered by a human. That safety net gets tighter the closer you get to real users.
