Skip to content
try reference course saved
English
← all Founders & PMs playbooks

playbook

Pressure-test an idea into a v1 spec

Turn a vague feature idea into a crisp v1 spec — user stories, the edge cases you're not thinking about, and an explicit out-of-scope line — before anyone builds.

easy ~20 min

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.

gather this first

  • The raw idea in your own words — a paste of the customer email, a Slack thread, or a 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

  1. 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.

  2. 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.

  3. 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.

  4. 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:** once the prompt sequence works, store it as a /spec custom command (see the Playbook's *Features* tab) so the next idea is one command, not four prompts.

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.