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”.

If you’ve had even the slightest inkling of initiative but have been stifled by fear or doubt or something else, I recommend reading Seth Godin’s new book, “Poke the Box“. It might give you the push off the branch you need to really fly. It’s well-written and a quick read. It’s really his manifesto calling people to action with the thesis that everyone can be innovative. Well, not everyone, but innovative people can exist anywhere, from those with authority over a Fortune 500 company to those with barely authority over the mail room. Your job description doesn’t matter. Initiative and the ability to overcome fear is what matters.

Poke The Box from Seth Godin on Vimeo.

Have you read the book, yet? What did you think?

When connected to two dissimilar metals (such as copper and zinc), the lemon transforms into a battery, producing a small voltage potential.  A new found use of lemons is discovered, much to the delight of kitchen scientists everywhere.  For us here at Key Tech, it illustrates the positive use of a usually avoided event: Galvanic corrosion.

The process: break it down

Galvanic corrosion occurs when dissimilar metals are in the presence of an electrolyte, such as salt water (or citric acid in the case of lemons).  One metal forms the anode and the other metal forms the cathode. The anode is more active (less corrosion resistant) and the cathode is less active (more corrosion resistant). When they are electrically connected, a current is produced which causes a change in the corrosion properties of the metals:

• The more active anode corrodes faster than it would by itself
• The less active cathode corrodes slower than it would by itself

These metals must be in electrical contact and they must be exposed to an electrolyte. This type of corrosion will not occur if the metals are completely dry or electrically insulated from each other. Galvanic corrosion is a common enemy of ship builders, but this destructive process is of interest to any designer where metals and alloys interface, such as at fastener locations.  Material choice as well as surfacing options become critical at these junctions for the life and structural integrity of the system.

Welcome to the Galvanic Series (in seawater)

For those of us who love tables, galvanic series were developed to list metals and alloys based on their corrosion potential in a specific electrolyte.  In seawater, these materials are listed from most cathodic (inactive/resistant to corrosion) to most anodic (active/ease of corrosion).  The further apart the metals/alloys are in a particular series (thus the most dissimilar they are), the higher the risk of galvanic corrosion.

Least Active (Cathodic)

• Platinum, Gold, Graphite, Titanium, Silver
• Stainless Steel (passive)
• Brass/Bronze
• Stainless Steel (active)
• Chrome
• Nickel
• Steel
• Aluminum
• Zinc
• Magnesium

Most Active (Anodic)

How to prevent or minimize galvanic corrosion

• Choose metals close together on the galvanic series for mating parts and fasteners.
• Never place a small area of active metal on a large area of inactive metal (e.g. a zinc-plated fastener on stainless steel part).
• Use coatings or other means to prevent electrical contact between parts:
  • Anodize
  • Chromate conversion (iridite)
  • Phosphate
  • Electroless nickel
  • Paint
  • Lubricants
  • Insulating tape
  • Non-absorbent washers
• Use a sacrificial anode (e.g. galvanized steel)

Rules of Thumb: Know Your Environment

Where the metallic components will reside should be considered when designing your overall system.  The Anodic Index can be found here.  These anodic index values provide the comparison needed when deciding what type of fastener material to use in your designs to prevent galvanic corrosion.  The basic rules of thumb are (taken from corrosion-doctors.org):

• Harsh Environments (outdoors, high temp, high humidity): the difference in Anodic Index should be less than 0.15V
• Normal Environments (storage warehouses or non-temperature and humidity controlled environments): the difference in Anodic Index should be less than 0.25V
• Controlled Environments (temp and humidity controlled): up to 0.50V difference in Anodic Index can be tolerated

A couple great resources for more detailed information on this subject are the ASM Metals Handbook (Vol 5 and 13) and “Handbook of Corrosion Engineering” by Pierre R. Roberge (2000).

Read more about the symbiosis of modeling and prototyping (PDF) for designing microscale parts in an article I wrote that was published in MICROmanufacturing Magazine this month, page 33 (Jan/Feb 2010, Volume 3, Issue 1).

You can read the article in the Summer 2009 printed publication or catch it in the online version, Meeting the challenges of micropart design.

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.

Thinking about these two milestones, I found myself strolling down memory lane. As a company, we’ve done lots of things right…and we’ve had our share of really phenomenal screw ups. One the things we recognized early was the value of our mistakes. We didn’t try to hide them, bury them away or ignore them. We put a spotlight on them…not to embarrass or deride, but to leverage a bad thing into something that made us stronger. We collect and document them in a database and regularly make presentations to the company with the message of ‘here is how bad this hurt me…don’t let it happen to you’. Call us weird (and we are), but our engineers really value and appreciate this.

In tribute to our 10 year anniversary, I thought others outside of Key Tech might like to hear some of our more colorful screw ups. So I put together a four-part series of what I think are some of our best. I hope you find something of value.

“The only real mistake is the one from which we learn nothing.” – John Powell

1. Keep Critical Members of the Design Team Involved Through Production – We were working on a project for an outside client that had a host of small complicated parts that were going to be injection molded in multi-cavity tools. We had just finished a successful demonstration to management of some one-off prototypes and were starting discussions with the client’s manufacturing people regarding design for manufacturing (DFM). The client’s management team was happy and decided to accelerate the turnover of the design from our external design team to their internal manufacturing group, thus ending our involvement in the project sooner than anticipated. We had formal design reviews and test reports, drawing packages and turnover meetings, but ultimately there are always details that are hard to capture and communicate. After our involvement ended, there were problems with the ramp up, which lead to cost and schedule problems. Ultimately, it reflected poorly on us.

   The lesson we learned is that critical personnel from the design team (whether internal or external) need to stay involved and be accountable through prototyping, design for manufacture, ramp-up, and even into production. The design team needs to know they aren’t done until the production manager is happy.

2. Manage Expectations and Bad News – Despite the efforts of the best design teams, there will be surprises and bad news during new product development, including a development schedule that sometimes slips. Don’t try to compensate or hide it when it happens. Nobody wants to report bad news, since we feel it reflects poorly on us. Sometimes, we try to sugar coat it or solve the problems off-line or, worse yet, just hope for the best… that the problems will eventually be resolved, that development costs will magically come back down, or the schedule will somehow find a missing four weeks. Rather than resolving, the problems more typically snowball. The younger engineers and PMs are particularly vulnerable to this mistake, but I will admit to falling prey as well.

   Problems will happen…and are even expected to happen. Manage expectations and communicate problems as soon as they manifest themselves. It will be appreciated by everyone.

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

There are many ways to lose focus developing a new product, especially with so many people involved and so much at stake. By taking a disciplined approach, one can avoid many of the common pitfalls that cost money and cause delays.

1. Develop a realistic schedule and stick to it. Always keep the critical path in mind and avoid letting non-critical path items slow down the project.
2. If possible, secure sufficient funding to complete development with some extra padding to cover the unavoidable things that come up. While the product development is best done in phases, raising funding in stages is often very inefficient and more expensive because the development team loses momentum if the timing is off.
3. Develop a comprehensive specification up front and be disciplined about preventing spec creep throughout the project.
4. Obtain voice of the customer (VOC) input very early in the project, since it will focus and define the feature set outlined in the product specification.
5. Perform market research prior to embarking on the development. Developing the marketing plan late in the game inevitably leads to costly last minute changes to the product.
6. Select the development team carefully, ensuring that members of the team communicate well. If outsourcing only a part of the development, make sure that part is very well defined and verify that the outsource partner has a full understanding of the requirements.
7. Prepare a detailed project plan that identifies the overall schedule with stage gates. The plan must clearly define the criteria necessary to pass each stage gate.
8. Identify the high risk aspects of the development and address them first in the project plan, before the bulk of the work gets underway. Wasted work equals wasted money.
9. Line up manufacturing partners as early as possible and involve them in the design process – include them in team meetings, design reviews, etc.
10. Communicate, communicate, communicate. Weekly team meetings often seem unnecessary, but keeping everyone on the same page throughout the project will reduce expenses in the long run.
11. Reduce the risk of safety and environmental testing by considering it early in the design.

This list goes to 11!

Photo credit: H Assaf