Once the product planning process is complete and a product is approved, you will need a Market Requirements Document. Some companies call this the PRD or Product Requirements Document. I call it a Market Requirements Document because the most important point to focus on in the document is what the market wants or needs. It also helps to identify where the document is generated - in marketing.
The market requirements document is designed to provide an outline of the prospective product for all interested parties. It should provide enough information for engineering to write a functional specification for the product. It should also be written in simple enough terms so that upper management or investors can read it and understand the potential product. (For example, all technology acronyms should be spelled out.)
The market requirements document is designed primarily for engineering. However, it should also provide information for upper management and/or investors on what type of product is being developed and for whom it is being developed. Sales and finance management will also need it for long-term forecasting.
There are generally two types of Market Requirement Documents, one for a new product and one for a new release of an existing product.
A new product MRD will include more detailed information on target market, forecast, distribution, and impact on other products. See the MRD outline for more information.
Once you have a successful product, you will need to determine what goes into each release. Major functionality will come from your product planning process, but there are a host smaller features request and bug fixes that will come from your existing customers. It is important to track and monitor these requests so that you can build a release that meets your customer's expectations.
The most important part of the Market Requirements Document is the inclusion of the features of a product release. This will generally take some negotiation with engineering in order to make a reasonable list of enhancements. It is useful to establish a goal for the release content whether it is customer satisfaction, innovation, or going after new target markets. I recently worked with a company where the goal for each release is to provide equal parts customer requested enhancements, innovation, and new markets based on engineering time.
It works very well to define this goal up front, however in reality each release will take on its own emphasis.
It is also important to decide the scope of the release and the availability. Is the release going to be a major revision, or just an update with one or two enhancements? Is there time pressure on any of the enhancements? This time pressure may come from customers who want a new feature before signing a deal, competitors who are taking sales away due to a specific feature, or events that are already scheduled that would benefit from a significant product announcement. After deciding the scope, objective of the release, and desired time frame, you can drill down into the contents of the release.
How much detail is included in this document is often the topic of much controversy. For readability, it is always best to keep any document concise. If a 50-page document lands on someone's desk, the chances of them reading it are slim to none. Five to ten pages should be enough. However, once a developer actually starts working on a project, they will quickly discover that a 10-page Market Requirements Document is sorely lacking in the type of detail they need to implement a feature.
I recommend keeping the MRD concise. I also recommend backing it up with lots of on-line material. Your MRD should reference specific customer input (see Chapter 2 on gathering customer input), competitive analysis, and market data. This information does not need to be presented in detail in the MRD, but should be available to the developers in an easily accessible place. By separating the detailed information from the MRD, you can continue to build your database of customer information and competitive data until the developer needs it.
You may already have a standard accepted format for Market Requirements Documents in your company.
If you don't, the following market requirements document template provides a high-level MRD example.
I have worked with many companies who want a block of signatures on the front of the MRD. This is done primarily to assure that people have read the document and have bought into it. The problem with this is that it slows down the process when you have to wait for the signature block to be completed. It also makes it a static document. Ideally the MRD should be a living document that is updated with changes in the market and competition sections as they occur. That way the engineer always has the latest market data. The product requirements section of the document must however stay stable, otherwise the company gets into a situation called "feature creep" which will destroy the product schedule.
Your MRD should be posted somewhere where it can be centrally accessed, either on a bulletin board, a file server, a secure internal web site, or distributed in paper format where it can be viewed regularly by all interested parties. You should notify concerned parties when you change it (preferably with a synopsis of the changes) so that people know that the information has been updated.
If you are looking for an alternative to the traditional MRD, please read my article, Stop Writing MRDs.