It can be said that the most important job of the product manager is to explain the requirements to the team. Only by explaining what the requirements are can we develop, design and test in the follow-up work. PRD is the best choice for product managers to explain requirements.

What is the Pearl River Delta?

PRD (Product Requirement Document) is an important document for a product manager to explain the requirements to other project members, and it is also the result of your participation in the requirements review meeting in PM.

You may not know what the requirements review will be, so I will simply say it. The requirement review meeting is a meeting where the product manager puts forward the requirements and PK with everyone, so that everyone can evaluate the requirements put forward by the product manager and then decide the follow-up work. Almost all development, design and testing will have endless work. Why do you let them give priority to your needs? This will seriously test you and your Pearl River Delta. If not, you will be developed, designed and tested from head to toe. The scene was as popular as the live broadcast.

As for why it is wrong, to a large extent, the product manager did not think clearly about the requirements of all aspects. Even if a logic is not clear or a step is missed, the rest of the team will cast a skeptical eye on you. If you have been suspected many times in a judging meeting, forget it, you are enjoying yourself.

Who is the Pearl River Delta for?

First of all, PRD is for product managers to see for themselves. The product manager puts forward a requirement, so the function and logic to realize this requirement can be slowly sorted out through the process of writing PRD. Someone said, "I have done all the calculus problems with my heart, and I can think clearly about your function and logic."

Secondly, PRD is for the rest of the team. A product manager, even if he can think clearly about all the functions and logic in his mind, can't guarantee that the rest of the team can think clearly about all the logic in his mind. Therefore, the product manager needs to let other team members understand the logic of requirements by outputting PRD.

Third, the Pearl River Delta is also for the boss. The product manager needs to make a product. When applying for resources with your boss, giving a clear PRD can let your boss see what you want to do.

Do you know how important the Pearl River Delta is?

The importance of the Pearl River Delta cannot be overemphasized.

First of all, the Pearl River Delta can prove the demand. You verbally talk to developers, designers and testers about requirements, and they may also verbally agree to help you. Then, maybe there isn't. Then. . . Near the start of the project, you suddenly find that they didn't do what you wanted. Then you go to them, and they can say it's not what you want. That scene is eating directly. Therefore, the product manager needs to carefully write a PRD. After the requirements are approved, the emails will be sent to the uncles of development, design and testing, and there will be documents left, so there will be no way to rely on them.

Secondly, the Pearl River Delta can prove PM. Many companies regard the revision times of PRD as a standard to judge the PM level, and may also serve as a reference factor for PM upgrade evaluation. If a product manager writes too many PRD modifications on average, it will seriously affect the upgrade evaluation.

PRD closed loop

To make a product, we need to think about the closed-loop problem of the product all the time. As a specification of requirements, PRD needs to reflect the closed loop of products. Complete the following steps, and you can write high-quality PRD.

What's your purpose?

This is the most important part of the Pearl River Delta. In fact, it is not difficult to make a product or realize a function/logic, but you have to think about why you want to do it, or you have to make sure that you get what you want by doing it. I can't think clearly about this question, and the latter one is useless. For example, if you are going to make a game activity page, the original purpose is to create something new, but the purpose is not well grasped and then kept, then your KPI is likely to be "Hehe".

Functions needed to achieve the goal?

Under the premise of clear purpose, PM should carefully think about the functions needed to achieve the purpose, which are the only way to achieve the purpose. It is best to give a function list, and each function point can be listed separately, corresponding to the test cases one by one.

You can also give the application scenario of the function, which is convenient for others in the team to understand the function. For example, a simple user wins an award on an activity page:

After purchasing the service, users get the redemption website.

After the user enters the URL, the activity page pops up.

The user clicks the "Get Award" button, and the registration/login box pops up on the page. Users enter the account password, log in successfully, and receive rewards.

After the function points are listed, the functions in the function list need to be sorted to get the priority. Requirements that are not done temporarily should also be put forward in advance and put into the demand pool.

Logic required to complete the function?

This part actually divides the function into many small function points, such as a redemption function, and can also be divided into small function points such as registration, login, and third-party login. Realizing the logic of each function point constitutes the whole redemption function.

This part, I feel, is the most important stage to realize the product experience. How to realize the logic of a function, so that users can use it without complexity, and at the same time, the development workload will not be too great, and at the same time, most scenes can achieve the correct results normally, which is not a simple matter.

Abnormal logic, crisis management?

After most users can use the function normally, they need to think about some abnormal logic and crisis situations. This part tests the logical thinking of the product manager very much, and comprehensively tests it from two aspects: depth and breadth. This part is also the easiest place for other people in the team to find logical loopholes, which makes you feel like you are eating live broadcasts every minute. Therefore, in this respect, we should work harder and find ways to think out every abnormal logic and handle the crisis well.

Let's take the redemption activity as an example. The purpose of the redemption activity page is to increase the installed capacity of a client, so it must be set that the client must enter the activity page to jump out of the redemption website (the client has browser function). Then the exception logic may be:

The user does not enter a URL at the client.

When the network is disconnected, the user enters the website address in the client/other browser.

The user enters the active website after the active time expires.

…………

Strive for the necessary resources

After completing the above steps, you need to ask the project team for resources.

Project members: programmers (front-end, back-end, operation and maintenance, etc. ), designers (interactive, visual), testing, operation, business, etc.

Hardware resources: servers, promotional items, etc.

Data feedback

This part is also very important. When you make a product, you definitely need to know its market feedback. After getting the feedback, you can decide what to do next. Here we need to design a data feedback system and establish the evaluation index.

page layout view

exchange rate

retention rate

User activity days

Product income

Quantity and quality of tasks and activities completed

After completing the above steps, a complete PRD closed loop is completed. Now, you can go to someone else's PK. If you do it seriously enough, you should not have to live a popular life, and you can stand up straight and be an uncle. This world is a world of "either you are an uncle or I am an uncle", so you should try to be an uncle yourself.

Note: There are still many pits.

This section explains the matters needing attention when writing PRD.

Transposition consideration

When writing PRD, you must always think about empathy. You must think that your document is used for development, design, testing, etc. , and understand the language as much as possible. Try not to use adjectives. When describing functions, you can try to think about the writing method with the logic of development.

Don't ask for perfection

This part is the deep pit I stepped on. I've always wanted to arrange all the logic in a flow chart, but in many cases it's impossible unless the product you make is relatively simple. Even if you can really put all the logic into a flowchart, the flowchart will be very complicated and difficult for the rest of the team to understand. It is best to explain the function separately, and the normal logic and abnormal logic separately.

What you see is what you get.

This is an era of reading pictures, and the picture is the clearest. Some function points are complex in logic, so we can consider using prototype diagrams to show them, and what you see is what you get.

How is the implementation progress?

In addition to PRD, it is best to make a project schedule, which should be updated in time to let the whole team know the progress of the project.

On language barriers and typos

A high-quality PRD, it is best to reach the verification level of press releases, and there are basically no language diseases and typos. If there are too many grammatical mistakes and typos, it is easy for people to think that you are not rigorous.

Typesetting standard

There must be a set of standards for typesetting, so as to ensure that every PRD you have follows the same standard. Typesetting should be beautiful and generous, and there should be certain choices in font, color, font size and line spacing.

Well, the above basically introduces the theoretical knowledge of the Pearl River Delta, and everything I said may be wrong. Having said that, in fact, the role of PRD is to let others help you with your work. In an extreme case, imitating the full-stack engineer, I put forward the concept of "full-stack product manager". When a product manager is tough enough, he can be proficient in planning, front-end development, background development, design, testing, operation and business. Then I will call this kind of person Ta "full stack product manager".

If you are a full-stack product manager, then what I said above about PRD may be rubbish to you, and you can do everything yourself. Please be sure to add me to WeChat and let me worship you. But even if you are a full-stack product manager, you can do all the work by yourself, and the completion time will definitely be long and the efficiency will definitely decline. So, PM brothers and sisters, let's write PRD honestly!