How long does turning an idea into a spec take?

About 20 minutes for a typical single feature — one prompt to read the idea back, one for user stories, one for edge cases, one to assemble the spec. The slow part is the decisions you make along the way, not the writing; Claude does the drafting.

What if the idea came straight from a customer email?

Paste the gist of the request, not the email verbatim — strip the customer's name, email address, and any account details, replacing them with [customer]. The spec should be about the feature and its users in the abstract, not tied to one person's inbox.

Who owns the out-of-scope line — me or Claude?

You do. Claude can propose what to cut from v1 and give reasons, but deciding what the first version won't do is a product call that only you can defend to engineering and stakeholders. Treat Claude's suggestions as a starting list to react to, not a final decision.

Can I adapt this to spec something fuzzier than a single feature?

Yes — run the playbook twice. The first pass produces the smallest learnable slice of the bigger idea; then feed that tighter spec into the prototype playbook to make it clickable before you commit to building anything larger.

Pressure-test an idea into a v1 spec

when to reach for this

An idea sounds simple in your head — "let users save articles for later" — and three weeks later eng is still untangling what you actually meant. The expensive surprises (the same article saved twice, what happens when it's deleted, whether it syncs across devices) are the ones you discover mid-build, when they're costly. This system spends 20 minutes up front turning a one-line idea into a spec sharp enough to estimate against: stories, edge cases, and a line that says what you are deliberately not doing in v1. It's all a conversation in Claude Desktop — no terminal, no install.

gather this first

The raw idea in your own words — paste the customer email or the Slack thread straight into the chat in Claude Desktop, or drop in an idea.md with a paragraph or two.
Roughly who it's for and the one job it has to do — "a reader, on the article list, who wants to come back to this later."
Any hard constraints you already know — a deadline, "web only for now," "must work without an account."

the workflow

Have Claude read the idea back before it specs anything

Don't ask for a spec cold. Make Claude restate the idea and the user in its own words first — if it misread the goal, you catch it now, not after it's written ten stories for the wrong feature.

you ask

Here's a rough idea: [paste the customer email / your paragraph]. Before you spec anything, read it back to me: who is this for, what one job does it do for them, and what's the simplest version that would still be useful? Don't write user stories yet.

what you get back A short read-back — "this is for a logged-in reader on the list view who wants to set an article aside; the simplest useful version is a save button plus a place to find saved items." If the user or the job is wrong, correct it before going further.

This "read it back to me first" move is the cheapest bug-catch you'll ever do — it costs one prompt and saves a rewrite.
Get the user stories

Stories force the idea into concrete "as a [user] I can [action]" units you can actually build and check off — far harder to hand-wave than a paragraph.

you ask

Now write 4-6 user stories for a v1, each as "as a [user] I can [action] so that [outcome]." Keep them to the core flow — saving, finding what's saved, and removing a save. No nice-to-haves yet.

what you get back Tight, buildable stories — "as a reader I can save an article from the list view so I can read it later," "as a reader I can see all my saved articles in one place," "as a reader I can remove a save." Each one is something eng can estimate and you can test.
Surface the edge cases you're not thinking about

This is where Claude earns its keep. The happy path is obvious; the spec that blows up the estimate is the one that only listed the happy path.

you ask

What edge cases and failure modes am I missing? Think about: saving the same article twice, saving then the article gets deleted or changed, a logged-out user trying to save, hitting some limit, and what an empty Saved list should show. For each, suggest the simplest sensible behaviour.

what you get back A list of the surprises — "saving twice should be a no-op, not a duplicate; a deleted article should show as 'no longer available' in Saved rather than vanish silently; logged-out save should prompt sign-in." These are the decisions you'd otherwise make under pressure mid-build.

Skim this list and make the calls now while they're cheap — a decided edge case is a one-line answer; a discovered one is a meeting.
Draw the out-of-scope line and assemble the spec

An explicit "not in v1" line is what keeps a two-week build from quietly becoming a two-month one. Naming what you're not doing is as important as what you are.

you ask

Assemble a one-page v1 spec: a one-line summary, the user stories, the edge-case decisions, and an explicit OUT OF SCOPE section (e.g. no folders, no cross-device sync, no sharing yet) with a one-line reason for each cut. End with 3 open questions I still need to answer.

what you get back A clean, shareable spec with a hard scope boundary — "out of scope for v1: folders/tags, syncing saves across devices, sharing a saved list. Why: each adds a data model we don't need to validate the core idea." Plus a few honest open questions.

make it your own

Bigger idea: for something fuzzier than a single feature, run this twice — once to spec the smallest learnable slice, then feed that spec into Build a clickable prototype to decide to make it real before you commit.
Already have feedback: if the idea came out of customer signal, run Synthesize feedback into a roadmap signal first so the spec is grounded in a real pattern, not one loud request.
Save the move (Power Track): once the prompt sequence works, store it as a /spec custom command (see the Playbook's Capabilities tab) so the next idea is one command, not four prompts. Custom commands are an opt-in Power-Track step — on Desktop you can keep the dialed-in prompt in a note and paste it instead.

watch out for

Claude drafts the spec; you own the scope. The out-of-scope line is a product decision — Claude can propose cuts, but deciding what v1 won't do is your call to defend, not its.
A spec with no edge-case section is the one that detonates the estimate. If Claude's edge-case list looks short, push it: "what else breaks?"
If the idea came from a customer, don't paste their name, email, or account details into the prompt — describe the request, replace specifics with [customer], and keep the spec about the feature, not the person.

you'll end up with A one-page v1 spec — stories, decided edge cases, and an explicit out-of-scope line — that you can hand to eng for an estimate, in about the time a vague Slack thread would've taken anyway.

Questions people ask

How long does turning an idea into a spec take?: About 20 minutes for a typical single feature — one prompt to read the idea back, one for user stories, one for edge cases, one to assemble the spec. The slow part is the decisions you make along the way, not the writing; Claude does the drafting.
What if the idea came straight from a customer email?: Paste the gist of the request, not the email verbatim — strip the customer's name, email address, and any account details, replacing them with `[customer]`. The spec should be about the feature and its users in the abstract, not tied to one person's inbox.
Who owns the out-of-scope line — me or Claude?: You do. Claude can propose what to cut from v1 and give reasons, but deciding what the first version won't do is a product call that only you can defend to engineering and stakeholders. Treat Claude's suggestions as a starting list to react to, not a final decision.
Can I adapt this to spec something fuzzier than a single feature?: Yes — run the playbook twice. The first pass produces the smallest learnable slice of the bigger idea; then feed that tighter spec into the prototype playbook to make it clickable before you commit to building anything larger.