The PRD describes the product your company will build. It drives the efforts of the entire product team and the company’s sales, marketing and customer support efforts. It’s hard to come up with a more important, higher leverage piece of work for a company.
The purpose of the product requirements document (PRD) or product spec is to clearly and unambiguously articulate the product’s purpose, features, functionality, and behavior. The product team will use this specification to actually build and test the product, so it needs to be complete enough to provide them the information they need to do their jobs.
If the PRD is done well, it still might not be a successful product, but it is certain that if the PRD is not done well, it is nearly impossible for a good product to result.
The PRD versus the MRD
PRD vs MRD
We draw a distinction here between the product requirements and the market requirements (often referred to as the “MRD”). Put very simply, the market requirements describe the opportunity or the market need, and the product requirements describe a product that addresses that opportunity or need.
The PRD versus the Product Strategy and Roadmap
PRD vs 产品战略和路线图
The product strategy describes a vision, typically between two and five years out, of where you want the product to go, and the product roadmap describes the various steps to get there. The PRD describes a particular product release along that path.
The purpose of this paper is to describe a proven, repeatable process to create a good PRD. The ten steps described here are not easy, but they can help you produce a strong PRD. The amount of time this process takes depends greatly on the size and complexity of your product, and how prepared you are in terms of the knowledge and skills required.
Step 1: Do Your Homework
Your goal with the PRD is to come up with a compelling product. In order to do this, you must do your homework. This means studying your customers, your competitors, and your team’s capabilities, including available technologies.
This begins with customers, users, competitors, industry analysts, your product team, your sales force, marketing, company executives, other employees – anyone that has insight into the problem and possible solutions.
Realize also that a significant factor in your ability to convince the team of the eventual success of the product is the degree of confidence you project, and you will be more confident and more convincing if you’ve done your homework well.
Step 2: Define the Product’s Purpose
Every good product starts with a need that it is trying to fill. You must have a clear understanding of that need, and how your product addresses that need.
It is essential that the product manager establish a very clear, concise value proposition that lets her easily communicate to everyone – the product team members, company executives, customers, the sales force – what the point of this product really is.
While this sounds obvious, few products have such a clear value proposition.
Consider the “elevator pitch” test. If you had a chance to ride the elevator with the CEO of your company, and she asked what the point of your product was, could you answer that question before the ride is up? If not, you have work to do.
It may be that the product does not have focus; it may be trying to do so many things that nothing clearly stands out. It may be that what you think is the big thing is just not resonating with customers. It could be that your product is trying to solve a nonproblem; maybe you have a technology that you’re still trying to find an application for.
The value proposition should also make clear how this product helps deliver on the product strategy. Note that you do not need to talk about every little feature; in terms of a clear value proposition, less is truly more.
The product requirements need to specify exactly what the objectives of this specific product release is, and how they will be measured. The objectives should also be prioritized.
For example, your objectives may be: 1) ease of use, 2) retail price under $100, and 3) compatibility with previous release. You could then go on to elaborate on how you will measure these objectives. For items like a specific retail price, it is straightforward. For items like “ease of use,” you need to be specific as to what level of usability the product requires. This is typically defined in terms of the target user. Usability engineers can rate the usability of your product for a given type of user. They can also rate the severity of usability issues, and you may specify that there will be no major usability issues.
The key is to be very clear to everyone involved just what success looks like, and to provide the guidance that the product team needs in order to make the necessary trade-offs in design and implementation.
Step 3: Define the User Profiles, Goals and Tasks
Now that you understand what problem you want to solve, the next step begins with an in-depth understanding of the target users and customer. During this step, it is important to work very closely with your product designer.
By this stage, the product manager will have hopefully met with many target customers, and have spent considerable time with first-hand observations and discussions. Now we need to classify the types of users and customers, and to determine who the primary users are.
For example, if you’re building an Internet auction service such as eBay, you know that you have both buyers and sellers, and for each of those you have low volume/occasional users and high-volume/frequent users. It is not hard to imagine that there are several other less prevalent types of users as well, such as the corporate purchasing agents that may buy items for their company.
What the product manager and designer need to do is first identify the most important constituencies, and then try to characterize them in considerable detail, so that you can use these profiles to guide you in the design of the product. These profiles are sometimes called “personas” and while they should be fictitious, they should be as representative, realistic and plausible as you can make them. The idea is to come up with an archetype which captures the essence of this type of customer.
Here’s an example:
Leon the Power Seller is a 46 year old male that lives in Fresno and runs a small motorcycle parts business. While he does maintain a small shop, almost all of his sales come from eBay, where he sells on average 400 items per month. He sells a wide range of motorcycle related items, but his most popular items are saddle bags for Harley Davidson’s. He owns two big Harley’s himself, and he also drives a 1993 Toyota Pickup. Leon is married and has two teenage sons.
Leon bought his computer just so that he could use eBay, and seldom uses anything except eBay and e-mail. Leon has been selling on eBay for three years now, and has learned what he needed to in order to effectively sell. He has a feedback rating of over 5000, which he takes great pride in. When eBay changes things on the site, especially the selling process, it can be very aggravating for him to learn the differences and change his procedures.
Leon has well-established routines where he lists items to sell on Monday, and most of his auctions end by Friday, and he tries to get the shipments out within a few hours of receiving the payments.
Hopefully this description helps you get to know Leon and understand where he is coming from. As we consider new features, we can ask ourselves what Leon’s response to the feature would likely be, and what we would need to do in order to get him successfully utilizing it.
Narrowing the set of profiles down to just the key ones is essential. Trying to please everyone is futile, and typically ends up pleasing no one, so it is important to try and come up with the few most important and prevalent profiles. Similarly, if you do not try and precisely characterize your target user, you will have this abstract notion and find it difficult to understand how your customers will react. You’ll tend to assume that your customer is more like you than he really is.
Once we have identified and characterized our main types of users, we then need to identify what each user’s main goals or objectives are in using this product. This may sound simple, but it can often be challenging to untangle the underlying problem to be solved, when all around you people are telling you essentially the solution they think they want.
Everyone from the CEO to sales reps to engineers to customers are all too happy to “help” you come up with the solution. They’ll tell you that you need to add a button or a shortcut in a particular place, or add a specific feature because a competitor has it, or change the colors because they don’t like it.
The problem with jumping right to the solution is that there are often much better ways of solving a problem that the product manager and designer can come up with, if they are given the time and the freedom to come up with alternative solutions.
The best solution hinges on having a clear understanding of just what problem needs to be solved. The objectives may be different for each user profile, so it is important to be able to look at the objectives in terms of the profile they relate to. It is very possible that the feature being requested addresses a problem that is not one of the objectives of the primary user profiles.
With the user profiles and their associated goals in hand, we can now move on to designing the tasks that help these people accomplish their goals. This is the heart of the product specification process, and is the place where creativity and innovation are to be encouraged and facilitated as much as possible.
Many outstanding products simply solve an existing problem in a new and better way. Sometimes this comes from the application of new technology, but mostly it comes from an insight that leads to a new approach.
For example, TiVo took the old problem of recording TV shows and came up with an entirely new approach that let customers accomplish their objectives much more easily, and established an entirely new category of electronics device.
Notice that we have talked about goals and tasks, but that we have not mentioned features. This is because features should be in support of required tasks that map to customer objectives. You will often find that many features either map to very low priority goals, or are simply extra functionality.
There are good reasons to eliminate any functionality you can in the name of making the required functionality more accessible. Ironically, the fewer features you have, the more powerful your product is often perceived. This is because the less features you have, the more features that your customers will actually discover and use, and the more they can successfully use, the more powerful they will perceive your product. The reason this is so counterintuitive is that most of us are not anything like our target customers, and we are willing to spend far more time exploring features and tolerating complexity than customers not in our industry.