Docs

Product requirements doc (PRD) template

Problem, users, requirements by priority, success metrics and open questions for one feature.

Use this template Draft a variant with AI

📋

PRD: recurring invoices

Status: in review. Owner: Sara Okafor. Reviewers: Kai (design), Ana (engineering), Tobias (finance).

Problem

Freelancers on our Pro plan bill the same clients every month. Today they duplicate last month's invoice by hand. In support tickets from the last quarter, 41 mention a forgotten or duplicated monthly invoice.

Users

Freelancers with retainer clients (most Pro accounts)

Small agencies billing hosting or maintenance fees

Goals

A user sets up a recurring invoice once and it goes out on schedule

Fewer "I forgot to invoice" tickets

Non-goals

Usage-based billing

Card payments collected automatically (separate project)

Requirements

Must have

Create a recurring invoice from any existing invoice

Schedules: monthly on a fixed day, every n weeks, yearly

Each run gets the next invoice number in sequence

Email to the client on send, copy to the user

Pause, resume and end a schedule

Should have

Preview the next three invoice dates

Reminder to the user two days before a run

Could have

Different line items per run (for example a yearly discount)

User flow

User opens an invoice, picks "Make recurring"

Chooses schedule and start date

Sees the next three dates and confirms

Schedule appears under Invoices, Recurring

Success metrics

25% of Pro accounts with three or more clients set up a schedule within 60 days

Monthly-invoice support tickets drop by half within one quarter

Open questions

What happens if a run date falls on a weekend?

Proposal: send on the date anyway. Tobias to check with two accountants.

Do paused schedules skip or catch up?

Skip. Catching up would surprise clients.

Timeline

Design review: Wednesday 28 October

Beta for 30 accounts: Wednesday 25 November

This is the page you get. Every block and row is editable.

What it is

A product requirements document (PRD) explains what a feature should do and why, before anyone designs or builds it. It covers the problem, who has it, goals and non-goals, requirements sorted into must, should and could, the user flow, how you'll measure success and the open questions. It describes the what. The design doc covers the how.

When to use it

Before design and engineering start on a feature
When several teams need to agree on scope
When you want a record of why a feature looks the way it does

How to use it

01
Start with the problem
Describe it with evidence from tickets, interviews or data. Link the source pages with @.
02
Sort requirements
Put each requirement under must, should or could have. Number the musts so reviewers can refer to them.
03
Review in comments
Share with comment access and tag reviewers in the status callout. Answer open questions in toggles.
04
Draft faster
Write the problem and goals yourself, then use Ask AI to continue with a first pass at the requirements.

Or have the AI draft your version

"Write a PRD for adding team calendars to a scheduling app, covering the problem, users, goals, non-goals, must, should and could requirements, user flow and success metrics."

Draft a variant with AI

All templates

📐
RFC 014: move search to Postgres full-text
Status: open for comments until Sunday 25 October. Author: Malik Haddad. Decision by: Ana Ruiz.
Summary
Replace the separate search cluster with Postgres full-text search and trigram indexes. One less service to run, and search results update in the same transaction as the data.
Context
The search cluster costs €640 a month and needs a weekly reindex
New pages take up to 10 minutes to show up in search
We have 1.2 million searchable rows, growing about 4% a month
Proposal
Add a generated tsvector column on pages, weighted title A, body B
GIN index on the vector, trigram index on title for typo tolerance
One query that combines both scores
select id, title, ts_rank(search, query) + similarity(title, $1) as score from pages, websearch_to_tsquery('english', $1) query where search @@ query or title % $1 order by score desc limit 20;
Alternatives considered
Keep the cluster and fix the reindex
Fixes the delay but keeps the cost and the extra service. Rejected.
Hosted search API
Good relevance, but per-request pricing gets expensive at our query volume and data leaves our database. Rejected.
Risks
Ranking quality may drop for long documents. Mitigation: compare top 10 results for 200 logged queries before switching
Index size grows the database by about 15%
Rollout
1.
Build the column and indexes behind a flag
2.
Shadow traffic for one week, log both result sets
3.
Switch reads, keep the cluster for two weeks as fallback
4.
Remove the cluster
Open questions
Do we need German stemming at launch, or English only?
Docs
Design doc (RFC)
A technical proposal with context, the design, alternatives you rejected and a rollout plan, open for comments.
🧭
Brief: customer portal
Customers download invoices and update payment details themselves, so billing tickets drop by half.
Problem
Billing questions are 38% of support tickets. Most ask for an invoice copy or a new card on file.
Goals
Invoices and payment history in one place
Card and address updates without contacting us
Billing tickets down 50% within three months of launch
Scope
In
Invoices, payments, contact details, password reset
Out
Contract changes and the mobile app (next year)
Owners
Product: Sara
Design: Kai
Engineering: Ana and Leo
Milestones
1.
Designs approved: 15 November
2.
Beta with 20 customers: 10 January
3.
Launch: 1 February
Open questions
Do we need the ERP export to run hourly?
Finance says nightly is fine for invoices but payments should show within an hour.
Who reviews the new payment terms text?
Legal, two weeks before beta.
Docs
Project brief
One page that says why a project exists, what is in and out, who owns what and when it is done.
Draft your own with AI
Describe the page you need in one sentence. The AI writes it, and you edit it like any other page.
How the AI works

📋Product requirements doc (PRD) template

Problem

Users

Goals

Non-goals

Requirements

Must have

Should have

Could have

User flow

Success metrics

Open questions

Timeline

What it is

When to use it

How to use it

Start with the problem

Sort requirements

Review in comments

Draft faster

Or have the AI draft your version

Related templates

📐Design doc (RFC)

🧭Project brief

Draft your own with AI

Cookies and storage

Product requirements doc (PRD) template

Design doc (RFC)

Project brief