PM Mapped
Working with AI WRITING GREAT SPECIFICATIONS · Specification Types

Specification Types with AI

AI drafts specifications quickly across types — functional, technical-adjacent, data, and more — and translates between levels of detail. The catch: it doesn't know your system's real constraints, so it produces confident, plausible specs that may not match reality. Treat output as a first draft to verify with your engineers.

← Back to the Specification Types tool
1How to use AI for this

A step-by-step way to work

1

Pick the right spec type for the job

Tell AI which kind of spec you need and who reads it — the format differs for a functional spec vs. a data spec.

2

Give it the real constraints

Supply the system facts it can't know; otherwise it invents plausible ones.

3

Draft, then translate

Get the detailed spec, then ask it to produce a stakeholder-friendly summary or a more detailed breakdown as needed.

4

Cross-check against criteria

Ask it to find inconsistencies between the spec and your acceptance criteria or PRD.

5

Verify with engineering

The spec isn't done until the people who'll build it confirm it matches the system.

2Worked examples

Real prompts, and what good output looks like

Translating between levels of detail
Your prompt

Turn this high-level intent into a functional spec a developer could work from: 'Let users undo their last action.'

What good output looks like

Functional spec — Undo last action: • An 'Undo' control appears after any reversible action (specify which actions are reversible). • Clicking Undo reverts the single most recent reversible action and shows confirmation. • Undo is available for [time window / until next action — decide]. • Non-reversible actions (e.g. permanent deletes) do not show Undo. • Open question: is multi-level undo in scope, or single-step only?

I've flagged the decisions you need to make — reversible-action list, time window, multi-level.

Notice the flags: AI turns vague intent into structure but correctly surfaces the decisions it can't make. Those bracketed items are yours and engineering's.
3Copy-paste template

A prompt you can reuse

Fill in the highlighted parts and paste it into your AI tool of choice. Edit the output — it's a starting point, not a finished answer.

Reusable prompt
Help me draft a [spec type: functional / data / technical-adjacent] specification for [reader: a developer / a stakeholder].

The feature/intent:
[describe what's being specified]

System facts you should use (don't invent others):
[real constraints, existing behaviour, data available]

Please:
1. Draft the spec in the appropriate format for that type and reader.
2. Mark every assumption and every decision I still need to make as a bracketed open item.
3. Flag anything that would need engineering to confirm against the real system.
4Common pitfalls

What AI gets wrong here

Invented system behaviour

AI describes how it imagines your system works, which may be wrong.

Do this instead: Supply real constraints and have engineering verify; don't ship specs referencing behaviour you can't confirm.

Wrong spec type for the audience

A developer spec and a stakeholder spec aren't interchangeable; AI may blur them.

Do this instead: State the reader explicitly and reject detail that's wrong for them.

False completeness

A tidy spec can look finished while hiding undecided questions.

Do this instead: Require open items to be surfaced as brackets, not silently resolved with a guess.
The judgment that stays yours

AI accelerates the writing of a spec, not the knowing of your system. It's strong at structure and at translating between levels of detail, but every confident claim about how things work needs your and your engineers' verification. Use it to draft and translate; reserve 'this matches reality' for the people who know the reality.