Independent
You could ship this story without shipping any other. Stories that depend on three others usually want to be one bigger story.
30 seconds. One email — magic link or six-digit code. Your workbook saves as you type, across every lesson.
Continue with email →Already have an account? Sign in
Breadth before depth. Twelve specific stories beat three abstract ones — and an AI prompt does the first draft for you.
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
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.
Here’s what you wrote down last time. We’ll lean on these in every lesson. If anything is missing, open the source lesson and fill it in — the rest of this workshop reads from there.
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 PM canon for “is this a good story?” is the INVEST acronym (Bill Wake, 2003). Use it as a sanity check, not a checklist:
You could ship this story without shipping any other. Stories that depend on three others usually want to be one bigger story.
It’s a conversation, not a spec. The story names the goal; the spec (next lesson) decides the how.
A user can tell you why they want it. If only the engineer can, it’s a task, not a story.
You can guess at effort without three days of research. If you can’t, it’s too big or too vague.
One story, one week, max. Bigger means it’s actually two stories standing on each other’s shoulders.
You can imagine the test. “User sees their balance after login” is testable; “user feels in control” isn’t.
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.
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.
Operator story · Lesson 1
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.
[OPERATOR STORY — Lesson 7]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.
Run the Claude prompt. Edit the draft. Drop your 8–12 stories below, one per row.
Done with this section? Review all your answers in one place.
Review my workbook →