Really Good Requirements
A big part of a Product Manager's job is to describe the functionality that will result in a successful product. There are a number of formats for doing this, including MRDs, PRDs, Functional Specs, Technical Specs, Backlogs. They're all descriptions of What Is To Be Done. And they all too easily end up on a shelf, while something else is done.
What requirement documents are really necessary? As I'll explain, it's the process, more than the name of the product, that really matters.
First, let's look at the intent of some of these documents:
A Market Requirements Document (or Customer Requirements Document) is intended to describe what is necessary to successfully compete in a given market, and describes that market in detail. A good MRD is focused on the customer and the competition, and defines the business opportunities that a product might address. In defining market segmentation and size, it may include aspects of a business plan. It may describe the high level functional requirements of a product in this context. User and buyer personas are often introduced in the MRD. Audience: executives, marketing, and some the members of the development team.
A Product Requirements Document is usually a little more focused on the functionality of the product itself, describing what features and functions are necessary to succeed. A PRD includes more design detail than an MRD, describes how functions can be combined into meaningful/useful feature sets, and it includes extensive prioritization of features. User scenarios, based on personas, are often introduced here. The product requirements should include a description of the user experience requirements. The PRD may include a long-term product roadmap, describing the long-term sequence of releases. Primary audience: The design and development team. However, this may be a consensus-building tool with executives and marketing staff.
A Functional Specification is a detailed description of each aspect of a product. It describes exactly what will be built. It should provide context by describing use cases that are based on personas and scenarios. The functional spec supplies the user experience guidelines for the product designer, and it may go down to the level of user interactions, including flow diagrams and "wireframe" screen designs. Audience: the design and development team.
A Technical Specification is an engineering document that describes how the product will be built. It may describe user interactions down to the "click" level, and provides information regarding interdependencies and interactions between functions. It may address the application of specific technologies and the design of data structures. A tech spec may take the form of a working prototype, which can be developed collaboratively between product management and engineering. (This can be subjected to usability tests before final development begins.) Audience: the development and QA team.
A Release Plan and Backlog are Agile terms for a list of features/functions prioritized into a sequence for development and release. These are typically built around specific use cases that are addressed in a release. Audience: The development and QA team.
If you're creating all these documents, you're probably wasting time - yours and your team's. If you consider the real purpose of product requirements, you can begin to pare these down.
Focus on the Process
A requirements document is the result of a process in which a product vision is developed and refined, and then the vision is developed into a product plan. It's the process that really matters, even though the document is an important artifact that will serve as an reference during development.
The requirements process is the Product Manager's opportunity to explain the competitive landscape, customer research and product development options to the team. It's an opportunity to work with management to align product plans with the company's business strategy, and to listen to Marketing's ideas, concerns and feedback. It's an opportunity to work with the development team to determine what's possible, before making final decisions. The process should be bidirectional: it's a time for listening, not just persuading.
An important outcome of this process should be the Product Vision. It's an idea that can be concisely stated and is both inspiring and credible. It's the central concept that everyone, from senior management to individual developers, understands and agrees on. The process of creating requirements docs should help you clarify and hone the vision, with feedback from as many contributors as possible.
The second outcome of the process is a consensus regarding what the product will do, and why. This is your opportunity to ensure that there is general agreement that you're building the right product, from both a business and technical standpoint. The documents you produce - whether presentations, requirements documents or specifications - are the "sign offs" that help you determine that you're on the right track. For this reason, you want maximum exposure for these, and you should make sure that key participants have seen/read them and are on board.
The form of the documents themselves should support this process. They should be accessible (easy to understand) and they should deal with the appropriate issues for your audience. You may combine the market and product requirements into a single document, but be sure to draw a distinction between analysis/observations and prescription/design. If you produce separate requirements and functional specifications, then there should be some overlap: Customer personas and scenarios are central to both, for example. You may want to link the documents so that if you change the target personas in the MRD, duplicated sections in a functional spec are updated.
The resulting documents become a reference point as development proceeds. When there's a what or why question about the product, the requirements/spec documents should be the first place someone turns. If they're well written and up-to-date, they can save a product manager many hours of answering the same questions over and over. Regardless of which documents you produce, be sure that you cover these elements:
- The overall vision
- User personas, scenarios and use cases
- Prioritized feature sets and functions
- The product roadmap
- User experience criteria and guidelines
It's important that these are "live" documents. Markets change, product priorities change, and user experience analysis can result in product design changes. You will be gathering additional customer information while a product is built, and sometimes this can prompt a change in direction. Whatever the reason, requirements and spec documents need to change as new decisions are made.
It can be really difficult to find time to keep these documents up to date, but it's worth the effort to record decisions. (If you're working with an Agile team, it's not optional - you have to keep the backlog updated.) To facilitate updating, it's often worthwhile to keep the documents in a central location, such as a SharePoint server or in a wiki, and set up automatic notifications when changes are made. This can also make it possible for the documents to become the basis for ongoing dialogs, which might be incorporated into or linked to the document, that can elaborate or clarify the meaning. This way, the process of explaining the product and building consensus is ongoing, throughout the project.
Regardless of what you call your requirements documents, it's the process that really matters. Get that right, record the results, and the documents will be right, too.
In a future post, we'll look at what makes a great specification.
What requirement documents are really necessary? As I'll explain, it's the process, more than the name of the product, that really matters.
First, let's look at the intent of some of these documents:
A Market Requirements Document (or Customer Requirements Document) is intended to describe what is necessary to successfully compete in a given market, and describes that market in detail. A good MRD is focused on the customer and the competition, and defines the business opportunities that a product might address. In defining market segmentation and size, it may include aspects of a business plan. It may describe the high level functional requirements of a product in this context. User and buyer personas are often introduced in the MRD. Audience: executives, marketing, and some the members of the development team.
A Product Requirements Document is usually a little more focused on the functionality of the product itself, describing what features and functions are necessary to succeed. A PRD includes more design detail than an MRD, describes how functions can be combined into meaningful/useful feature sets, and it includes extensive prioritization of features. User scenarios, based on personas, are often introduced here. The product requirements should include a description of the user experience requirements. The PRD may include a long-term product roadmap, describing the long-term sequence of releases. Primary audience: The design and development team. However, this may be a consensus-building tool with executives and marketing staff.
A Functional Specification is a detailed description of each aspect of a product. It describes exactly what will be built. It should provide context by describing use cases that are based on personas and scenarios. The functional spec supplies the user experience guidelines for the product designer, and it may go down to the level of user interactions, including flow diagrams and "wireframe" screen designs. Audience: the design and development team.
A Technical Specification is an engineering document that describes how the product will be built. It may describe user interactions down to the "click" level, and provides information regarding interdependencies and interactions between functions. It may address the application of specific technologies and the design of data structures. A tech spec may take the form of a working prototype, which can be developed collaboratively between product management and engineering. (This can be subjected to usability tests before final development begins.) Audience: the development and QA team.
A Release Plan and Backlog are Agile terms for a list of features/functions prioritized into a sequence for development and release. These are typically built around specific use cases that are addressed in a release. Audience: The development and QA team.
If you're creating all these documents, you're probably wasting time - yours and your team's. If you consider the real purpose of product requirements, you can begin to pare these down.
Focus on the Process
A requirements document is the result of a process in which a product vision is developed and refined, and then the vision is developed into a product plan. It's the process that really matters, even though the document is an important artifact that will serve as an reference during development.
The requirements process is the Product Manager's opportunity to explain the competitive landscape, customer research and product development options to the team. It's an opportunity to work with management to align product plans with the company's business strategy, and to listen to Marketing's ideas, concerns and feedback. It's an opportunity to work with the development team to determine what's possible, before making final decisions. The process should be bidirectional: it's a time for listening, not just persuading.
An important outcome of this process should be the Product Vision. It's an idea that can be concisely stated and is both inspiring and credible. It's the central concept that everyone, from senior management to individual developers, understands and agrees on. The process of creating requirements docs should help you clarify and hone the vision, with feedback from as many contributors as possible.
The second outcome of the process is a consensus regarding what the product will do, and why. This is your opportunity to ensure that there is general agreement that you're building the right product, from both a business and technical standpoint. The documents you produce - whether presentations, requirements documents or specifications - are the "sign offs" that help you determine that you're on the right track. For this reason, you want maximum exposure for these, and you should make sure that key participants have seen/read them and are on board.
The form of the documents themselves should support this process. They should be accessible (easy to understand) and they should deal with the appropriate issues for your audience. You may combine the market and product requirements into a single document, but be sure to draw a distinction between analysis/observations and prescription/design. If you produce separate requirements and functional specifications, then there should be some overlap: Customer personas and scenarios are central to both, for example. You may want to link the documents so that if you change the target personas in the MRD, duplicated sections in a functional spec are updated.
The resulting documents become a reference point as development proceeds. When there's a what or why question about the product, the requirements/spec documents should be the first place someone turns. If they're well written and up-to-date, they can save a product manager many hours of answering the same questions over and over. Regardless of which documents you produce, be sure that you cover these elements:
- The overall vision
- User personas, scenarios and use cases
- Prioritized feature sets and functions
- The product roadmap
- User experience criteria and guidelines
It's important that these are "live" documents. Markets change, product priorities change, and user experience analysis can result in product design changes. You will be gathering additional customer information while a product is built, and sometimes this can prompt a change in direction. Whatever the reason, requirements and spec documents need to change as new decisions are made.
It can be really difficult to find time to keep these documents up to date, but it's worth the effort to record decisions. (If you're working with an Agile team, it's not optional - you have to keep the backlog updated.) To facilitate updating, it's often worthwhile to keep the documents in a central location, such as a SharePoint server or in a wiki, and set up automatic notifications when changes are made. This can also make it possible for the documents to become the basis for ongoing dialogs, which might be incorporated into or linked to the document, that can elaborate or clarify the meaning. This way, the process of explaining the product and building consensus is ongoing, throughout the project.
Regardless of what you call your requirements documents, it's the process that really matters. Get that right, record the results, and the documents will be right, too.
In a future post, we'll look at what makes a great specification.