reph

Templates · Product

PRD / requirements doc template

Problem, users, requirements, success metrics and scope for a feature

Start with this template →Sign in

Opens on reph with the template ready to start. No account needed; sign in to keep your document.

Use it when

A feature is approved to build and engineering, design and stakeholders need one agreed source for what and why

Who it's for

Product managerEngineerDesigner

Part of a kit

Product launch, step 2 of 6. From brief and PRD through experiment, launch checklist, release notes and the customer newsletter.

Filled example

The template filled in for a made-up company, so you can see what good looks like.

Scheduled reports

Author: Elena Petrova · Date: 2026-09-24
Owner Elena Petrova
Stakeholders Analytics eng, Design, Customer success, Sales
Target release 2026-11-18
Status In review

Problem

Tallis Labs Insights customers build dashboards, then screenshot them into email every Monday. Customer success logs about 120 requests a month for "send this report automatically", and 3 of our 10 largest renewals this year asked for it in writing. Without it, executives who never log in stop seeing value, and seat counts shrink at renewal.

Users & personas

Primary: the team analyst who owns dashboards and today sends them by hand weekly. Secondary: the executive recipient who reads the report in email and rarely opens the app.

Goals & success metrics

Weekly active report viewers
2,140
▲ +0%
Accounts with a schedule
0%
▲ +0%
Report email unsubscribes
0%
▲ 0%
Metric Baseline Target By when
Accounts with at least one schedule 0% 35% 60 days after GA
Weekly active report viewers 2,140 3,000 90 days after GA
"Send automatically" CS requests 120 per month Under 20 60 days after GA
Unsubscribe rate per send n/a Under 2% Ongoing

Requirements

ID Requirement Priority Notes
R1 Schedule any dashboard daily, weekly or monthly at a chosen time and time zone Must
R2 Recipients can be workspace members or external emails Must External gated by admin setting
R3 Email contains a PNG snapshot plus a link to the live dashboard Must
R4 Filters saved with the schedule are applied at send time Should
R5 PDF attachment option Could Asked by 2 enterprise accounts

User flows

The analyst opens a dashboard, picks Schedule, chooses cadence, time and recipients, and sees a preview email. Errors (dashboard deleted, query timeout) pause the schedule and email the owner instead of sending a blank report.

Non-functional requirements

Snapshots render within 60 seconds at p95. Sends are rate limited to 500 per workspace per hour. Emails meet WCAG AA contrast and include alt text describing each chart.

Out of scope

  • Slack and Teams delivery (next quarter)
  • Conditional alerts ("send only if revenue drops 10%")

Dependencies

  • Rendering service capacity (Platform team, committed)
  • Email deliverability review with the infra team (not yet committed)

Launch plan

Internal dogfood on 2026-11-04, beta for 20 accounts on 2026-11-11, GA on 2026-11-18 behind the scheduled_reports flag.

Open questions

Review

Reviewer Role Status
Tariq Hassan Engineering lead Approved
Mei Tanaka Design lead Approved with comments
Owen Brooks Business owner Pending

Review by: 2026-10-01

Decision Date Decided by Notes
Ship R1 to R4 for GA, R5 after 2026-09-30 Tariq Hassan, Elena Petrova External recipients need admin opt-in

The template

Show the blank template

PRD / requirements doc

Author: [your name] · Date: [date]
Owner [your name]
Stakeholders
Target release
Status Draft

Problem

The problem in the user's words, with evidence: a support ticket count, a churn number, a quote from an interview. Not "we should have X."

Users & personas

Who hits this problem, how often, and how badly. If more than one persona is affected, name the primary one. The doc should optimize for them.

Goals & success metrics

How you'll know this shipped and worked, not just shipped. The tiles show where each metric stands today; the table holds the target.

Primary metric
0
▲ +0%
Secondary metric
0
▲ +0%
Guardrail
0
▲ 0%
Metric Baseline Target By when

Requirements

Numbered so engineering can scope against them; MoSCoW keeps "nice to have" from quietly becoming a blocker.

ID Requirement Priority Notes
R1 Must
R2 Should
R3 Could

User flows

Step through the primary path end to end, including error and empty states. Link a diagram if a picture says it faster than prose.

Non-functional requirements

Performance, accessibility, localization, privacy, rate limits: the requirements that don't show up in a happy-path demo but will show up in an incident.

Out of scope

  • Adjacent work that a reviewer will assume is included unless you say otherwise

Dependencies

Other teams, systems or a third-party API this can't ship without. Flag anything not yet committed.

Launch plan

Rollout sequencing (flagged, staged, GA) and who signs off at each stage.

Open questions

Review

Who must sign off before engineering commits, and the record of what they decided.

Reviewer Role Status
Engineering lead Pending
Design lead Pending
Business owner Pending

Review by: [date]

Decision Date Decided by Notes

Questions

How is a PRD different from a feature brief?
The brief asks whether to design it, the PRD defines what ships and how success is measured
Who signs off?
The reviewers in the Review section, usually eng lead, design lead and the business owner
Should it describe the technical design?
No. Link the design doc and keep this about the problem and requirements

Fill it with your agent

Connect Claude to reph over MCP, then paste this. The draft arrives as suggestions you accept or reject section by section. How to connect Claude.

Find my reph doc "PRD / requirements doc" with search_docs, then read it with read_doc. Draft problem, personas, success metrics and numbered Must, Should or Could requirements from the linked feature brief, interview notes, support ticket tags and analytics baselines. List reviewers in the Review section. File it with suggest_edit, one replace_section op per section (heading line kept) so each can be accepted alone. Ask each open question (unbaselined metrics, uncommitted dependencies) with add_comment quoting that section's heading line, then call request_review with a one-line summary.

Related templates

Feature brief

Short brief aligning team on a feature before design

Product managerDesignerEngineer

Experiment (A/B) plan

Hypothesis, variants, metrics, sample size and decision rule

Product managerResearcherEngineer

Launch checklist

Everything to ship a feature: eng, docs, support, marketing

Product managerManager

Release notes

What shipped, what changed, and how to upgrade

EngineerTech leadProduct manager

Customer product newsletter

Release highlights, a how-to and one call to action for your customers

Product managerMarketerFounderCustomer success

Analytics request

Brief for a data or analytics request: the decision it informs, the exact question, metric definitions, segments, timeframe, sources, due date and output format

Product managerResearcherMarketerExecutiveOperationsAnyone

Start with this template →Sign in