The 9-Phase AI PRD Workflow: From Problem Brief to Build Checklist

Here's what happens when a PM types "write me a PRD for [feature]" into ChatGPT: the model produces something that looks like a PRD. It has sections. It has confident language. It has bullet points. And it's almost certainly useless — generic paragraphs that could describe any product, metrics that can't be measured, and an architecture section that doesn't know your stack exists.

Aakash Gupta and Miqdad Jaffer (OpenAI) diagnosed this precisely: AI-generated PRDs without structure produce "overly long documents that said nothing. As a result, how much PRDs were read dropped off a cliff." The problem isn't the AI. The problem is feeding it a one-line prompt and expecting a production-ready specification.

Product managers spend 30–50% of their working week on documentation (Productboard, Knowlee.ai). A single PRD can consume 3–5 days of drafting, iterating, and aligning. Meanwhile, 59.8% of PM teams report "time saved on repetitive tasks" as AI's top value (ProductPlan, 2026). The gap between "AI saves time" and "AI produces strategic output" is a workflow problem — and it's solvable.

This post is the solution: a 9-phase AI PRD workflow that chains your product thinking into a pipeline. Each phase feeds the next. Each phase has a specific AI prompt template, a defined output, and a PM's checkpoint. By the end, you go from "I have a feature idea" to "here's an engineering-ready PRD with a build checklist" — in roughly 2 hours instead of 3–5 days.

For the foundational question of what AI can and can't write in product documentation, start with [INTERNAL_LINK: ai-for-product-managers-documentation]. If you've already built a prompt chain using our 5-component engine, this 9-phase workflow is the next layer of depth — taking you from PRD draft to build-ready specification. See [INTERNAL_LINK: automate-prd-writing-ai].

A PRD is not one document. It's a chain of decisions — each one constraining the next.

When you define the problem, you're setting the boundary for what solutions are valid. When you define success criteria, you're creating the yardstick that engineering will build toward and stakeholders will evaluate against. When you define the tech foundation, you're drawing the lines that module specs must stay inside. Skip a phase, and downstream decisions float on assumptions.

A single AI prompt collapses this chain into a flat output. The model guesses at your problem, invents metrics, assumes a generic architecture, and produces a document that reads smoothly but contains no real constraints. The result is what Gupta and Jaffer observed: long documents nobody reads, because they contain nothing specific enough to act on.

The 9-phase workflow solves this by making each decision explicit. Each phase is a separate AI interaction — a prompt with a specific job — and the output of each phase feeds the next as input. The AI never has to guess because the previous phase already answered the question.

This also prevents what we call the illusion of completeness: the trap where an AI-generated PRD feels done because it's well-formatted, but misses the organizational context, technical constraints, and edge cases that make it actually useful. For a deeper diagnosis of this pattern, see [INTERNAL_LINK: illusion-of-completeness-ai-prd].

Here's the pipeline at a glance:

code

PROBLEM BRIEF → SUCCESS CRITERIA → TECH FOUNDATION → ENTITY DICTIONARY
                                                              ↓
BUILD CHECKLIST ← AI CONTEXT BLOCK ← TEST PLAN ← MODULE SPECS ← MODULE MAP

Each arrow is a phase transition. Each transition carries forward the decisions made in the previous phase. Nothing gets lost. Nothing gets invented.

Time: 15 minutes (PM) + 3 minutes (AI)

Most PRDs start with a solution. "We need a notification preferences page." That's not a problem. That's a solution dressed as a requirement. The problem brief forces you to define what you're solving before you decide how to solve it.

What Goes Into the Problem Brief

A problem brief has five sections. Fill them out before touching AI:

Product Context: One paragraph. What product area? Current state? What changed?
Problem Evidence: A user quote, a ticket count, a data point, a support trend. Not "users want." Evidence.
Who Is Affected: Specific user segment. How many? How much does it cost them?
Organizational Context: Why now? What's the strategic driver? What happens if we wait?
Non-Goals: Minimum 3 specific things this feature will NOT do.

Here's a real example from a B2B SaaS product:

code

Product Context: Power users (3+ sessions/week) of our analytics dashboard
have been progressively disabling notifications since the Q2 push migration.
Current notification settings are binary on/off per channel — no frequency
control, no quiet hours, no digest options.

Problem Evidence: 41% of power users have disabled all notifications.
127 support tickets about notification fatigue in Q3. User interview quote:
"I turned them all off after getting 3 alerts during a single client meeting."

Who Is Affected: 840 power users (out of 2,100 total). These users account
for 62% of expansion revenue.

Organizational Context: Q3 OKR is "reduce power user churn from 8.2% to
below 5%." Notification fatigue is the #2 churn driver in exit surveys.
Competitor launched granular notification controls last quarter.

Non-Goals: Will NOT add SMS/email channels. Will NOT change notification
permission model. Will NOT introduce AI-driven notification prioritization.

The AI Prompt

Feed your 5-section brief to the AI and ask it to expand:

code

Using the problem brief below, write the Problem Statement section of a PRD.
Structure it as:

1. Current State (what exists today, who it affects)
2. Problem Evidence (cite every data point from the brief — do not fabricate)
3. Impact Assessment (quantify the cost of inaction)
4. Strategic Context (why this matters NOW, connection to company goals)
5. Non-Goals (list as-is from the brief)

Problem Brief:
[paste your 5 sections]

If any claim cannot be verified from the brief, flag it with [NEEDS PM INPUT:
what specific information is missing]. Do not fabricate statistics or quotes.

What you get: A 400–600 word problem statement anchored in your evidence, connected to strategic context, with explicit non-goals. It should pass the "would an engineer believe this?" test.

PM's checkpoint: Read the expanded problem statement. Does the evidence hold? Is the strategic context accurate? Did the AI fabricate anything? If a data point appeared that you didn't provide, flag it and regenerate with "Do not add statistics not present in the brief."

Time: 10 minutes (PM) + 2 minutes (AI)

Product managers often skip this step because it's hard. "Improve user satisfaction" feels directionally correct and nobody challenges it. But vague success criteria are the #1 reason PRDs produce features that ship and don't matter.

The Rule for Success Criteria

Every success criterion must be numeric, time-bound, and falsifiable. That means someone could look at the data 90 days after launch and say "this worked" or "this didn't" — with zero ambiguity.

Bad: "Improve notification engagement." Good: "Power user notification opt-out rate drops from 41% to below 15% within 60 days of launch."

Bad: "Users should find notifications useful." Good: "Notification click-through rate exceeds 12% (current: 4.3%) within 90 days."

The AI Prompt

Feed Phase 1's output and ask the AI to stress-test your criteria:

code

Using the problem statement below, propose 4-6 success criteria. Each criterion must be:

- Numeric (a specific number, not a direction)
- Time-bound (a specific timeframe: 30/60/90 days)
- Falsifiable (you can definitively say "pass" or "fail" at the deadline)

Additionally, for each criterion, identify:
- The baseline value today
- The data source that will provide the measurement
- One scenario where the criterion passes but the feature still fails
  (the "gaming the metric" test)

Problem Statement:
[paste Phase 1 output]

What you get: 4–6 criteria that are actually measurable, plus a "gaming the metric" analysis for each that catches vanity metrics.

PM's checkpoint: Pick 3–4 criteria you'll actually track. Delete the rest. Add any criteria the AI missed that your VP or stakeholders will ask about. The AI doesn't know your leadership's priorities.

Time: 10 minutes (PM) + 3 minutes (AI)

This is the phase most PMs skip — and the one engineering will thank you for. The tech foundation documents what already exists, what can't change, and what constraints the architecture imposes. Without it, the AI will design a solution that assumes a greenfield architecture.

What Goes Into the Tech Foundation

Existing Infrastructure: What systems does this feature touch? (e.g., "Push notification service — Firebase Cloud Messaging, current rate limit 500/second")
Integration Points: What APIs, data pipelines, or services connect here?
Data Model Constraints: What can't change? What schemas are locked?
Technical Debt Considerations: What's fragile? What's scheduled for refactor?
Architecture Decisions: Any firm choices already made ("We're using event-driven, not polling")

The AI Prompt

code

Using the problem statement and the technical constraints below, write the
Technical Context section of a PRD. Structure it as:

1. Existing Infrastructure (systems this feature touches, their constraints)
2. Integration Surface (APIs, services, data flows — list each with its contract)
3. Data Model Boundaries (schemas that cannot change, fields that are locked)
4. Technical Debt Notes (fragile areas, known limitations, upcoming refactors)
5. Architecture Decisions (firm choices that constrain the solution space)

Problem Statement:
[paste Phase 1 output]

Technical Constraints:
[paste your 5 tech foundation sections]

If any constraint conflicts with a likely solution approach, flag it as
[CONSTRAINT CONFLICT: description and options].

What you get: A technical context section that engineers will read and think "this PM understands our stack." It surfaces conflicts early — before they become blocking issues in sprint planning.

PM's checkpoint: Run this section past your tech lead. 10 minutes now saves hours of rework later. Ask: "Did I miss anything?"

Time: 10 minutes (PM) + 4 minutes (AI)

Every PRD has domain concepts: User, Notification, Channel, Preference, Quiet Hours, Digest. When different sections of the PRD use the same word to mean different things — or different words to mean the same thing — engineering builds the wrong thing.

The entity dictionary is the antidote. It's a shared vocabulary that every subsequent phase references.

What an Entity Dictionary Contains

For each entity: name, definition, attributes (with types), relationships to other entities, lifecycle states, and validation rules.

Example entry:

code

Entity: Notification Preference
Definition: A user's configuration for receiving a specific type of notification
           through a specific channel
Attributes:
  - user_id (FK → User)
  - notification_type (enum: ALERT, DIGEST, SUMMARY, MENTION)
  - channel (enum: IN_APP, PUSH, EMAIL)
  - frequency (enum: IMMEDIATE, HOURLY, DAILY, WEEKLY, OFF)
  - quiet_hours_start (time, nullable)
  - quiet_hours_end (time, nullable)
  - created_at (timestamp)
  - updated_at (timestamp)
Relationships:
  - Belongs to User (many-to-one)
  - Constrained by Channel Capability (many-to-one)
Lifecycle: Created (default: IMMEDIATE) → Updated (user changes) → Archived
           (30 days after user sets to OFF)
Validation:
  - quiet_hours_start must be < quiet_hours_end
  - Cannot set frequency=IMMEDIATE and have quiet hours
  - Channel must be enabled at account level

The AI Prompt

code

Using the problem statement and technical context below, generate an Entity
Dictionary. For each domain entity this feature touches, define:

1. Name (singular, PascalCase)
2. Definition (one sentence that distinguishes it from similar entities)
3. Attributes (name, type, nullable, default — in a table)
4. Relationships (to other entities, with cardinality)
5. Lifecycle (states and transitions)
6. Validation Rules (what must be true for this entity to be valid)

Start with a seed list: [list 3-5 core entities you already know exist]

Problem Statement:
[paste Phase 1 output]

Technical Context:
[paste Phase 3 output]

What you get: A complete entity dictionary — typically 8–15 entities for a medium-complexity feature. This becomes the reference that Phases 5 and 6 build on.

PM's checkpoint: Review every entity. Add any the AI missed. Correct attribute names that don't match your team's conventions. This is the vocabulary document — get the names right.

Time: 10 minutes (PM) + 4 minutes (AI)

A PRD that reads as one monolithic feature produces a build that takes one monolithic sprint — and ships late. The module map decomposes the feature into independent, buildable modules with clear ownership boundaries and dependency arrows.

The Module Map Structure

For each module: name, responsibility (one sentence), entities it owns (from Phase 4), inputs, outputs, dependencies (on other modules), and estimated complexity (S/M/L).

The map should show module dependencies as a directed graph — if Module B depends on Module A, A must be built first.

The AI Prompt

code

Using the entity dictionary and technical context below, propose a module
decomposition for this feature. For each module, define:

1. Module Name (short, descriptive)
2. Responsibility (exactly what this module owns — one sentence)
3. Entities Owned (from the entity dictionary)
4. Inputs (what data/events this module consumes)
5. Outputs (what data/events this module produces)
6. Dependencies (other modules it requires — list by name)
7. Complexity (S = 1-2 days, M = 3-5 days, L = 1-2 weeks)
8. Owner (suggested: [Frontend/Backend/Full-Stack/Data/Platform])

Then produce a dependency graph showing build order. Module with zero
dependencies = Build First. Module that others depend on = Build Early.

Entity Dictionary:
[paste Phase 4 output]

Technical Context:
[paste Phase 3 output]

What you get: A module decomposition with 4–8 modules, each scoped to a single engineering owner, with explicit dependency arrows.

PM's checkpoint: Review the module boundaries. Are the dependencies right? Is anything scoped too large (L when it should be two Ms)? Run this past your engineering lead for a 5-minute sanity check.

Time: 5 minutes per module (AI) + 5 minutes per module (PM review)

This is the heavy-lifting phase. For each module identified in Phase 5, the AI generates a detailed spec: what it does, how it behaves, what happens when it fails, and what edge cases it must handle.

The Module Spec Template

For each module: functional description, API contract (if applicable), UI behavior (if applicable), error states, edge cases, and integration test scenarios.

The AI Prompt (run once per module)

code

Using the entity dictionary and module map below, write a detailed spec for
the [MODULE NAME] module. Include:

1. Functional Description (what this module does, in 2-3 paragraphs)
2. Input Specification (exact data shape, validation rules for each field)
3. Output Specification (exact data shape, when and how output is produced)
4. Behavior Rules (if X happens, module does Y — list all branches)
5. Error States (what happens when: input invalid, dependency unavailable,
   rate limit hit, timeout, data inconsistency)
6. Edge Cases (minimum 5: empty states, boundary values, concurrency,
   permissions, data migration scenarios)
7. Integration Points (exact API calls or events this module sends/receives)

Entity Dictionary:
[paste Phase 4 output]

Module Map:
[paste Phase 5 output]

Module to Spec: [MODULE NAME]

What you get: A 500–800 word spec per module that an engineer can implement without asking "what should happen when..."

PM's checkpoint: Read each spec for completeness. Edge cases are the highest-value section — the AI will catch things you didn't think of. Add any domain-specific edge cases the AI can't know about.

Time: 5 minutes (AI) + 10 minutes (PM review)

The test plan converts module specs into verifiable acceptance criteria. It covers three layers: unit tests (per module), integration tests (module interactions), and user acceptance tests (end-to-end scenarios).

Each test case has a PASS/FAIL condition. No ambiguity.

The AI Prompt

code

Using the module specs below, generate a test plan with three layers:

1. Unit Test Cases (per module): For each module, list test cases covering
   happy path, error states, and edge cases. Each test: [MODULE] → [SCENARIO]
   → [EXPECTED RESULT] → PASS/FAIL condition.

2. Integration Test Cases: Test interactions between modules. Each test:
   [MODULE A] ↔ [MODULE B] → [SCENARIO] → [EXPECTED RESULT] → PASS/FAIL.

3. User Acceptance Test Cases: End-to-end scenarios from a user's perspective.
   Each test: [USER PERSONA] → [ACTION SEQUENCE] → [EXPECTED OUTCOME] →
   PASS/FAIL.

For each test case, assign a priority: P0 (must pass to ship), P1 (should
pass, can waive with documentation), P2 (nice to have).

Module Specs:
[paste Phase 6 output — all modules]

What you get: A test plan with 15–30 test cases across three layers, prioritized, with unambiguous PASS/FAIL conditions.

PM's checkpoint: Focus on the UAT cases. These are what you'll demo to stakeholders. Are they testing the right things? Do they match the success criteria from Phase 2?

Time: 5 minutes (AI) + 5 minutes (PM review)

If your engineering team uses AI coding agents (Claude Code, Cursor, Copilot, Codex), this phase is a force multiplier. The AI context block compiles the key decisions from Phases 1–7 into a system prompt that carries the full context of your PRD. When an engineer prompts "build the notification preference module," the agent already knows the entity dictionary, the module boundaries, the tech constraints, and the acceptance criteria.

The AI Prompt

code

Using the full PRD below, compile an AI Context Block — a system prompt that
a coding agent (Claude Code, Cursor, Copilot) will use as context when
generating code for this feature. The context block must include:

1. Feature Summary (3 sentences — what we're building and why)
2. Technical Constraints (must-use infrastructure, cannot-change schemas,
   rate limits, integration contracts)
3. Entity Dictionary (condensed — name, key attributes, relationships only)
4. Module Architecture (what each module owns, dependencies, build order)
5. Coding Conventions (language, framework, patterns your team uses)
6. Acceptance Criteria Summary (the P0 test cases that must pass)
7. Forbidden Patterns (things the agent MUST NOT do — specific and explicit)

Full PRD:
[paste all previous phase outputs, condensed]

Format the context block as a single markdown code block. It should be
pasteable as-is into a coding agent's system prompt.

What you get: A 300–500 word system prompt that carries the PRD's architectural DNA into every AI-generated line of code.

PM's checkpoint: Review with engineering. They'll know what to add. The forbidden patterns section is especially high-leverage — "don't add a new database table," "don't introduce a new dependency without approval."

Time: 5 minutes (AI) + 10 minutes (PM review)

The build checklist is what engineering actually works from. It sequences the modules from Phase 5 into a build order, adds verification gates between each module, and estimates total timeline.

The AI Prompt

code

Using the module map and module specs below, generate a Build Checklist.
Structure it as:

1. Pre-Build Verification (things that must be true before engineering starts:
   environments ready, access granted, dependencies available)

2. Build Sequence (modules in dependency order — each module includes:
   - Module name and owner
   - Estimated effort (from module map)
   - Dependencies (must be complete before this starts)
   - Key files/locations (suggested)
   - Verification Gate (what must pass before marking this module complete)

3. Integration Milestones (after which modules do we run integration tests?)

4. Final Verification (the full test plan run, all P0 tests passing)

5. Ship Checklist (feature flag enabled, monitoring dashboard live, runbook
   created, stakeholder communication sent)

Module Map:
[paste Phase 5 output]

Module Specs (summarized):
[paste key points from Phase 6]

Test Plan:
[paste Phase 7 output]

What you get: A sequenced, dependency-aware build checklist that an engineering manager can assign in the next sprint planning.

PM's checkpoint: This is your handoff document. Review it with the most detail. Is the build order realistic? Are verification gates specific enough? Will an engineer know exactly what "done" means for each module?

Here's the complete pipeline with estimated times. The PM's time is front-loaded into Phases 1–3 (defining the problem, criteria, and constraints). The AI's time is concentrated in Phases 4–9 (generating structured output from structured input).

Phase	PM Time	AI Time	Output
1: Problem Brief	15 min	3 min	Problem Statement (400-600 words)
2: Success Criteria	10 min	2 min	3-4 Measurable Criteria
3: Tech Foundation	10 min	3 min	Technical Context Section
4: Entity Dictionary	10 min	4 min	8-15 Entities Defined
5: Module Map	10 min	4 min	4-8 Modules, Dependency Graph
6: Module Specs	25 min	20 min	Detailed Spec Per Module
7: Test Plan	10 min	5 min	15-30 Test Cases (3 Layers)
8: AI Context Block	5 min	5 min	System Prompt for Coding Agent
9: Build Checklist	10 min	5 min	Sequenced Build Checklist
Total	~105 min	~51 min	Engineering-Ready PRD

Total elapsed time: roughly 2 hours of PM work spread across the nine phases. Compare that to the 3–5 days of manual PRD drafting — and the output is more structured, more constraint-aware, and more actionable than what most PMs produce in a week.

The 2 hours is not continuous. You'll likely run Phases 1–3 in one sitting (35 minutes), let the AI generate Phases 4–9 in the background (or sequentially), and spend another hour reviewing and refining. But the assembly work — the typing, formatting, structuring, cross-referencing — is gone. The PM's time shifts entirely to judgment: Is this right? What's missing? What would my engineering lead object to?

📥 9-Phase AI PRD Workflow Checklist — The complete 9-phase pipeline with prompt templates, checkpoint criteria, and the build-ready output structure. Download and run your next PRD through the full workflow. Download the checklist →

What's Next

[INTERNAL_LINK: ai-for-product-managers-documentation] — The pillar post: what AI can and can't write in PM documentation
[INTERNAL_LINK: automate-prd-writing-ai] — The 5-component AI PRD engine: input template, prompt chain, constraint validation, human review, and distribution
[INTERNAL_LINK: illusion-of-completeness-ai-prd] — Why AI PRDs feel done but aren't, and the 10-point completeness test
[INTERNAL_LINK: measurable-constraints-framework] — The full constraint framework behind the validation gates in this workflow
[INTERNAL_LINK: 5-ai-tools-prd-writing-compared-2026] — Claude vs ChatGPT vs Gemini vs Grok vs Copilot for PRD writing

Sources & Further Reading

Productboard. "The State of Product Management." October 2025. https://www.productboard.com/
Knowlee.ai. "Enterprise AI Guide for Product Managers." 2026. https://www.knowlee.ai/
Gupta, Aakash & Jaffer, Miqdad. "How to Write Product Requirement Docs (PRDs) in the AI Era." August 2025. https://www.news.aakashg.com/p/ai-prd
ProductPlan. "The State of Product Management Report." 2026. https://productplan.com/
Mai, Johnny. "A Day in the Life of a PM at Microsoft." 2026.
Sikder, Rahul. "We Used AI Tools to Write Our PRD — Here Are the Results." Medium, September 2025. https://medium.com/@rahul.sikder3/we-used-ai-tools-to-write-our-prd-here-are-the-results-8c6043014a9b
Sharma, Shailesh. "The Last Product Manager." Substack, 2026.
Pereira, David. "The Skills I Cultivated for 15 Years Are Now Available for Free." via Roberto Hortal, 2026.
airfocus by Lucid. "The PM Bottleneck." 2026. https://airfocus.com/

The 9-Phase AI PRD Workflow: From Problem Brief to Build Checklist

What Goes Into the Problem Brief

The AI Prompt

The Rule for Success Criteria

The AI Prompt

What Goes Into the Tech Foundation

The AI Prompt

What an Entity Dictionary Contains

The AI Prompt

The Module Map Structure

The AI Prompt

The Module Spec Template

The AI Prompt (run once per module)

The AI Prompt

The AI Prompt

The AI Prompt

What's Next

Sources & Further Reading

Go Deeper

More in PM Automation

5 AI Tools for PRD Writing Compared (2026): The Results May Surprise You

The 80/20 Rule of AI Documentation: What PMs Should Outsource (and What They Can't)

AI for Product Managers Documentation: What AI Can (and Can't) Write