Confluence PRD Template: Copy, Customize, and Publish

Copy the free Confluence PRD template

This is an original, lightweight product requirements document template for a feature or a focused release. Use it as a starting point: remove sections that do not help your team, and leave unknowns visible instead of filling them with guesses.

The download contains the same Markdown shown below. It is a document outline, not an Atlassian blueprint file or an automatic import integration.

# PRD: [Feature name]

| Field | Detail |
| --- | --- |
| Status | Draft / In review / Approved / Shipped |
| Product owner | [Name] |
| Engineering lead | [Name] |
| Design lead | [Name] |
| Target release | [Date or milestone; mark estimates] |
| Last updated | [YYYY-MM-DD] |
| Related work | [Jira epic URL] |

## 1. Problem and evidence

[Describe who has the problem, what happens today, and why it matters.]

- Target users: [Role, segment, or workflow]
- Current workaround: [What users do now]
- Evidence: [Research link, support theme, or baseline data]
- Unknowns: [What still needs validation]

## 2. Goals and success measures

[Describe the user outcome this release should achieve.]

| Outcome | Metric definition | Baseline | Target | Measurement owner |
| --- | --- | --- | --- | --- |
| [Outcome] | [Event, denominator, time window] | [Known value or unknown] | [Agreed target] | [Name] |

## 3. Scope and non-goals

### In scope

- [Capability required for the first release]
- [Supported user group or platform]

### Out of scope

- [Deferred capability and reason]
- [Explicit limitation]

## 4. User journey

As a [user], I want to [action], so that I can [outcome].

1. [Entry point and prerequisite]
2. [Main action]
3. [Feedback and successful outcome]
4. [Failure path and recovery]

Design reference: [Link to reviewed wireframes or prototype]

## 5. Functional requirements

| ID | Requirement | Priority | Acceptance criteria |
| --- | --- | --- | --- |
| R1 | [Observable behavior] | Must | [Given a state, when an action occurs, then a result follows] |
| R2 | [Observable behavior] | Should | [Specific, testable result] |

## 6. Edge cases and quality requirements

- Empty state: [What appears before there is data?]
- Invalid input: [How is the problem explained and corrected?]
- Permissions: [Who may view, create, change, or delete?]
- Interrupted action: [Retry, cancellation, or recovery behavior]
- Accessibility: [Keyboard, labels, focus, and announcements to verify]
- Performance: [Agreed threshold, workload, and test conditions]
- Data handling: [Data collected, access, retention, and deletion]

## 7. Dependencies, risks, and assumptions

| Item | Impact | Owner | Validation or mitigation | Due |
| --- | --- | --- | --- | --- |
| [Dependency, risk, or assumption] | [What it affects] | [Name] | [Next step] | [Date] |

## 8. Open questions and decisions

| Question | Owner | Decision needed by | Resolution |
| --- | --- | --- | --- |
| [Unresolved question] | [Name] | [Date] | [Decision and rationale, or pending] |

## 9. Release and measurement plan

- Release owner: [Name]
- Rollout: [Audience, stages, and readiness checks]
- Rollback or disable criteria: [Signal and responsible person]
- Support readiness: [Help content, known limitations, escalation]
- Measurement review: [Date, owner, and dashboard link]

## 10. Review checklist

- [ ] The problem has supporting evidence or is labeled an assumption.
- [ ] Scope and non-goals are explicit.
- [ ] Each must-have requirement has testable acceptance criteria.
- [ ] Design, engineering, and relevant stakeholders have reviewed the draft.
- [ ] Open questions have owners and decision dates.
- [ ] Release and measurement owners are assigned.

## Change log

| Date | Change | Reason | Owner |
| --- | --- | --- | --- |
| [YYYY-MM-DD] | [Summary] | [Why it changed] | [Name] |

What should a product requirements document include?

A useful PRD makes the product decision clear: whose problem you are solving, what this release will do, and how reviewers will know that the intended behavior works. The template separates those decisions from implementation details so design, engineering, and product can review the same scope.

Atlassian’s own product requirements template also includes objectives, success measures, assumptions, and user stories. Start with the native template if you are already drafting in Confluence; this Markdown version is useful when the source starts in a text editor or an existing document.

Worked PRD example: bulk CSV import

Consider a fictional feature that lets workspace admins import a list of contacts. The example below illustrates the level of detail to aim for; its file limits and behavior are sample product decisions, not claims about this editor.

Problem, scope, and non-goals

Problem: Workspace admins currently create contacts individually. Before committing to the feature, the team needs evidence about the size and frequency of that work. Goal: Let an admin validate a CSV file and create contacts without retyping each row.

In scope: CSV upload, required-field validation, duplicate detection, a preview, and a final result summary. Out of scope: Scheduled synchronization, spreadsheet formulas, and updates to existing contacts.

Turn a vague requirement into a testable one

“Handle invalid files gracefully” leaves too much room for interpretation. A reviewer should be able to work through a concrete input and agree on the outcome:

R1 — Validate required columns before creating contacts

Given an admin uploads a CSV without the required email column,
when validation runs,
then show "Missing required column: email",
create no contacts,
and allow the admin to choose a corrected file.

R2 — Enforce the agreed file limit

Given the sample release supports at most 1,000 data rows,
when a file contains 1,001 data rows,
then reject it before import and explain the 1,000-row limit.

R3 — Confirm the import result

Given the preview shows 12 valid rows and the admin confirms,
when the import finishes,
then report the number created and any failed rows.

Next, record the remaining decisions: does a duplicate match on email alone, can partially valid files be imported, and what happens if an admin retries after a network failure? Give each question an owner. Those answers determine acceptance tests and implementation work.

Separate release checks from success measures

A passing import test proves the feature behaves as specified. It does not prove that it solves the user’s problem. Choose a separate outcome measure, such as the proportion of started imports that finish successfully, and define its denominator and observation window before setting a target.

How do you put this PRD template into Confluence?

Use a preview-and-copy workflow: edit the Markdown, inspect its rendered structure, and paste the formatted output into a Confluence page.

1. Copy or download the template. Replace bracketed prompts with your feature details. Keep unresolved questions clearly labeled.
2. Open Markdown to Confluence. Continue into the editor and paste the Markdown into the input panel.
3. Review the preview. Check heading levels, requirement tables, links, and nested lists. Shorten table cells that are difficult to scan.
4. Choose Copy Rich Text. Paste into a new or existing Confluence page in edit mode. Use a draft page for the first check.
5. Add Confluence-specific elements. Add real mentions, Jira links, macros, and page restrictions inside Confluence. Plain placeholders do not create those integrations.
6. Inspect and publish. Check tables and checklists after pasting, assign a document owner, and share the page for review.

Atlassian documents Markdown shortcuts in the Confluence Cloud editor. Typing those shortcuts and pasting an entire Markdown document are different workflows, so verify your actual paste result. Browser clipboard behavior and the destination editor can affect formatting.

What should you check before a PRD review?

• Replace ambiguous wording. “Fast,” “easy,” and “secure” need agreed behavior or measurable criteria before they can guide verification.
• Keep requirement IDs stable. Link related work to R1, R2, and so on, so a renamed section does not make the reference unclear.
• Show boundary cases. Include empty input, invalid data, permissions, cancellation, and recovery when they affect the feature.
• Record non-goals. A request omitted from the document may look forgotten. An explicit non-goal shows a deliberate scope decision.
• Give open questions owners. A question without an owner or decision date can remain unresolved through implementation.
• Keep the page current. Record material scope changes and their reasons, then point reviewers to the latest decision.

For an ongoing review process, see the PRD team publishing workflow. For formatting issues, use the Markdown publishing guide.

Frequently asked questions