Internet Jargon — PRD

🗣️Chatting
1

In a Product Manager’s (PM) day-to-day work, the PRD is one of the most critical deliverables — its full name is Product Requirements Document, commonly translated in Chinese as “Product Requirements Document”.

If developing software is likened to constructing a building, then the PRD serves as the detailed architectural construction blueprint.

1. Core Purpose of the PRD

The PRD exists to eliminate information asymmetry. It translates the PM’s ideas into logic understandable by developers and evaluation criteria usable by testers.

  • For Development (Dev): Specifies which features to build, their logical branches, and edge cases.
  • For Design (UI/UX): Defines required page elements and interaction flows.
  • For Testing (QA): Clarifies acceptance criteria, enabling test case creation.

2. What Does a Typical PRD Include?

Although templates vary across companies, a typical PRD usually contains the following sections:

  • Document Overview: Revision history (what changed, who changed it), project background, and objectives.
  • User Roles: Who will use this feature? (e.g., user personas)
  • Business Process Flowchart: High-level business logic (e.g., the complete path from order placement to successful payment).
  • Functional Details (Most Critical):
    • Wireframes: Static page sketches.
    • Rules Specification: Where does clicking a button navigate? What is the character limit for an input field? How is the user notified when offline?
  • Non-functional Requirements: Performance requirements (e.g., response time), security, compatibility (iOS/Android).

3. How the PRD Differs from Other Documents

Beginners often confuse the PRD with the BRD and MRD. Their hierarchical relationship is typically as follows:

  1. BRD (Business Requirements Document) — Business Requirements Document:
    • Focus: Is it profitable? Why should we invest in this project? (Intended for executives.)
  2. MRD (Market Requirements Document) — Market Requirements Document:
    • Focus: Who are our competitors? What are our competitive advantages? (Intended for marketing/operations teams.)
  3. PRD (Product Requirements Document) — Product Requirements Document:
    • Focus: How will it be implemented? What are the specific interactions? (Intended for engineering and design teams.)

4. What Makes a Good PRD?

For engineering team members, the worst PRDs are those riddled with logical inconsistencies or written arbitrarily. A good PRD should:

  • Be Clear and Unambiguous: Avoid vague terms such as “approximately,” “possibly,” or “optimize user experience.”
  • Be Logically Consistent: Ensure smooth execution of normal flows, and explicitly address exceptional scenarios (e.g., erratic user behavior, network outages, lack of permissions).
  • Have Explicit Version Control: Every requirement change must be clearly documented to prevent disputes arising from “verbal requirements.”

One-sentence Summary:

The PRD is the product manager’s detailed manual describing “what the product looks like” and “how it works.”