Prd Development

Purpose

Guide product managers through structured PRD (Product Requirements Document) creation by orchestrating problem framing, user research synthesis, solution definition, and success criteria into a cohesive document. Use this to move from scattered notes and Slack threads to a clear, comprehensive PRD that aligns stakeholders, provides engineering context, and serves as a source of truth, avoiding ambiguity, scope creep, and the "build what's in my head" trap.

This is not a waterfall spec, it's a living document that captures strategic context, customer problems, proposed solutions, and success criteria, evolving as you learn through delivery.

Input

Works best with: The feature or initiative the PRD covers. Also useful: Discovery notes, problem statements, user research, success metrics, and constraints, paste whatever exists; the workflow slots it into the right phases and skips what's already answered.

Anything supplied with the invocation itself, text after the skill name, a pasted context dump, or an appended ARGUMENTS: line, counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The workflow starts at problem definition and builds up from there.

Example invocation: Build a PRD for self-serve workspace provisioning, here are my discovery notes and the OKR it ladders to.

Key Concepts

What is a PRD?

A PRD (Product Requirements Document) is a structured document that answers:

1. What problem are we solving? (Problem statement)
2. For whom? (Target users/personas)
3. Why now? (Strategic context, business case)
4. What are we building? (Solution overview)
5. How will we measure success? (Metrics, success criteria)
6. What are the requirements? (User stories, acceptance criteria, constraints)
7. What are we NOT building? (Out of scope)

PRD Structure (Standard Template)

# [Feature/Product Name] PRD