Remember the Juicero? The Zune? How about Google Glass or Lululemon Astro yoga pants? The first pair is listed by Forbes as recent product design failures. The last two are included in the Chicago Tribune’s list of the biggest product flops.
The point here is that many new products fail, even those developed by businesses with deep pockets. Sometimes the customer requirements weren’t fully understood, but in many cases, while the concept was excellent, the execution failed. In other words, the product didn’t give customers what they wanted.
The Product Requirements Document helps to avoid this kind of disaster. This blog takes a look at this essential element of the new product development process. We explain what it is, why your project needs one, and how to set about creating it. We’ll also touch on updating because this is a living document your team should use rather than file away.
Understanding Product Requirements
You need more than a great idea to create and launch a new product: it has to be something there’s demand for, (or for which demand can be created). This means the first step in the new product development process is to write a Market Requirements document, (which may also form the core of a business case).
Having defined the need, you are then in a position to define what the product should do. These needs are captured in the Product Requirements Document, (which we can call the PRD). However, the PRD is much more than a list of features. It’s actually a roadmap for the development of the product. As such, it’s a collaborative document that should be signed off on by all the stakeholders in the development process.
Target costs, while a vital element of new product development, are seldom included in the PRD. That’s because this document focuses on functions and not the business case.
Teams are often tempted to rush, or skip completely, the process of writing a PRD. It’s easy to view it as an administrative task that slows the exciting process of developing a new product. Doing that ignores the real contribution of the PRD to the success of the project.
The point about the PRD is that it forces the product owner and development team members to think through what’s actually required. This aligns business and technical objectives and increases the prospects of launching a successful new product.
Why You Need a Strong Product Requirements Document
If you don’t have a thorough yet concise and readable PRD, you don’t have a good development plan. You’re unlikely to hit your objectives for the product, and it will probably not be the success you’re hoping for.
More specifically, the reasons for investing time in the PRD are that it:
- makes the requirements for the product explicit rather than assuming everyone understands what’s needed
- supports collaboration between the various functions involved in bringing a product concept to market
- establishes dependencies and constraints, so you know what’s needed for success and the limits of what’s achievable
- lets you prioritize product features, which helps guide decision-making and trade-offs
- establishes success metrics, so you know how near or far from your original goal you are
- forces you to consider the entire product lifecycle – not just the initial buyer but subsequent users and even the disposal process
Perhaps the most important reason for creating a carefully considered, well-written PRD is this: it reduces risk and increases your chances of success. If you’re looking for investors in your product, it will show them the details have been considered carefully, you know what you’re doing, and they have a good chance of getting a return.
How To Write A Good Product Requirements Document
The purpose of the PRD is to define the product. This is done in terms of what it’s for or what problem it solves, who will use it, and the features and performance it should have.
Taking the market requirements document as a starting point, begin by defining who the customers will be. It’s usually good to have some demographics here, such as typical age, sex, and size, getting as specific as the market description allows.
Then describe the product, identifying all the functions and features required and how they will meet customer needs. These will become the goals for the product, and should be SMART – that is Specific, Measurable, Achievable, Relevant, and Time-bound.
It’s helpful to determine constraints and limitations. This could include safety regulations that must be satisfied, the need to incorporate or exclude certain components or materials, and branding requirements. If regulatory approval will be needed, (almost always the case for medical devices and equipment), that should be captured at this stage.
Including Use Cases – brief sections detailing how typical customers would put the product to work – helps clarify the purpose and function of the product.
One thing the PRD should not be is a wish list. It’s important the document is created through discussion and consensus rather than being a collection of features the various departments would like to see.
Updating and Revising Product Requirements
When first creating the PRD, inevitably, some information will not be available. Part of the process should include tasking people or teams with obtaining this so it can go into a later revision. In some cases, plugging these knowledge gaps may require prototyping, creating breadboards, and testing.
It’s also inevitable that assumptions made early in the project are found to be invalid. Timescales may not be achievable, materials might not be available, or manufacturing processes might not exist.
Another situation forcing updates to the PRD is when cost information emerges that changes the financial viability of the project. Typical situations are when subassemblies, components, or materials are found to be significantly more expensive than first envisaged.
In all three scenarios, as new information becomes available, the PRD must be revisited and updated. In extreme cases, it may be determined that the product is simply not practical or feasible. More likely though, some trade-offs will be needed, which is where feature prioritization becomes important.
End-to-End Design and Development with Gener8
For businesses and entrepreneurs needing more resources and wishing to move quickly, creating a PRD can be a frustrating step in the new product development process. However, its potential to reduce risk, prevent surprises, and increase marketplace success makes it essential.
Partnering with Gener8 provides a way of squaring this circle. With full-spectrum engineering capabilities and a specialty in instrument design and manufacturing, we can handle every aspect of the process, from design to development and production.
We understand though, that end-to-end solutions aren’t always what’s needed. That’s why we’re also able to plug gaps in our clients’ processes. We can help with development, with manufacture, and yes, even with creating the Product Requirements Document.
Ready to bring your vision to life? Partner with Gener8 and turn your innovative ideas into reality with our full-service, end-to-end engineering expertise.
