Product requirements document ( PRD ) is no stranger to every product manager. It is the transition and embodiment of product project from "conceptualization" stage to "drawing" . Carry out indexing and technicalization ", the quality of PRD directly affects whether the R&D department can clarify the function and performance of the product, and whether it can develop products that meet the expectations, so PRD is also an important indicator of the professionalism of the product manager.
It can be understood that PRD is the product manager's promotion and communication about product functions. It presents product intentions to readers through clear and concise expressions. The readers of PRD generally include developers, designers, testers, and even products and products. The project leader (usually the project director) and the company owner are different for each company. PRD is not only a detailed description document of product functions, but the role of PRD is that it is the implementation standard of product quality control, and it is the beginning of implementing the product from concept to reality .
What should the PRD include?
1. Product name
The product name is also a general description of the document. Generally, it includes basic information such as title + version + time + writer + related person.
The title is the name of the document, whether it is the version to be discussed or the official development version, the production time corresponding to the version, and who needs to be involved, etc. All need to be stated.
2. Catalog
The directory is used to show the structure of the document. Generally, it should not exceed three levels, otherwise it will be too messy. Of course, the content of PRDs presented by different companies is different, and the catalogue is also different. In detail, the content of the document can include requirement description, role description, flowchart, page and function, interaction interface with other systems, effect expectations, data indicators, PRD iteration records . The PRDs of many companies also include introduction, overview, term definitions, usage scenarios, product goals, and competitive product analysis . Operational specifications, relevant developers, responsible persons, development time, etc., make PRD very heavy, and the catalogue is relatively large. To put it simply, PRD can only be developed around functional requirements, then the catalog is much simpler, basically including the big title of functional requirements . The picture below is the directory of a PRD I once read. From the directory, we can see that the content of this document is actually very large.
3. Function description
The function description is the main part of the PRD. My writing habit is to prefer simplicity rather than complexity. The function descriptions are introduced in detail, and others can be omitted. Because most programmers don't pay too much attention to these long stories in the development of products, they often only focus on the content that can be quickly transformed, and too much document content will cause certain interference. Therefore, proper simplification, enhanced readability, and indication of product intent are the most precious.
In the specific function description, we often use some other methods, such as product function structure, product information structure, user use process, etc., to visualize the text content, which not only makes the document easier and more intuitive, but also reduces the reader's reading burden. . It is very smart for many teams to use prototype diagrams and pictures to assist. The following figure shows the flow chart of this forum posting.
Speaking of simplification, in fact, many Internet companies are now emphasizing more communication and less documentation, and they don't even have PRDs. Zendao , a well-known project management tool in China , advocates writing requirements in the way of function points. In short, it is to extract each function point in the original PRD and record it in Zendao as an independent function point. The relevant personnel of the product project determine the requirements through discussion, and then take the requirements as the center to perform task decomposition and assignment, progress monitoring, testing, and release.
At this point the requirement is no longer the final rule, but allows for changes and cancellations. The requirement status here is divided into four states, draft , active, changed and closed . Its state flow diagram and demand change diagram are as follows:
This method is mostly used in the more common agile development mode nowadays. These Internet companies put more emphasis on communication, openness, and quick solutions. We do not judge whether this method is good or not. However, as a more professional normative document, the combination of PRD and project management tools is actually the choice of more enterprises. Now let's go back to PRD and talk about some principles that PRD needs to have.
What characteristics should a qualified PRD document have?
I summed up the principle of "no two, no two", which means that PRD needs to be " error-free, unambiguous , testable and traceable " .
Error-free is the most basic requirement of PRD. Error-free here not only includes the correct definition of the content of the document, no grammatical errors, but also ensures the correct expression of the product manager's ideas and intentions.
Unambiguity requires a sentence to express one meaning, so that many readers of the document read the same meaning.
Verifiable means monitorable and verifiable. The functional description in the PRD is required to achieve testable and measurable performance indicators. Do not appear indeterminate words, such as: high efficiency, perfect interaction, etc., are unverifiable.
Traceability means that the source of each functional requirement should be clear , why I do it, it should be well-founded, rather than making a decision in a head-scratching way .
It is also a basic requirement of PRD to achieve "two incomparable". Let's talk about a few writing skills that I have summarized in my work, which can be regarded as my experience.
Talk about those PRD writing tips that are worth sharing:
1. To express properly and popularly
In the final analysis, PRD is still a professional document, and professional terms and vocabulary are indispensable, but this does not mean that the more professional vocabulary the better, too much professional vocabulary to make people confused is the most failed PRD. It is invaluable to use the language as simple as possible to express professionally, because easy to understand and operate is the more important mission of PRD. After I finish writing a document, I usually show it to as many people as possible, except for technical personnel, operations, sales, and even your relatives and friends. They will raise different opinions and questions. In fact, this is a good Correction is also the process of finding problems.
2. Make the logic as clear as possible
Because PRD is about the interpretation of product requirements, it involves a lot of large and small functions, and the various function points are closely related , which requires the product manager to have very clear logic and express abstract thinking concretely. A hard requirement for product managers. Since the logic of human thinking is subject to innate factors, it is also mentioned above that we can use software tools to assist in the realization. There are many forms of expression, such as prototypes, processes, and other forms . Form is not important, remember that everything is intended to be communicated clearly.
3. Remember to highlight the key points
The key points are the key descriptions of the core functions, and the auxiliary descriptions are simplified as much as possible, there are main and secondary, and there are give-and-takes, so as to express in simple language. In fact, writing PRD is similar to writing essays when we were young. There are titles, content, analysis, and summaries. The key points are highlighted, so naturally it takes more pen and ink. Many product managers tend to strive for completeness, for fear of omissions, and to take into account every detail. In fact, this is completely unnecessary. PRD is not writing a paper, and there is no need for repeated arguments. It is enough to explain things clearly and understandably.
Summarize
PRD actually tests the overall quality of the product manager. To write a PRD well, in addition to improving their professional quality, product managers need to maintain their sensitivity and curiosity about the product, and strengthen their logical thinking and writing skills. The text mentioned are the places that need to be paid attention to in the PRD writing process. In fact, before a complete PRD is produced, you may need a long-term information collection process. Anyone may become your inspiration source, including users , competitors, R&D teams, sales teams, operations personnel , etc. You provide constructive suggestions and creative points, so listen to their voices and keep accumulating and collecting. PRDs are not achieved overnight, and product managers should always be prepared.
