
Stream a simulated run, inspect the notifications it would send on Slack and email, and see exactly where it sits in the 7-stage PM OS flow. No password required.
The short version
The PRD Generator agent runs every Monday at 11 AM, takes the top 2-3 prioritized opportunities, and auto-drafts a full PRD for each one. It grounds requirements in the actual research (interview quotes, journey friction, NPS drivers, support patterns), aligns with the design system, and surfaces technical constraints. The output has eight sections from goals and success metrics through risk and mitigation. The point isn't to skip the PM thinking. It's to skip the blank page and the meetings spent reconstructing context. PRDs take two hours to refine instead of ten hours to write. Connect your opportunity stack, research repo, and Figma, then generate one PRD this week.
Writing a PRD is a slog. You start with a prioritized opportunity ("SMB customers struggle with slow onboarding"), but turning that into an actual spec takes meetings with design, engineering, and leadership. You're translating research findings into requirements. You're documenting constraints. You're building in edge cases.
It takes weeks. And if you don't stay on top of it, it gets stale - the opportunity changes, the context shifts, and you're updating the old spec instead of writing a new one.
The PRD Generator agent automates the first draft. Every Monday, it takes prioritized opportunities and auto-generates detailed PRDs. Not final (you'll still refine), but thoughtful: grounded in research, aware of technical constraints, and structured for engineering.
How It Works
The agent ingests multiple data sources and synthesizes them into a spec:
Opportunity context: The prioritized opportunity with problem statement, affected segments, and expected impact.
Research context: Related interviews, journey maps, and user feedback that support the opportunity. The agent grounds the PRD in actual customer pain, not hunches.
Design specs: Existing wireframes, design systems, or design notes. The agent ensures the PRD aligns with design direction (or flags misalignment).
Technical context: Engineering notes, API documentation, and tech debt impacts. The agent estimates: would this work with current architecture? Are there dependencies?
The output: a complete PRD with goals, success metrics, technical approach, and implementation notes.
Data Sources and Setup
Prerequisites: You'll need:
- Prioritized opportunities: From the Opportunity Prioritization agent
- Design system / Figma: For design consistency and component documentation
- Technical documentation: Architecture, API specs, existing feature code
- Research repository: Interviews, survey data, user feedback related to the opportunity
- CRM / Analytics: Customer context (who benefits, how much value)
Schedule: Weekly Monday at 11 AM. Generates PRDs for top 2-3 prioritized opportunities.
The Claude Prompt
You are writing a PRD based on an opportunity and supporting research.
Here's the prioritized opportunity:
[OPPORTUNITY: problem statement, affected segments, expected impact, effort estimate]
Here's the research supporting this opportunity:
[RESEARCH: interview quotes, journey friction, support patterns, NPS drivers, anything relevant]
Here's the relevant design context:
[DESIGN: existing design system, relevant components, wireframes if available, design direction]
Here's technical context:
[TECH: relevant APIs, architecture docs, similar features in codebase, tech debt impacts]
Here's the customer context:
[CUSTOMERS: how many affected? revenue impact? which segment benefits most? competitive context?]
Please write a detailed PRD that includes:
1. **Goals & Success Metrics**
- 2-3 clear goals for this feature
- 3-5 success metrics (trackable, measurable)
- Target values (what counts as "success"?)
2. **Problem Statement**
- What problem does this solve?
- For which customers? Why do they care?
- Why now? (market, competition, customer demand?)
- What's the cost of not building this?
3. **User Stories & Use Cases**
- 3-5 primary use cases
- For each: "As a [role], I can [action], so that [outcome]"
- Include happy path and edge cases
4. **Solution Approach**
- High-level approach
- Design approach (what does the UX look like?)
- Technical approach (what changes do we make?)
- Any design system dependencies?
- Any API/architecture changes needed?
5. **Requirements**
- Functional requirements (what must it do?)
- Non-functional requirements (performance, scale, security)
- Constraints (tech debt, existing limitations)
- Any assumptions?
6. **Launch Plan**
- Rollout approach (everyone at once? segment rollout?)
- Documentation needed
- Support/ops training needed
- Customer communication plan
7. **Risk & Mitigation**
- Technical risks
- Adoption risks
- Competitive risks
- How do we mitigate each?
8. **Future Considerations**
- What's phase 2?
- What won't we do in v1?
- How does this unblock future features?
Format as a complete PRD: professional, specific, and ready for engineering review. Ground every requirement in research or business context.
What You Get
Instead of manually writing PRDs from scattered notes:
- Comprehensive drafts: You have a starting point, not a blank page
- Research-grounded: Every requirement traces back to customer pain or business impact
- Technically aware: The agent considers architecture and tech debt, not just feature specs
- Fast iteration: You spend time refining instead of drafting from scratch
- Consistent structure: All PRDs follow the same format (easier for engineering and design to review)
Real outcomes:
- PRDs take 2 hours to refine instead of 10+ hours to write
- Engineering gets clearer specs with fewer back-and-forth clarifications
- You ship faster because the spec is clear before you start
For the full agent fleet and scheduling details, see Your AI Agent Fleet.
Also on Medium
Full archive →AI Agents and the Future of Work: A Pixar-Inspired Journey
What product managers can learn about AI agents from how Pixar runs a film team.
Many AI Agents Are Actually Workflows or Automations in Disguise
How to tell agents from workflows from cron jobs, and why it matters for what you ship.