AI drafts product specifications more accurately when the key decisions are already made — scope defined, constraints known, acceptance criteria roughed out. The brief that makes a good AI prompt is the same thinking a good spec requires: if you can’t write the brief clearly, you’re not ready to write the specification.
In the past two years I’ve written specifications for a Next.js frontend migration, an Elasticsearch search platform, a headless CMS rollout, and dozens of smaller features sitting on top of a complex booking engine. These aren’t simple specifications — they involve technical constraints, commercial dependencies, and integration points that aren’t visible in the feature request.
For most of them, I now use AI to draft the initial structure and first pass. Not to replace the thinking — to compress the time between the thinking being done and the document that represents it.
Here’s what that actually looks like, what it changed, and what I still write myself.
Why specifications are a good candidate — and a tricky one
A specification has a predictable structure: user story, acceptance criteria, edge cases, out of scope, open questions, dependencies. The format is well-understood. The challenge is rarely the structure — it’s knowing which edge cases matter for your specific system, which out-of-scope decisions will surface as stakeholder arguments later, and how precisely to describe the boundary between what’s in and what isn’t.
AI is good at structure. It’s poor at system-specific judgement. That distinction is what makes it useful here rather than dangerous — as long as you use it in the right sequence.
The sequence that works
I don’t ask AI to write a specification. I ask it to draft a specification given decisions I’ve already made. The difference is the order: thinking first, drafting second.
A prompt that works includes: the user story in my own words, the context (where in the journey this feature sits, what comes before and after), the acceptance criteria I’ve already decided on in rough form, the constraints I know about — technical, regulatory, commercial — and explicitly what the spec doesn’t need to cover.
What I’m doing is encoding my decisions into the prompt. The AI fills in the structure, formats acceptance criteria correctly, identifies obvious edge cases I should consider, and flags open questions. It doesn’t make product decisions — those are already defined before the prompt is written.
What the first AI draft looks like — and where it needs your judgment
The first draft is usually 70–80% right. Structure is correct. Acceptance criteria are well-formed. Edge cases are mostly there, but often generic rather than system-specific — “what happens if the network times out” rather than “what happens when the Elasticsearch cluster fails over mid-search and the fallback returns stale results.”
What I edit: acceptance criteria that require system knowledge I haven’t provided, edge cases that don’t apply to our architecture, and — most importantly — anywhere the AI has resolved an ambiguity rather than flagged it. That last one is the critical review point. AI defaults to filling gaps rather than surfacing them. I want to see the gaps, because that’s where the engineering risk usually sits.
Where it doesn’t work
Specifications with significant architectural implications. If the feature requires understanding how our booking engine handles session state, or how our CMS propagates content to five brand frontends, the AI can structure the document but the acceptance criteria will be wrong without a level of technical context that takes as long to write as the spec itself.
It also breaks when the brief is vague. “Write a spec for the search feature” produces generic output that needs complete rewriting. “Write a spec for autocomplete behaviour on the destination field, where the constraint is sub-200ms response time and the data source is Elasticsearch with a custom synonym dictionary” produces something usable.
What I still write myself
Anything that touches a decision I haven’t made yet. If scope is genuinely uncertain, the spec needs to surface that uncertainty — not resolve it.
AI resolves. I surface.
The rationale section: why we’re building this, why now, what we’re deliberately not doing. That’s the product thinking that doesn’t survive delegation.
The context note to engineering: the paragraph at the top that says “the tricky bit is X, we explored Y and discarded it for Z reason, the approach we’re taking assumes W.” That context is what makes a specification a thinking document rather than just a requirements list — and it’s what prevents the same questions being relitigated in the first sprint review.
The practical takeaway
Use AI to draft the specification after the key decisions are made, not as a substitute for making them. If you can’t write a clear brief, you’re not ready to write the specification. The brief is the spec in compressed form — AI makes the expansion faster, it doesn’t replace the compression. Get the thinking done first. The drafting will follow quickly.
TL;DR
- AI handles specification structure well — user stories, acceptance criteria, edge case lists — but doesn’t know your system; system-specific constraints and architectural context must come from you
- The sequence that works: make the key decisions first, encode them into a precise prompt, then let AI draft the structure; the brief is the spec in compressed form
- The critical review point: anywhere the AI has resolved an ambiguity rather than flagged it — that’s where engineering risk sits
- What stays with you: scope decisions that aren’t yet made, the rationale section, and the context note to engineering that makes a spec a thinking document rather than a requirements list
Delphine Ragazzi is a Product Owner with 20 years of experience across digital analytics, CRO, and product delivery. She writes about product decisions, data, and AI at douli.com.
