Top Secret: How the Senior PO Writes a PRD
Top Secret: How the Senior PO Writes a PRD
Learn more about what a product requirement document does, and the considerations that every product owner should take when writing one.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
The Product Requirement Document (PRD) are very common to Product Owners. It is used to transfer products from conceptualization to visualization and to turn 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.
A PRD is the product owner's declaration of the functions of the product, through which the purpose of the product is demonstrated to the reader. The readers generally are developers, designers, testers, the heads of the product and the project (generally the project director), and the owner of the company. The 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 a concept to reality.
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, staff, and other relevant information.
#2 Table of Contents
Table of contents is used to display the structure of a PRD. Generally, it is no more than three levels; additional level might make the table too messy.
The table of contents should include a number of important sections, including: requirements, descriptions, role descriptions, flow charts, pages and functions, interfaces with other systems, the effect expected, data indexes, and iterative history. It is no doubt that different companies have different PRDs, so tables of contents are different. PRD might also include an 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.
In short, a PRD can be much simpler, if it only focuses on functional requirements and the headlines of the functional requirements.
#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 in the document can lead to confusion.
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 a great idea.
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, stories are created 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. The story can be changed and cancelled. There are four statuses of a story: 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 jargon and terms. After writing a PRD, it should be read by others, such as technicians, operations, and sales for feedback and questions. This is a great way of finding issues and devising solutions.
#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 have clear and abstract thinking. As the logic of human thinking is constrained by innate factors, software and tools can be used to help with it. Everything should be done to clearly describe the requirement.
#3 Make key points stand out
The key point is the description of the core function. The auxiliary instructions should be simplified as much as possible. In fact, PRD writing is similar to essay writing, with headlines, content, analysis, and summary. Many product owners try to be inclusive, which is not necessary. Writing a PRD is not writing a paper. You do not need to reinforce any argument again and again. The whole point is to understand the requirement and write it in a clear and explicit way.
Opinions expressed by DZone contributors are their own.