PRD Template

Free product requirements document (PRD) template for product managers. Comprehensive structure helps teams define solutions, scope features, and align on implementation before development.

Product // PRD

v1.2

  • Product Strategy = “Where are we going, and why?” (1–3 year view)
  • 1-Pagers = “Which problems should we solve to get there?” (initiative-level bets)
  • PRDs = “How do we execute the solution to those problems?” (feature-level plans)
  • Impact Assessment = "What did we learn"

📌 Title

Feature or product name (e.g., Expert Calendar Sync MVP)

Add links to product strategy here.


🔍 Summary

One-liner on what this is and why we’re building it. This will give a broad view of the solution.


🎯 Problems it solves / Objectives & Success Metrics

  • What are we trying to achieve?
  • How will we measure it — leading metrics (e.g., adoption, usage rate, reduced manual ops) and lagging metrics (e.g., conversion rate, revenue).
  • Metrics should cascade from the 1-pager but include leading indicators.
For reporting, link to a sketch of how you would like the dashboard to look (Excel or Miro work best).

🧩 Scope (MoSCoW)

When compiling your scope, keep in mind:

  • Be ambitious — add any ideas that help achieve the goal, no matter how complex.
  • Prioritize carefully — use the MoSCoW framework to rank priority. If only Must Haves are completed, can you deliver a good feature?
  • Ensure any new metrics to track leading & lagging indicators are included as Must Haves.
  • Use a table format (separate tables can be used for different sections).
Theme (Optional)FunctionalityShort DescriptionMoSCoW

🧱 Risks / Constraints

  • Add headings for compliance, marketing, technical, etc.
  • Call out anything worth highlighting.

🎨 UX / Design / (AI) Prototype (Optional)

  • Link to Figma, wireframes, or design specs.
  • Validate concepts/prototypes by end users before shipping.
  • Small enhancements may not need validation; larger features likely do.

🔌 Tech Notes / Dependencies (Optional)

  • Any relevant feedback from Engineering on implementation & scope.
  • Parts of scope up for debate (e.g., complexity).
  • Include de-scoped items for possible future revisit.

📆 Timeline & Milestones

  • Dev Start: May 6
  • Target Launch: June 3
  • Impact Assessment: July 4

🎢 Rollout Plan & Timeline

  • Who will be targeted?
  • How will the feature be rolled out? (e.g., pilot group, phased release, A/B testing, full release)
  • Rationale for rollout strategy.
  • Proposed timeline for each phase.

📣 Communication Plan

Internal Communication:

  • Channels: Userpilot, weekly product review, Teams, email, Sana, etc.
  • Key Messages: What internal users need to know (feature, impact, support).
  • Timing: When communication occurs.

External Communication:

  • Channels: In-app notifications, email, QBR slides, direct CS/Sales outreach.
  • Key Messages: What external users need to know (benefits, usage, support).
  • Timing: When communication occurs.

📚 Training & Support

  • Training Sessions: Live or asynchronous (e.g., Sana).
  • Documentation: Internal FAQs, user guides, Atlas updates.
  • Support Channels: Dedicated Teams channel, ticketing system, product team contacts.

🧱 Known Issues / Risks & Mitigation

  • Known bugs, limitations, or potential challenges pre-launch.
  • How will these be managed and communicated? (e.g., workarounds, communication plan for affected users)