Agent Basics for PMs

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 review

If 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

SkillQuestionArtifact
BRD co-creationAre the problem, user, goal, and metric clear?BRD draft, open questions
Product definitionWhat are the MVP, actors, flow, and boundaries?Scope and priorities
PRD writingHow does the requirement become executable?PRD, stories, acceptance criteria
Requirement reviewIs the document ready for collaboration?Score, blockers, proposed changes
Launch reviewDid 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 preview

Chat 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

LayerDesign
ExperienceCo-creation chat, artifact workspace, diff, approval
ProductRequirement, artifact, review, version, permission
OrchestrationMain agent, five skills, stage workflow, resume state
CapabilityDocument, patch, review, search, and business API tools
ModelStage judgment, questions, drafting, structured output
ControlEvidence 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.

On this page