Top 3 Principles of Quality Product Requirements Document (PRD)
As is mentioned in this post, the two main resposibilities of product manager consist of the assessment of product opportunities and the evaluation of products being developed. And it's the product requirements document that is needed to define the product about to go online and carry out the description of product features and function.
Though the form of PRD varies in accordance with different companies, teams and individuals, there are 3 nonnegligible principles during the writing process of it: concise text, low to medium fidelity, test and verification. Let's go deeper about the three standards and please comment below if you have any thoughts to share with me.
1. Why and How to Use Product Requirements Document?
In short, the Product Requirement Document is a combination of BRD (Business Requirements Document) and MRD (Market Requirements Document) which is often written in a professional language. It's the inheritance and development of BRD, meanwhile the technicalization process of MRD. From BRD and MRD through to PRD is a process of demonstrating and outputting the final results, which just sublimiates the thinking of product managers.
A quality PRD usually includes three parts:
a. Introduction and Summary
The prime purpose of PRD is to let readers understand and get familiar with the needs' background and summary. It can be included with the demand summary, the general rules of statement, the demand purpose and document changes, etc. If it's just used internally, there is no need to write it in every detail.
b. Business Description and Prototype
This is the core part of the entire document and includes the main function of product framework, such as Business Structure Diagram, Flow Chart, Page Interaction and Permissions, etc. In the meantime, the basic interaction between pages, text annotations and wireframes are also indispensable.
c. Non-Functional Requirements
This is meant for some auxiliary needs, including location access, CDN cache strategy, Push mechanism and the local file storage strategy, etc.
For the first version of product, it may take more time to explain the entire business process and functional structure. Not only can a quality PRD reduce the communication cost betwen the team, but also be used as the later reference.
2. Three Principles of PRD Writing
a. Concise Text
It's true that the detailed instructions can give developers the most comprehensive guidance and reference, but those "too elaborate" remarks and text description can sometimes reduce overall efficiency. When the product is reviewed and discussed in details, some of the issues may be repeatedly mentioned and it would be critical if the key logic can be graphically or textfully presented.
For some commonly-known rules and functional requirements, it's better to streamline the product documentation otherwise developers wouldn't have that much time & patience to go through it. Undoutedly, if you have mutual understanding within the team members and you know each other's development habits & design routines, then the product planning and iteration can be as time efficient as possible also.
b. Low to Medium Fidelity
The pursuit of visual details and interactive effects, especially in the user testing and external display, will bring the excellent results. But for internal communication where only the core functions and information architecture need to display, then the wireframes come in handy. On the other hand, the high-fidelity prototypes will require much more time and efforts when there are modifications and demand changes, which will seriously affect the product design and development progress.
c. Prototype Test and Verification
This is the stage where the ideas of product manager are presented, and it's the place where the creativity and innovation flow. For many products, there are three kind of testings that are of great importance:
Usability Testing, good for finding the missed product requirements so as to confirm whether the initial requirements of the product are neccessary.
Feasibility Testing, good for solving some issues in early stage and avoiding the time and energy cost caused by the re-adjustments.
Concept Testing, good for getting quality feedback by doing testing on target customers and using rapid prototyping tools.
All in all, to streamline the test, keep low-to-medium fidelity, test and verify prototype, spend time and efforts on how to improve the core competitiveness of product, reduce ineffective and repetitive work is the stepping stone to output high-quality and valuable product & PRD.