Top Secret: How senior PO writes a PRD

Product Requirement Document (PRD) is very common to Product Owners. It is to transfer product projects from conceptualization to visualization. and to make the Marketing Requirement Document (MRD) into indexes and techniques. The quality of a PRD has a direct impact on whether the RD department could define the function and performance of the product, and whether the product can be developed to meet the requirements, so a PRD is also an important indicator of the expertise of a product owner.

PRD is the product owner's declaration on the functions of the product, through which the purpose of the product is demonstrated to the reader. The readers generally are developers, designers, testers, and even the heads of the product and the project (generally the project director), and the owner of the company. PRD is not only a detailed description of product functions, but also the standard of product quality control, and the beginning of transferring the product from the concept to the real.

What should be written in a PRD?

#1 Product name

Product name is the general description of the document, including title, version, date, written by, relevant staff, and etc. Title is the name of the document; version defines it is to be discussed or formal.

#2 Table of Contents

Table of contents is used to display the structure of a PRD. Generally, it is no more than three levels, otherwise it will be too messy.

Document includes requirements descriptions, role descriptions, flow charts, pages and functions, interfaces with other systems, effect expected, data indexes, iterative history. It is no doubt that different companies have different PRDs, so tables of contents are different. PRD might also includes introduction, overview, definition, usage scenarios, product purpose and competitor analysis. If a PRD is used with the company, it also has the presentation form of functions, interface design, operation specification, developers, supervisors, and schedules.

#3 Functional specification

Function description is the main part of PRD. Senior POs tend to be simple and to give only detailed descriptions of functions., because most developers don't pay much attention to the long text in the PRD, and they tend to focus only on the content that can be understood quickly. Too much content of the document can lead to interference.

When making specific functional descriptions, other methods are adopted, such as to summarize the structure of product function, the structure of the product information, user workflow, etc., to visualize the content of the document. Many teams use prototypes and images in a PRD, which is very smart.

Speaking of simplicity, in fact, many IT companies are emphasizing more communication and fewer documents. They do not even have PRDs. ZenTao, a Scrum tool, is designed to simplify PRDs. In ZenTao, create stories for each function. Product relevant staff discuss each story and then confirm it. Based on the story, tasks are created and assigned. Then it is monitored, tested and released. Story can be changed and cancelled. There are four statuses of a story, namely draft, active, changed and closed. Below is the workflow of story change in ZenTao.

This is more common in Agile development, because IT companies emphasize communications, open-up, and quick solutions. We do not judge whether this is good or bad. However, as a relatively professional normative document, the combination of PRD and project management tools is an option for companies. Now let's go back to PRD and talk about some PRD writing tips.

PRD Writing Tips

#1 Use common and appropriate words

PRD is a professional document, but it doesn't mean that it has to be all about jargon and terms, which will fail PRD. After writing a PRD, it should be read by others, such as technicians, operations, sales, so they will put forward feedback and questions. In fact, this is a good way to correct the problem, but also the process of finding problems.

#2 Being logical and explicit

PRD is an interpretation of product requirements, which involves much about product functions, and each function is closely interrelated. This means that the product owner should be logical and has clear and abstract thinking. As the logic of human thinking is constrained by the innate factors, software and tools can be used to help with it. prototypes, processes, and other forms can also be  used too. Anyways, everything is done to clearly describe the requirement.

#3 Make key points stand out