Everyone has heard the napkin sketch story.  The brilliant new product is first sketched out on a napkin, communicating the idea from one mind to many.  The oldest example I have heard was from an engineer who had just gotten out of school and had started working at North American Aviation, Inc., before World War II, and one of his first mornings at the company he literally saw what was to become the P-51 Mustang fighter aircraft sketched out on a napkin, coming from the boss.  It was a variation on an existing design, but none the less, from that napkin to one of the most effective fighting machines in history, which played a crucial role in keeping the freedom of the world, means it was a pretty good napkin sketch.  But the sketch needed much more definition than a line drawing.  It improved on the current status quo, and came with a whole host of other requirements that pushed the known limits of mission range, speed, and reduced cost to build, to name a few.  The napkin sketch was not the beginning and end of product definition for this very successful project, although it had an impact by being written down, it still needed to be defined with a larger list of requirements and goals, especially since the project had an amazingly quick development cycle.    

Nowadays, this 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 when multiple challenges amass, a well written PRD should help the whole team consider all of the requirements and performance goals of the product, and prioritize 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. 

Initial drafts of your PRD do not have to be perfect or complete early in the effort to bring the new product to life.  Initially features that are not defined yet can be TBD.  The PRD provides a guide and coordination from the beginning, just like the napkin sketch, and the associated British governments request for proposal documents did at the time for the P-51.  Specifications will get further refined, and some initial goals may be exceeded. 

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. 

It is easy to over focus on marketing the concept to communicate what it is, and although this is part of setting up a product definition, marketing alone can ring hallow to experienced venture capitalist and product development partners you might be trying to get on board.  Conversely, hyper focus on details, without the overview of what the product is doing for its target customers will read more like a white paper on a discovery, and unfortunately this can come across as not fully thought thru enough to support product development, all the while not providing the right guidance for a team of problem solvers. 

“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. Everytime 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, dogs?
• 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 mold?  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. US, North America, EU, Japan?  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 $100,000 of 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 napkin 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 Startup Support Program.