How to Prompt AI to Write a Product Spec
Most AI-written product specs read well and say nothing useful. Here is the input structure and prompt sequence that gets a spec someone could actually build from.
A product spec written by AI usually reads well and misses the three things that actually matter: what happens on the edge cases, who the user is when they are not the happy path, and what you are explicitly choosing not to build. Getting a usable spec out of AI is less about the prompt's wording and more about what you feed it before you ask.
This is the structure that produces a spec someone could actually build from, not a polished paragraph that restates your idea back to you.
Why AI product specs default to fluff
Ask an AI tool to "write a product spec for a booking app" and it will produce something that sounds like a spec: sections, headers, a feature list. What it will not have is the information that was never in your one-line prompt. AI does not know your users, your constraints, or your launch date, so it fills those gaps with plausible defaults. The fix is not a cleverer sentence, it is giving it the inputs a real spec depends on before you ask for the document, which is really an extension of prompt engineering basics applied to one specific document instead of a general rule.
Step 1: feed it the five inputs first
Before you ask for the spec itself, give the model these five things in plain language. Skipping any one of them is where the vague output comes from.
Input | Why it matters | Example |
|---|---|---|
Who the user is | Changes tone, complexity, and what counts as a feature vs. a distraction | "Solo landlord managing 4-8 rental units, not tech-savvy" |
The one job it does | Keeps the scope from creeping into a platform | "Track rent payments and send reminders, nothing else this version" |
What you already ruled out | Stops AI from re-proposing things you decided against | "No tenant-facing app yet, no accounting integration" |
A real constraint | Forces trade-offs instead of a wish list | "Ships in three weeks, one developer" |
What success looks like | Gives the spec a way to be checked later | "A landlord can log a payment in under 10 seconds" |
Step 2: the prompt
Once those five inputs exist, the prompt is almost mechanical. This is the template:
Write a product spec for [product idea], using the context below.
User: [who, in one sentence]
Core job: [the one thing this version does]
Explicitly out of scope: [list]
Constraint: [time, team size, or platform limit]
Success looks like: [one measurable sentence]
Structure the spec as:
1. Problem and user, two sentences
2. Core user flow, numbered steps
3. Features, split into Must have and Not this version
4. Edge cases and what should happen for each
5. Open questions you are unsure about
Be specific. If a requirement is ambiguous, put it under Open Questions instead of guessing.The last line matters more than it looks. Without it, AI resolves every ambiguity silently and confidently, and you only find out it guessed wrong when the build doesn't match what you meant.
Step 3: push on the edge cases separately
The first draft's edge case section is almost always thin, three or four obvious ones. Do not accept it. Follow up with a narrower prompt:
List 10 edge cases for [core user flow] that a first draft would miss. For each, state what should happen.This works because the second prompt has one job instead of five. A model producing an entire spec is budgeting attention across structure, tone, and content at once; a model listing edge cases for one flow can go deeper on that flow alone. The difference shows up directly: a first-pass spec for a booking flow might list "double booking" as an edge case, while a dedicated pass adds what happens when a booking is cancelled after a reminder already sent, what happens across a timezone change, and what happens if payment fails after the slot is held.
Step 4: separate must-have from not-this-version, and mean it
A spec that lists twenty features as equally important is not a spec, it is a brainstorm. Ask directly:
From the feature list above, pick the 3 that this version cannot ship without, and move everything else under Not This Version with a one-line reason each.The reason matters as much as the split. "Not this version, because a landlord managing 4 units does not need bulk CSV import" is a decision someone can push back on. "Not this version" with no reason is just a list that will quietly get renegotiated feature by feature during the build.
A worked example
Idea: a simple tool for a solo personal trainer to track client sessions and payments. Inputs given: user is a trainer with 15-25 regular clients, on their phone between sessions; core job is logging a session and marking it paid; explicitly out of scope is scheduling and client-facing login; constraint is two weeks, no budget for a developer; success is logging a session in under 15 seconds.
The resulting spec's must-have list was three items: add a client, log a session against a client with a paid/unpaid toggle, and a weekly view of unpaid sessions. The edge case pass, run separately, surfaced a case the first draft missed entirely: what happens when a client is logged, then deleted, but has unpaid sessions attached. The answer it proposed, block deletion until sessions are marked resolved, became a real requirement instead of a bug found after launch.
What this does not replace
A generated spec is a strong first draft, not a finished decision. It will not know your actual budget beyond what you told it, it cannot talk to your users, and it will confidently fill any gap you leave open. Treat the output as something to argue with, not something to hand off unread. If you are about to turn the spec into a working build, how to write prompts for AI app builders covers translating a finished spec into the kind of prompt an app builder can act on, and how to validate an ai product idea is worth doing before you write the spec at all, not after. Before you can talk to real users, prompting AI to roleplay as a customer is a reasonable way to pressure-test the assumptions the spec is built on.
Once the spec exists, keep it. how to write a system prompt for a custom ai assistant and how to get consistent ai output every time both build on the same idea: front-loading context produces better output than a cleverer single sentence, whether you are asking for a spec, a prompt, or a piece of code.
FAQ
How long should an AI-generated product spec be?
Short enough that someone reads the whole thing. One to two pages for a small feature or MVP is normal. If the spec is running past three pages, the scope is usually too big for one version, not the spec too short.
Can I skip straight to asking for the spec without giving context first?
You can, and you will get a plausible-sounding spec back. It will just be wrong about the parts you didn't specify, and you will not know which parts those are until later.
Should I use the same prompt for a technical spec and a product spec?
No. A product spec describes what the thing does and for whom. A technical spec describes how it is built: data model, APIs, architecture. Asking for both in one prompt usually produces a shallow version of each.
What if AI's edge cases are wrong for my situation?
Common, especially for anything domain-specific. Treat the list as a starting point to correct, not a final answer. The value is in surfacing cases you hadn't thought of, even if half its guesses about what should happen are off.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
