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.