Yaferdog
For details
Writing a pleasant PRD is the basic skill of a qualified PM, how to write well – excellent in mind & simple in form.
1. Why is an excellent PRD needed
Small case: The requirement review was expected to take one hour. PM confidently opened PRD and began to talk about his comprehensive requirements, but the r&d team found all kinds of details and logic that were not found in PRD and began to question. PM was so worried that she responded to all kinds of questions and the review meeting finally ended in two hours. When the development started, RD found that quite a lot of logical details were still missing in this PRD, so he secretly cursed PM for being unreliable and went to PM for confirmation. As a result, PM was criticized during the whole demand development cycle, while he was tired of following up the demand. After the requirements were developed, PM began to return and found that many details were not what he wanted, so HE went to RD for modification. RD thought that you, an unreliable PM, still dared to modify the requirements, but refused decisively and offered the ultimate solution. Look, there was no writing on the PRD, all PM could do at this time was to keep silent…
In fact, we found from above that a good PRD is useful.
- Is the embodiment of PM basic skills
- Save effort on developing PMS
- Improved credibility in RD’s mind (this is important)
- Criteria for requirements acceptance
How to write an excellent PRD
Then, how to write an excellent PRD – in mind, simple in form.
Each PRD should be the embodiment of the PM work, should let a man know nothing about on demand can be aware of demand in the whole picture and detail, but no one is going to start to write a good PRD, no one will be written in the first place in the PRD is thought about all the details, a good PRD is necessarily PM stepping on a pit, summed up the points, the pit Then, what elements must be included in an excellent PRD? Dry goods see below:
1. Demand latitude
What is the background of the requirement? No one wants to make a completely unknown or meaningless requirement. As a part of the project, it is necessary for r&d personnel to know the most important content of the requirement itself — what is the background of the requirement? What does demand mean? In addition, PM and R&D must also know the effective measurement method of this requirement, and then there is a fixed method, namely:
- Significance of requirements: XX requirements solve XX problems for XX to improve XX indicators/experience
- Measurement method: XX changes in XX data
2. Business latitude
Subtlety: A requirement/project (large) contains many small requirements branches, business logic, and even terms and definitions that were not previously available. This needs to be considered carefully and the flow of all roles in the business needs to be considered so as not to be affected.
Simplified: Instead of a long description document, you may need a logical diagram.
The content of business latitude is as follows:
1) Business flow chart
What is the specific business of the requirements, which departments are involved, and how materials/data/information are transferred in each department.
Take taobao refund process as an example
2) Operation flow chart
How to use each function from the user’s point of view and what the page hopping logic is.
Take the login process as an example
3) Functional branching diagram
What functions are included in the overall requirements, and what are the specific functions?
4) New definition description
What are the new definitions involved in the requirements and how do they relate to the business?
3. Page latitude
Explain the requirements, explain the business, the next step will need to be specific to the page, this part is the user really see the content, the details here is also the research and development when the real implementation of the most likely to encounter unclear details, so, the heart is particularly important. So what exactly does page latitude include?
There are five aspects:
1) Role differences
Whether to display different contents in different roles when entering the page.
2) Way of presentation
After entering the page, the default display style, rules of multi-information arrangement, logical changes involved in UE chart, details before and after the control is clicked, and the limit of the number of words need to be described in detail.
3) Interaction mode
What is the interaction mode of each control switch in the page? Is there any special interaction mode that needs to be pointed out
4) Exit method
Check whether the page exit logic complies with the logic of entering and reentering the page (based on scenarios and requirements). If the page exit logic does not comply with requirements, clearly mark the page exit logic.
5) Data rules
Details of refresh, cache, loading and loading need to be described in detail. However, since this part involves a lot of technical content, it is necessary to communicate with RD in advance before filling in the determined content to PRD.
5. Boundary conditions
Abnormal situations also need to be classified and described in PRD in detail. For RD, this part is indispensable, and it is the most prone to leak in PRD. Boundary cases generally include the following six types.
1) Login related
User login and non-login display logic, whether can enter the function, etc.
2) Network related
How to deal with no network/weak network, how to display the page.
3) Blank page correlation
How to display blank page information
4) Version-related
How the historical version accommodates new styles and information.
5) Operation related
The user kills the APP when using it and clears the cache.
6) Account related
How to process data after an account is changed on a device.
7) Data correlation
If the data to be processed in this requirement is useful in other requirements, will it be changed together? How to accommodate the problem
Always check your typos and typography
A typo will make most of your previous efforts in vain, the appearance of typo will make the hard-won credibility of a sharp decline, so do not look down upon it, it is a manifestation of a PM professional attitude.
Look back at the layout. Whether it is comfortable to look at and the information is clear and easy to understand determines the first impression of PRD. Please treat PRD like a work of art.
Summary: Here’s a picture, that’s all there is:
Third, write the last words
A PRD is not just a PRD, but a PM’s logic, thoughtfulness, understanding of requirements, and understanding of beauty can be seen from a PRD, which represents the level of a PM.
Good at heart, simple in form, with PRD, need to be the same… .
This post was originally posted by @yaferDog everyone is a product manager. Reprint without permission is prohibited.
Photo from PEXELS, based on CC0 protocol
PRD
Product requirements Document
Document writing
