AI product practice: PRDs, teams, governance and career
Bring it all together. This module covers the documents, team habits and governance that make AI products work — and how to show employers you can lead them.
Learning objectives
- Write an AI PRD that specifies behaviour under uncertainty
- Run output reviews and error analysis with your team
- Build governance checkpoints into the product process
- Assemble an AI PM portfolio and prepare for interviews
6.1 The AI product requirements document
A traditional PRD lists features and acceptance tests. An AI PRD must also specify behaviour under uncertainty. Use these sections:
| Problem and users | Who, what job, evidence of the pain |
| AI's role and autonomy | Assist, automate or act; tools and permissions; human oversight |
| Context | What data the AI sees at the moment of use, and what it must never see |
| Quality spec | Eval set, grading method, launch thresholds, must-never conditions |
| Experience | How uncertainty, errors, feedback and handover appear to users |
| Budget | Target cost per task and latency |
| Launch and monitoring | Rollout stages, kill switch triggers, metrics tree |
| Risk and compliance | Risk classification, privacy, fairness checks, transparency, owner |
6.2 Working with an AI product team
AI products need more disciplines at the table: AI or ML engineers, data engineers, designers, domain experts who judge quality, and legal, privacy and security partners. Two rituals make the biggest difference:
- Read the outputs together — a regular session where the team reviews real outputs, especially failures. It builds shared judgement faster than any dashboard.
- Error analysis — group failures into types (wrong facts, missed instructions, bad tone, wrong tool), count them, and fix the biggest category first.
The PM's role is to own the quality bar and the trade-offs — not to write the prompts, though being able to prototype one helps enormously.
6.3 Governance checkpoints
Build these into your product process rather than leaving them to the end:
- At framing: classify the risk (for example under the EU AI Act), and check whether personal data is involved
- Before beta: data protection impact assessment where needed, red-teaming, fairness checks across user groups
- Before launch: transparency to users (labelling AI interactions and content where required), documentation such as a system card, incident plan
- After major changes: including model migrations — re-run the checks that could be affected
Microsoft's Guidelines for Human-AI Interaction are a useful design review checklist, organised by initial interaction, during interaction, when the AI is wrong, and over time. See also AI Governance, Risk & Compliance.
6.4 Growing your AI product career
Employers hiring AI product managers look for evidence that you can do the work, not just talk about it. Build a small portfolio:
- A working prototype of an AI feature, built with an AI assistant or no-code tool, with a short write-up of what failed
- An eval set and results for that prototype — few candidates have one
- An AI PRD using the template in 6.1
- A product teardown of a public AI feature: what it does well, where it fails, how you'd measure and improve it
Common interview questions include: "How would you measure the success of this AI feature?", "When would you not use AI?", "The model is right 85% of the time — would you ship it?" (the answer depends on the cost of the 15% and how easily users notice and recover) and "How would you price an AI feature with variable costs?" This course and AI Product Management give you the frameworks to answer each one.
Write a two-page AI PRD for a feature of your choice using all eight sections in 6.1. Include a cost-per-task estimate (Module 2), autonomy levels per tool if it's agentic (Module 3), a metrics tree (Module 4) and a migration plan for the model it depends on (Module 5).
See a worked example
Outline for 'AI claim triage' at an insurer: Problem: 3-day wait for first review. Role: classify and route claims, draft requests for missing documents (augment; handlers approve). Context: claim form and photos; never medical records. Quality: 600-case eval set, ≥ 92% correct routing, 0 auto-declined claims. Experience: confidence shown, one-click re-route. Budget: under 10p per claim, under 5s. Launch: one region, 3 stages, kill switch on routing accuracy below 85%. Risk: fairness check by claim type and region; DPIA; system card; owner — claims product lead.
Key takeaways
- An AI PRD specifies context, quality, autonomy, budget and risk.
- Read real outputs together; fix the biggest error type first.
- Governance checks belong at framing, beta, launch and after changes.
- A prototype, an eval set, a PRD and a teardown make a strong portfolio.
- 'Would you ship at 85%?' depends on the cost of the errors.