An example of a real-world PRD in action: https://github.com/yournextstore/new.store/blob/main/docs/new-store-prd.md
NOTE: That PRD is deeply thorough and far more comprehensive than your typical PRD; it's been optimized for vibe coding where LLMs are like junior, chaotic engineers that require a lot of detail and handholding to yield good results.
Describe in 2–3 sentences what this product or feature is, what core user/job-to-be-done it solves, and why we’re building it now.
Rationale:
Why is this the most valuable thing to build next? (Tie to user pain, strategic goal, or opportunity.)
- Is this a PoC, MVP, full v1, or enhancement to an existing product?
- What’s in and what’s out of scope?
- Mention timeline or team size if relevant.
Rationale:
Why this scope? (What are we deliberately leaving out and why?)
Bullet points of major technology choices, and why they’re chosen (if relevant).
Rationale:
Why these technologies (fit, speed, existing skills, integration)?
Step-by-step journey of the core use case. Use “as-the-user” language or diagrams as needed.
- Where/how does the user start the journey?
-
List the main steps a user takes. (Consider a numbered list for clarity.)
-
Rationale:
Why this order/flow? Any important choices/tradeoffs?
-
Forks, errors, advanced/optional paths.
-
Rationale:
Why are these handled (or not handled) in v0/MVP?
For each major section, include a “Rationale:” immediately after each requirement/choice. Do not hesitate to note controversial or subtle tradeoffs.
-
Layout: Describe high-level layout. (Wireframes, sketches, Figma links optional)
-
Rationale:
Why this layout (user habits, benchmarking, tech constraints)?
-
-
Controls: Input fields, toggles, buttons—list with purpose.
-
Rationale:
Why these controls? Why not others (e.g., to keep MVP simple)?
-
-
States: Loading, success, error, empty.
-
Rationale:
Why these states? Any intentionally omitted?
-
-
For each key feature, describe:
-
What it does: 1–2 sentences.
-
Inputs: Data required/accepted.
-
Outputs: What’s returned/displayed.
-
Rules/Constraints: Validations, defaults, error-handling.
-
Rationale:
Why this feature, in this way? Any known tradeoffs or simplifications?
-
-
API interactions: What endpoints do we hit, with what payloads?
-
Rationale:
Why this interface/data format? Why POST vs. GET, etc.?
-
-
Data sources: Where does data live, what formats/validation apply?
-
Rationale:
Why this persistence/validation logic?
-
-
3rd-party dependencies: Any external services (e.g., AI models, APIs)?
-
Rationale:
Why use external vs. build in-house?
-
-
Performance: Latency, data size, throughput.
-
Rationale:
Why these targets? (User experience, infra cost?)
-
-
Reliability: Retry, error handling, fallback logic.
-
Rationale:
Why these strategies/levels?
-
-
Security/Privacy: Auth, PII, keys/secrets.
-
Rationale:
Why this approach? (e.g., speed to MVP, compliance, future-proofing)
-
Skip or condense for less technical audiences, but include details for v0s, MVPs, and any project with cross-cutting infra or new APIs.
-
Diagram (optional): How do components interact?
-
Key modules/services, boundaries.
-
Rationale:
Why this split? What alternatives were considered?
-
Responsibilities: What does each own/do?
-
Rationale:
Why this mapping of logic?
-
-
Tech/Frameworks: What’s used and why?
-
Rationale:
Why not another library/framework?
-
-
Integration Points: How does it connect to other components?
-
Rationale:
Why synchronous vs. async, etc.?
-
-
State/Statelessness: Where does state live?
-
Rationale:
Why here, not elsewhere?
-
-
Any novel AI prompt structure, search logic, or data formats?
-
Rationale:
Why invent/choose this approach?
-
Static files, database schemas, embedding strategies, etc.
-
Rationale:
Why this approach (speed, reusability, cost)?
-
-
About users, data, infra, 3rd parties.
-
Rationale:
Why are we comfortable with these assumptions?
-
Timeline, team, tech, budget, regulatory.
-
Rationale:
Why are these constraints “hard” vs. “nice-to-have”?
-
Where do we know we don’t know?
-
Assign owners/review dates if possible.
-
Rationale:
Why defer these?
-
Tip:
If building a new product, MVP, or complex integration: **always start with a “Walking Skeleton” phase! For small/contained features, consider if this still helps de-risk things (e.g., touching new APIs or systems)._
Phase 1: Walking Skeleton
-
Implement minimal, end-to-end flow (can use stubs/dummy data for UI, backend, API).
-
Goal: Verify system wiring, unblock future work, reveal integration issues fast.
-
Rationale:
Why start with a skeleton? (De-risk, reveal infra/API gaps before investing in features.)
-
Phase 2+: Flesh Out
-
Replace stubs with real logic, add error handling, polish, edge cases.
-
Rationale:
Why this order? (E.g., what’s the riskiest/least understood part to build first?)
-
(Add additional phases as needed, e.g., “Data Migration”, “UX Polish”, “Testing & Hardening”)
-
Who owns each phase/part?
-
Who updates the PRD if scope changes?
-
Rationale:
Why this division of work?
-
-
What must be true for us to call this “done”?
-
Demo, user feedback, perf targets, etc.
-
Rationale:
Why these as success, not others?
-
Include only if critical for correctness, or move to appendix/external doc as needed. Every deep technical spec should have a Rationale if non-obvious.
-
High-level list of planned post-v1 features, dependencies, and deliberate omissions.
-
Rationale:
Why defer these? (Risk, complexity, focus.)
-
-
Code repos, admin tools, test UIs, design docs, prior art.
-
Rationale:
Why is each resource linked? (Source of truth, onboarding, historical context.)
-
-
Date of creation, major updates.
-
Author(s), contact person for clarifications.
-
Rationale:
Why document changes/ownership? (Prevents doc rot, ensures accountability.)
-
- After every major requirement, add a Rationale: “Why did we do it this way?”
- For new or cross-cutting projects, always use a Walking Skeleton phase in the implementation plan.
- Keep sections modular: Core (always), Advanced (if needed). Move details to appendices if risk of doc rot.
- For features/areas with tradeoffs or controversy, be explicit in rationale.
- Success Criteria and Doc Ownership are always mandatory.
- Use checklists or bolding to flag MVP vs. stretch/optional.
- Optimize for clarity, alignment, and real-world decision-making, not just documentation!