The PRD is one of the most important documents a project manager needs to write and update with his team. It defines the value and purpose of a product, and must enable the product development team to understand the product’s capabilities, functionality and features in sufficient detail. The document is intended to evolve with each iteration of product development.
It is also used to provide all members of an organization with the same level of knowledge about how the product works, and thus exclude any misunderstandings or misinterpretations. Engineers use it to implement the function as required, sales teams to draw up documents and sales pitches, and management to have an overall view of the project.
PRD versus MRD
Be careful not to confuse the PRD with the MRD (Market Requirement Document), which is drafted upstream to define customer needs, contains functional requirements and serves as the basis for drafting the PRD, whereas the PRD lists the project’s technical and functional specifications. The MRD is the highest level of marketing analysis. It covers issues such as customer needs, market, competition and pricing.
PRD versus Spec
Drafting PRD
The production of the PRD must follow a top-down approach, starting with the overall vision of the project. It is necessary to question all the players involved: technical, production, the methods function, marketing… In order to formalize the product’s functionalities from the outset, to anticipate development costs and to provide a framework for the project’s progress. A well-defined PRD also includes details of how the end-user will interact with the functionality, and what that functionality will look like. It is a deliverable of the feasibility phase, which is intended to be fixed, but modifications can be made to it throughout product development, thanks to ECRs (Engineering Change Requests). The PRD will therefore be versioned during the various phases.
What must the PRD contain?
- Purpose/goals: explain why you’re building this product.
- Features: for each element, you should include at least a description, a purpose and a use case. Additional details may be useful or necessary, depending on the complexity of the element.
- User flow: include schematics and mock-ups to help engineers understand the product and how functionality is to be implemented.
- System and environment requirements
- Hypothesis, constraints and dependencies: list what is expected of users, what limitations must be taken into account for implementation, and what external elements are needed to make the final solution work.
Sample plan :
1- General project information
- Purpose/goals
- Planning
- Roles and responsibilities
2- Overview
- Feature listing
- Basic use
- User flow
3- Functional specifications (operational requirements)
4- Production, industrialization et quality control
- Packaging
- Production line calibration and testing
- Environmental constraints
- Plant supply
- Compliance
- Product labeling and marketing requirements
- Industrial processes
There’s no set truth about the PRD, how it should be written or what it should contain. Everyone does things in their own way, and this is one of them.
Recent Comments