TL;DR

Most "AI for product managers" content is about tools: ChatPRD, Notion AI, ChatGPT prompts. That's the wrong layer. The dominant variable in PM AI output is not which tool you pick — it's whether you wrote a spec before prompting. This post is a worked example: a real PRD-style brief, written from a 6-section spec, in 30 minutes, with the exact prompt and the exact AI output. Same method as spec-driven AI for engineers, different artifact.

Why PM AI tools don't get you faster

I've watched PMs in Dhaka and Singapore go through the same cycle:

1. Discover ChatPRD or a PRD template library. Feel productive for 2 weeks.
2. Plateau. The templates produce generic PRDs. Engineering still pushes back with "this doesn't say what the user does."
3. Revert to writing PRDs by hand. Conclude that AI doesn't really help PM work.

The diagnosis is the same as for vibe-coding engineers: the tools give you starting points, not endings. Without a spec, the AI defaults to the most common PRD pattern, which is the bad one — feature lists, no metrics, no failure modes.

The fix is also the same. Stop using AI as a template engine, start using it as a contract-following implementer.

A real worked example

I'm going to walk through writing a PRD for a real feature. The setup is composed (not from any specific company) to keep this useful as a worked example. The method is identical to how I'd write a real one.

The feature: A "share your invoice" button that lets a bootcamp participant generate a public, read-only invoice URL to share with their employer for reimbursement.

The audience for the PRD: senior engineering, who will scope and build it.

Time budget: 30 minutes total. 10 minutes for the spec, 5 minutes for the prompt, 15 minutes reviewing and tightening the output.

Step 1: Write the spec (10 minutes)

Before opening any AI tool, in plain Markdown:

## Artifact
A PRD for a "Share invoice" feature on the bootcamp participant portal.

## Audience
Senior engineering leadership at a 6-person startup.

## Required sections (in this order)
1. Problem statement (3 sentences max, must reference a specific user
   pain we have evidence for)
2. Current state (what happens today without this feature)
3. Proposed change (one paragraph)
4. Success metrics (3 quantifiable, each with how-measured + by-when)
5. Non-goals (what we are explicitly NOT building)
6. Risks (top 3, each with one-line mitigation)

## Constraints
- Active voice only
- No vendor-specific solution language
- Each section under 100 words
- Cite the user pain claim with at least one piece of evidence

## Failure modes to prevent
- Don't propose a feature without naming a user it serves
- Don't list 10 metrics — exactly 3, each measurable
- Don't include implementation details (engineering decides those)
- Don't be hedgy. State what we'll do, not what we might consider

## Context
- The bootcamp is a 5-day intensive in Dhaka, BDT 100 refundable deposit
- 40% of participants pay personally, then need to expense to their employer
- Current "invoice" is a screenshot of the portal — looks unprofessional
- 3 participants in the last batch asked for a "real PDF invoice" to send HR
- We have no PDF generation infrastructure today

That's the spec. Notice: no AI tool open yet. The spec is doing all the structural thinking.

Step 2: The prompt (5 minutes)

I paste the spec into Claude (the prompt is just the spec, plus one line):

Write the PRD per the spec below. Follow every constraint and avoid
every failure mode listed.

[paste full spec]

That's it. No "act as a senior PM," no "be concise." The constraints are in the spec; the AI follows them.

Step 3: The output (and what to edit)

What Claude produced (lightly edited for readability):

Share Invoice — PRD

Problem statement

Bootcamp participants who pay personally need a professional invoice to expense to their employer. Today they screenshot the portal, which looks unprofessional and 3 participants in the last batch explicitly asked for a real invoice. This friction risks losing employer-reimbursed registrations, who are ~40% of our participant base.

Current state

Participants see their registration in the portal with the BDT amount paid. They have no way to generate or share a clean record. Workarounds we see: portal screenshots forwarded to HR, manual emails asking us to send a "proper invoice," and at least one case of dropped registration when HR rejected the screenshot.

Proposed change

Add a "Share invoice" button to the participant portal that generates a public, read-only invoice URL (/invoice/[opaque-code]) showing the participant's name, bootcamp title, BDT amount, bKash transaction ID, and date paid. The URL is opaque-coded so it's safe to share but not enumerable.

Success metrics

1. Invoice generation rate: ≥30% of paid participants generate an invoice within 7 days of payment. Measured via server-side analytics event invoice_generated. Target hit by end of next batch.
2. Employer-reimbursement satisfaction: Survey at end of bootcamp asks "Was the invoice accepted by your employer?" — target ≥90% Yes. Measured via post-batch survey.
3. Support tickets for invoice requests: Drop to zero within 30 days of launch. Measured by tagging invoice_request in the support inbox.

Non-goals

• PDF download (the URL is the invoice; viewers can print to PDF themselves)
• Editable invoice fields
• Multi-currency support
• Tax documentation features

Risks

1. Public URL leak via screenshot or sharing. Mitigation: opaque codes plus no PII beyond participant name; no payment method displayed.
2. Employers reject the format. Mitigation: design the page to look like a printable invoice (header, table, total) before launch.
3. bKash transaction ID exposure. Mitigation: confirm with bKash that displaying the trxID on a participant-facing URL is acceptable per their merchant terms.

Step 4: What I edited (15 minutes)

Three edits, all targeted:

1. Success metric #1 was too vague on timing. Changed "by end of next batch" to "within 30 days of launch" because batch boundaries don't align with the launch timeline.
2. Risk #2 needed a specific mitigation owner. Added "design owns the printable layout, due before engineering starts implementation."
3. Added a "Dependencies" section the spec didn't ask for, because mid-review I realized this requires the analytics events table to exist — which it does, but the engineering team would want it called out.

Total time: ~30 minutes for a PRD that would normally take me 90 minutes to write from scratch.

What made this work

Two things, both about the spec:

1. Failure modes were named. "Don't list 10 metrics — exactly 3" prevented the most common bad-PRD pattern. The AI didn't have to guess.

2. Context was structured, not prose. The four bullets under ## Context gave the AI evidence to cite. The "3 participants in the last batch asked for a real PDF invoice" reappeared verbatim in the Problem Statement because it was a concrete fact to anchor on.

How to apply this to your work this week

Pick a PRD or design doc you'd normally spend 90+ minutes on. Before you open ChatGPT or Claude:

1. Write your spec in plain Markdown — by hand, or with the free Spec Builder. 5-10 minutes.
2. Paste the spec into the AI with one line: "Write the artifact per the spec below."
3. Read the output once. Make 2-3 targeted edits per day 3's discipline — name the specific gap, don't ask for vague rewrites.
4. Ship.

You'll cut your time on structured docs by 50-70% and the output will be more consistent across your team because everyone is following the same spec template.

If you'd like to do this with hands-on review of your specs by other PMs in a small group, the bootcamp includes a non-engineering track. Otherwise, this method is everything you need; the rest is the doing.

Further reading

• ChatPRD — purpose-built PM AI tool, useful complement to the method above
• Productboard: 6 AI Prompt Templates for Product Managers
• Product School: Top 21 AI Tools for Product Managers
• Bagel.ai: 50+ AI Prompts Product Managers Use Weekly