PRD is the document most often seen by every product staff, and there are still many product friends who asked me how to write PRD and how to express clearly. In fact, PRD does not have a prescribed format. Each company can write a PRD suitable for its product team according to its actual needs.
PRD (Product-Requirement-Document), this is a document that is not unfamiliar to any product manager. A PRD is a measure of the overall thinking of a product manager. A PRD can tell that a product manager is in The professionalism of a certain field can also reflect the overall product thinking of a product manager.
The overall thinking of the product manager is reflected in:
1. Refine core requirements
2. Think about ways to meet core needs
3. Evaluation method selection plan
4. Summary of thinking function
5. Thinking about supporting functions and related functions
6. Detailed design function
7. Sub-functions (iteration among functions)
PRD actually writes out the overall trend of the above thinking, and at the same time extracts the idea of the product, and expresses it in words to the developer, to the UI, to the visual, to the boss…PRD gives a kind of thought, which is the overall idea of the product And the relevant personnel who instilled core requirements into the product all said that PRD is a function of connecting the previous and the next, because the MRD is connected to the upper and the next is a technical description of the MRD.
There are already too many PRD files of Internet companies on the Internet. Large Internet companies such as Taobao, Baidu, and Tencent have their own PRD specifications. The PRD that suits the needs of enterprises is the real PRD. Take Taobao’s PRD as an example to explain the main content of PRD.
1. File naming (number)
The file number is very important, because the product iteration process will have different file versions. The general naming rule is “company name + product name + PRD + D1.0” (take the first version as an example), so naming has iterations using version numbers If it is a small product demand change, it can be directly named “company name-product name-PRD-D1.01”, if it involves an increase in functional requirements, it can be named “company name-product name-PRD-D1.1”. When the second version of the product appears, it can be named “Company Name-Product Name-PRD-D2.0”.
2. Revision control page
There are generally several items: number, document version, revised chapter, reason for revision, revision date, and person who revised it. The numbering is just to give the order of modification. The document version shows the current modification content in which edition, the revision chapter is the modification of which chapter and which function module, and the reason for the revision indicates the problem of this function modification. The revision date takes the date of the revision as the revision date. The revision person displays the person who revised the content module, which may be the current user or other product personnel.
3. Directory
It is not recommended to add a new directory by yourself, you can copy one from other documents, regardless of the content of the directory, you can update it after writing the PRD. But it is recommended to use Mind manager to sort out ideas.
4. Please discuss PRD with the following departments
PRD, as a “carrier” to undertake the role, will communicate with technical, operational, financial and other personnel, and the topics of communication with these personnel will appear in the sub-functions or in the basic details of the details, and need to communicate with relevant personnel Determine the “communication content”, which will be very important for the overall product process. At the same time, the extraction of product core functions is also an important link. A very important function of the product manager is communication. Example and customer service center: customer service department, content of discussion: predict customer service cost and workload; discuss how customer service supports; assist in assessing fraud/data tampering risks: fraud/data tampering risks, and risks of incorrect use. This is to be written in discussing PRD with other departments. A product manager needs to consider how to communicate and cooperate with other departments. A large part of the function of the document is to remind you of the work to be done, while constantly supplementing the work to be faced.
5. Overview
The concept is the summary, which includes: noun description, product overview and objectives, product roadmap, product risk.
Noun description: name, description. The name is a relatively new name that will appear in the document, and the description is an explanation of these names.
Product overview and objectives: Explain what the product does and why such a product is needed. At the same time, what goals the product wants to achieve. Product overview and goals are to explain the core functions of the product, and hope to achieve expectations.
Product roadmap: product staging goals, stage descriptions, and determination of time points. The product is an evolving process. Many times the first phase product only completes 70% of the product’s functions, and the second phase will continue to improve the remaining 30%. At the same time it may overturn the re-launch of the second edition. The product roadmap is not as good as planning all the phase goals, but more through maintenance to keep the product updated and iterative.
Product risk: Describe the possible risks of the product, such as the risk of business negotiations, the risk of external cooperation, the risk of improper use, etc. The risk level is high, medium and low.
6. User needs
User needs generally have only a demand description. The requirement description has the following contents: target customer, requirement description, scenario description, priority.
The target customer is the end user of the product, and the end user of the product is determined.
Demand description is a description of the needs of target customers, expressing what users need most, and finding the most fundamental needs of users.
Scenario description, under which circumstances the product will be used by users, is the user scenario simulation.
Priority refers to the priority of the user’s current product function requirements, and the priority of which functions are most desired by the user is ranked first.
7. Optional plan
List all the key points (main ideas) of the program that can be selected to achieve the goal of the product, give an appropriate evaluation to each program, and recommend the best program. You must have a lot of alternatives when planning this product. Don’t give up these options. There will never be outdated ideas, only the best ideas for the time. So you can write a few alternatives, perhaps a direction for your next product revision.
8. Benefit cost analysis
The product manager is an all-rounder and has experience in this. Product managers need to know financial knowledge. A large part of it is the cost of building the environment of the product and the cost of support personnel. General benefit cost analysis includes three aspects: benefit forecast, product technology center cost, non-product technology center support cost.
Benefit forecasting refers to providing benefit forecasts in various product environments, and marking the main variables and assumptions. It is best to include current and past benefit data. For example, the PV value of the website and the number of software usage are all benefit forecast data.
Product technology center cost refers to the resource requirements required by the product technology center to design and deploy this product, including labor costs, software and hardware expenditures, etc. Very often, this cost needs to be assisted by the project manager, and what kind of talent is needed to join the product requires human assistance.
Non-product technical center support costs, products are not only completed by the product group, but also require the cooperation and assistance of other departments. For example, how much resources need to be invested by the customer service department for the service of the product, and how much resources need to be invested by the operation department to operate the product.
9. Functional requirements
Function requirements are generally composed of four parts, function overview, function details, integration requirements, and BETA test requirements.
The function overview generally includes two parts, one is a flowchart, the other is a function table. The flowchart is the process planning for the overall trend of the product, and the flowchart is used to sort out the overall function of the product. Therefore, it is recommended that all product managers sort out the product process before making products. The function table textualizes the flow chart and lists the function points of the product.
Function details, this is the description and planning of all product functions. Include the following:
Brief description: Tell what this function does.
Business rules: Each product has its own rules when used, and the product business rules are to refine the product process. I personally suggest that the business rules of this function, including some details, such as the format of typesetting, and the way of date display, are fully set so as to facilitate the communication and understanding of other personnel.
Interface prototype: The prototype interface made by the product manager at this time is just a display frame, don’t refine it, this will create an illusion of interaction and UI. Just make a simple interface, more often just a frame diagram.
Performer: Product user.
Preconditions: specific operations.
Post-condition: display after operation. In UC (user case), post-conditions are another case, so the results of pre-conditions and post-conditions suggested in PRD are combined.
Main process: It makes sense to put the mainstream at the end, combined with the above, make the main process description. Make a point description of the flow direction of this function.
10. Integration requirements
A very important ability of the product manager is reflected in the product integration ability, using the company’s existing resources or external resources (cooperative companies, etc.) to achieve the integration of product functional requirements. While realizing the function penetration, more ways to realize the function expansion on the new product to assist the core function.
11. BETA test requirements
Many products have been released in BETA versions, just to receive comments and some performance tests. This part of the content is not necessary, but now many products have begun to release the BETA version first and then the official version, of course, it can also be solved by upgrading. So BETA testing requirements are not necessarily required. If there is a BETA test requirement, you need to write down the BETA version test requirements and the desired target requirements.
12. Non-functional requirements
It is said that product managers are all-rounders, and this is thoroughly reflected. Many product managers ignore this point, but many aspects are used, but they are weakened in the product process.
In general, non-functional requirements include the following parts: product marketing requirements, rule change requirements, product service requirements, legal requirements, financial requirements, help requirements, safety requirements, etc. It is not so much a comprehensive mastery of skills, as it is communication, how to communicate with personnel in different departments, so that more people can assist in the normal use and launch of the product.
13. On-line and off-line demand
Time limit for launch: Is this product scheduled to be launched? Is there any special basis or regulation for the launch date?
Offline demand (active requirements must specify the offline time): Is this product scheduled to go offline? Is there any special basis or regulation for the offline date?
14. Operation plan
Explain the follow-up operation plan of the product. Including collaborative operations with the operations department. What’s more is to show product managers how to display more product functions to users. Product managers are the masters of core requirements, and it is particularly important to participate in the overall product operation plan.
…
Writing PRD is not all the work of the product manager, but it is an indispensable part. It largely reflects the thinking of the product manager and the grasp of the core functions of the product. At the same time, the product manager’s communication, coordination, planning, etc. have been given a certain degree Verification, but the first function of each product manager is to write a PRD that other people can understand.
