From Product Idea to Proof of Concept
Write the high-level spec
Spec is the 'what' in plain language — one paragraph per Must story, plus a sketch of the system around them.
Spec versus PRD
Most teams use the words interchangeably. They shouldn't. The spec and the PRD are two different documents written for two different reasons:
The spec
Describes what the product does, in plain language, from the user's point of view. It's the document an engineer reads to know what they're building. No business framing, no metrics, no go-to-market — just behavior.
The PRD (Lesson 05)
Wraps the spec in business context: goals, non-goals, user flows, success metrics. It's the document a stakeholder reads to know why you're building it.
Write the spec first. The PRD is a frame; the spec is the painting.
One paragraph per Must story
For each Must story you finalized in Lesson 02, write one short paragraph that answers three questions:
Write in present tense. "The user sees a list of last month's expenses, grouped by category." Not "the user will be able to see…" Future tense smuggles in uncertainty.
Then: the system sketch
The per-story paragraphs describe behavior. The system sketch describes the bones around them — in three short bullet lists:
Data
What objects does the system have to keep track of? List nouns. (Users, sessions, transactions, projects…)
Surfaces
What does the user actually touch? List screens or commands. (Sign-in, dashboard, settings, share-link page…)
Integrations
What does the system depend on? List external services or APIs. (Email provider, payment processor, AI model, analytics…)
Five bullets per list, max. The point is to surface the dependencies you didn't realize you were taking on. If your "integrations" list has nine entries, your POC just got six weeks longer than you thought.
The integration list is the early-warning system for "this isn't a one-week build anymore."
Use Claude to draft the spec
Paste your Must list and your Workshop 1 answers into the prompt below. Claude will draft per-story paragraphs and the three system-sketch lists. Edit ruthlessly — the model will sometimes invent a screen you didn't intend, or assume an integration you don't want. That's good. Catching it now is the whole point.
You are a senior product manager. Draft a high-level spec for the v1 of a product I am building.
Context:
- Target customer: [paste from Workshop 1 Lesson 02]
- Root problem: [paste from Workshop 1 Lesson 01]
- Chosen solution: [paste from Workshop 1 Lesson 04]
The Must list (the v1 scope): [paste your Must list from Lesson 02]
Output structure:
Per-story spec
For each Must story, write one paragraph (2–4 sentences) covering:
- What the user sees
- What the user does
- What the system does in response Use present tense. Be specific about screens, fields, and data.
System sketch
Data
List up to 5 nouns the system must keep track of, with one phrase each on what each represents.
Surfaces
List up to 5 screens or commands the user actually touches.
Integrations
List up to 5 external services or APIs the system depends on. Flag any that are likely to add more than a day of work.
Open questions
End with 3–5 specific questions a real engineer would ask before starting to build. (E.g. "Are sessions per-user or per-device?", "Do we need offline support?") These are the things I should pin down before Lesson 04.
Tonight's assignment
Run the prompt. Edit the per-story paragraphs into your own voice. Trim the system sketch to the minimum that's honest. Drop the result into the workbook below — this is the input for Lesson 04.