Write the PRD
Two pages, six sections. Length is a feature. The non-goals do as much work as the goals.
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
1. Overview
Two or three sentences. The customer, the problem, the solution. Lifted almost verbatim from Workshop 1's pitch.
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).
You are a senior product manager. Draft a 2-page PRD for the proof of concept of a product I am building.
Source material:
[1] Customer + problem + solution (the pitch) [paste from Workshop 1 — the customer profile, root cause, and chosen solution]
[2] Must list (v1 scope) [paste from Lesson 02 of this workshop]
[3] High-level spec [paste from Lesson 03 of this workshop — per-story paragraphs + system sketch]
[4] POC slice + risky assumption [paste from Lesson 04 of this workshop]
Use this exact six-section structure. No additional sections. No preamble.
1. Overview
2–3 sentences. Customer, problem, solution. Crisp.
2. Goals
3–5 bullets. Each one specific enough to check off.
3. Non-goals
3–5 bullets. Each one names a feature someone might reasonably ask for and explicitly refuses it for this POC. Pull from the excluded features in [4].
4. User flows
One numbered walk-through per Must story (max 3). Use this format: "User opens X → user does Y → system responds with Z."
5. Functional requirements
The per-story spec from [3], lightly cleaned up. An engineer should be able to start building from this section alone.
6. Success metrics
1–3 metrics tied to the risky assumption in [4]. If a number isn't available, name a qualitative signal ("user finishes the flow without asking for help").
Total length: 2 pages. If you exceed 2 pages, cut the Overview and the Functional requirements first — never the Non-goals.
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.
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.