The product requirements document (PRD) has been called the product manager’s best friend. It serves as compass, roadmap and GPS in helping guide your product to launch. Give your PRD its due attention and it will become your trusted assistant — your righthand man (or woman!)

The PRD is a living document to which everyone on your development team contributes and refers throughout the development process.

A PRD can be maintained in any number of forms. Common PRD platforms include:

• Word document
• Spreadsheet
• Database
• Dedicated requirements management (RM) solution (like Jama Connect)

But unless you’re in a sector where documentation formats are prescribed by government or industry standards, your organization will need to come up with its own PRD format or template. Having a standardized template ensures everyone involved in product development can easily navigate the PRD and “be on the same page” with the rest of the team.

In this article, we’ll cover:

• What a PRD is
• The main components of a PRD
• Steps you should take in creating a PRD
• The most common challenges or issues encountered when writing a PRD

Finally, we’ll offer you a downloadable PRD template you can customize for use in your organization. We’ll also tell you where you can learn more about maintaining a PRD on a requirements management platform.

What is a PRD?

The product requirements document defines:

• The purpose and value proposition of a product to be developed
• The features and functionality (i.e. the requirements) for the product
• The goals and timeline for the product’s release

A PRD is not the same thing as an MRD. The MRD (marketing requirements document) is developed by the marketing department and captures what users need and want from the product. The MRD is created before the PRD.

The Main  Components of a Product Requirement Document

A product requirements document has four primary components:

1.     Purpose

• What problem does the product solve?
• Who will use it?
• How does it align with the company’s strategic goals and initiatives?

2.     Features

• Requirements (which define each feature)
• Context and rationale (that help explain the requirements)

3.     Release Criteria (should cover five areas)

• Functionality — minimum functionality required for release
• Usability — how you will ensure the product is easy to use
• Reliability — how you will determine that the system is sufficiently reliable
• Performance — the benchmarks the product must achieve
• Supportability — how you will ensure the product can be supported by your company

4.     Timeline

• Target release window
• Project milestones
• Release dependencies — known factors (beyond release criteria) that may affect release

---

RELATED POST: Checklist: Selecting a Requirements Management Tool

---

Steps for creating an effective PRD

Step 1: Do your homework

To create a great new product, you need a thorough understanding of the problem that product is going to solve. The only way to gain that understanding is by doing some homework.

Study your customers. Talk to them. Discover exactly what problem they need you to solve for them. Why does it matter to them? What is it costing them?

Study your competitors. Study their solutions to the problem. From what you’ve learned from your customers, determine your competition’s strengths and weaknesses when it comes to solving the problem. How can you better fill the need?

Consult with marketing, sales, and your technical experts, anyone who has insight into the problem.

Assess your team’s capabilities. How are they equipped to tackle the problem? What technologies are they familiar with or excited about that might be useful in addressing the problem?

Study the available technologies. What are their advantages and disadvantages relative to solving the problem?

The purpose of all this homework is to prepare yourself to lead your product development team. When you know what you’re talking about, you’ll project confidence. That will inspire confidence in your team, and prepare all of you to face the challenges ahead.

Step 2: Define your product’s purpose

Using what you’ve learned in Step 1, you’ll now fill in the first section of the PRD in this and the next two steps.

You need to establish a clear, concise value proposition that succinctly communicates the need the product will fill and spells out how the product aligns with your company’s overall objectives and product strategy. Hone this value proposition down to an “elevator pitch” that can be recited in under one minute.

Provide guidance that will help the team make tradeoffs during the design and implementation of the product Make it clear to everyone what a successful implementation of the product will deliver.

Step 3: Define your product’s principles

Establish a set of principles for the product that will guide the team through development.

For a medical device, for example, the principles might be:

• Extremely safe
• Highly reliable
• Easy and intuitive to use

You may find that defining your product’s principles leads you to refine and tighten up your value proposition statement. Or you might find that your principles fall simply fall out of the value proposition exercise. Either way, your product principles will act as a compass that will help guide your team as they define user tasks and product features in the next two steps.

Step 4: Identify user profiles, goals, and tasks

Once you have defined the purpose of your product, you need to establish who you’re building it for. You need a clear picture of your product’s users, their goals in using the product, and the tasks they will perform with the product to accomplish those goals. This is a drill-down exercise: First define the user profile, then the goals, and finally, the tasks.

---

Want the inside scoop? See what users are saying about Jama Connect

---

Build your user profile

As you begin to define your user profile, you’ll probably be able to identify several potential users for your product. Out of these, you need to identify the primary user: the user who is most important to your company in terms of sales of the product.

Once you’ve determined the primary user, build a descriptive user profile or persona. This profile will indicate the target user’s gender, age, industry, job function, and other demographic data. It should also include any habits and attitudes the user has that might influence their use of your product.

Your goal in building a user profile is to gain a collective understanding of where your primary user is coming from. When your team considers new features, they should ask themselves how that user would react to them and how likely they are to use them.

It’s important to make your user profile as realistic and representative as you can. Team members need visualize the user. The profile should also represent the needs, desires, habits and attitudes of a solid cross-section of your primary users, so that you end up shaping your product for the majority of your primary user group and not some small niche within it.

Above all, be sure to focus only on the primary user. Keep secondary users out of the discussion. It is impossible to please everyone, so don’t even try. Optimize for your primary user.

Identify user goals

Once you have your primary user profile, identify that user’s main objectives in using the product. What does he or she need to accomplish?

Be aware that when you speak to users, they may tell you the solution they think they want rather than their goals. Users often have a tough time disentangling what they want to accomplish from how they go about accomplishing it. This is important, because there are likely much better ways to solve their problem than what they have in mind.

You need to give designers and engineers freedom to find the best solution. Keep your focus on determining exactly what the user needs to accomplish and what obstacles are standing in their way.

Identify user tasks

Finally, work with your team to design tasks to help users accomplish their goals.

Encourage creativity and innovation during this exercise. Try to envision ways the user can accomplish their goals quickly and easily. Then, evaluate alternatives against one another.

Note: tasks are not features. Features support tasks and are defined later. Features should map through tasks to higher-level goals.

Step 5: Specify your product’s features.

Now, your team is going to start filling in what will be the bulk of your PRD. In this section, you will describe each feature in terms of its functionality. You will describe any constraints that have been placed upon the design of the product. You should also note any assumptions made while defining your requirements.

The product’s functionality will be expressed in what are known as functional requirements. Functional requirements dictate what the product must do. They must not, however, dictate how the product does that. The “how” will be determined during product design and development.

It is important that the requirements not dictate the implementation or bias it toward one solution or another. Only with “solution-agnostic” requirements will your designers and engineers be free to find a solution that is optimized toward accomplishing the user’s goals.

The product’s constraints will be expressed in what are known as non-functional requirements. Non-functional requirements capture any restrictions or limitations that have been placed on the product’s design by stakeholders.

Constraints often specify compatibility needs. Users may need the product to run a specific platform, for example. Your company or customers may need the product to interface with one or more of their existing systems. Constraints may be used to indicate the limits of a product’s operating environment—temperature ranges and other environmental conditions the product must withstand.

---

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference? 

---

You may find it helpful to structure the description of each feature by breaking it up into parts within your template. Your “feature template” might include:

• Description
• Purpose
• User problem and task(s) the feature addresses
• Functionality
• Constraints
• Assumptions
• Design (preliminary wireframes or mockups)
• Not doing (anything not to be included in the release)
• Acceptance criteria

Finally, go back and question your assumptions. Have you fully identified all the assumptions you’ve made? Are those assumptions valid? Have forgotten anything? It is very easy to make assumptions without even being aware of them. Review your requirements to make sure they’re solution-agnostic.

Step 6: Prototype and test your concept

Product managers and developers often make the mistake of having too much confidence in their PRD once they’ve finished drafting it. The problem is that by the time Beta feedback arrives, it’s too late to make major changes.

The remedy for this problem is to perform product validation testing using prototypes. Modern prototyping tools make this easier than ever.

Product validation testing is typically broken down into three types: feasibility testing, usability testing, and product concept testing.

Feasibility testing

Feasibility testing involves building a prototype or model, and then examining it to determine whether it is feasible to build.

Get your engineers, architects and designers involved. Explore available technologies and possible approaches. Identify obstacles and evaluate their severity. Are they insurmountable? It’s better to know now.

Usability testing

Usability testing is a highly effective way to get feedback from your target customer. It often identifies missing requirements or requirements that are less necessary than originally supposed.

You and your designers will need to come up with ways of presenting the functionality so users can understand how to use the product. Plan on running multiple iterations before you arrive at a satisfactory user experience.

Product concept testing

Knowing your product is feasible and usable is not enough. What’s most important is to make sure people will actually buy it. For that, you need to get your product in front of real users and determine if it actually helps them accomplish their goals in a satisfying way. That’s where product concept testing comes in.

Product concept testing can normally be combined with usability testing. To accomplish this goal, however, it’s very important that the prototype be highly realistic. Fortunately, today’s prototyping tools make this not only possible, but fast and easy as well.

Fold in your feedback

As you test your product concept, update your requirements based on the feedback you’ve gained. The importance of this step cannot be overemphasized. Most engineering errors originate in the requirements, and the cost of correcting those errors rises dramatically once implementation begins.

Step 7: Establish release criteria and timeline

Once you’ve established and validated your requirements, it’s important to prioritize and rank them and to set your goals for the release.

Many product managers prioritize features by tagging them with labels, such as “must have,” “high want,” and “nice to have.” But it’s also important to rank order each requirement within those categories. There are two reasons for this.

The first is time to market. Schedules often slip. When they do, you may need to trim features and requirements to meet your release date. You don’t want your team implementing the easiest requirements first only to find that there’s not enough time to complete all your must-haves.

The second reason is that requirements evolve. During implementation, you’re likely to discover new needs. Some may be critically important and supersede existing requirements in terms of priority. You need to know where those new requirements fit in your pecking order. If you don’t, less important factors will determine what gets implemented first, which may have a negative impact on your product’s success.

Besides prioritizing requirements, you should also establish some quantifiable metrics for success that will establish the fitness of your product for release. Your success metrics may include measurements for:

• Performance
• Reliability
• Usability
• Safety
• Supportability
• Scalability
• Localizability
• Other factors relevant to your product

Step 8: Review and revise your draft PRD

Before you start implementation, test your PRD for completeness.

Get all your stakeholders involved. They should make sure the PRD addresses their needs and concerns. Do the developers fully understand the problem to be solved? Does QA have enough information to build a test plan and write test cases?

Once you’ve addressed any issues your stakeholders have identified, you’ll have a PRD from which you can begin to build a product.

Step 9: Manage product development

Over the course of product development, countless issues over requirements (or the lack thereof) will arise. Always refer to the PRD. If the answer isn’t there, resolve the issue and record the decision.

Your PRD is a living document. Use it to track all your features and requirements throughout development and product launch.

Above all, keep it accurate. Doing so will simplify preparation for milestone reviews. Plus, your whole team will have a clear picture of what you’re all aiming for.

---

RELATED POST: Requirements Management Tools and Software

---

Common challenges encountered when writing a PRD

Challenge #1: Ensuring usability

When it comes to usability testing, two frequent mistakes are (1) doing too little, and (2) doing it too late.

If you’re new to usability testing, you’ll probably be surprised by how much first-time users struggle with your prototype. You’ll quickly see the issues they have and how to address them.

Here are some important points to keep in mind when planning and performing usability testing:

• Do usability testing during requirements development, not during implementation
• Plan on multiple iterations
• Make sure the project manager and designer are present for most if not all sessions
• Invite other internal stakeholders to observe (can be eye-opening)
• Pay attention to what users do, rather than what they say

If you’re not sure why users are doing something, ask, but it’s more important to observe their interactions with the product. If you don’t have usability engineers in your organization, you may want to contract with a firm that specializes in usability to run this testing.

Challenge #2: You are not your customers

Customers are seldom as immersed in technology as product creators. Often, functionality that seems obvious and intuitive to those who design a product can seem obtuse and counterintuitive to potential users who are exposed to it for the first time. A poor first impression can sour a potential customer on your product.

You must perform reality checks of your product with real users on an ongoing basis. Do they understand how it works? Will they use it? Will they value it? Customer feedback during development is invaluable.

Challenge #3: Solution favoritism

When writing requirements, you must specify what the product must do (the problem to be solved), NOT how the product will do it (the solution). It is important not to bias requirements toward one solution or another.

There are two pitfalls with solution-biased requirements.

First, engineers my make incorrect assumptions. There can be many different solutions to the same problem. Some will be better than others. Incorrect assumptions may exclude the best of those solutions, closing doors to innovation.

Second, you risk frustrating the development team. Your engineers are paid to come up with a solution, which they then must implement and maintain. They’re the folks who will have to live with it and support it. Engineers want autonomy to be innovative. They tend to resent specifications that read like a recipe.

Ensure that every requirement in the PRD is clearly stating what the product must do, but not dictating the solution itself.

Challenge #4: Too little detail

While you want to give engineers and designers plenty of leeway to find the best solution, you still need to fully specify the product.

If there are gaps in your PRD, you may pay a heavy price down the road. Team members are likely to make assumptions to fill in the gaps. Different team members will likely make different assumptions. Problems no one anticipated may rear their ugly heads late in the game when it’s far more expensive to correct them.

The best safeguard against this is to have the team review drafts of the PRD early and often. Address all questions and resolve them in the PRD. Plan on problems cropping up during development. Allocate time for addressing them. Update the PRD as they are resolved.

Challenge #5: Too much detail

Too much detail can be just as bad as too little. If the PRD becomes a massive tome, team members will lose patience and won’t read it. This can lead to more assumptions.

Remember that the PRD is a top-level document. Use the appropriate level of detail. If your product is highly complex you may need lower-level documents, like software requirements specifications, for each of your subsystems.

State requirements succinctly. Segregate explanatory text and keep that succinct as well. Add only what is necessary for context. If you find you are having issues in writing succinct requirements, or team members are constantly asking for clarification, you may want to consider a rigorous requirements syntax like EARS.

---

RELATED POST: What is Requirements Traceability and Why Does it Matter for Product Teams?

---

Challenge #6: Feature overload

You want your product appeal to as many customers and users as possible. So, it can be tempting to add features to meet everyone’s needs and desires. Unfortunately, especially with high-tech products, adding features is often counterproductive.

Piling on features adds complexity to the product. That can make some features harder to find and lead to user confusion. An overabundance of features also drives up maintenance costs and customer support costs.

Be judicious in adding features. Exercise discipline. The tech world is littered with products that started off great, then became so bloated that customers abandoned them. They no longer served their purpose as well as they did when they were new and lean.

Challenge #7: Engineering-driven requirements

Your engineering team may be enamored with an emerging technology they want to work with. They may be excited by a challenging problem they want to solve. This can lead them to overwhelm the product manager with requirements, effectively dictating the solution they want to build.

Product managers should listen to engineering needs but focus on value. They need to define a product that customers will buy and that’s feasible to build, one that can be executed on time with a strong effort. They can’t let engineers build whatever they want or something that can’t be achieved within program’s time constraints.

Challenge #8: Marketing-driven requirements

Sales and marketing also want a say in product definition. They maintain close contact with their best customers. They have first-hand knowledge of what customers want, and they’re charged with selling that.

One way this becomes a problem is with what are called “specials.” Someone at your company promises a customer a special version of your product with new features the customer requested. Typically, this is done in exchange for additional purchases or fees.

Specials create several issues for your company.

First, the additional features create add complexity which can lead to customer confusion and frustration, as we discussed earlier under Challenge #6 (feature overload).

Second, you wind up with multiple versions of the product that you now must build, test, maintain and support. All that added task can bog down engineering and prevent your company from pursuing more profitable work.

Finally, customers often struggle to articulate what they need. The requested features may have been a stab at what they think they want. Once they receive their new features, users may find they don’t meet their needs after all.

To avoid this pitfall, be disciplined. Evaluate the value of each proposed feature. Know when to walk away and be willing to do so.

Better yet, make sure your standard product is useful and compelling enough that customers can live without custom features. Get those valued customers involved in product concept and usability testing. Dig deep to get at what they really need.

Challenge #9: Traceability

Finally, your PRD doesn’t just track your product’s requirements. It needs mechanisms for tracking issues, test cases, bugs, and problem resolution to each requirement as well. It must support requirement traceability.

Implementing traceability can be complicated and tedious in a Word document or spreadsheet. A dedicated requirements management tool, like Jama Connect, can greatly facilitate requirements traceability.