The Product Requirements Document (PRD) and the product roadmap are the two key artifacts that a product manager must have mastery over, for success in this role. In many firms, the PRD is called something else, such as a Business Analysis Document (BAD!), Product Requirement Specifications (PRS), Marketing Requirements Specifications (MRS) and so on.
Here are a few links to articles on different websites about what a PRD should contain.
One challenge you will face is that there is no easy way to start a PRD from scratch. And you will encounter such a situation if you join a startup, or begin work on a new product, or start working in a new firm. Here are some tips that can help you start the work:
A PRD Follows A Template
The PRD for a consumer electronics product, a web-based product or a VAS product such as caller ringtones are very, very different. Still, all the PRDs follow a common template used within the organization. You should pick up the most recent template in use based on past available PRDs and start filling out the different sections within the PRD.
If you are working in a startup, a quick web search will give you many links where you can download PRD templates. Use the template as a starting point, and simply remove all sections that do not seem important. What remains will allow you to begin writing product specs.
A PRD Is A Live, Versioned Document
As you start writing use cases, functional specifications or other details about the product and product usage, you will quickly realize that this is an iterative process. So you can take 2 approaches to make a good PRD – cover it depth-first or breadth-first.
The depth-first approach is good if there are multiple product managers, or if you have an external dependency. This way you completely scope out a set of features for the engineering team to review, and then to start their work.
The breadth-first approach works best when you are not sure of the specs., and have multiple engineering teams waiting for the PRD. This way, you have something for all the teams in the first draft.
Remember, even after a PRD is reviewed, and specs are accepted after modification, you can make changes and add those to the appendix. This way, a new joinee can see the document history, and understand the product evolution.
Start With Functional Use Cases
Unless the product is a set of API for scripts on the web to use, every product will have use cases. These will include how the product is installed, how it is started, how the controls function, what are the roles of the users and so on. These are easily translated into straightforward use cases.
You should list out all these use cases, write a one line summary for each of them and then break them into functional groups (error handling, security, startup etc). These will help you build the base of the PRD.
Break Up The PRD Into Sections
One section of the PRD must cover the business problem you are solving and the potential revenue opportunity. If you have those, and the functional use cases, you are very far along on the first draft of the PRD. Additional sections that you need to write specs. for will include the performance requirements, usage constraints, security specifications, dependencies and so on. You should spend a lot of time to write these, as these are the tricky issues that can cause major problems after product release.
Make Lots Of Diagrams
Any time you feel that there is a complex use case, or a particular system component is hard to describe, make a diagram. You can make block diagrams, flow charts and navigation maps and anything else required. And you can either add them to various sections of the PRD, or keep them at the end in the appendix. Make PPTs if required and insert them in the appendix.
More Is Good
A PRD must have a lot of details about every feature, requirement and scenario. This will remove ambiguity, simplify the design process and avoid trouble down the line. Use as much detail as possible for every facet of the PRD. It is actually for this reason that many firms use 2 versions of the PRD, a smaller version in PPT format summarizing the product release for external audiences, and a detailed version in a DOCX or XLSX format for review and referral.
Forget The Competition’s Features
Sometimes, a PRD will contain comparisons with a competitor’s product or even specific features. This is a waste of time, as you are comparing a current feature set with something you team will deliver much later. Such comparisons should not enter the PRD, however, you can add a list of internet resources on the competition to the references section of the PRD.
Writing a PRD is a prestigious task for a Product Manager. Following the guidelines listed above will let you create a high-quality PRD within a few weeks, that will be acceptable to all groups, and will allow engineering to build the solution that you describe.