1. Understand and master PRD documents
-Writing ideas
-Writing methods
-Writing format
2. What is a PRD document
– The upward direction of the PRD document is the inheritance and development of the MRD content, and the downward direction is to technicalize the various theoretical requirements in the MRD document, and explain the function and performance requirements of the product to the R&D department and the design department.
– The PRD document is the lowest and most detailed document in the product document, so you need to be careful and patient when writing.
3. Let’s talk about the differences and uses of BRD/MRD/PRD documents
3.1 BRD
- There are benefits to doing this and explain where the benefits are
– Before Tang Seng set off, see Tang Huang (the boss) and told Tang Huang the importance of going west to get Buddhist scriptures and the benefits of Daxing Dharma. Tang Huang agreed and issued a visa-free passport (authorization), so Tang Seng set off with a mission. At that time, the Tang Dynasty A real V5.
3.2 BILLION
- After it is clear through BRD that this thing is worth doing, describe what it should be done, and explain the reason for doing it
– Tang Seng is on his way, but he needs to choose which route to take, how many people to take, why he goes this way, and why he takes these people, to make it clear:
> Route A: more monsters
> Route B: more gods
> Route C: more beautiful women
pass by Analysis, Tang Seng decided to choose the C route, so there are three dozen white bone spirits, passing through the daughter country and other classic stories (just kidding)
3.3 PRD
- Authorized, and the route to be taken has been determined, the rest is to build equipment (products)
– To give the equipment requirements to the craftsmen (R&D personnel), you need to clarify your (PM) requirements for the equipment (products)
> Gold hoop rod (need to be shortened into the ear, 1 mm in diameter, 6 mm in length, required Gold color, the weight must be controlled within 1KG)
> Nine-tooth nail rake (must have 9 teeth, nonsense, black, tooth length 8cm, handle length 1.5 meters, diameter 2.5 cm)
> So the craftsmen (R&D personnel) created a Unparalleled weapon
BRD>MRD>PRD is a process of step-by-step demonstration and results, a process of sublimation of product managers' thinking, and a process of the trinity of these three documents.
4. Object-oriented PRD documents
4.1 R&D personnel
-Because the R&D personnel Bunsheng focus on the realization and performance of functions, they are relatively less concerned about other performances such as operation, market, design, etc., and more knowledge about the product comes from the product manager's product presentation.
4.2 Designer
- Designers will pay more attention to the tone and prototype of the product, so the demand for PRD documents is relatively weak.
Therefore, PRD documents, according to the reading object, don't play tricks, use the most straightforward and simple words, and make the problem clear, and be careful to be cut in two by the programmers pulling out the axe.
5. Several representations of PRD documents
Speaking of PRD documents, many friends who have seen the template before will open Word and start writing without thinking. In fact, the purpose of PRD documents is to clarify the problem, not what tools to use! According to the actual situation, there are probably the following ways to clarify the problem:
– Text mode (Word…..the most common)
– Prototype mode (Axure….recommended)
– Picture mode (some product managers are originally art-to-interchange products, so they are good at it, there are thresholds… .)
– Video mode is also ok, but it burns too much oil
6. Contents of common PRD documents
Documentation description, product description, global function description, detailed function description
6.1 Documentation
6.1.1 Product version number (1.26)
-Version number ( 1.26 )
-> Major adjustments and upgrades
-> Product structure and functions have been adjusted.
Only when the above points occur, will the version number be modified
- Sub-version number ( 1.26 )
-> Local functions are carried out on the original basis Upgrade or adjustment
–> The local function has been upgraded or adjusted on the original basis.
Only when the above conditions occur, will the sub-version number be modified
– revision number (1.26)
–> local small-scale optimization and bug fixes
–> general It is a non-moving and functional thing.
Only when the above points occur, will the revision number be modified
- the naming principle of the version number
-> the principle of returning to zero: the previous number is increased by one, and the following numbers are all zeroed
-> charging principle: Changes in the sub-version number and revision number are generally regarded as in-version upgrades, and no additional fees will be
charged .
6.1.2 Historical revisions
– Number
– Version number
– Revision section
– Revision reason
– Revision date
–
The role of revisionist’s historical revision:
-> Compare before and after revision ->
Help maintain and manage PRD
-> Revision person
-> Revision date
-> Easy to refer to, Just look at the revisions
6.1.3 Glossary of terms
Some products that are not easy to understand, easy to confuse, or abbreviated words are listed in a unified list at the beginning, which is conducive to reading. For example , for
product 100:
-Points: According to a series of operating behaviors of users of product 100, the system generates virtual points according to the background settings. Points determine the user's level
and forum authority. The calculation method of points is: total points = number of posts X1 + Bronze X1 + Prestige X1 + Member History Online Time X1
- Prestige: It reflects the user's seniority in the forum. It is determined by comprehensive
factors . It is an important reference for user points.
-Copper plate: the currency of 100 products, mainly used to purchase valuable download materials and information, complete novice tasks to get enough
copper plate , and release download resources to get a considerable amount of copper plate, copper plate is an important reference for user points .
6.2 Product Description
Including: product information structure, product structure diagram, user flow chart
6.2.1 Product Information Structure
– The information structure diagram is a schematic diagram of arranging products only according to the product performance information in the product manager’s thinking (an example will be given later)
> The information structure can help us organize the product structure, and it is also a reference for R&D personnel to establish a database
6.2.2 Product Structure Diagram
– The product structure diagram is a schematic diagram showing the structure of the product in a structured way according to the logic and expression of the product (an example will be given later)
- Through this product structure diagram, we can roughly visualize the previously abstract logic, It is also convenient for document readers to understand our product ideas
6.2.3 User flow chart
– User usage flow chart is used to describe the behavior trend of users in the process of using the product.
Through user behavior, the information structure and product structure are connected. By reading the user usage process, readers can better understand the user behavior designed by the product manager.
Use Flowchart -> Product Structure -> Product Information Structure
6.3 Global function description
6.3.1 Global function description
Since we will describe the function description of each class and each subclass in more detail next, we need to clarify the global things that cannot be put into subclasses here
, even though they are global functions. But it can also be classified into descriptions, such as: UI, interaction, etc....
Example of global function description:
Unified instructions for user interaction:
– After the user triggers an operation, the client should load the user interface first, and use the hot wheel to prompt the
user .
– For the time display of this client, it is recommended to use user-friendly prompts, for example: 20 minutes ago, one day ago, three days ago, or more than 7 days, it will be
displayed as a specific time, such as: March 30 at 17:55, more than One year, it shows 17:55 on March 30, 2012.
6.3.2 Detailed requirements description
After the overall description is completed, we will start to describe the requirements in detail for each requirement section
– according to the actual requirements, you can express
the common expression order in the order you are used to:
> Express according to the logic of the function (more abstract , R&D likes)
> Express it according to the product structure (the logical expression of channels, pages, modules, and elements is relatively suitable for the logic of the product manager, which the product manager
likes ), that is, according to the previous product structure diagram.
– Which one is specific depends on the team’s requirements and tacit understanding
6.3.3 UML > Use Case Documentation > Use Case Diagram and State Diagram
UML is on the stage (in fact, the UML knowledge involved in writing PRD documents for product managers is very limited)
– Chinese name: Unified Modeling Language
– English name: Unified Modeling Language
– Definition: It is an object-oriented modeling language, which is Implement object-oriented description and modeling of software
systems .
UML common description diagram types
- use case diagram - representation
- state diagram
- sequence diagram
- structure diagram
- etc....
6.3.4 What is a use case diagram
Use case: A use case is a method of describing the functional requirements of a system
Use case diagram: A use case diagram expresses the relationship between the external participants of the system and the system, and is a schematic diagram composed of participants and use cases. Components of a
use case diagram: participants ( It can be a person, it can be another system, it can be something else, it is relative), use case,
association line, box. The use case diagram does not illustrate the specific process, but the use case diagram emphasizes the relationship between the system and the participants.
6.3.5 Use Case Description
The table you see is just a basic format. There is no one that has become and fixed in the industry for you to apply the use case. Everything is written according to the default habits of your team and your purpose. Do it according to your own needs.
6.4 Detailed function description
6.4.1 Basic structure of detailed functional requirements description
Overall Use Case Diagram of the Product
- Functional Block 1 Requirements
- Sub-Function 1
of Functional Block 1 • Element 1 Description of Sub-Function 1 of Functional Block 1 (Use Case Description)
• Element 2 Description of Sub-Function 1 of Functional Block 1 (Use Case Description)
– Sub-Function 2
of Functional Block 1 • Element 1 Description of Sub-Function 2 of Functional Block 1 (Use Case Description)
• Element 2 Description of Sub-Function 2 of Functional Block 1 (Use Case Description)
• Functional Block 2 Requirements (Use Case Documentation)
– Subfunction 1
of Function Block 2 • Element 1 Description of Subfunction 1 of Function Block 2 (Use Case Description)
• Element 1 Description of Subfunction 1 of Function Block 2 (Use Case Description)
– Subfunction 2 of Function Block 2
• Function Block Element 1 specification of sub-function 1 of 2 (use case description)
• Element 1 specification of sub-function 1 of functional block 2 (use case description)
6.4.2 Principles of Detailed Requirements Specification
①MECE principle
MECE, Mutually Exclusive Collectively Exhaustive, in Chinese means "mutually independent and completely exhausted". That is to say, for a major issue, it can be classified without overlapping and without omission.
And it can effectively grasp the core of the problem and solve the problem.
②MECE is just a way of thinking. When the PRD document is written and delivered to research and development, there will still be some situations that are not considered in place or the needs are adjusted.
so:
– Before writing the PRD document, you must ensure that the thinking is in place, and the product structure itself will not have major changes in the short term
– The requirements classification and expression should refer to the MECE principle
– so that even after delivery, there are adjustments or areas that need to be optimized Refactoring will occur. Refactoring requirements, re-adjusting product structure, etc., are disastrous for teams already in the development process
– requirements writing is more a test of patience, ideas, and experience, but product architecture Confirmation is a test of a product manager's ability to plan and grasp the product
- don't be afraid, don't be superstitious
7. Characteristics of an excellent PRD document
7.1 Correct
Make sure that the statements in the documentation correspond to the product manager's thinking and are correct
7.2 Unambiguous
The description of the document is easy to read and understand without ambiguity
7.3 Complete
The MECE principle tries to ensure that the system of expressing the functional requirements of the product is complete
7.4 Consistent
The terms used in the document are consistent, and the description of the same thing should be the same, and avoid mixing synonyms
7.5 Has priority
The functional requirements of the product are in priority order. For a one-time planning called a multi-functional PRD, the order of the functional requirements should be indicated.
7.6 Verifiable
For the functional description, it can be tested, not without testing. Things that cannot be qualitative, such as words such as high efficiency and perfect interaction, cannot be verified.
7.7 Modifiable
PRD documents are conducive to later revisions and upgrades
7.8 Traceable
The source of each functional requirement should be clearly understood
8. About data
"In an analysis of foreign data with 300,000 samples, 71.3% of them operate with their left thumb on a mobile phone, and 82.6% operate with their right hand on an iPad. They use their index finger when they are flat on their legs, and use their right hand when holding both hands. thumb".
- Is it very different from our imagination?
- To make a product, sometimes you need feeling, and sometimes you need data.