How to Write a PRD (Product Requirements Document)?

The initial written definition of what the product will be, is commonly called a Product Requirements Document. Often there are sub-set documents that proceed or further define the PRD, like the Market Requirements Document or Engineering Requirements Document, but the PRD is where things come together for all of the disciplines involved.  It isn’t written once and never touched again.  It should continue to be refined and updated as the project evolves.  It should be the launching point for various groups within the product development process to identify design challenges early, areas that might require early mock-up testing, the frame work for prototype test plans, input for marketing material, if that isn’t already published, and cost assessment challenges. It is a road map for the product being developed but not a solution.  It identifies what the product should be making better for us, what it will do, in what kind of environment and for what kind of users. 

It will list what specifications the new product has to meet, but it will not try to be a recipe to solve those challenges.  That is what the development team will do, solve the challenges.  And a well written PRD should help the whole team consider all of the requirements and performance goals of the product, and prioritise them, so the team can efficiently move forward, with the constraints they have.  Keeping this in mind can make the difference in getting to market or not. 

Maybe certain early choices regarding the product design will affect the initial plans for how the product is serviced or installed, and the PRD can be updated to reflect this to support planning for user instructions and field service manuals.  Maybe the product is never repaired, but discarded and replaced with a new one, but this is a hard choice if the cost of goods is not fully understood, yet.  The PRD can help navigate all of these pitfalls, and prevent one from ballooning into a late development cycle problem, delaying certifications and product release. 

A good product development consultancy can help clients, large and small, put together their PRD, to help bring the start of the project together, understand the road ahead, bumps and all, and chart a path to a successful product release.  Many clients don’t understand the importance of compiling a PRD.  Whether it is the benefits mentioned above like getting the team on the same page, or the ability to communicate the concept and how far it has been thought thru to potential financial backers, your PRD will clarify project intents and goals to the extended team, including consultants brought on to the effort. 

“So how do I write a PRD?”

The things below should be considered at minimum. Keep your PRD under revision control so you can refer back to earlier versions if needed. Every time you make an update to the PRD save it as a new revision (Rev 2, Rev 3, Rev 4) so it is easy to see the progression and changes over time.

  • What does the new product do / what is it making easier or better?
  • For whom does it help?  Who is the target market(s)?  Adults, kids ?
  • What is the approach of the new idea?  What general features is it offering?
  • How will the user interact with it?  Touch points, buttons, displays, …
  • Industrial design and branding, is it established, is it a new look, a re-branding, should it be timeless, or shocking and break the mould?  Incorporating logos?
    • Is the look tied to an app or software user interface?  Does that need updated or created as well for ease of use for different users and integrated branding?
  • Should the new product last forever, like a good wrist watch, or is it one use, or?
  • What will it need to survive (environmentally) and what specs will it have to meet?  Will it need to work in the middle of the desert at noon?  Work under water?  Will it need UL or FDA or CE or… certifications to go to market with due diligence? 
    • Be realistic on the environment and regulatory requirements too.  If it doesn’t hold up then more effort should have gone into the design, but if it is way more rugged than it needs to be then your cost of goods is much too high.
    • Consider markets to be sold in, i.e. in India or worldwide?  Which market will be first and most important?
    • What level of:
      • Fluid ingress or sealing is needed, IP rating, NEMA, 60601-1?  How is it cleaned?  Does the product get submerged, how deep and for how long? 
      • Dust ingress is part of the IP ratings, for example, and it should be considered when looking at the environment for use and not assumed that the fluid ingress will be rigid enough to cover dust ingress as well.
      • Drop ruggedness, 1 m 6 times, 2 m 26 times, are there other shock loads?  Is the device portable?  Is it secured to a vehicle during use and experiences vibration?
      • Temperature and humidity ranges needed for operation and storage?  This can significantly impact sourcing components like displays. 
      • Solar exposure
      • Tip over and stability?
      • EMI shielding requirements?  Even for cross talk?
      • ESD requirements?  
      • Some combined conditions, say after drop testing, sealing robustness during heat cycling, can be the most daunting.  The PRD can be an early tool not just to plan testing but confirm true worst cases to design for. 
      • Does the design need other safety considerations for child safety, high voltage, and so on?
      • Keep in mind that a thorough review of the requirements being established in the PRD, early on, can help appropriately define the actual requirements and tests that need to be met, to keep the design effort focused. 
  • Will lots of these new products be sold to a broad market, or just a few made?  This not only affects cost and profit margin estimates, but determines fabrication methods, materials, and if custom parts are viable versus off the shelf sub-components.  Your business model may even pivot on this. 
  • And what are the costs of goods goals?   Don’t forget packaging, shipping and distribution costs in the long run. 
  • Does the product have any shipping or packaging constraints?
  • How will it be serviced? 
  • If the new product has a long list of features, which ones are must haves to succeed and which are nice to haves that might be better left for a second generation product, or might not even be needed once customers start providing feedback?

The early layout of the PRD can also help look for contrasting requirements right off.  If the new product is supposed to be super affordable but has a “nice to have feature” that everyone loves but will add significant cost, then it is good to start resolving that contradiction early on.  Maybe it needs a custom removable battery pack, but to meet regulations the new battery module will add  for development and certification testing, plus additional part cost of goods, so maybe it is OK for the first generation product to have a permanently installed battery at lower development costs.  Using the PRD and its ability to communicate to the whole team can help gather feedback on all of these issues as the product development process speeds ahead, and help prevent expensive conflicts later in the process, when stopping and backing up can be a big problem. 

So next time you have 120 days to develop a new gadget to head off the invasion of a key ally and save the world, start with a sketch and a PRD.  You’ll be glad you did.  And whatever your new idea is, it will benefit from the early planning and mapping out through the PRD. 

If you need help establishing a PRD for your new idea, we can help with those first steps.  Ask us about our Start-up Support Program.

Blog Home