PRD Template for Jira + Confluence
For teams on the Atlassian stack, Confluence and Jira together create the most integrated spec-to-ticket workflow available. A PRD in Confluence can embed live Jira data via the Jira Issues macro, so stakeholders see implementation progress directly from the spec page rather than context-switching to Jira. When a requirement changes, the PRD and the linked tickets update in the same workflow.
This template is designed for Confluence-native teams who want a PRD that serves as a living document throughout development — not just a planning artifact that gets abandoned after sprint kickoff. It covers the Confluence page structure, which macros to use and where, how to link epics and stories bidirectionally, and how to manage the PRD status through its lifecycle from draft to closed.
Why Confluence PRDs work better with Jira integration
The most common failure mode for PRDs is abandonment after kickoff. The PM writes the spec, engineering reads it, and then the tickets get created manually with loose traceability back to the requirements. Requirements change during development but the PRD is not updated. At launch, no one can remember why certain decisions were made. The Jira Issues macro solves this by making the implementation status visible directly in the PRD.
Bidirectional traceability — knowing which PRD requirement maps to which Jira ticket, and which Jira ticket implements which PRD requirement — is particularly valuable during QA, launch, and post-launch review. When a bug is reported, you can trace it to the original requirement. When a requirement is questioned, you can see exactly which tickets implemented it and whether they were completed.
The Confluence comment and annotation system also enables a review workflow that email-based PRD sharing cannot match. Stakeholders can comment on specific sections, tag team members for input, and see a full history of the discussion that led to each decision. This creates institutional memory at the requirement level, not just in Slack threads that are impossible to find later.
Template sections
5 sections covering the complete prd workflow.
Confluence page structure and metadata header
Start every Confluence PRD with a structured metadata header using the Table macro. This gives all readers immediate access to the key facts without reading the whole document. Link the Jira epic key directly — this makes the PRD findable from Jira and the Jira tickets findable from the PRD.
Use a Confluence Table macro for the header: | Field | Value | |---|---| | Feature Name | [Feature Name] | | PM Owner | [@mention name] | | EM Owner | [@mention name] | | Jira Epic | [PROJ-123](link to Jira) | | Status | Draft → In Review → Approved → In Development → Shipped → Closed | | Target Release | [Specific date or sprint] | | Last Updated | [Date — update manually or use Confluence date macro] | | Stakeholders | [@mention list] |
Tips
- Set the page title to match the Jira epic name exactly so they are searchable together
- Use the Confluence @mention feature for PM and EM owners — they will be auto-notified when the page is updated
- Add the PRD to the parent Confluence space for your product area, not just in a flat list — the hierarchy makes it findable
Problem statement with Confluence macros
Write the problem statement in structured paragraphs under a Heading 2. Use the Confluence Info macro (the blue callout box) to highlight the single most important data point — this is the number that justifies the initiative. Use the Warning macro for known risks or constraints that reviewers must be aware of before approving.
{info} Key insight: 68% of enterprise users who churn in the first 90 days cite "couldn't set up integrations" as their primary reason (Source: Q2 2025 churn survey, N=147). {info} Enterprise customers onboard with integration requirements that our current setup flow does not support. The self-serve setup flow works for individual users but breaks down for accounts that need SSO, custom domain routing, and admin-managed user provisioning. These accounts currently require manual setup by our solutions engineering team, which takes an average of 11 business days and costs $2,400 per account in SE time.
Tips
- One Info macro per PRD — use it for the single most important data point, not as a container for all your data
- The Warning macro should be used for genuine risks that could affect the go/no-go decision, not as a general "things to note" catch-all
- Link all data references to their sources — Confluence allows you to link to Amplitude dashboards, Google Sheets, and other tools directly from the text
Requirements with live Jira integration
Write requirements in a numbered list with priority labels (P0–P3). Then below the requirements list, add a Jira Issues macro configured with a JQL query for the epic. This creates a live view of implementation progress that updates automatically as engineers move tickets through the board — stakeholders can see which requirements are in progress, in review, and done without asking for a status update.
Requirements: 1. [P0] Users can connect their Identity Provider via SAML 2.0 without assistance from Vantage SE. Acceptance criteria: A user with admin role can complete the SSO setup flow in under 15 minutes with only the IDP metadata file. 2. [P0] Admin users can provision new users from the IDP group without individual invitations. AC: User appears in the workspace within 5 minutes of being added to the IDP group. 3. [P1] Existing users who are added to an IDP group get converted to SSO authentication without losing their data. AC: User can log in via SSO; email/password login is disabled. Jira Issues macro (add in Confluence): JQL: epic = PROJ-123 ORDER BY priority ASC Columns: Issue key, Summary, Status, Priority, Assignee
Tips
- Configure the Jira Issues macro to show Assignee and Status columns — this lets stakeholders see who is working on what without going to Jira
- Use JQL filters to show only specific issue types if needed: epic = PROJ-123 AND issuetype = Story
- Add a "Requirements → Jira mapping" section that explicitly maps each requirement number to the Jira ticket(s) that implement it — this is the traceability matrix that QA and post-launch review will need
Design and technical sections
Embed Figma designs directly in the Confluence page using the Figma embed macro (available in the Atlassian Marketplace) or a simple iframe embed. For technical context, create a linked Technical Design Document in Confluence and reference it here rather than embedding the full technical content in the PRD — this keeps the PRD readable for non-engineering stakeholders.
Design: [Embed Figma frame or link to Figma prototype] Figma file: [Link to full file with all frames] Design review status: [In progress / Approved — by Name on Date] Technical considerations: Technical Design Document: [Link to Confluence TDD page] Key constraints identified by engineering: - SAML implementation requires updates to the auth service (Platform team dependency) - User provisioning requires a new webhook endpoint for IDP events Engineering estimate: [X] story points across [N] sprints
Tips
- The Figma embed is the single most impactful thing you can add to a Confluence PRD — it eliminates the "where is the latest design?" question permanently
- Keep the PRD and TDD as separate Confluence pages linked to each other — product readers need the PRD, engineering readers need both, and they have different update cadences
- Use the Confluence inline comment feature to annotate specific design decisions with the rationale — this is the most frequently lost institutional knowledge
Status transitions and PRD lifecycle management
A Confluence PRD should transition through explicit statuses from Draft to Closed. Use the Status macro (available natively in Confluence) to display the current status prominently at the top of the page. Schedule explicit reviews at each status transition rather than letting the PRD languish in "Draft" indefinitely.
PRD lifecycle: Draft → In Review (2 weeks for stakeholder review) In Review → Approved (stakeholder sign-off, engineering estimate complete) Approved → In Development (sprint kickoff) In Development → Shipped (launch + post-launch metrics live) Shipped → Closed (30-day post-launch review complete, retro done) Review process: Share the Confluence page link with all stakeholders. Use Confluence comments for feedback. Allow one week for async review, then hold a 45-minute review meeting to resolve open comments and confirm approval.
Tips
- Set a Confluence page restriction to "view only" once the PRD is Approved — this prevents accidental edits after engineering kickoff. Create a change log section for any post-approval changes.
- Archive (not delete) closed PRDs — they are valuable context for future work and post-mortems
- Use the Confluence "Watch" feature to notify all stakeholders automatically when the page is updated during development
Copy-paste template
# [Feature Name] PRD --- ## Metadata | Field | Value | |---|---| | Feature Name | [Feature Name] | | PM Owner | [Name] | | EM Owner | [Name] | | Jira Epic | [PROJ-123] | | Status | **Draft** *(update with Confluence Status macro)* | | Target Release | [Date or Sprint] | | Last Updated | [Date] | | Stakeholders | [Names or teams] | --- ## Problem Statement *[Info macro: one-sentence data-backed reason this initiative matters]* [Two to three paragraphs describing the user problem with data. Include: who is affected, what they cannot do today, how you know this is a real problem, and what the cost of inaction is.] --- ## Goals and Non-Goals **Goals:** 1. [Measurable goal connected to a KR or business metric] 2. [Measurable goal] **Non-goals:** - [Explicit scope boundary — what this initiative will NOT solve] --- ## Requirements 1. **[P0]** [Requirement description.] *Acceptance criteria: [Testable definition of done.]* 2. **[P0]** [Requirement description.] *Acceptance criteria: [Testable definition of done.]* 3. **[P1]** [Requirement description.] *Acceptance criteria: [Testable definition of done.]* 4. **[P1]** [Requirement description.] *Acceptance criteria: [Testable definition of done.]* 5. **[P2]** [Requirement description.] *Acceptance criteria: [Testable definition of done.]* **Jira implementation status** *(live via Jira Issues macro — add in Confluence):* `JQL: epic = [PROJ-XXX] ORDER BY priority ASC` *Columns: Key, Summary, Status, Priority, Assignee* --- ## Design [Figma embed or link] **Design file:** [Figma URL] **Design status:** [In progress / Under review / Approved by Name on Date] --- ## Technical Considerations **Technical Design Document:** [Confluence link] **Key constraints:** - [Constraint 1 — identified by engineering] - [Constraint 2] **Engineering estimate:** [X story points / [N] sprints] --- ## Success Metrics | Metric | Baseline | Target | Measurement method | Timeline | |---|---|---|---|---| | [Primary metric] | [Value] | [Value] | [Amplitude / Jira / SQL] | 30 days post-launch | | [Secondary metric] | [Value] | [Value] | [Source] | 60 days post-launch | --- ## Open Questions - [ ] [Question] — Owner: [Name] — Due: [Date] ## Decision Log | Decision | Rationale | Date | Made by | |---|---|---|---| | [Decision made] | [Why] | [Date] | [Name] |
Frequently asked questions
Generate instead of filling in templates
Connect your tools, and Vantage generates the content using real product data. Free to start.
Free to start. No credit card required.