Sharon West THUMB

Sharon West

Engineering

Electrical & Software Engineering

Mechanical Engineering

Creating product requirements can seem like a straightforward task, but it has plenty of potential pitfalls. While generating requirements can be easy, generating good requirements, well…. that’s another story.&nbsp;
Getting well-written requirements that will capture what you want can be really tough. (There’s a good reason why the job title “Requirements Engineer” exists.)

Delve's experts in insights, strategy, design, and engineering can guide you through an end-to-end innovation process that delivers results.

Our Services Page: Product Design and Development (text only)

There are a few reasons why writing good requirements is hard. It can be tricky to make sure you don’t miss anything important. There’s an art to balancing the need for information that will guide development with the freedom to navigate a path to the best final product. And requirements need to be discussed, iterated, and agreed upon throughout the project. These are not easy or intuitive tasks!
As a mechanical engineer who’s had experience in design, manufacturing, and project management throughout the product development cycle, I’ve learned a few things about creating product requirements, including the differences between requirements that can be a great help to the team and those that can be a real thorn in the side. In this post, I’d like to share some tips I’ve picked up that will help your project team succeed.&nbsp;

The post is divided into the following sections:
<ul><li>What Are Product Requirements?</li><li>Generating Product Requirements</li><li>Handling Uncertainty Gracefully</li><li>The Importance of Detailed Product Milestones</li></ul>
In the context of this post, I’ll discuss requirements for general hardware and/or electromechanical product development, i.e., not simply for software, and not focused on any specific product type. (Product examples in this post include a medical product, IoT products, and industrial equipment.)
<h2>What are Product Requirements?</h2>
Broadly speaking, product requirements capture everything a product must do. They incorporate needs from various stakeholders in the project. They might include items like performance metrics, human factors necessities, manufacturing constraints, and business obligations (like cost of goods).
Requirements should typically be written at the beginning of a project, before development begins, but as I’ll discuss below, it’s an ongoing process that will certainly overlap with development.

2023 08 10 guide to developing product requirements INLINE1 planning

<h2>Generating Product Requirements</h2>
So where do you start?
At the beginning of the process, I like to ask myself and my team these four questions to make sure I’m including all essential information.

More often than not, designing your cool new product relies on some new widget - but you’re not sure if you should design your own or buy one from a supplier. Six tests offer a straightforward framework for deciding whether you should design or buy that component.

Download Promo: Should You Design or Buy?

<h3>1. What does the product absolutely have to do? </h3>
This question gets to the primary requirements that should be driven by user needs.
You might be surprised that when your team drills down into this question, you find just a few key functions that the widget needs to perform. Having those primary functions clearly defined can be helpful as the team encounters hurdles along the development path. Primary requirements can inform reality checks: “We really want the widget to light up, but it’s not critical for this phase. Let’s make sure the primary function can be achieved first, before we focus on the bells and whistles.”
PRIMARY FUNCTION EXAMPLE: Let’s say you’re designing a connected toothbrush. Maybe there are just two or three primary requirements. It needs to be able to brush teeth. This might be broken into two requirements: have bristles, weigh less than xx grams. And if it’s connected, it needs to communicate. Does it need to communicate lengthy encrypted messages? Probably not — maybe just one or two pieces of data need to be transmitted. This gets down to the idea of a Minimum Viable Product (MVP). What must this thing be able to do at a bare minimum?

2023 08 10 guide to developing product requirements INLINE2 toothbrush

<h3>2. How will the product be used throughout, and in all aspects of, its product life?</h3>
Just as creating user personas can help guide product development, it can be helpful to imagine the product as a character in its own story. The requirements will be different not only based on the user but also on the surrounding environment — everything the product will experience.
The product is also going to be assembled, tested, possibly sterilized, shipped, stored, maybe serviced, and ultimately disposed of or recycled. The point is, it’s not going to exist solely in your engineering lab — it’s going to have a life of its own in the real world. And it’s not going to be used by the careful inventor whose “baby” it is — it’s going to be used, and <a href="https://www.delve.com/insights/how-design-for-misuse-creates-safer-products" target="_blank">probably misused</a>, by real people.
USER AND ENVIRONMENT EXAMPLE: A blood pressure monitor will have primary requirements, but it will have a host of additional requirements that can vary widely based on intended use. If it’s going into a living room to be used by a grandparent who struggles with arthritis, vision, or hearing, the considerations for the final product will be different than if it’s going to be used in a hospital by trained staff, or used intermittently in a school by a school nurse.
SERVICEABILITY EXAMPLE: There’s a product I encountered early in my career that always comes to my mind — a complex, room-sized piece of processing equipment for semiconductor manufacturing. The nature of the process meant that regular service was essential, as was keeping the act of service efficient because down time was so painful to the customers. To increase service efficiency, a requirement was made that only a single type of screw (thread, drive style, and length) could be used throughout the product — this amounted to hundreds of screws. Adding that requirement late in the game would have been costly, if not impossible. Determining these things up front is key.

2023 08 10 guide to developing product requirements INLINE3 screw

<h3>3. Have you engaged all the stakeholders?</h3>
While the primary functions and life of the product will drive some of the requirements, there will be others that are driven by business needs or capabilities. Ideally the manufacturing process will be designed around the product, not vice versa, but the world’s not always so ideal.
If the manufacturing team must use existing machinery and expertise to assemble the product, there might be some requirements that will drive aspects of the design. Some may be simple — fiducials for alignment, or grip points for pick and place robots, for example. Others may be more complex, like the product needing features for glue joints or ultrasonic welding.

The Gen 3 device is a step up in capabilities, ease of use, and quality of interactions while remaining true to the brand’s look and feel.

Case Study: Rachio 3

STAKEHOLDER EXAMPLE: Delve has designed two generations of the <a href="https://www.delve.com/work/rachio-3" target="_blank">Rachio smart sprinkler controller</a>. When developing Rachio 3, the third-generation product, the project team decided it would fit inside the outdoor enclosure designed for the second-generation product. This constraint required the unit to nest within a prescribed shape and to share an identical bolt pattern to the second-generation controller. Along with giving customers an easy upgrade path — they can easily swap out the older unit for the new one — it saved Rachio from investing in new tooling for a new outdoor enclosure.

2023 08 10 guide to developing product requirements INLINE4 sprinkler

<h3>4. What’s the worst that could happen?</h3>
Asking “what’s the worst that can happen?” can be a scary exercise until you realize it’s much better to consider these things before they happen, rather than after. Formal risk assessment exercises can help identify risks that will need to be mitigated — and these become requirements. But even a short, informal discussion with the project team and stakeholders about “what worries you about this product or project?” can help identify key requirements that seem obvious only in hindsight.
Please don’t skip this step or take it lightly! We don’t do risk assessments or add safety requirements to cover our own butts — we do them to protect our planet, our friends, and our family members. The moment I find myself thinking, “Do we really need this precaution?,” I think of colleagues who worked on products that were recalled because they might harm someone, or worse, actually harmed someone. When considered in that context, this step is never superfluous — it’s a necessity.

<h2>Handling Uncertainty Gracefully</h2>
Let’s say you’ve gone through some of the above exercises to generate requirements. Are you finished? Unless you’re a pro at this, probably not. The devil, as always, is in the details.
Good requirements are often defined as being SMART:
Specific Measurable Appropriate/Achievable/Attainable Relevant/Realistic Time-bound/Trackable
Different teams and companies use different words in this acronym, but the general idea is the same. I find it especially helpful at the beginning of the process, when details are scarce.
The thing is, whether or not you have all the details, you can still capture useful input to inform the design process. Each requirement can still meet the SMART criteria to avoid ambiguity. While writing your requirements, make sure to strive for a shared understanding, define what you can, leave options open, and record guidance and rationale.&nbsp;
Here’s more on how to do that:<h3>1. Build a shared foundation.</h3>
In most cases, the devil is in the details of mutual understanding. If you and I write a requirement that the product should “look cool,” it shouldn’t be surprising that you and I might disagree on whether or not the final design satisfies that requirement. How can we help the team get onto the same page? Add detail. Provide metrics for vague descriptors. Think about how you will test it: what will pass, and what will fail?

The “look cool” example is pretty easy to see, but what if we write something technical like “the PCB must function from 10C to 40C.” Do we all agree what “function” means? Will it be acceptable if it performs its task at a different speed than ideal? What if it can perform a limited subset of its tasks when it’s at the extremes of the temperature range? Does the temperature in the requirement refer to the surface temperature of the PCB or the temperature inside the product’s case, or the temperature of the room it’s in?
Being persnickety enough to capture these details can better help everyone understand the requirements in the same way. If you’ve got details, capture them!

2023 08 10 guide to developing product requirements INLINE5 PCB

<h3>2. Keep options open, define what you can, and accept sacrificial requirements.</h3>
Fuzzy requirements can be especially common early in the design process. Most teams need to move forward with requirements that are not locked down. Indeed, many requirements will not be written or even considered until a design path is chosen. Why bother trying to specify a motor voltage if you might end up using pneumatics?
If you know something — but not everything — about the requirement, capture it broadly enough to allow different design paths. “The product must communicate three different states to the user” can be solved several ways, while “The product must have three LED colors” is more restrictive. It’s typically fine to defer requirements tied to a particular design path until after some early prototyping is done. At some point, the team will select technology B over technology A and then you can start nailing down details like motor voltage or maximum pressure. Until that time, the team should feel comfortable working with requirements that are either open enough to accommodate all possible design solutions, or writing requirements that are intended to be temporary.

Sacrificial requirements are those that the team acknowledges might be thrown away. Maybe the final design is planned to run at a single speed, but we don’t know which yet, so the prototype needs to run at multiple speeds. You can help your team get on the same page by recording rationale or notes like, “This requirement is for alpha prototype phase only. The plan is to select and offer only one speed on the final product.”
You might need to put up some sacrificial tent poles to hold enough fabric to capture the shape of the product today, as a step toward getting to the tent you really want to build in the future. By the end, the tent poles might be a different length or at different angles, but the general idea that’s enveloped will be the same.<h3>3. Provide guidance if you can’t (yet) define requirements.</h3>
Especially when requirements are fuzzy, it’s even more important to be sure we’re speaking the same language. These early phases are when it can be helpful to capture both requirements and guidance.
Something I do a lot with early-stage products is define guidance versus requirements. Requirements, by their nature, need to be testable. But what about those targets where you want “as much as possible” but just don’t have a metric for an acceptable minimum yet? That’s where guidance comes in. Adding guidance items to your requirements document helps keep targets that might one day become requirements in front of the team.
The graphic below shows how I have captured guidance on projects.

Product Requirements Guidance on Projects Table

Capturing guidance can also be immensely helpful where the target is testable, but not testable yet. If the hardware’s going to interface with an app, but the app’s not going to be designed until later, there are some functional targets the hardware design team’s going to need — even if they can’t be tested until the app is available. Metrics that will eventually be tested may be captured as guidance to help the design team focus on their target, even if it’s not immediately testable.
Generally, guidance items are not tested, but if the team is concerned about glossing over guidance items during a round of prototype testing, you can create a “test” for each piece of guidance with the pass/fail criteria simply involving a general assessment. For example, there may be no defined metric for the guidance, “should be easy to assemble,” but you can still include a test like, “record observations on how easy the product was to assemble and record any specific notes for improvement in the next phase.” The pass/fail criterion might simply be, “test is passed if notes for improvement are recorded.”
<h3>4. Seek out and capture important rationale</h3>
Just like documenting guidance, capturing rationale is an important aid to the design team. Understanding why a requirement (or guidance item) is the way it is can be immensely helpful.
If there’s a requirement that something can’t move until pushed with a certain force, it might be driven by the need for the assembly not to shift during manufacturing. Or it might be driven by the need for the final product to only be actuated when a special tool is involved. It might even be intended as a lockout against unintentional use when someone untrained is “fiddling” with the product.
These cases might be solved with alternate requirements. Understanding the rationale can help the team ask the right questions, like, “Could we solve this a different way?,” or, “Is this the right metric?”

It doesn't matter how innovative your new product is if your competitors beat you to market.

Don't Miss: How to Get Your Product to Market Faster

<h2>The Importance of Detailed Milestones</h2>
Lastly, problems can arise when we all agree on requirements for a product but disregard the requirements for each phase. Do we all agree on what we’re going to build during each phase or sprint or iteration or calendar year?
If we both nod and say “proof of concept,” but you’re envisioning a mockup with some plywood and I want something I can use to wow my boss — or project sponsor or investors — then we’re basically speaking different languages.
There are so many different ways to develop a product. The development path and how it’s broken up into phases can be vastly different for each company and/or project. Communication is key to minimize disconnects!
One useful tool for coming to agreement about the exact requirements for each phase is an “Is/Is Not” table:

Product Requirements Is Is Not Table

If you prefer prose, you might simply write:
What we’re making in this phase is a “looks like” model, not a “works like” prototype. It will not be functional but it will have a lever that moves, although that movement may not have realistic resistance. It will have painted-on texture, but not true molded-in texture. The grip will have some foam but will not be the final material or manufacturing method.

It’s also important to review the requirements within each phase. As I discussed above, the requirements for early prototypes might exist only for those prototypes. At the start of each new phase, the team should spend some time going through the requirements to cull items no longer needed, update any items which have changed, and/or add any new items based on learnings from the previous phase, such as new input from marketing, etc.
<h2>Why Bother?</h2>
I used to feel that requirements were little more than a bunch of legalese that were more of a hindrance than a help. But defining product requirements is an essential part of the development process, and I’ve learned that neglecting this effort or taking it too lightly can hurt the project in the long run.
If you keep in mind the goal of helping your whole team deliver a stellar product by all playing from the same sheet of music — the Product Requirements Document — you can craft practical requirements that allow your team to work in harmony to create great things!

From concept to manufacturing, our engineering services can get your products to market.

Services Page: Engineering

Learn more about&nbsp;<a href="https://www.delve.com/services/engineering" target="_blank">Product Development Engineering Services from Delve​.</a>

SEO Text: Engineering Services

Newsletter Signup: Digital-Physical Product Development (icon visual)

2023 08 10 guide to developing product requirements2 HERO

Creating product requirements can seem like a straightforward task, but it has plenty of potential pitfalls.

Contact Us | General (Let's build something together)

Medical Devices

Consumer Products

Home

Insights

A Guide to Developing Better Product Requirements

Breadcrumbs

A full-service product design and strategic innovation consultancy.

Delve

Creating product requirements can seem like a straightforward task, but it has plenty of potential pitfalls.

description

generator

kSwNn6qD4B-4HloWnWMUBWQNpBx2_mPi3nMqgsh6ato

google-site-verification

requirements, like, straightforward, task, plenty, product, potential, creating, pitfalls

keywords

https://cms.delve.com/assets/images/_1200x630_crop_center-center_82_none/2023-08-10-guide-to-developing-product-requirements2_HERO.jpg?mtime=1703714467

https://linkedin.com/company/delvedesign/

https://www.delve.com/insights/a-guide-to-developing-better-product-requirements

referrer

robots

twitter:card

twitter:creator

twitter:description

https://cms.delve.com/assets/images/_800x418_crop_center-center_82_none/2023-08-10-guide-to-developing-product-requirements2_HERO.jpg?mtime=1703714467

twitter:image

twitter:image:alt

twitter:image:height

twitter:image:width

twitter:site

twitter:title

{"title":{"title":"A Guide to Developing Better Product Requirements | Delve"}}

Learn the Not-So-Basics

Privacy Policy

FCOI Policy

Services

Case Studies

Testimonials

What We Do

About Us

Our People

Join Our Team

Careers

Newsroom

Who We Are

Boston

Madison

Philadelphia

San Francisco

Our Studios

Partner with Delve

Contact Us

Contact

Vamsee Pamula, Founder &amp; President, Baebies

Read informative articles from Delve's team of experts. Discover innovative strategies and insights about product design, engineering, and development.

Delve Insights: Product Innovation & Development Blog

innovation, product, design, advice, development

https://cms.delve.com/assets/images/_1200x630_crop_center-center_82_none/Delve_titlecard.png?mtime=1654035558

https://cms.delve.com/assets/images/_800x418_crop_center-center_82_none/Delve_titlecard.png?mtime=1654035558

A Guide to Developing Better Product Requirements

A Guide to Developing Better Product Requirements

Related Insights