Getting a Real Product Spec Out of Any AI Tool

The goal is not to get the model to write your product. It's to force every decision out of your head and onto the page before any code gets generated, because an agent will happily build the wrong thing at incredible speed.

Write two sentences by hand. No AI.

[Product name] is a [what kind of thing] that lets [one specific user] do [one specific job]. Today they do it by [current painful method].

If you can't write those two sentences, you're not ready to spec. Go talk to the user first. Everything below assumes you have them.

Don't ask for a spec straight away. Ask to be questioned first. This is the single highest-value step, and the one almost everyone skips.

I'm about to write a product spec for something I'm building. Before you
write anything, interview me.

Here's what I have so far:
[paste your two sentences]

Ask me the questions you'd need answered to write a spec precise enough
that a developer could build from it without guessing. Ask them one batch
at a time, maximum 5 questions per batch, ordered by how much the answer
would change the shape of the product.

Prioritise questions about:
- what happens in the unhappy path
- what data must exist before the first screen works
- what I am deliberately NOT building
- who else touches this besides the main user

Do not write the spec yet. Do not suggest features. Just ask.

Answer honestly, including "I don't know." A spec built on invented answers is worse than no spec.

Once the questions run out, paste this.

Now write the spec, using my answers above. Follow this structure exactly
and do not add sections.

Rules:
- Plain language. No marketing copy. No adjectives that don't carry
information.
- If something is undecided, write "UNDECIDED: <the open question>"
rather than inventing an answer.
- No implementation detail unless I gave it to you. Describe behaviour,
not code.
- Be specific enough that two different developers would build the same
thing from it.

Structure:

1. WHAT IT IS — two sentences, no more.
2. WHO IT'S FOR — one primary user, one job. Name the secondary users
separately if they exist.
3. THE CORE LOOP — the single sequence of actions the product exists to
support, start to finish, numbered.
4. DATA MODEL — every entity, its fields, and its relationships. Plain
text or a table. Flag which fields are required at creation.
5. SCREENS / SURFACES — a named list. For each: its job in one line, and
what a user can do there.
6. RULES AND EDGE CASES — permissions, states, what happens when things
are empty, duplicated, expired, or fail.
7. OUT OF SCOPE — an explicit list of things this product does NOT do.
Include the tempting ones.
8. OPEN QUESTIONS — everything marked UNDECIDED above, collected.

The first draft is always too agreeable. Run these separately, one at a time.

Find the holes

Read the spec above as a hostile senior engineer who has to build it.
List every place where you'd have to make a decision the spec doesn't
make for you. Don't fix them — just list them. Be specific about which
line is ambiguous.

Cut it down

Which parts of this spec could be removed while still delivering the
core loop in section 3? For each, say what breaks if it's removed.
I want the smallest version that's still worth shipping.

Stress the data model

Walk three concrete scenarios through the data model in section 4:
one happy path, one where a user abandons halfway, and one where two
users act on the same record at the same time. Tell me where the model
doesn't hold.

Then regenerate the spec with the fixes. Two or three rounds is normal.

A spec tells you what. A plan tells you in what order.

Break this spec into build phases.

Constraint: every phase must be independently shippable — it can go live
on its own and be worth something, even if the phases after it never get
built. If a phase can't ship alone, split it again.

For each phase give me:
- the name and what it delivers
- the tasks, each small enough to be one file or one concern
- what is deliberately deferred to a later phase
- how I'll know the phase is done

Aim for 3-5 phases. Phase 1 should be auth and the data model.
Payments, scale, and polish go last.

Never paste the whole spec at build time. Paste this shape instead:

[1. THE SPEC SLICE]
<paste only the section of the spec for the thing you're building now>

[2. THE RELEVANT FILES]
<the existing code it must match — not the whole repo>

[3. THE CONSTRAINTS]
Don't touch migrations. Don't add dependencies. Follow the conventions
in CLAUDE.md.

[4. THE EXIT CONDITION]
Done means: <specific, checkable>. Stop there. Don't add anything I
didn't ask for.

The exit condition is what stops the model gold-plating. Most people never write one.