All kidding aside, this satirical Onion article is a lighthearted reminder that the FDA approval process can be a time-consuming and complex process.  But remember also that it is an exceedingly necessary process given the nature of our work.  At Key Tech and elsewhere, engineers, biologists, and researchers are lucky to be developing products that affect peoples’ lives.  But the reality then is that we are developing products that have the power to affect peoples’ lives!  I find it reassuring that our industries are subject to the measures the FDA puts in place if it means safe and efficacious end-results for the consumer.  In a 1940’s comic strip entitled Pogo by cartoonist Walter Kelly, the title character exclaims, “We have met the enemy and he is us”.  I would say that Kelly – who died of complications of diabetes in 1973 – would agree that his words could also be applied to any field involving human health and safety as, “We have met the end-user and he is us”.

Think your user interface is “intuitive”? Ask your grandma to use it. Ask a doctor (if your grandma is a doctor, don’t cheat – ask another doctor… or another grandma). Ask a teenager. Take it across borders and ask again.

Did you include the right features? Not if you ask enough people.

Could you have solved that technical challenge another way (a better way)? Most definitely! If only you had the same list of priorities that your detractors do.

I’m not advocating that a device needs to be all things to all people. But, if the customer base includes various demographics and nationalities, it’s going to be helpful to know how the customers differ instead of only using my own judgment and beliefs.

Now this is a blog about product engineering, but I have a feeling this idea can spread to just about everything in my life. We just don’t want to discuss politics, religion, or sports teams here. How about you? Have you ever had your preconceptions shattered?

The concept of “personalized medicine” is based on the targeting of specific factors that make one individual more receptive to a therapy than another. Pharmaceuticals can alleviate symptoms and cure disease. However, many drugs  only help fewer than half of the people who take them, and many come with the small chance of side-effects – everything from diarrhea or drowsiness  to death. The idea of personalized medicine is that patient populations can be tested to verify before prescription that a drug will be effective for them and that side effects will be minimal.  Tests may be based on a genomic marker or a biological cell structure.

Key Tech has been designing and developing diagnostic devices, both point-of-care and high throughput, for over 10 years now.  In recent years, we’ve been conceiving and developing new drug delivery devices as well and we are witnessing the growing market for patient-friendly medicine delivery and the companion diagnostics that qualify a patient population for targeted drugs.  We’re looking forward to watching this approach to medicine develop and mature.

Most of the specific values of the product specification will come from external sources, as opposed to technical constraints. The spec will include the needs of the end-user, but any design is likely to also involve input from those people between the engineers and the end-users – a contract client, the marketing department, or internal management. In product development, there are very real market pressures to consider regarding sales, user needs, competitors, price, and more that will influence the overall design.

Specifications will vary from product to product, but there are certainly some aspects that are likely to show up everywhere.

Performance

Of course, most devices have to meet performance criteria as a major consideration of their success. This includes factors like accuracy, reliability, appropriate measurement or operating ranges, data logging capacity, or data transmission characteristics. These factors may be defined as minimum and maximum limits, to be determined later based on cost, technology, and other features. Try not to limit the possibilities yet, leaving room for compromises later.

Construction

Even if the materials haven’t been defined because of performance features still waiting to be designed, there are details that can be defined early on. We might define the parameters of a Drop Test, a maximum device weight, or other factors that will influence our choices of materials and assembly. Will the inside of the device need to be accessible for cleaning or service? How will the device be used?

Environmental

When products work fine in the lab and crash in real life, there may have been factors that were overlooked. Long-term problems like corrosion, moisture, dust, and UV damage can cause intermittent failures as the product is used and aged. Short-term problems such as operating and storage temperatures, poorly regulated power, or susceptibility to electromagnetic interference (EMI) can break a device under certain conditions while it seems to work fine at other times. Where will the device be used?

Appearance

Some engineers may not like to consider how a device will look before it is actually working. However, design and appearance are important factors in the usability, marketability, and overall attractiveness of a device. You may have a company color scheme or user interface requirements to meet.

Additional Factors

Depending on the product, there can be a variety of other considerations. For medical devices, safety and regulatory compliance are significant considerations to be determined early in the project. How the user will interact with the device is also important. Additional factors such as requirements for product reliability, serviceability, assembly, and documentation may also be defined. Here’s where we might include any operational procedures like setup or shut-down requirements, calibration, or testing.

Photo credit: Chris Baker

Any other thoughts on its meaning?

Here we have a sign that is confusing to at least one group of users (and a lot of the people that those users know). In this case, the water taxi sign-makers get kudos for going out of their way to create a pictorial sign in an attempt to bypass any language barriers for international tourists. Unfortunately, the graphic in the middle is very busy and confusing. This is a case that would benefit from the “less is more” principal; simple graphics and text would get the point across much more clearly and quickly. And, although text can also be confusing, most foreigners pick up at least a bit of the language when navigating a foreign land, (“Please”, “Thank you”, “Yes, we love IKEA!”).

So, if you were designing this sign, how might you have determined whether it sufficiently communicated its meaning? And, if you know where to get one of those Swedish robots, please forward the link…

They found that, when test subjects are in situations where there are multiple sources of information coming from the external world or emerging out of memory, they’re less able to filter out what’s not relevant to their current goal. That failure to filter slows them down because they are unable to ignore irrelevant information. Frequent multi-tasking, such as keeping up with incoming email while reviewing a document and listening to music, may actually decrease your ability to filter through information later, even when you are not multi-tasking.

A few years ago I attended a course at MIT Sloan on Product Portfolio Management, taught by Dr. Rebecca Henderson. Part of the material Dr. Henderson presented included results from research on engineer productivity as a function of the number of projects the engineer was juggling at once. On reading the recent Stanford research, it struck me that media multi-tasking is probably not that different from juggling multi-project activities, and that proper management of multiple simultaneous projects should include focusing on one thing at a time, as recommended by the Stanford group. The MIT-cited productivity data looked something like the plot below, showing that productivity peaks at about two assigned projects, and falls rapidly away as the assigned projects approach 4 and beyond. It probably goes without saying that the best people on a team will end up with the most projects. If possible, don’t let that number of projects exceed 2 or 3.

Now, back to my other tasks…

Research results on an engineer's productivity as a function of the number of projects they're working on.

What is that “everything else”?

It includes marketing, legal, manufacturing, operations, quality assurance, sales, distribution, customer service, and more.  And if it’s a regulated medical device, then there are also regulatory and reimbursement issues that are critical to the ability to sell a product and that directly affect price points.  Most of these issues need to be addressed prior to or at the same time as the technology development.

At this point of a presentation, I know I’ve lost most of the technical inventors in the audience, because when you say words like “marketing”, “legal” and “regulatory” to technology types, they often hear “wah, wah, wah”.   So I won’t go on any longer.  Just know that if you are undertaking this kind of development, you need to manage far more than just developing technology, and your plan and your team should be ready to address all of these factors.

9. Regional products – More and more companies are being drawn to the large, nascent medical markets overseas, in China and India in particular. If you’re also feeling an attraction to these areas, remember that your current product may not suffice, even if it has been successful in the US and Europe. And we’re not talking about the expected things like software or labeling issues.

   Your product was most likely designed to meet specific stakeholder needs for the regions in which it was developed, including the user interface design, product cost and even the per-use cost. Chances are good that what worked in one region will not work in some of the big overseas markets noted above.

   The U.S., in particular, has distinctively different buyers and/or users of technology-based products than China or India or other developing countries. Don’t be surprised if you end up having to significantly re-design the product for some of these overseas markets to better fit the needs of the local region. Your cost model may have to change completely, and may not work at all. Plan for this…don’t get blindsided. You may even want to find a local product developer in each distinctly different region that can provide input for the design.

10. Reimbursement – Reimbursement is central to the business plan of a majority of medical products. We have been surprised to find that this topic is not better researched by some of our clients.

    We’ve seen more than once where the reimbursement research was delayed, purposefully or not, until some later point in the development program. We’ve seen cases where an expected or planned reimbursement model didn’t work or where existing reimbursement codes were wrong or didn’t apply. We’ve even seen cases where there were no applicable reimbursement codes.

    Reimbursement can have a big impact on per unit and disposable cost targets, as well as the upfront development NRE. Give this the attention it deserves. Proceeding without understanding the reimbursement model adds significant business risk.

I hope you found something of interest in the above… and even something that may help you one day with your future development projects. That’s it for this four-part series, but you may see more of these lessons in the future. Don’t be afraid to make mistakes, just don’t repeat them.

6. Technology Development vs. Product Development – We’ve seen this issue arise more often when working with startups and younger companies, but not exclusively. It has to do with recognizing the differences between technology development and product development. Technology development should always precede product development.

   Tech development is centered on fully understanding how the base technology is going to respond in both the normal and abnormal conditions. This might include the development of algorithms and sensitivity studies, looking at interference effects and confounding factors, error terms, etc.

   Product development is taking the fully understood technology and packaging it in a particular form. Of course, there are shades of grey where they overlap, but the concepts are different.

   The problems start when you try to initiate the product development process before you’ve finished with the technology. Many startups make this mistake. They have looked at the normal range of performance parameters, but have not really studied how the technology will perform over an expected range of operating conditions, much less the extreme conditions with a host of error terms.

   Don’t fall into this trap. Fully develop and understand the technology before you start the product.

7. Stay objective – If there ever was an old adage to follow, this is it. Stay objective and use stage gates with formal charters, budgets and schedules to move from one gate to another. Don’t fall in love with ‘your baby’. It takes passion to manage your product / business, but it also takes a clear head.

   There are usually two types of risk in a new product development project: technical risk and business risk. We use an internal process that manages both in parallel, with a chartered stage gate process. Charters are internal agreements we use for each development step on both the technology side and the business side. The charter includes milestones, schedules and cost limits. This is a formal process attended by upper management…and it can be bloody.

   If you’re not ready or you did not meet your charter requirements, don’t expect charity. If this sounds harsh, it’s only because we learned the hard way how deep of a hole you can dig for yourself if you don’t force yourself to stay objective.

8. Spec creep – It’s a term that we’ve all most likely heard and used…small incremental changes to the specification – surprise additions to your original product spec and feature set. They come from both outside the design team (e.g., sales and marketing) and inside the design team.

   Are they a good thing? Depends on your perspective.

   Are they necessary? Sometimes, but probably not as often as the sales folks want you to think.

   They can kill your projected costs and schedule. The PM needs to be on guard and protective of the design and functional specifications that form the foundation for the product. There is a waterfall effect as the product and project matures. Any changes / specification additions made halfway through a project need to be reconciled backward up the waterfall, as well as from that point forward.

   It can make a mess out of your design documentation and traceability. For all you new PM’s, develop your ‘required’ specifications in one document, as well as your ‘nice to haves’ in another. Get official approval / buy-in and then be ready to go to war. Don’t blink, budge or waver in the slightest. Tell the sales manager he/she can have their added feature as part of a post-launch upgrade kit. If a post-launch upgrade is unacceptable, be prepared to explain, in detail, the budget and schedule impact and risk of the spec changes so that all parties can make an informed decision.

Remember, this is just the third part of a four-part series. Check back later for more on the topic.

3. Identify and Focus on Risk – It may seem counterintuitive, but identify and focus on the riskiest challenges first. There are many phases to developing a new product and the impact of unknown risks grows larger with each one.

   It may look better for the project to start a host of parallel tasks as a means to quickly get started and show progress. Instead, the project team can mitigate or prevent cost and schedule overruns by identifying those high-risk items that might have the biggest impact on the success of the project, even if they’re down the road. If some of the risk items spell doom if not successful, focus on these items as early as possible. Underestimating a challenge here can throw an entire project off-course. Better to understand a problem early, when the design is still flexible. Use your best people. You may take some heat for apparent lack of progress, but you will be rewarded in the end.

4. Know When To Say When – If you’re in a car that is moving fast and heading for a cliff (and you can’t slow down or transform into a plane), get out…even if you have to jump. It is going to hurt, but not as much as staying in the car.

   We’ve been involved in projects when we didn’t heed this advice. One in particular comes to mind. The cost of the raw materials in the BOM was essentially the desired selling price point. The feature set was considered locked… no changes (reductions) were allowed. The project NRE costs were already over budget and climbing fast. Many man-hours had already been devoted trying to devise imaginative solutions and the client was unable to make rational decisions that could have mitigated the impending disaster. There was no plan going forward.

   The cliff was in sight and we couldn’t control the car. We thought we could help mitigate the crash if we stayed involved. In hindsight, it was time to jump… but we didn’t. Sometimes it’s just as hard to hear bad news as it is to say it (see #2); jumping can be the only way to send up the red flare that something is wrong.

5. Don’t V&V with Early Stage Prototypes – Avoid the desire / tendency to start pre-clinical performance tests or verification and validation (V&V) before you have pre-production prototype devices with sufficient design controls and manufacturing pedigree. These devices need to use the same materials and manufacturing processes that will be used on the actual production product, at least for all critical aspects of the product.

   We have been pressured to start with earlier prototype versions and then reconcile (post-development) all non-production quality issues. This can lead to significant problems if your reconciliations are called into question or if there really are crucial differences between the prototypes and production units. One simple but classic example is when you have rapid prototyping plastic parts. For the most part, they will not stand up to the rigors of environmental testing.

   Granted, this still demands judgment since you wouldn’t ramp up to full scale production (with hardened steel tools) for V&V. At a minimum, define the critical parts and features of the device that need to be made with the final materials and production processes and go from there.

Remember, this is just the second part of a four-part series. Check back later for more on the topic.