1. Overview
Two or three sentences. The customer, the problem, the solution. Lifted almost verbatim from Workshop 1’s pitch.
Why a PRD, when you already have a spec
The spec from Lesson 03 says what the product does. The PRD says why we’re building it, who it’s for, and how we’ll know it worked. The audience is different too — the spec is for the engineer, the PRD is for everyone else: a designer, a teammate, a future-you who’s forgotten what you were thinking, an investor, the AI you’re about to point at the code.
For a POC, the PRD is also the document you paste into Claude Code or Cursor in Lesson 06. It’s the source of truth for the build. Treat it that way.
Length is a feature
The first PRD most people write is twelve pages. The second is twenty. By the third, no one is reading them. Two pages is the right length for a POC PRD — long enough to capture the goals, short enough that an engineer will actually read the whole thing before opening their editor.
A PRD nobody reads is worse than no PRD at all. It looks like alignment and isn’t.
The six sections
2. Goals
3–5 bullets. What the POC must accomplish. Each goal should be specific enough that you could put a checkmark next to it.
3. Non-goals
3–5 bullets. What the POC explicitly will not do, even though someone might ask. Pull from your “Won’t (this time)” list in Lesson 02 and the excluded features from Lesson 04.
4. User flows
One numbered walk-through per Must story. “User opens app → user sees X → user clicks Y → user sees Z.” Three flows, max, for a POC.
5. Functional requirements
The per-story spec from Lesson 03, lightly cleaned up. This is the meat. The reader should be able to start building from this section alone.
6. Success metrics
1–3 numbers that would tell you the POC worked. Tied to the risky assumption from Lesson 04. If you can’t measure it, name a qualitative signal instead (“user finishes the flow without asking for help”).
Why non-goals do so much work
The non-goals section is the one most first-time founders skip, and it’s the one that pays the most dividends. Every non-goal is a future argument you don’t have to have. Every non-goal is a piece of scope creep that you’ve already won.
Useful non-goals look like this
- “The POC does not support multiple accounts per user. Multi-account is a v1.1 problem.”
- “The POC does not handle offline mode. Users need an internet connection.”
- “The POC ships with five hard-coded categories. User-defined categories are a v1.1 problem.”
Notice that each one names a feature someone might reasonably ask for, and refuses it on the record. That’s the move.
Use Claude to draft the whole thing
The PRD is a stitching exercise — you’re assembling the spec, the Must list, and the POC slice into one document with a consistent voice. Claude is good at this kind of stitching. Paste in your three inputs, ask for the six-section format, and edit the output for tone (the model tends to over-write the Overview).
Operator story · Lesson 5
From Alon’s notebook
The PRD that saved a quarter at Intuit because the non-goals section was longer than the goals section. Suggested hook: the specific non-goal that prevented a six-week feature creep, and what the team did with the saved time instead.
[OPERATOR STORY — Lesson 11]Tonight’s assignment
Run the prompt. Paste the PRD into the workbook below, section by section. The whole document is the input for Lesson 06 — this is the file you’ll feed to Claude Code or Cursor when you start building.
Assignment · Section 11
Draft the PRD
Sign in to save your answers.Six sections. Two pages. Pulled from your spec, Must list, and POC slice.
Done with this section? Review all your answers in one place.
Review my workbook →