How to write a good product requirement document (PRD)?

PRD (product requirement document), as the name implies, is a document that describes the requirements of a product, and its core is to describe the requirements clearly.

Through PRD can be seen a product manager of the product understanding of logical thinking, product managers in the relevant field of knowledge and professional depth and the overall understanding of the product. How to write good PRD, let product development team members, develop, test, and operate students to understand the product requirements, so that others can see the value of the product and the meaning of the document, it is estimated that many people have thought, how to let PRD not be challenged by others, how to obtain their approval estimate is the product manager often consider the issue. Others may think that PRD as long as the central idea, clarify demand is enough, to the downstream students they understand the finished, but this document is applauded, whether useful, whether there is value may never be considered.

From the PRD user side, we will analyze the essential factors or necessary conditions for good PRD.

First, understand the PRD of the Reading object, the user.

PRD templates generally have the following information:

PRD expected readers include: product, development, testers and corresponding principals and user side representatives. The product, development, tester will learn the background and detailed requirements of this requirement, as well as the future direction of each demand point or value to the user. The user's representative can then use the document to see if the content described in PRD is what it expects, whether it is compliant, and whether it is covered by its own expectations. Therefore PRD is also the product manager and the related role confirms the development task the important basis. This PRD will be used as a basis for subsequent development, testing, and verification of requirements when all characters have approved the contents of the PRD.

Second, a complete PRD should also have the elements

1. Name and number of document

The number and naming of documents is critical, each product is accomplished by several iterations, and the product functionality or upgrade requirements for each iteration may be different, so you need to define which iteration the file belongs to the product and modify several versions. The method of file naming is generally defined by the version number, for example, the simple method is, XX product v1.0prd_v2, the previous V1.0 is the product iteration number, the V2 PRD version number. A little detail can be defined as XX products xxxx demand prd_v2, that is, the needs of this iteration to name the task, so that more easily read and memory.

2. Version history of the document

Includes, numbering, document version, chapter, Reason for modification, date, modification person. Numbers are just for the order of the changes, the current modified content displayed by the document version belongs to the first version of the document (or several changes, one revision in general), and the chapter is specific to the function module that the modification content belongs to, so that the reader can find the modified content in time, and the reason why to modify the demand, Let the reader intuitively understand the reason. Date refers to the time required for a document to be modified, which refers to the modification of the content of the requirement.

3. Catalogue

You don't need to create a new one, you can update the catalog in the template directly after the document completes. The directory is used to understand the structure of the document

4. Introduction

This section includes: Product Overview and Objectives, product roadmap, expected readership, successful definition criteria and judgments, reference materials, terminology descriptions

Product Overview: Explain the background and core features of the product development.

Product Roadmap: The Blueprint for product planning, the core tasks of each critical phase. Product development is a continuous iterative process that requires several versions of iterations, and it is common for a function point to be returned to the first iteration after it has been done n iterations. The product manager needs to be mentally prepared. Product roadmap does not require all of the stage goals to be fully planned, but an estimate of the future development of the product requires more updates and iterations to reach the goal. A clear presentation of the product's roadmap can help the product manager grasp the full picture of the product and better control the development process.

Intended reader: Document usage objects

Criteria for successful definition and judgment: aims to demonstrate product objectives

References: PRD

Noun Description: Name, description. Names are the newer names that appear in the document, and they are explained by the description.

5, requirements overview

Requirements overview Typically includes an overview of requirements, user classes and characteristics, operational environments, constraints on design and implementation, project planning, product risk, and so on

Requirements Overview: In two parts, one is the business flow chart, the whole process of product business process to do a graphical display, the product is the overall function of the process of interpretation. Second, the demand list, the secondary development of the requirements of the task to classify, give a concise description of requirements and priority.

User classes and Characteristics: End users of the product, determine the end-user of the product, and explain the role and actions of the consumer.

Operating environment: The use of the product after the online environment, such as supporting browsers and its version, operating system, database requirements, etc., testers to see the environmental requirements will be in the test focus on testing, and the final on-line product needs to be the best operating environment to inform the user.

Design and implementation constraints: such as the development environment for controls, how interfaces are invoked, and so on

Project plan: For the content to be developed in the PRD, give key milestones, such as the time required to review, the completion time of development, on-line time, etc.

Product Risk: Describe the possible risks to the product, such as performance bottlenecks, unresolved issues, the risk of improper user use, and so on.

6. Functional Requirements

Functional requirements are generally explained by functional details and the main course description. Feature details are the description and planning of all product features. Feature details include the following:

Brief description: Describes the purpose of this feature, including its source or background, to address what issues.

Scenario description, the product in which case will be used by users, is the user scene simulation. This is also the product manager to say "good" the necessary conditions for the story.

Business rules: Each product in the development of the corresponding business rules, the rules are clearly described, so that development, testers can intuitively understand the rules, and no ambiguity. Business rules must be complete, accurate, and understandable. If the description of the business rules involves page interaction or page modification, it is recommended that you give a sketch of the page or a screenshot of the page to indicate what you want to modify. It is also recommended that the page's input box, the content format of the Drop-down box, length, the relationship between the controls to make a description, when visible, invisible, gray off or lit conditions in the document are given instructions. Read the reader's understanding of business rules easily.

Interface prototypes: As mentioned earlier, the product manager needs to design the page prototype as it relates to the part of the page interaction. Prototype design usually requires product managers and UI designers to complete. The recommended approach is that the product manager can design a page frame that explains the fields to be rendered by the page, their characteristics, and the scenes to be used by the page to the interaction designer. After the interaction and visual designers to complete the product prototype design.

User description: To the product user to make a description, can be incorporated into the brief description.

Preconditions: The requirement implements the prerequisite for dependency. For example, when uploading photos, you need to have image files.

Post condition: Subsequent processing that is raised after the operation.

Main process: It makes sense to put the mainstream in the end, and, combined with the above, make a master flow statement, a step-by-step description of each functional flow direction (this is very important).

I've seen a lot of PRD, there is no prerequisite in the document, there is no post conditions, only the mainstream of the description, but there is no description of the main process in each functional process of the various trends, only a main direction, people feel PRD into the Operation manual. In fact, the introduction to the branch is very important, and the various issues raised in the development and testing are related to the unclear definition of the branch. A qualified PRD not only to describe the main flow, but also to the branch of the various problems arising from the process to be detailed and provide solutions. The PRD feature must be a clear, comprehensive exposition of requirements and the handling of all kinds of anomalies rather than waiting until the development and testing phase to identify the problem and then give the answer (although PRD cannot fully cover all possibilities, maximizing the thinking of all business issues is the principle to be followed when compiling PRD). In addition, the description of functional requirements in the method given by the "may", "or" and other words, it must be clear, the only description. If there are other scenarios, it is recommended that you write "optional Scenarios", where early alternatives to the product build can provide more choices for the functionality implementation, and when the scenario is determined you can indicate in the document which scenario is being used.

Recommend a method: "Use case", in the object-oriented software design model, the use case is an elaborated content, use case is to the function use scene explanation. The use case is a very methodical introduction to each function of the predecessor, post conditions, the main flow of the introduction, to help develop, test and other roles to quickly understand the product features.

7. Optional program

List all the options that are available to achieve the goal of the product (the main idea), evaluate the program appropriately, and recommend the optimal solution (described in the functional requirements). You must have a lot of options in doing this product plan, don't give up these solutions, never have outdated idea, only the best time idea. So you can write a few options, perhaps the next phase of your product revision in one Direction. Remember, a lot of thinking is a never-ending project.

8. Benefit Cost Analysis

Through this point can be seen that product managers must be a versatile, not only to have the industry knowledge, but also need to have financial knowledge. The cost measurement of a product generally includes three aspects: Benefit forecast, product technology cost and other cost expenditure.

Benefit forecast refers to the benefits that can be produced in the future, by comparing the products of the past or competitor's products to estimate the benefit forecast, such as the number of potential users of each function point, the frequency of usage, the new user characteristics and the quantity that attracts. Product technology cost refers to the development and design, as well as after the operation of the needs of the resource requirements, including human, hardware and software (bandwidth, server, computer room) expenditure. When there is a project manager can be the project manager to coordinate this part of the requirements, if there is no project manager, the product manager sidelines, call the development manager to find operation and other departments to implement the matter. Other costs include support costs, such as operational resource inputs, marketing inputs, and customer service inputs.

It is recommended that product managers take a course on financial management of non-financial personnel, if you can experience the Sand table training, record the financial breakdown, accounting assets and liabilities, cash flow, profit margin calculation, the cost and benefit accounting is very helpful, and financial requirements of the meticulous, Excellence is also the need for each product manager long-term adherence and compliance.

9, the integration of demand

Product integration capability is an important ability of product managers, business cooperation is often unavoidable, it is also common requirements to integrate business functions that are subordinate to two different sources, such as system login using the company's domain user login, or payment using Tenpay, Alipay payment, It is also an important performance to embody the core competence of the Product manager to solve the integration demand.

10. Beta test requirements

Many of the products are available in beta or in-line versions prior to the formal launch, or grayscale, to test some of the core functionality or performance of the product. This part of the content is not necessary, but if necessary, you need to give the objectives or testing, metrics to be achieved at this stage.

11. Non-functional requirements

In general, non-functional requirements include the following parts: Product marketing needs, operational requirements, financial requirements, legal requirements, use assistance, problem feedback, and so on. This information constitutes the complete content of the product line, but also a good embodiment of the Product manager's comprehensive quality.

12. Business Plan

How to operate after the product on the line, what is the target audience, recommended promotional strategies, problem feedback channels, risk monitoring, highlight publicity, and so on, as well as the cooperation with the operators. As a product designer is not the development of finished products can draw a full stop, so that products use, use well, Word-of-mouth is more important, so it is very recommended that the development of the business plan with product design personnel to participate.

Again, the demand change

Demand is not static, in the process of product development requirements change is normal, product team members need to correctly look at changes in requirements, and to control the changes. The advice here is to do the requirements analysis, as far as possible to consider each issue thoroughly, ahead of the needs change forecast and response plan, if necessary, and team members communicate in advance of changes in the content.

When communicating with the team, it is necessary to have an open mind, from the perspective of the team members, the future development trend of the product, the change of the market pattern, to correct the change demand, and always keep the product direction correct and the team member's goal consistent.

Summary

PRD's ability to map out the product capabilities of a product manager, this ability is divided into basic and advanced two categories, there is no doubt that PRD should be a basic ability, product managers a necessary skill, PRD ability reflects the product manager's understanding of user needs, this ability is actually based on the industry's expertise (expressed in the understanding of the business) on the basis of, coupled with good communication skills, a good product manager to write the PRD must be high accuracy, developed product expansion is good, at the same time by users. Therefore, the product manager must study the industry knowledge in the daily, understand the user's operation rules, communicate with the user more, listen to the problem more, discover the problem, solve the problem, with the understanding of the industry and the user and the gradual profundity of the control, the content of PRD will be more and more comprehensive This PRD will be a learning material for other people and will have far-reaching effects. All said product manager leads the product development direction, is the product "the father" or "the mother", the heartfelt hope each product manager can be a competent parents.

Author: cherry,2007 into Tencent Company, has been engaged in Internet advertising product management, at present in the sng/effect advertising platform to engage in product operations advertising results.