---
title: PRD Template
description: Free product requirements document (PRD) template for product managers. Comprehensive structure helps teams define solutions, scope features, and align on implementation before development.
slug: prd-template
---

# 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) | Functionality | Short Description | MoSCoW |
| ---------------- | ------------- | ----------------- | ------ |
|                  |               |                   |        |

---

## 🧱 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)