The Legend of the Too Tall Lasers

For the past several years, every Candela employee has heard the story of the too tall lasers. It goes like this: All Candela US sales reps have company vans, to carry demo lasers as part of the sales process. Several years ago, after more than a year of development, a project team wheeled their latest greatest device out to the local rep’s van. You can imagine everyone’s surprise when the product just wouldn’t fit. For the next couple of months, the launch team fumed while the engineering group shaved a few inches from the design.

How could this happen? And what should the company have done differently?

It would be easy to blame the engineers, but the real problem was systemic: There was no requirement specification. Many in the medical device industry think of the requirement spec (aka design input spec) as just another regulatory requirement – another piece of paperwork foisted upon an already overworked R&D group. Some engineers see the requirement spec as a marketing responsibility, disconnected from their responsibility to design the new device. Even worse, some see the requirement spec as another data point where the company could fail an FDA audit – no documented requirements means no non-compliance.

I want my new products to win. Winning means satisfying customer needs, hitting market share targets, and meeting the company sales and profitability goals. Winning means beating the competition. Winning means I get a bonus and/or my stock options are more valuable. Winning is personal.

Winning starts with the right requirements spec. The requirement spec is simply the list of all things my product must be, to win. A great requirements spec embodies superior customer intimacy. The complete requirements spec includes the (four-part) customer’s needs, regulatory requirements, and the business’s needs. Getting the requirements spec right is the responsibility of every single person on a new product development (NPD) project team. The right requirements spec is not a guarantee that your product will win, but it’s an absolutely necessary step along the way. A great requirements spec speeds the NPD process by focusing the team on the right goals, and reducing the likelihood of surprises later. So, if you want to win, you need to master the art of the requirements specification.

In case you couldn’t tell, I feel pretty strongly about this. When I rejoined Candela, one of our first tasks was to add the requirements specification into our NPD process (aka Design Control procedure). I personally wrote the first draft of our first requirements specification. That was the easy part. Getting to an agreed-upon spec required innovation, negotiation and perspiration from our project team.

How do you write a great requirements specification?

Business thinkers have tried to turn this art into a science. The best textbook treatment I’ve seen is Ulrich and Eppinger’s book Product Design and Development. Voice of the Customer can be a useful exercise if you aren’t already very familiar with customer needs.

Textbooks and processes only get you so far. Experience, as usual, is the best teacher. So, it’s really helpful if you have strong requirements definition experience among your core project team members, or if you have a solid requirements spec from a previous project to use as a baseline. I have learned a lot from my colleagues over my career – here are a few things I’ve picked up:

1. Get out in the field and observe. All core members of the project team should spend significant amounts of time observing their customer using relevant predicate devices in the real world. There is no excuse for not doing this. Watching web videos is good preparation for a field visit, but not a substitute. The team must see how devices are stored, unpacked, set up, used and shut down / disposed. A couple of times I have hired outside firms to help my team excel at learning user needs. It has been well worth it.
2. Capture learning from the research phase of your project. Most projects start off in some internal or external research group before a cross-functional team starts to work them. If your company has licensed some university technology, understand and document the motivation of the academic project. For example, the academics may have determined that a biodegradable stent must provide radial strength for 90 days because their research showed that the post-stent vessel was fully healed in about 45 days and a good design should provide 2x margin.
3. Analyze the competition. Understand why they are winning some sales, and what your customers want you to do better. Try to project where your competitors will go with their next products.
4. Imitate.  Find out what devices your customers like, and why (even unrelated products). For example, all sorts of devices now sport user interfaces inspired by the iPod and iPhone, because those user interfaces provide real benefits.
5. Beg, borrow and steal.  Find non-competing colleagues who have specs you can borrow from. No sense reinventing the wheel. Just don’t copy blindly. Someone’s old angioplasty catheter spec might be useful for your percutaneous valve project. Or not.
6. Refer to standards. I wish there were more standards for medical devices, but there are definitely some out there. The ISO catalog is a good place to start.
7. Write from a user’s or stakeholder’s point of view. Say that “the console must be able to transport the device over an elevator gap,” rather than specifying a minimum wheel size.
8. Be specific. Say that “the catheter must be able to be unpacked into the sterile field by a single user in no more time than it takes to unpack the predicate device” rather than saying “the catheter must be easy to unpack.” By “predicate device” I don’t mean a regulatory predicate. I mean an existing device that has a relevant benefit that meets your users needs.
9. Don’t be too specific.  Focus on the user benefits and leave room for multiple solutions. Don’t say “must have a color touch screen”; instead describe the benefits that you think a color touch screen would deliver (e.g. low number of user steps to activate the device, perception of quality).
10. Start off by writing a “reach” spec. Compromise later if you hit a technical or timeline hurdle. A “reach” product has a high level of difficulty, but would be a home run if you could do it. It’s good to know what you are shooting for, and a “reach” requirement spec promotes out-of-the-box thinking. You may start off trying to make your product “both faster and smaller” than the previous generation, but you may have to settle for just “faster and no larger than” the previous generation to fit your new power management system.
11. Make every requirement testable in some way. You need to have a method of measuring whether you’ve met the requirement. Say “a trained user should be able to prime the catheter in the same amount of time as the predicate catheter,” rather than saying “the catheter should be easy to prime.” Besides typical bench test, specs can be checked in an animal study, your clinical study, a phantom or model, a simulated user test (clinical research associates and clinical education specialists are often good for this), a user survey, or in a limited market release.
12. Follow your user steps.  Write requirements specifications for every step in the process of using your device, from the time it arrives at the user site, to the usage of the device, and ultimately to its disposition. Some real life examples:
    1. A requirement that our packaging was easy to identify on a crowded hospital shipping dock, so that our users were not delayed getting products they ordered overnight.
    2. A requirement that our catheter would be deliverable over a standard coronary guidewire.
    3. A requirement that post-use, our hazmat cryogen containers must be shippable by an untrained user back to the factory.
13. Don’t forget your company’s business needs. If you really want to win, you need to understand and meet your company’s business needs. Manufacturing and servicing costs are obvious here. If you are in an existing company, your company’s business needs may also include leveraging existing sales channels, manufacturing compatibility and/or supply chains.
14. Remember that the spec is a living document. The requirements should be modified when you learn something new about the product, either from the field or the lab. During the product development process, if you are vigilant, the spec will improve.
15. Perform a post-launch spec review.  After launch you might identify some requirements you may have missed, which will make it into the next rev or the next generation.

This has been a long post. If you’ve made it this far, thanks, and consider sharing with your friends and colleagues via the “share this” buttons below.