Design News is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

3 Ways Requirements Documents Kill Product Development Projects

documents
We all agree that a requirements document is an essential part of the product development process, but can this document actually lead to the downfall of a project?

Creative people hate documentation. Technical people hate ambiguity.

We all agree that a requirements document is an essential part of the product development process, but can this document actually lead to the downfall of a project?

Here are 3 ways that a requirements document can hinder the success of a project.

1. It Doesn’t Exist

It’s pretty tough to start a project and get everyone moving forward in the same direction if you don’t have a requirements document. However, this happens far more often than you may think.
Early startups often struggle here. “We are just trying to prove feasibility,” or “We just need to get to proof-of-concept first,” are the most common reasons these early stage companies use to explain the absence of a requirements document.

However, even at this early stage, a requirements document can help focus your activities and eliminate redundancy of tasks, all of which will help you save money. (This can be a big deal since money tends to be the item of scarcity with most young startups.)

2. Requirements Doc Is Really a Specification Doc in Disguise

Too many developers forget that a requirements document is meant to describe what the product will do. Because engineers are problem solvers, our brains love to jump quickly to solutions, and we often fall in love with those early solutions.

This is why we have a tendency early on to describe how the device is going to do what it is going to do (solution-oriented), instead of what we want the device to do (results-oriented).

The former is a scientific approach, and the latter is a user-centered approach.
Describing the “how” of functionality is what the specification document is for, which comes later in the process.

Designing with specifications guiding the early stages of development is a sure way to stifle creativity, and potentially make your device susceptible to getting beaten up by the users and regulatory people late in the process.

3. Requirements Doc Doesn’t Include Design or Usability Requirements

Many times, developers will populate the document with the most well-known items. “It has to be portable; it must fit in the trunk of a car; it must have a display.”

These are all important requirements, but also very simple ones.

Design requirements should go beyond this by gathering a deeper understanding of the user and their needs through various forms of research to discover hidden and unmet user needs.

For example, understanding that a medical device must be handheld is a pretty simple requirement.

A more complete requirement might involve requiring the handle to allow the user to control suction, steering, and activation with that same hand, and without changing the position of that hand during usage.

Conclusion
Taking the time to create a stellar requirements document can prevent wasted time by eliminating redundant tasks. Creating a requirements document that truly is a requirements document and not specifications document may free up your teams to be more creative in their product development approach.
Finally, if requirements are based on deep user needs, it increases the chance of both clinical and market acceptance, and it often creates competitive advantage.

Tom Kramer is passionate about making ideas become reality. You either find him at Kablooe Design helping his customers develop the latest and greatest products or speaking at various industry events on the topic of innovation and optimizing the product development process.

Hide comments
account-default-image

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish