How to Write a PRD in Notion (Step-by-Step Guide)
Notion is one of the most popular tools for writing PRDs because of its flexible block-based editor and database capabilities. Many product teams have standardized on Notion for product documentation.
This guide walks through the complete process of creating a PRD in Notion, from page structure to collaboration workflows. We also cover where Notion PRDs fall short and how to address those gaps.
Step-by-step guide
Step 1: Create a dedicated PRD database
In your team workspace, create a database (full-page or inline) called "PRDs" with properties for Status (select: Draft, In Review, Approved, Archived), Owner (person), Priority (select: P0-P3), Target Release (date), and Epic Link (URL to Jira/Linear). This database becomes your PRD index.
Step 2: Set up a PRD template
Create a database template with sections: Problem Statement, Goals and Non-Goals, User Stories, Requirements (with a linked database for tracking), Technical Considerations, Success Metrics, and Open Questions. Use toggles for sections that might be long.
Step 3: Write the problem statement
Start with the problem, not the solution. Describe what users are experiencing, include data points (support tickets, analytics, research quotes), and explain why this problem matters now. Keep it to 2-3 paragraphs.
Step 4: Define goals and non-goals
List 3-5 specific, measurable goals. Then list explicit non-goals: things you are intentionally not solving. Non-goals prevent scope creep and set clear boundaries for engineering.
Step 5: Add requirements as a linked database
Create a separate "Requirements" database and add a relation to your PRD database. Each requirement gets its own row with properties: Priority, Effort Estimate, Status, Acceptance Criteria. This turns your PRD from a static doc into a trackable spec.
Step 6: Share for review
Use Notion comments for inline feedback. Set the PRD status to "In Review" and share the link in Slack. Ask reviewers to leave comments rather than editing directly. Resolve comments after addressing each one.
Step 7: Move to Approved and link tickets
Once stakeholders sign off, change status to Approved. Create tickets in your issue tracker (Jira, Linear) and paste ticket URLs into the requirements database as a "Ticket Link" property.
Common mistakes
Writing the solution before the problem
The most common mistake is starting with "We will build X" instead of "Users are experiencing Y." Always lead with the problem. The solution section should flow naturally from a well-defined problem.
No explicit non-goals
Without non-goals, every reviewer adds scope. Non-goals are a PM superpower: they prevent the PRD from growing into a kitchen sink.
Requirements as paragraphs instead of structured data
Writing requirements as prose makes them impossible to track. Use Notion databases with status and priority properties so you can see at a glance what has been implemented.
Not linking to tickets
When PRD requirements are not linked to engineering tickets, the PRD becomes stale. No one updates it. Add ticket links as a property so you can track implementation progress.
Tips
- Use Notion AI to draft initial sections, then edit heavily for accuracy
- Create a PRD review checklist as a callout block at the top of your template
- Use the Notion API to automatically update PRD status when linked tickets complete
- Archive old PRDs instead of deleting them - they are valuable context for future projects
How Vantage helps
Notion PRDs are static documents that you fill in manually. Vantage generates PRDs from connected data: your analytics, codebase, Figma designs, and Slack conversations. Requirements are extracted automatically and tickets are generated with dependency awareness. If you find yourself spending hours manually filling in Notion PRD templates, Vantage automates the grounding and generation while you focus on the decisions.