The Complete PRD Template Guide: 15 Templates From Top Product Teams

The best PRD templates share one counterintuitive trait: they force you to understand the problem before writing a single requirement. This comprehensive guide provides actual copyable templates from companies like Amazon, Intercom, Figma, and Basecamp—plus analysis to help you choose the right one for your team.

Most PRD guides describe templates abstractly. This one delivers direct links to templates you can copy today, organized by approach (lean vs. comprehensive), tool (Notion, Google Docs, Figma), and company stage (startup vs. enterprise). Whether you're a solo PM needing a quick one-pager or leading a 50-person product org requiring sign-off workflows, there's a battle-tested template here.

What actually makes a PRD template worth using

Before diving into templates, understand why the best product teams structure their requirements documents the way they do. After analyzing PRDs from 13+ top companies, three patterns emerge consistently:

Problem before solution. Every high-performing template—Intercom, Asana, Shape Up, Lenny's 1-Pager—separates problem understanding from solution design. As Lenny Rachitsky writes: "Nailing the problem statement is the single most important step in solving any problem. It's deceptively easy to get wrong, and when done well it's a superpower of the best leaders."

Explicit non-goals. The second most common element across elite templates is a "Non-Goals" or "No Gos" section. Kevin Yien's template (from Square) and Basecamp's Shape Up Pitch both emphasize defining boundaries as much as requirements. This prevents scope creep before it starts.

Living documents, not static specs. Modern PRDs from Figma and Miro embed interactive elements—Figma file embeds, milestone trackers, launch checklists—treating the PRD as a project's living hub rather than a one-time artifact.

The 5 best PRD templates for different team contexts

1. Amazon's Working Backwards PR/FAQ: best for new products and major bets

Amazon's approach inverts traditional product development entirely. Instead of starting with features, you write a press release announcing the product as if it's already launched—forcing clarity on customer value before any building begins.

Werner Vogels, Amazon's CTO, explains: "Once we have gone through the process of creating the press release, FAQ, mockups, and user manuals, it is amazing how much clearer it is what you are planning to build."

Template structure: The document has three parts. The Press Release (one page maximum) includes a headline following the format "[COMPANY] ANNOUNCES [PRODUCT] TO ENABLE [CUSTOMER] TO [BENEFIT]," a subtitle, hypothetical launch date, introductory paragraph explaining the solution and target customer, problem statement, solution description, a fictional customer quote expressing delight, a company leader quote, and a call to action.

The External FAQ addresses customer-facing questions and likely press inquiries. The Internal FAQ covers business questions (TAM, pricing, competition), technical feasibility, timeline, and resources needed.

Best for: Major new products, strategic initiatives, companies comfortable with writing-heavy culture. AWS, Kindle, and Prime Video all emerged from this process.

Limitation: Writing-intensive—takes days to weeks. Most PR/FAQs get rejected, which is a feature (cheap idea validation) not a bug.

Get the template: Coda PR/FAQ Template by Colin Bryar

This lean template works for any project size and has become the industry's most widely adopted format. Its power lies in ruthless prioritization—six sections, one page, problem-first.

Template structure:

Problem Statement (the most important section): What is the problem? Who has it? How do we know it's real? Why is it important to solve?
Solution: Proposed approach and why this over alternatives
Success Metrics: How you'll measure success
Scope: What's included and explicitly NOT included
Timeline: Key milestones and target launch
Open Questions: Unknowns, risks, assumptions to validate

Best for: Startups, getting initial stakeholder buy-in, any feature before diving into detailed specs. Works as the foundation before expanding into more comprehensive documentation.

Available in Notion: Lenny's 1-Pager

3. Kevin Yien's PRD template: best for growth-stage teams needing process

Created by the former Head of Product at Square (now at Mutiny), this template balances comprehensiveness with flexibility through a 5-stage workflow that prevents the common failure of moving to solutions before alignment.

Template structure: A header block contains project name, team name, contributors (PM, Designer, Engineer, Analyst), resource links, status tracker across five stages (Draft → Problem Review → Solution Review → Launch Review → Launched), and last updated date.

Part 1 focuses on Problem Alignment: problem description, why it matters (to users and business), customer insights, and stakeholder sign-off section with checkboxes.

Part 2 covers Solution Alignment: solution overview, goals, Non-Goals (explicit out-of-scope items), key flows and logic, design mockups, edge cases, and another stakeholder sign-off section.

Part 3 addresses Execution: launch plan, metrics and success criteria, rollout strategy.

Part 4 is the Appendix: change log, FAQ, dependencies.

What makes it distinctive: The mandatory contributor reviews at each stage create accountability without becoming waterfall. The explicit guidance to "Think of this like drawing the perimeter of the solution space—draw the boundaries so the team can focus on how to fill it in" prevents over-specification.

Best for: Growth-stage companies with 5-50 person product teams, major features requiring cross-functional alignment.

Get the template: Kevin Yien's PRD

4. Intercom's Intermission template: best for JTBD-focused teams

Intercom invented the Job Story format as an alternative to user stories, and their internal PRD (called "Intermission") embodies this philosophy. The one-page constraint is brutally enforced.

Paul Adams, Intercom's VP of Product, explains their reasoning: "The longer the doc, the less it gets read. The longer the doc, the less it gets remembered... If you're forced to limit the brief to one page, you will get much better at describing the problem you're solving."

Template structure:

Project Name
Problem Statement: Problem being solved (or speculative opportunity), why you're solving it, links to customer conversations/research, facets across product areas
Job Stories: Multiple statements following the format "When _, I want to be able to _, so I can _"
Success Criteria: How you determine if the problem is solved, qualitative and quantitative measures
Scope (added after high-level design): Releases breakdown, in-scope and out-of-scope items, estimated beta dates

Critical note: "Do not add the solution here." Intercom handles solution design separately, typically in Figma.

Additional guidelines from the template:

"Always use plain simple English, no technical terminology or codenames. Write this document as you would describe the problem to a colleague face to face."
"An Intermission must always fit on a printed A4 page. If it does not, you haven't a clear enough view of the problem yet."

Best for: Teams practicing Jobs To Be Done methodology, B2B SaaS, organizations with strong design partnerships.

Get the template: PDF Template

5. Figma's PRD in Coda: best for design-heavy teams wanting living documents

Created by Yuhki Yamashita (Figma's VP of Product), this template leverages Coda's interactivity to create PRDs that function as living project hubs rather than static documents.

Template structure:

Overview: Project name, problem statement, goals/success metrics, non-goals
Background & Context: Customer insights, market research, related work
Solution: High-level approach with embedded Figma designs (live, interactive), key flows
Detailed Requirements: Functional requirements, edge cases, technical considerations
Key Milestones: Interactive table with phases, dates, owners, status
Launch Checklist: Interactive pre-launch, launch day, and post-launch items
Appendix: FAQ, change log, dependencies

What makes it distinctive: Figma files embed directly into the document, updating automatically as designs evolve. The interactive tables for milestones and checklists turn the PRD into a trackable project management tool.

Best for: Design-forward organizations, complex features requiring tight design-development coordination, teams comfortable with modern documentation tools.

Get the template: Coda version by Yuhki Yamashita

Lean templates when you need to move fast

Basecamp's Shape Up Pitch

Basecamp's methodology rejects detailed specs entirely, keeping solutions at the right level of abstraction so engineers and designers make decisions during building. The "Pitch" document has five core ingredients:

Problem: Raw idea or use case being addressed
Appetite: How much time this is worth (not an estimate—a constraint). "We're giving this 2 weeks, not 2 months."
Solution: Rough elements at macro level only
Rabbit Holes: What could go wrong, risks identified upfront
No Gos: What's explicitly out of scope

The concept of "appetite" is unique to Shape Up—you decide the time budget before scoping, which forces prioritization.

Get the framework: Shape Up (free book)

Here is a complete example someone shared online.

Miro's Product Alignment Document (PAD)

Miro uses a canvas format instead of a traditional document, laying out elements in 2D space for better visual overview. The PAD divides work into three stages: Problem Framing, Solution Framing, and Post-Launch Recap—with the final stage focused entirely on reflection and learning.

What's notable: Creating the PRD in Miro itself means stakeholders can see all elements at a glance and comment directly on specific areas.

Reference: Miro's Product Management Process

Enterprise and complex environment templates

Uber's PRD Template

Features a comprehensive PRD Checklist covering all required sections, plus an impact matrix showing how initiatives affect multiple Uber products and functions (Rider, Driver, Eats, Fleet). Includes explicit Legal and Privacy approval fields.

Best for: Complex product environments with multiple product lines, regulatory requirements, or significant compliance needs.

Get the template: Google Docs version

Asana's Spec Template

Uses a two-stage approach: Project Brief (problem and opportunity space) followed by Project Proposal (how to solve it). Between stages, a checkpoint reads "Review Project Brief before continuing"—enforcing problem alignment before solutions.

Includes a "Non Goals" section and explicit stakeholder approval gates.

Get the template: Google Docs version

How top companies actually approach product specs

Understanding the philosophy behind templates matters as much as the templates themselves. Here's how leading product organizations think about requirements documentation:

Stripe: shaping before specs

Michael Siliski, PM Lead at Stripe, describes their approach: "At Stripe, we talk about product 'shaping'... Shaping is the process of creating a rough solution to a concrete user problem—it fills the space between broad strategy and the detailed product specification."

Stripe's shaping documents "come at it from the perspective of a user... a lot of the time, those look like a description of a user story, interspersed with code snippets because a lot of our products are APIs."

Their writing culture extends beyond PMs: "Engineers, partnerships, PMs, everybody is producing documents. That's part of how Stripe has always worked, from a perspective of trying to get to the right answer and make sure the best ideas come through, not just the loudest voices."

Linear: taste over metrics

Karri Saarinen, Linear's CEO, describes an unconventional approach: "We don't do A/B tests. We validate ideas and assumptions that are driven by taste and opinions, rather than the other way around where tests drive decisions."

On OKRs: "We haven't used OKRs. For goals, we like to keep it simple and sometimes have more strategic goals, like 'Be the default tool for startups'... I find these types of goals useful to align our team to what we are after without being too specific about how we get there."

Linear has just one person with a PM title despite 50+ employees. "Instead of having a PM for every team or area of the product, we like to see that the broader team collectively thinks about the product."

Spotify: the DIBB framework

Spotify uses Data → Insight → Belief → Bet for company alignment. Each "bet" links to a two-page document: page one covers overview (sponsor, stakeholders, success metrics, related bets), page two contains the DIBB summary explaining the 'why' and 'what.'

Marcus Frödin, Director of Engineering: "DIBBs are 'things that we believe about the world, where we want to understand why we believe it.'"

Meta/Facebook: oral culture, engineer-led execution

Will Lawrence, PM at Meta: "In over 1 year as a PM at Facebook I've created zero tickets/tasks. We don't do sprints either. PMs here focus on vision, strategy, and partnerships. Less on project management and tasks. Engineers carry most of the project management responsibility and create their own tasks."

How to choose the right PRD template

Your ideal template depends on three factors:

Company stage and team size:

Solo PM or early startup: Lenny's 1-Pager or Intercom's Intermission
Growth stage (10-50 in product org): Kevin Yien's PRD or Asana's Spec Template
Enterprise or complex product: Uber's template or Confluence blueprints
Major new product bet: Amazon's PR/FAQ

Team philosophy:

JTBD-focused: Intercom's Job Story Template
Design-led: Figma's Coda PRD
Autonomy-focused: Shape Up Pitch
Process-oriented: Kevin Yien's staged approach

The most common PRD mistakes (and how templates prevent them)

Jumping to solutions. Every battle-tested template separates problem sections from solution sections. Intercom takes this furthest: "Do not add the solution here."

Scope creep through ambiguity. Non-goals sections (present in Kevin Yien's, Asana's, and Shape Up templates) make explicit what you're not building.

No stakeholder alignment checkpoints. Kevin Yien's contributor review sections and Asana's "Review Project Brief before continuing" checkpoint prevent the failure mode of building something nobody agreed to.

Treating PRDs as static. Figma's interactive milestones and checklists, plus Miro's canvas format, keep documents alive throughout development.

Over-specification that removes team ownership. Shape Up's concept of "appetite" and Kevin Yien's "perimeter drawing" philosophy both preserve space for engineering and design judgment.

Conclusion

The right PRD template isn't the most comprehensive one—it's the one your team will actually use. Start with Lenny's 1-Pager for most projects, graduate to Kevin Yien's staged approach as you scale, and consider Amazon's PR/FAQ for major new product bets where customer clarity is paramount.

What distinguishes all these templates from generic PRD guides is their origin: real product teams at companies like Intercom, Figma, Square, and Basecamp built and refined them through actual product development. They encode hard-won lessons about what matters (problem clarity, scope boundaries, stakeholder alignment) and what doesn't (exhaustive feature lists that nobody reads).

The meta-lesson across all templates: spend more time on the problem than feels comfortable. Every template from high-performing product teams forces this discipline. As Edo van Royen observes after reviewing 13 PRD templates from top companies: "The biggest problem in product is that we tend to jump to solutions too soon."

Turn one of these templates into a working draft from your product context with the Claude Code for product managers guide.

The Complete PRD Template Guide: 15 Templates From Top Product Teams

Table of Contents