Lesson 1

Map your user stories

Breadth before depth. Twelve specific stories beat three abstract ones — and an AI prompt does the first draft for you.

10 minFrom Product Idea to Proof of Concept

Where this workshop picks up

The first workshop, How to Define Products, ended with a five-minute pitch for a defined product idea. This one starts where that ended. You have a customer, a root cause, and a chosen solution. Now you have to turn it into something a real person can click.

Six lessons get you from idea to a working proof of concept:

The road to a POC, in six steps

  1. Map user stories — this lesson.
  2. Prioritize stories (MoSCoW) — what's in v1 and what isn't.
  3. High-level spec — the "what" in plain language.
  4. Prioritize features and pick the POC slice — the thinnest end-to-end path.
  5. Write the PRD — two pages, six sections.
  6. Build the POC — with Claude Code or Cursor as your pair.

Every lesson pairs the theory with a copy-pasteable prompt for Claude. The prompts don't replace the thinking — they just remove the blank-page tax.

What a user story is, exactly

A user story is a single sentence that names a person, a thing they want to do, and the outcome they care about. The format dates to the late-90s extreme programming crowd and survives because it forces you to answer all three at once.

User-story template

As a [user], I want to [verb], so that [outcome].

Two notes on form:

  • The verb is a feature. "Track expenses" is fuzzy. "See last month's spend in one screen" is something you can build and test.
  • The so that is the real point. If the outcome doesn't change the user's day, the story isn't worth shipping — even if it's technically correct.

INVEST, in plain language

The PM canon for "is this a good story?" is the INVEST acronym (Bill Wake, 2003). Use it as a sanity check, not a checklist:

Independent

You could ship this story without shipping any other. Stories that depend on three others usually want to be one bigger story.

Negotiable

It's a conversation, not a spec. The story names the goal; the spec (next lesson) decides the how.

Valuable

A user can tell you why they want it. If only the engineer can, it's a task, not a story.

Estimable

You can guess at effort without three days of research. If you can't, it's too big or too vague.

Small

One story, one week, max. Bigger means it's actually two stories standing on each other's shoulders.

Testable

You can imagine the test. "User sees their balance after login" is testable; "user feels in control" isn't.

Breadth before depth

The instinct on the first pass is to write three deeply-considered stories. Don't. Write twelve shallow ones. You'll find that three of them are the actual product, four are nice-to-haves, two are someone else's product, and three are tasks pretending to be stories. You won't know which is which until you see them next to each other.

The stories you don't write are invisible to you. The ones you do write are arguments you can have.

Lesson 02 is where you cut. This lesson is where you cast the net wide.

Use Claude to draft the first twelve

Here's where the AI saves you the blank-page tax. Paste the prompt below into Claude (claude.ai or the desktop app), filling in the bracketed bits with your Workshop 1 answers above. You'll get 8–12 user stories in INVEST-friendly form. Edit and paste your favorites into the workbook below — don't accept the draft uncritically.

You are a senior product manager helping me map user stories for a new product I am building.
Here is what I have so far:
    

  • Target customer: [paste "who it's for" from Workshop 1 Lesson 02]
    • 

  • Root problem: [paste root cause from Workshop 1 Lesson 01]
    • 

  • Chosen solution: [paste chosen solution from Workshop 1 Lesson 04]
    • 

Generate 8–12 user stories in the format:
"As a [specific role], I want to [specific verb + object], so that [concrete outcome]."
Rules:
    

  • Be specific. "Track expenses" is too vague; "see last month's spend on one screen" is right.
    • 

  • Each story should be independently shippable (the I in INVEST).
    • 

  • The "so that" clause must describe a real change in the user's day, not a feature.
    • 

  • Cover the breadth of the product, not just the obvious flow. Include edge cases, recovery from failure, and one or two stories the user might not think to ask for.
    • 

  • Number the stories 1–12 so I can refer to them later.
    • 

After the list, briefly call out the 2–3 stories you think are most central to the product, and why.

From Alon's notebook

The first time Alon ran this prompt on a real product idea, the model surfaced a story he'd been actively avoiding — the one that turned out to be the actual product. Suggested hook: which story it was, why he was avoiding it, and what changed the day he wrote it down anyway.

Tonight's assignment

Run the prompt. Paste in your Workshop 1 answers. Edit the output. Drop your final 8–12 stories into the workbook below — one per row. Lesson 02 is where you decide which ones survive.