If you’ve ever asked “how do I actually write a PRD?” and come away from Google with a list of six vague headings and no idea what to put under them, this guide is for you. I’ve written and reviewed PRDs for over a decade as a product manager, and I’ve watched dozens of the candidates I mentor freeze at exactly this point — they know a PRD needs an “objective” and “success criteria”, but they’ve never seen a real one filled in end to end.

So this isn’t another list of components. We’ll cover the six sections every PRD must have, and then I’ll write a complete worked example in front of you — a real PRD for a “save your card for faster checkout” feature — section by section. At the end you’ll get a copy-paste template you can start with today.

First, what a PRD actually is (and isn’t)

A Product Requirements Document (PRD), simply put, lists out all the features of a product in as much detail as possible. In the product management world, a PRD is nothing less than a Bible — it’s the Product, Design and Tech teams’ go-to document for anything related to the product.

A PRD is different from a Business Requirements Document (BRD) or Market Requirements Document (MRD). A BRD/MRD focuses on what the actual customer problem is, or what the business opportunity is — the “why”. A PRD focuses on the “what” and the “how”: what are we going to build, and how are we going to build it?

Here’s the thing people get wrong: there is no fixed, standard template for a PRD. Every product manager has their own style, and every company has its own flavour. What doesn’t change is the set of questions a good PRD has to answer. Those questions map to six key components — so let’s go through them, and then build one for real.

The 6 key components of a PRD

1. Objective

This section explains, at a high level, why we’re building this product, what customer problem it solves, and how it helps the business grow.

Not every product is meant to change the world or have org-level impact. Even a modest objective like “achieving competitive parity” is perfectly valid. The point of this section isn’t grandeur — it’s alignment. Every stakeholder should walk away agreeing on why this exists.

2. Success Criteria

Success criteria are the quantitative metrics you’ll use to judge whether the product succeeded or failed after launch. Be as specific as possible and leave nothing open to interpretation.

For example: if you’re revamping your sign-up flow to reduce user drop-off, your success criterion might be “a 10% drop in incomplete/abandoned sign-up requests”. You can define multiple metrics — as long as your system can actually measure them. A metric you can’t instrument is just a wish.

3. Product / Feature details

This is where the meat of the PRD sits. It lists the actual features and sub-tasks, usually written as user stories. The standard format:

As a [user type], I want to [perform some action] so that I [achieve some goal].

Say you want to store users’ credit card details on your e-commerce platform for faster checkouts. Your user story would look like:

As a buyer, I want to store my credit card details in my profile so that I don’t have to enter them every time and can check out faster.

That format is an industry standard, not scripture — adapt it to whatever your team understands best. The real job is clarity: Product, Design and Tech should read it and understand the requirement the same way.

Crucially, cover the corner cases. In the example above: What happens if the user enters card details but your system can’t verify them with the bank? Is there a character limit on the name field? Corner cases are where junior PMs get exposed and where real production bugs are born.

Beyond user stories, depending on complexity, this section should also carry: flowcharts / process-flow diagrams; implementation or tech-architecture notes where possible; assumptions made while building; constraints or known scenarios where the product won’t work; and prerequisites or dependencies on other data or products.

4. User Experience (UX) flows / Designs

Include a visual representation of the UX or user journey — wireframes, or low/high-fidelity prototypes. A picture really is worth a thousand words here. Seeing how the product will look to the end user solidifies the understanding you built in the previous section. Add competitor screenshots for reference if a similar feature already exists elsewhere.

As I wrote in Top 5 Product Management tools every PM must be good at: if your vision of the UX is all verbal, there’s going to be a significant gap between what you imagined and what the design team builds — leading to endless iterations and quietly eroding your credibility with the design team.

5. Roadmap / Release plan

A PRD should carry a tentative release timeline. For a complex product this usually means a phased release: a core set of features ships as the MVP (Minimum Viable Product), and the rest follow in later releases. This helps the tech team prioritise and allocate resources sensibly.

6. Stakeholder Review & Sign-off

This is one of the most important parts of a PRD, and it’s the one most often skipped — even at big MNCs. Review and sign-off brings accountability into the system. It forces stakeholders (Product, Business, Design, Tech) to commit to a defined scope, and ideally there’s no going back.

Product releases slip because the Product team expands scope mid-development, or the Business team quietly changes (or “forgets”) a requirement they’d agreed to, or the Tech team reworks the implementation to dodge complexity. It may not sound professional, but it’s the truth and you know it. As I put it in Top 10 Product Management Skills: tech is usually the easy part — people are the ones that bring the complexity. A signed-off PRD is your defence against all of it.

A full worked example: a PRD for “Save card for faster checkout”

Enough theory. Here’s what those six sections look like filled in for a real feature — letting returning buyers save a card so they can check out in one tap. This is deliberately concise; a real PRD would go deeper, but the shape is exactly this.

1. Objective

Returning buyers abandon checkout because re-entering full card details on every purchase is slow and painful, especially on mobile. We’ll let buyers securely save a card and reuse it for one-tap payment. The goal is to reduce checkout friction, lift repeat-purchase conversion, and stay at competitive parity with platforms that already offer saved cards.

2. Success Criteria

• 10% reduction in checkout abandonment for returning users within 3 months of launch.
• 20% of returning buyers save at least one card within 2 months.
• +5% increase in repeat-purchase conversion rate.
• No increase in payment-fraud or chargeback rate versus the pre-launch baseline.

3. Product / Feature details

User stories

• As a returning buyer, I want to save my card during checkout so that my next purchase is faster.
• As a buyer, I want to see my saved cards at checkout and pick one, so I don’t re-enter details.
• As a buyer, I want to delete a saved card from my profile so that I stay in control of my data.

Corner cases

• The card is saved but the bank fails to verify/tokenise it → don’t store it; show a clear error.
• Saved card has since expired → flag it at checkout and prompt for a new one.
• Buyer has multiple saved cards → mark one as default, allow switching.
• Security → require CVV re-entry for each transaction even on saved cards.
• Guest checkout → no save option is shown (no account to attach the card to).

Assumptions / constraints / dependencies

• Assumption: card details are never stored on our servers — we store a token from the payment gateway (and, in India, comply with RBI card-tokenisation guidelines).
• Constraint: only cards from supported networks/gateways can be saved in v1.
• Dependency: the payment gateway must support tokenisation and return a reusable token.

4. UX flows / Designs

[Wireframe placeholder] Checkout screen shows a “Save this card for faster checkout” checkbox under the card form. Returning buyers see a “Saved cards” list at the top of the payment step with a “＋ Use a new card” option. A “Manage cards” screen in the profile lets buyers view and delete saved cards. Attach the Figma link / screenshots here.

5. Roadmap / Release plan

• MVP (Phase 1): save and reuse a single card, CVV required per transaction, delete from profile.
• Phase 2: multiple saved cards, set a default, manage in profile.
• Phase 3: true one-tap checkout, network tokenisation, saved UPI/wallet options.

6. Stakeholder Review & Sign-off

Stakeholder	Role	Sign-off
Product	Owns scope & priorities	☐
Business / Payments	Owns conversion & commercial targets	☐
Design	Owns UX flows & wireframes	☐
Engineering	Owns implementation & tokenisation	☐
Legal / Compliance	Owns RBI/PCI-DSS compliance	☐

Once every box is ticked, scope is locked. Changes after this go through a documented change request — not a Slack message someone denies sending later.

Copy-paste PRD template

Start from this skeleton and delete what you don’t need:

# PRD: [Feature name]
Author: [name]  |  Status: [Draft / In review / Signed-off]  |  Last updated: [date]

## 1. Objective
- Problem:
- Why now / business goal:

## 2. Success Criteria
- Metric 1 (target, timeframe):
- Metric 2:
- Guardrail metric (must NOT get worse):

## 3. Product / Feature details
### User stories
- As a [user], I want to [action] so that [goal].
### Corner cases
-
### Assumptions / Constraints / Dependencies
-

## 4. UX flows / Designs
- [Link to Figma / wireframes / screenshots]

## 5. Roadmap / Release plan
- MVP:
- Phase 2:
- Phase 3:

## 6. Stakeholder review & sign-off
- Product / Business / Design / Tech / Legal → [sign-off status]

How to actually write it (a practical order)

Most PMs write a PRD top to bottom and get stuck. I write it in this order instead: nail the objective and success criteria first (if you can’t state the metric, you’re not ready to build), then draft user stories with the corner cases, then loop in Design for the UX flows, then set the roadmap with Engineering, and only then send it for sign-off. Writing it in that sequence means every section is informed by the one before it — and you stop rewriting the same doc five times.

Common mistakes I see

• No measurable success criteria — “improve the experience” is not a metric.
• Skipping corner cases — this is what separates a PRD that ships clean from one that spawns a bug backlog.
• No sign-off — the single biggest cause of scope creep and delayed releases.
• Writing for yourself, not the reader — if Tech and Design can’t act on it without a meeting, it’s a diary entry, not a PRD.

FAQ

What is a PRD?

A Product Requirements Document is the document a product manager uses to define what a product or feature should do and how it should behave, so Product, Design and Engineering are aligned before building.

PRD vs BRD vs MRD — what’s the difference?

A BRD/MRD covers the why (the business or market problem). A PRD covers the what and how (what we’ll build and how it should work).

How long should a PRD be?

As long as it needs to be and no longer. A small feature might be one page; a complex product several. Clarity beats length — if a section isn’t helping Design or Tech act, cut it.

Who writes the PRD?

The product manager owns and writes it, but it’s built collaboratively — Design shapes the UX section, Engineering the feasibility and roadmap.

Do PRDs still matter in agile?

Yes. Agile changed how often you revise the doc, not whether you need shared, written clarity. A lightweight living PRD beats tribal knowledge every time.

What tools should I use to write a PRD?

Whatever your team already lives in — Confluence, Notion, Google Docs. More on this in Top 5 Product Management tools every PM must be good at.

---

Preparing for PM interviews? Writing a crisp PRD is a common interview exercise. I’ve mentored 50+ candidates into roles at Google, Microsoft and Amazon — book a 1:1 mock interview session and we’ll practise it live.