Creating a good product requirements document (PRD) is a crucial part of launching a successful new product. The PRD outlines what is expected of the product. Any omissions or vagueness in the PRD will translate into a product that comes short of its goals.
Creating a Product Requirements Document
The purpose of the PRD is to provide the engineers with clear definitions of the problems facing customers that the product is supposed to solve. In order to get a clear definition of the problems at hand you must understand the market. Using the five steps of innovation will help you organize your efforts to get a clear understanding of the market and its problems.
The Five Steps of Innovation Are:
- Find a problem
- Structure the problem
- Analyze the problem
- Envision the end result where the problem does not exist
- Create the solution
Find a Problem
The problem that you are able to find depends on the industry you are in. The best tips for identifying a problem are to experience the scenario as much as possible and to keep your mind clear of preconceptions.
A vivid imagination will help with this step. Imagine a different way of doing things. Imagine that the rules we follow can be broken. Imagine if things were easier, better, faster. Get input from people of different races, ages and genders to get ideas.
This step includes uncovering a clear picture of the people who encounter the problem. What are their stories? What are they trying to accomplish? Why are they doing this? Remember that these are the people who will use the new product.
It is very easy to enter into a mode of thinking like train tracks where no deviations happen and we barely notice alternatives. This is the box people always want to think outside of.
To minimize this is crucial to innovation. Getting different opinions can help. Try to see the value of each opinion rather than giving a mental “pass” or “fail” grade to each one. You need to see the scenario from different angles to correctly identify the problem, and you can borrow these angles from different people.
Structure the Problem
Once you identify a problem you need to structure the problem in simple terms. This will help you understand the scenario and take a look at how the situation is created. This will also help you look at your reasoning to see any inconsistencies or flaws.
Flow charts are a helpful way of structuring a problem. Tree diagrams and lists can also be helpful depending on the problem itself.
Besides structuring the problem visually with charts and diagrams you should structure the problem verbally. Structure the problem as a story describing the experience of the customer, or as a clear and concise statement of facts
Analyze the Problem
Now that you have identified a problem and you have structured it in several different ways you can start analyzing the problem. This is where imagination comes in again and it is useful to think outside the box.
Try to identify the parts of the process that can be improved. Try to think of steps that can be eliminated or combined. But most importantly try to think of ways to blow up the status quo and create a new and improved process. Think about current technology and where future technology could take us. Think about new applications for existing technology.
Envision the solution
Now try to describe a product that solves the problems you identified. The point of this step is not to have exact specifications, rather it is to describe what the solution is. Describe a world where the problem is solved. Describe a new way of doing things. Describe how they will be done, with how much ease and how long it will take.
This is where you get the significant content of a PRD.
Create the solution
This job is for the engineers to do using the information on the PRD and their professional expertise.
Features of a good Product Requirements Document
A good PRD is one that is very specific on what needs to be done without limiting the engineers on how to do it. Requirements can be grouped into several categories for easier definition:
Functional problems are objective capabilities the product must have:
- Performance requirements are dealing with speed, capacity and other elements of the functions.
- Constraints are conditions that limit the product like size, materials, and cost.
- Interface requirements are about the interaction between hardware and software and relate to the ease of use for the user.
- Security requirements deal with compliance with government standards and customer privacy needs.
There must also be a clear definition of how to tell if a requirement has been satisfied. An acronym for telling if a requirement is clear is the word SMART:
Specific: there should be no misunderstanding about what is required.
Measurable: the requirement should be able to be measured against previous performance.
Achievable: the requirements must be achievable
Realistic: the requirements must be realistic with the available resources
Time bound: the requirements should have a deadline for completion
With these steps you have the building blocks to write an effective PRD. But you have to implement what you have learned into a document. Here are tips on writing the actual document.
Writing the PRD
Using the above steps you should gather your thoughts and ideas about the problem and about the requirements of the new product. Sketch and draw and tell stories about what you have learned until you feel good about your understanding of the subject.
Be sure to talk to many people about your work and your ideas. New people will give you new ideas and new ways of thinking about the problem. Actually just verbalizing your own thoughts will help you get a clearer picture of what you want to accomplish.
Use a good PRD template to organize your ideas. You can find many good templates online. Find any sensible template and populate it with your information. Get a first draft done. Don’t worry about grammar or hitting a high level of clarity on the first draft, just get a draft done and use it to move forward towards a better draft the second time. Repeat this step through as many drafts as you need. Take your time and let your thoughts marinate rather than calcify. Be fluid in your thinking and direct in your approach and you will write a great product requirements document.
