How to compile a required document for PRD

PRD (Product Requirement document)

1.Make preparations: Understand the strengths and technologies required by customers, competitors, and product teams. Customers, customers, competitors, analysts, product teams, sales teams, marketing staff, and company staff are required to collect issues and possible solutions they can discover. Establish good communication.

 

2.Determine the purpose of a product: any good product starts with a requirement. You can clearly understand this requirement and how your product meets it.

The product manager puts forward a clear and concise value proposition so that everyone can understand the intention of the product. Elevator room presentations, elevator marketing, do not elaborate too much details, from some aspects, a valuable point of view should be the simpler the better.

 

3.Determine user prototypes, user targets, and User Tasks

 

User prototype: At this stage, PM communicates with many users and takes a lot of time to observe and discuss. Now we need to classify users and customers and decide which type is our primary customer. It is very important for PM and PD to determine the type first. They should describe the user features in detail as much as possible to use this model to guide the product. This model is generally called a 'Role personal'

 

User goal: clearly understand what problems need to be solved. Each user model may have different purposes and needs to be found in the aspects involved in the user prototype, it is possible that the problem solved by a certain function in the future will not be one of the major users' goals.

 

User task: Tasks

The fewer features you use, the more powerful your product will be discovered. Because the fewer features, your users will discover and use more features, more and more features are successfully used. Amen thinks your product is more powerful.

 

4.Define product principles: Now you need to define your requirements and user experience as detailed requirements

For example, eBay is easy to use, safe, and interesting.

 

5.Product prototype and validation feasibility testing (whether the product can be developed, your engineers and designers should be involved in technical feasibility investigation and exploration of available methods)

Availability testing (product designers and you should work closely together to propose product features so that they can adapt to different users .)

A good prototype tool for product concept testing, which effectively simulates future products to the extent necessary for testing by actual users. It is very important to test your product before actually launching the product. Once the actual project starts, it will become very difficult to make important changes, and the cost will become very high.

 

6.Verification and questioning: When you think you understand the problems you need to solve, it is easy to verify and question assumptions, assumptions, or even think you don't know, but do not use unknown conclusions as a guideline, which will impede your success.

 

7.Write: When you write down all the requirements, most PRD files are Word documents, ppt files, or white paper. What format is not very important. What is important is that the team can easily understand it. Remember that conversations are two people's views, but PRD is to communicate with the entire group. Remember that product sales are the most important thing.

The PRD document consists of four parts:

 

Product purpose: Your job is to point out the goal, the team needs to know what their purpose is, the goal description should be as clear as possible, please ensure that your content includes: the problems you want to solve, it is not a solution; Who is the target user; there are many details, but the big picture must be clear; the scenario description; more brainstorming meetings and temporary oral discussions to better write them out, it gives the team a better understanding.

 

Product features: the most important requirement of the Product Requirement document is. The specific requirements depend entirely on your field, but no matter what industry you are in, your product team will benefit from the clear and unambiguous requirements stated in the demand, rather than a vague solution. Describes the interactive design and use cases of each function. You must be very clear about each function and user experience, and leave enough flexibility and autonomy for the engineering team. It is equally important to determine the purpose for which requirements are met. Here we need to mention "Demand Tracking", which is an important process for key products. Each product specification may benefit from a clear identification of the purpose for which the requirements are met, and it will be very difficult if someone decides to cut the requirements and wants to gain a deeper understanding. From requirement to purpose, the document will be clearer.

 

Standard release standards are constantly changing, but a good PRD should consider setting a minimum requirement for each standard. Typical examples include performance, testability, reliability, availability, and controllability.

 

One of the most difficult problems in time progress is to describe the time schedule required by the product. It is useless to list a time. You need to describe the environment, motivation, and expected goal. You need the entire team to achieve the expected goal like you, and finally complete a successful product.

 

8.Priority: In addition to clear requirements, it is important to prioritize and arrange your requirements. Classification is very important and cannot be taken lightly. The product manager must have high standards for any tag "must have". If a required feature is not found, the product should not be produced yet. These "must have" functions directly reflect the core value of the product. The "important" category page is very important. You only need to meet these features if you have the opportunity to sell the product.

 

9.Test Integrity: Now you have a PRD draft, and you need to test its integrity. Can engineers fully understand and achieve the goal? Does the QA Team have enough information to make a test plan? Can we start the case? When the investors or related persons have reviewed the PRD and determined the various aspects to be explained, all the problems will be solved. Now you can develop products based on the PRD.

 

10.Manage Products

During product implementation, even the best PRD, countless problems were solved. Solve all PRD problems. If you do not write them in PRD, your task is to quickly solve the problem and record it in PRD. If you do your work and prepare to record it in PRD, the Project Review will become very simple, as any part of the review is vivid.

 

Remember that PRD is a "active" file that tracks all functional processes during product development. At last, you will find a lot of additional things. If you think it is necessary, write them into PRD.

Requirement types (interface, function, report, performance, and interface requirements)

This article from the "Little Dinosaur" blog, please be sure to keep this source http://455215.blog.51cto.com/445215/1564623

How to compile a required document for PRD