Recap and Practice

Key takeaways

• A spec is a short, plain-language working note — what you're building and what you're not — not a contract you freeze; one page is plenty.
• Clarify the problem and the person before features, and write down non-goals: they're your sharpest defense against an AI adding "helpful" extras.
• User stories with a so that clause and a tiny PRD with a concrete "Done When" line turn intent into testable, buildable behavior.
• Pin down the data model early — field names leak everywhere — and slice the spec into vibe-sized tasks you can verify one at a time.
• Describe the problem, not the solution; outcomes stay cheap to change in a spec and expensive to change in code. Keep the spec alive as you learn.

Try it

Take any idea you've been sitting on and turn it into a one-page spec in a single AI session. Have the AI interview you with five sharp questions first, then write — in your own words — the problem, the user, three user stories (each with a so that), an explicit non-goals list, a six-line data model, and one "Done When" line you could physically perform. Save it as SPEC.md. The test of a good spec: you could paste it into a brand-new chat tomorrow and the AI would know exactly what to build.

Prompt of the chapter

I have a rough idea: <one-line description>.

Act as my product thinking partner. First, ask me 5 sharp questions,
one at a time, to clarify the problem, the target user, and what "done"
looks like. Don't propose features yet.

After I answer, draft a one-page spec with these sections:
- Problem  - User  - Goal
- In Scope (v1)  - Non-Goals (v1)
- User stories (each "As a __, I want __, so that __")
- Data model (a short list of fields)
- Done When (a concrete, physically-performable acceptance test)

Keep it tight — under one page. If something is ambiguous, ask before
assuming. I'll edit the draft until I agree with every line.