I loved visiting my uncle Bud in Rensselaer Indiana.  He had a passion for computers from the very early days of the field.  I learned a lot of programming from him.  Uncle Bud never spoke down to us kids, he’d dispense his knowledge slowly as he drank cup after cup of coffee and as the ash on the cigarette in his hand grew so long you couldn’t help stare at it, sure it would fall.  Garbage-In / Garbage-Out is conventional wisdom for any programmer, but it was new to me then.  As I think about the design process now, the same adage applies.  The inputs of a design job are the product requirements.  If they are garbage, the best design team in the world will still produce garbage.

Different industries call product requirements by other names.  The product requirements, specifications, design brief, all basically are lists of functions, features, and requirements that a product must possess or exceed if the product is to live up to the vision of those who wrote the requirements.

Requirements are the most basic blueprint of a new product.  Even before the napkin sketch, the requirements define in words the problem to be solved and what features will exist to solve it.  So I’m surprised each company goes about creating them differently; sometimes not creating them at all and just winging it or assuming everyone is on the same page.  In a way, setting the product requirements is the most important design step.  I will admit – also one of the most boring.  Getting creative types to sit still and write a plan is not easy.  But, if written poorly, the most brilliant product design team can execute the vision perfectly and the product fails in the market.

Several types of requirement go into a good product requirements document.  Some industries separate them into unique documents, but the format is not important.  Here’s what is important:

Good product requirements…

  • Document the features and functions that users want; if two are opposing, determine priority
  • Target a price or manufacturing cost
  • Consider environmental requirements
  • List any regulatory or safety requirements
  • Determine what functional tests the product will need to meet

How deeply you go into describing your features and functions has a bit to do with the novelty of the product.  If you have a small and experienced team doing similar products time after time, some details can be left to shorthand notes. If the product will require a large interdisciplinary team and it’s a new product no one has even seen the likes of, the product requirement might read like a book.  I’ve worked on military equipment design where the requirements documents are hundreds of pages.  I’ve worked on consumer products were the requirements were a 5 minute phone conversation because we’d done so many similar products together, almost all of the technical requirements were implied.

Sometimes your features oppose each other.  For example low weight vs. long battery life.  In this case it’s not useful to call out that the designers should maximize battery life and minimize weight.  The authors of the requirements need to make some judgement.  These are important decisions that can make or break a product.  You can write the requirement like, “minimize weight, provide minimum 3 hours battery life”, or “maximize battery life while keeping weight below 1.4 kg”  Sometimes the team needs to research and calculate a bit to finalize a requirement.  Still you should get as accurate as you can and describe to the team how you want to handle the trade-offs.

I sometimes get clients who think they should hold back a target price as if they are going to have to negotiate with me over the manufacturing cost of their product.  Or like somehow if they don’t tell me the target is $20 I might miraculously design a product that costs $10.  It could happen, but it won’t be because you hold back the target price. If you don’t have a cost target you’re a fool.  Your customer has a cost target.  Your competitor has a cost target.  You have a cost target, you’d better not fool yourself on that point.

It’s best to consider what the environmental requirements will be for the product early in development.  Requirements for sealing, drop, temperatures (and many items that tend to be forgotten) impact design decisions.  With our focus on rugged products, we developed the Juggernaut Rugged Scale as a tool to help clients determine their use requirements and environmental specifications as one of our first steps.

The most dangerous requirements are the ones you don’t find out about until after the design is complete or in the field.  I once designed a toilet fill valve and didn’t find out about a critical anti-siphon regulation until our initial prototype testing had been completed.  We had to completely redesign the valve as the anti-siphon feature fundamentally changed where the valve could be placed within the device.  This requirement wasn’t merely wanted by customers, it was a building code.  Unknown requirements destroy design schedules, sometimes sending the team back to square one.  Few other mistakes can exact that kind of toll.  That  is why we’ve got it on our 5 U’s of risk evaluation but that’s a separate topic.

Unknown requirements can come from many places: government (regulatory), patent infringement, supply chain, manufacturing, and service are common offenders since they aren’t always included as stakeholders in the early part of product development.

As you build your product requirements, think of it as a living document.  You will certainly be learning as you develop the product and some features will need to be added, dropped or modified.  Once you’re sure it’s not “garbage-in”, it will guide the design process, and especially how you evaluate and test that it’s the product you wanted.