Case Study: From Meeting Notes to a Reviewable PRD
Combine goals, runtime, skills, tools, state, approvals, and evaluation into a product blueprint from meeting notes to a review-ready PRD.
“Agent Basics for Product Managers” part nine
Previous: Evaluating and Shipping Agent Products · Series home
The previous articles separated the core principles. Now we can recombine them into a product: a user provides meeting notes, business context, or a partial BRD, and the system advances the requirement toward a review-ready, traceable PRD.
This is not a chatbot that writes for a product manager. It is an agent-driven PM workspace.
1. Define the delegated outcome
The user is not delegating “write some PRD text.” The goal is to turn incomplete business material into a document that product, design, engineering, and QA can review, while preserving sources, assumptions, open questions, and risks.
Completion means goals, actors, scope, flows, edge cases, metrics, dependencies, and acceptance criteria pass a quality gate.
2. Let the main agent judge the stage
Idea / raw material → BRD co-creation → product definition
→ PRD writing → requirement review → launch reviewIf the user and business metric are unclear, the system should not pretend the material is ready. It may create a draft, but assumptions and gaps must remain visible.
3. Put repeatable methods in skills
| Skill | Question | Artifact |
|---|---|---|
| BRD co-creation | Are the problem, user, goal, and metric clear? | BRD draft, open questions |
| Product definition | What are the MVP, actors, flow, and boundaries? | Scope and priorities |
| PRD writing | How does the requirement become executable? | PRD, stories, acceptance criteria |
| Requirement review | Is the document ready for collaboration? | Score, blockers, proposed changes |
| Launch review | Did the product achieve its goal? | Metrics, lessons, next actions |
Skills preserve stable methods; the main agent routes between them. The team can improve the review rubric without rewriting the entire agent.
4. Make evidence status visible
Every important claim is a confirmed fact, agent assumption, pending confirmation, or high-risk item. The model's plausible completion becomes a visible product object instead of a hidden risk.
5. Keep tools narrow
Separate tools read source material, retrieve a requirement, propose a document patch, run a review, and submit an approval. Durable writes go through the product API, which verifies identity, permission, and version. There is no unbounded “manage requirement” tool.
6. Give chat and the workspace different jobs
Top: requirement stage, review status, save status
Left: agent questions, recommendations, and progress
Center: sources, BRD, product definition, PRD, review, retrospective
Right: current document, evidence labels, diff, and previewChat supports collaboration. Artifacts hold durable work. The status bar reflects formal state. The user answers a small number of questions that truly block the next stage rather than completing one giant questionnaire.
7. Control writes with proposals
After an answer, the agent creates a structured patch. The product layer validates the target, fields, and version. The interface displays the change. Approval creates a new version and audit event. Version and conflict checks prevent concurrent changes from silently overwriting one another.
8. Evaluate the complete task
Evaluation covers stage judgment, question value, evidence classification, skill and tool choice, PRD quality, unauthorized writes, approval behavior, recovery, user acceptance, completion time, and manual editing. Fluent writing is only a small part.
The product blueprint
| Layer | Design |
|---|---|
| Experience | Co-creation chat, artifact workspace, diff, approval |
| Product | Requirement, artifact, review, version, permission |
| Orchestration | Main agent, five skills, stage workflow, resume state |
| Capability | Document, patch, review, search, and business API tools |
| Model | Stage judgment, questions, drafting, structured output |
| Control | Evidence labels, schemas, approval, trace, evaluation, replay |
Product managers do not learn agent fundamentals to replace runtime engineers. They learn them to design a new software relationship: users delegate goals to a system while retaining the awareness, judgment, and control that matter.
Agent value comes from judgment and action. Trust comes from boundaries and evidence. A product needs both.
Evaluating and Shipping Agent Products
Evaluate outcomes, process, safety, and efficiency, then use release gates to make agent behavior controllable.
A Practical Font Guide for Independent Developers
A free commercial-use font guide for independent developers: choose by scenario, then review previews, licensing, CSS stacks, and a reusable coding-agent prompt.