Introduction #
I officially started as a product manager in July. Honestly, when I first entered this field, I only had a vague idea of what a PRD even was.
Before this, watching others write documents, I thought it was just about drawing prototypes and describing features. But when I actually started doing it myself, I realized the problems were far more complex than I imagined. I’d design features with missing pieces, get stumped during dev reviews, and after launch discover that I forgot to set up tracking and couldn’t get the data I needed.
After some painful lessons, I started seriously researching how to write a proper PRD. This article is my summary of PRD writing methods, and also a note to my novice self.
Three Forms of PRD #
Before diving into how to write one, let me address a common mistake newcomers make: not every requirement needs a full PRD.
With today’s fast-paced development cycles, some simple changes don’t warrant a dedicated document at all. For instance, changing a few words or adjusting a button color? Just note it in your task management system. I call this in-task design.
But there’s also the opposite extreme: when you’re building a complex product from scratch—say, an e-commerce app or a social platform—a single PRD can’t possibly contain all the design details. Multiple product managers might collaborate on a whole Product Suite, with a top-level PRD as the master index and individual PRDs for each module.
The PRD type we write most often in daily work sits right in the middle: User Story-oriented PRD. That’s what this article focuses on.
The Standard PRD Structure #
A qualified PRD should contain these six sections:
- Version History
- Background and Objectives
- Story Introduction
- High-Level Design
- Detailed Design
- Delivery Design
Let me walk through each one.
Version History #
This is straightforward: document every update you make. But here’s the key point—version history isn’t updated every time you change something. It’s tied to your Review cycles. After each Review, you note what changed. This way, whoever joins the next Review can quickly see: compared to last time, what adjustments were made?
Background and Objectives #
This section is also basic, though in many companies, the Background might already be covered by an MRD (Market Requirements Document) from the business team.
Background answers: Why do we need this feature? What business value will it bring?
You don’t need to go into excessive detail here—just articulate the core rationale. Is it expanding the user base? Improving a key business metric? Addressing a pain point users frequently complain about? State the essential reason clearly.
Objectives answer: What results do we expect after this feature launches?
Objectives can be quantitative or qualitative. “DAU up X%,” “churn rate down Y,” or “support for a new user scenario”—whatever matters for your context. What matters is that everyone reading the PRD understands what value this feature is supposed to create.
Objectives matter because they help everyone reading the PRD understand: what value is this feature ultimately supposed to create? How to achieve those objectives doesn’t need to be explained here—that’s what the rest of the PRD is for.
Story Introduction #
This is a section many novice PMs skip.
When designing features, many people open their prototyping tool and start drawing pages immediately. That’s the wrong approach. As a PM, what you really need to explain first is: What is the meaning of this feature? What problem does it solve?
The core of Story Introduction is breaking down scenarios. The method is simple: list every user action you can think of, one item per line. Don’t write in detail—just capture the key nodes of the user journey.
Why do this? Because after listing these scenarios, readers will have a “mental picture”—they’ll associate it with similar products they’ve used, forming an initial impression of the feature. This mental picture is crucial. Everything that follows fills in and refines that picture.
After establishing scenarios, you need a value analysis. For instance, we believed that supporting video posts would increase user dwell time on the app. Video content (especially long-form) keeps users engaged more persistently. And dwell time is a critical metric: the more time users spend here, the less time they have for competitors.
Of course, value analysis usually requires PMs to collaborate with operations teams. Going solo often leads to logical blind spots.
High-Level Design #
High-level design corresponds to three of the five product design diagrams: Module Map, Feature List, and Page Structure.
The Feature List is the heart of it all. Many people think prototypes are most important. They’re wrong. A clear Feature List is the table of contents for the entire PRD.
How to structure a Feature List? Organize by modules. Use M to mark Modules, F to mark Features. List all features under each module exhaustively.
Why exhaustive? Because it gives the team a complete overview. Development teams have dozens of people, each sprint capable of only implementing three or four features. First, they need to know the big picture. Tech Leads can assign tasks based on the feature list. QA can prepare test cases from it. The feature list is like a book’s index, ensuring nothing gets missed.
Page Structure is the visual index corresponding to the feature list. Each page hosts certain features. If you find a feature in the list that has no page to host it, or a page that hosts features not in the list, something’s missing. This is a self-consistency check mechanism.
Detailed Design #
Detailed Design is actually the most straightforward part because everyone’s familiar with it: describe each page’s interactions and field specifications.
But one key point: every detail in the Detailed Design must correspond back to the Feature List and Page Structure. If you wrote a feature but it wasn’t listed earlier, add it. If a listed feature has no detail, fix it.
After several self-consistency checks, your design will be very complete and unlikely to miss logic. Trust with your team builds this way.
Delivery Design #
This is another section that’s easy to overlook.
Within Delivery Design, the two most critical areas are: Data Tracking Design and Launch Prerequisites.
Data Tracking: Many PMs only remember they need data analysis after the feature launches—then discover they forgot to set up tracking and can’t retrieve the data. This is a terrible situation.
The right approach: before the feature enters development, during the design phase, think through what data you need. Can your current tracking setup support your analysis needs? If not, modify the tracking plan now.
Data analysts are also “users” of your PRD. During testing, they verify that tracking is correct and can generate the reports you need. If not, testing hasn’t passed. It’s a double safeguard.
Launch Prerequisites: Does this feature depend on other systems launching first? Will it affect historical data? Do backups need to be prepared in advance? PMs must think through all of this.
After Launch #
One habit I have: one to two weeks after a feature launches, when data stabilizes, I update the PRD. I tell the team: here’s what we predicted, here’s what actually happened.
If you design 10 PRDs and all 10 features’ post-launch data closely match your predictions, you’re definitely an expert. Being off initially is normal—don’t be afraid. Taking that first step already puts you ahead of most people.
Review Efficiency #
One final tip for improving efficiency: before the PRD review meeting, send the document one to two days in advance to the devs.
Many newcomers, worried about being criticized by experienced engineers, hide their PRD until the review meeting and rely on live performance. This is a bad habit.
The right approach: boldly share early. Let everyone review beforehand and come to the meeting with questions. Many issues can be resolved offline, making the meeting far more efficient.
Closing Thoughts #
Product management is a practice-heavy profession. Only by actually writing and doing can you turn others’ experience into your own ability.
Keep building.