fbpx
 

15 Jun The Detailed Product Specification

Posted at 06:36h in Engineering Challenges by

Ok, it’s time to get a little technical (very little). We’ve talked to a lot of companies with award-winning products, great ideas, and good sense, but when we try to nail down some of the details, they get a little flustered. What is the depth of field required for the machine vision system? Do we need auto-focus or is fixed-focus okay? Do you need USB, Wireless, or Ethernet connectivity to import and export data?

Being in product development, we constantly want to know our constraints. How big is our playground? As children, this was considered quite annoying to our parents and teachers. Now that we’re grown-up, we find that it is no less annoying to our clients and vendors, not to mention our spouses. But, that’s not to say it isn’t extremely valuable.

Maybe you haven’t considered data format compatibility or compliance with IEC 60601 standards. That’s why our first step is to try to flesh out the Product Specification.

What is a Product Spec?

The product specification document provides the set of guidelines a product will be tested against once development is complete. It is effectively the contract to which all parties will be held. Perhaps that contract is between marketing and engineering or customer and consultant, but it defines what the product will do, how it will function, how much it should cost, and everything else about the product. The primary benefit of writing the product specification is to ensure that everyone involved has considered all the factors, agreed upon the trade-offs, and knows what is expected. Therefore, the specification should be carefully worded, unambiguous, and with criteria that can be objectively evaluated.

Although writing a product specification may sound straightforward, it can be difficult to articulate certain aspects of the design or to nail down the range for acceptance. However, spending the time and effort to complete it up-front can easily prevent expensive design changes down the road.

Perhaps the best way to communicate the subtleties of the specification structure is through examples. Of course, because of confidentiality I cannot provide the specifications from any of our projects, but I can write a simple, hypothetical spec for a common product. Since you’re likely reading this post at a computer, I’ll write an example for development of a pair of computer speakers.

Definitions

The most fundamental concept to understand is the difference between a requirement and a desire. In this case, words matter quite a bit. We use the following conventions in our terminology:

Shall, will, or must:  Requirement is needed for the success of the product. Variation from “shall, will or must” will require product specification revision.

Should: The specification should be met unless another arrangement is agreed upon in writing by the Project Manager and the stakeholder.  Documentation of the other arrangement must be included in the project file. Product specification revision is not required.

May: Not required but would be desirable.

An example to show the difference between shall, should, and may:

This example highlights the needs and desires of all of the stakeholders:

  • Marketing has identified that users want a way to know if the speakers are ON.
  • The Industrial Designers like the appearance of a single LED near the base of the speaker because it is simple and easy to understand because it is commonly used to denote Power, but this choice is not related to branding or a related family of products so it is not a requirement.
  • Engineering may identify an off-the-shelf volume knob that is lit when powered which removes the need for the LED and perhaps some additional internal electronic components.

Because of the definitions, changing from the LED to an illuminated knob would only require notification of the Project Manager, who should probably consult with the Industrial Designers, but it does not require changing the specification. Furthermore, while a preference has been shown for green, any color would satisfy the spec.

Output in the specification

1.    The user shall have a means to identify that the device is ON.

2.    The device should have a single LED that is ON when Power is ON.

3.    The Power LED may be green.

Something as simple as an LED can really have an impact much greater than anticipated. This example shows how the complicated considerations of all of the stakeholders can be communicated and represented in a few precise sentences.

Defining a detailed product specification up-front forces all of the stakeholders to think about the real functionality and identity of the finished product, even before the designers and engineers have put real effort (read: time and money) into the development. Often, the process of creating the spec can eliminate a lot of the dead-end design paths before they begin. They also ensure that the finished product will meet everyone’s expectations.

Hopefully, this helps identify some of the intricacies of the wording in a product spec. Every project is different, so it’s not simple to create a template or checklist to consider every possibility. Asking questions helps a lot, although I try to refrain from conjuring my inner 3-year-old, “Why? Why? Why? Why?”.

Key Tech
Latest posts by Key Tech (see all)
Tags:
, , , , ,


Every challenge is different – Tell us about yours.