Show Notes
Parker Rex breaks down product requirement documents (PRDs) and shows how to use them effectively for AI-focused projects. He contrasts Amazon’s six-pager with a lean, developer-friendly approach he prefers, and walks through a practical workflow from problem to plan to runnable tasks.
What PRDs are and why they matter
- PRDs sit at the center of design, business, and development. They keep cross-functional teams aligned.
- Don’t just hand a prompt to an LLM and hope for magic. Use product thinking to shape strategy before execution.
- A strong PRD clarifies the “what” and the “why” so the team can focus on delivering value, not guessing at requirements.
Amazon six-pager vs. lean product briefs
- Six-pager concept: a narrative, print-friendly document that answers what the product is, why it exists, and how success will be measured. It covers introduction, FAQs, the press release-style headline, and metrics.
- Practical lean alternative (Parker’s favored approach): start with the problem, audience, and a validated plan. It emphasizes a clear problem statement, user needs, and a concise plan to validate and execute.
- Bottom line: both approaches aim to align teams around a single story of value; pick the style that fits your context, but always anchor in problem and outcomes.
The six-pager essentials (high-level)
- Introduction: sets the direction and scope.
- Goals and metrics: what success looks like and how you’ll measure it.
- Tenants and strategic priorities: guiding principles and where to focus.
- State of the business and lessons learned: context and evidence from past work.
- Press release (the “headline”): the succinct, external-facing summary of the feature and impact.
- FAQs: common customer questions to surface early.
- Printouts at the end: the document is meant to be a reference that the team can read aloud in meetings.
Start with why: problem-first thinking
- Define the raw problem or use case that motivates the effort.
- Ground your idea in real-world pain (not just a cool technology).
- Example themes Parker shares: wanting to connect with like-minded tech folks, or needing better collaboration tools and tech stacks.
- Avoid “solution in search of a problem”: validate the problem early to prevent wasted time and tokens.
Validate with real users (Mom Test)
- Talk to customers or community stakeholders to test assumptions without leading them.
- Avoid verbal agreements that confirm what you want to hear; seek honest, actionable feedback.
- If you can’t reach people, look for evidence in threads, posts, or user signals that indicate a real pain.
Appetite: time and budget constraints
- Appetite is the bet size: how long and how much you’ll invest.
- Without a constraint, scope tends to explode. Set a clear boundary (e.g., a two-week sprint, a fixed budget).
- Use appetite to guard against feature creep and to force prioritization.
From problem to solution: sketching the plan
- Identify building blocks and data primitives (e.g., for a community feature: members, posts, comments, prompts, workflows).
- Sketch the architecture and potential interactions, then enumerate rabbit holes and no-go areas.
- Rabbit holes surface risks that could derail the project; no-go clauses explicitly say what you won’t do (e.g., “not mobile-first” or “no heavy real-time features”).
- This pre-work becomes the backbone of the PRD and later planning.
Pre-work flow: pitch, then validate, then plan
- Pitch the idea and refine it with customer feedback before heavy lifting.
- The sequence Parker uses: problem -> pitch -> customer feedback -> refine -> planning.
- The goal is a credible reason to proceed, backed by evidence, not optimism alone.
Turning a PRD into action: planning with prompts and context
- Before you prompt an AI, convert the PRD into a planning-friendly format with context about your codebase and constraints.
- Use planning prompts that translate the PRD into actionable items for your coding agents.
- Examples Parker references:
- A velocity-coding prompt that takes a PRD and outputs a structured plan tied to your repository.
- Augment (context engine) to provide your codebase context to the planning prompt.
- Outcome: a plan file in your repository that includes task breakdowns, phased milestones, and architecture notes.
A concrete example: slash commands feature and the plan structure
- Problem: users want a better post-writing experience with rich formatting (block quotes, code blocks, better output).
- Plan output (from a planning prompt) includes:
- Problem statement, target outcomes, and success criteria.
- Task breakdown with phases (e.g., UI primitives, command registry, trigger mechanisms).
- A lightweight technical architecture sketch.
- Context for engineers and which parts of the repo to touch.
- Repo structure Parker uses for planning:
- AI docs
- Plan
- To-do
- Done
- Each plan can have multiple phases (phases reflect different feature iterations or experiments).
How to organize planning artifacts
- Treat planning like code: version, review, and evolve.
- Common structure:
- AI docs: context and decisions
- Plan: the PRD-to-planning narrative
- To-do: actionable tasks
- Done: completed work and learnings
- Break plans into clear phases and tie tasks to the broader goals and metrics.
Practical takeaways and tips
- Always start with the problem and the audience before naming features or building prompts.
- Use a fixed appetite to prevent scope creep and keep momentum.
- Validate with real users or signals; avoid relying on wishful thinking.
- Translate the PRD into concrete planning prompts that reference your codebase context.
- Keep a living, organized repo of planning artifacts to accelerate future work.
Takeaways
- PRDs are a practical tool to align design, business, and development—especially when using AI.
- A problem-first approach with explicit appetite, rabbit holes, and no-go decisions reduces waste.
- Turn PRDs into actionable planning prompts and structured plans in your repo for fast, auditable execution.
- Use real customer feedback to guide prioritization and ensure you’re solving a real pain.
Links
- The Mom Test by Rob Fitzpatrick - Guide to customer conversations
- Augment Code - AI coding platform with context engine for planning