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.

In the world of new product development, protecting confidential information is vitally important to the success of your business. Time to market, competitive advantage, and even cost competitiveness can hinge on your ability to keep your information private while you conduct research and develop a product. Here are a few ways we protect confidential information during our product development process.

Need to Know Basis / Trade Secrets

It may go without saying, but the easiest way to keep your information confidential is to not tell anyone. This is referred to as a trade secret and works particularly well for things that cannot be easily reverse-engineered, like embedded software code or a process formula. The onus is on you to keep your secrets, but they can last forever (like the formula for Coke). When you have to work with outside developers or vendors, you can give them only what they need to build your part. Without the context of other components or the overall product, it’s less likely someone will be able to tell what is actually valuable about your overall product or concept.

Patents

Registering your idea with the US Patent and Trademark Office can actually be fairly cheap and easy, for the first year. It can cost around $1,000 to file a preliminary patent that then allows you one year to file the formal application. However, this registration gives you the registered invention date that can help you prosecute anyone that steals your idea.

The Non-Disclosure Agreement

Depending on the complexity of your product and situation, you may need to provide others with information that is actually confidential. To protect yourself, you can execute a non-disclosure agreement (NDA) between yourself and the person or company you’re working with. The NDA is an agreement that, among other things, lays out the obligations for protecting and handling confidential information. It can be one-way (protecting just your information) or mutual (allowing both parties to share confidential information). If you’re working closely with someone, the mutual NDA may make it easier to communicate ideas back and forth. However, if you’re only supplying fabrication drawings or you don’t want a vendor to give you anything confidential (that you then have an obligation to protect), you may want to just stick with a one-way agreement.

A quick online search will yield a number of template NDAs that you can download for free and modify to fit your needs. Any NDA should include various obligations to keep confidential information private and protect against either party using that information in competition. There are a few topics that we think are important in these types of agreements:

1. Put a time limit on how long confidential information has to be protected. You don’t want to be required to protect someone’s confidential information forever.
2. Specify that all ‘confidential’ information is to be identified and marked in writing to identify it as such. Things can be identified orally as being confidential, but must be followed up in writing within a reasonable time period. This is particularly important when multiple engineers are hopping on and off the project, and since our memories aren’t what they used to be.
3. Any trade secrets must be specifically identified as such before transmission. They are unique since they can last forever…remember that if you decide to accept receiving one from others.

Keep it secret, keep it safe

Ultimately, it’s your obligation to keep critical information safe and secure: limit who knows what you’re doing, protect what you have with patents and/or trademarks, and consider an NDA when appropriate. Work with developers and vendors you trust, but get the NDA anyway.

Photo credit: Oliver Gruener

Disclaimer: I am NOT a lawyer and strongly urge you to seek professional assistance if you think you need to protect or handle intellectual property (IP). For what it’s worth, I do not consider anything in this article as confidential or proprietary…feel free to disseminate in any form…although I’d appreciate a little credit if you do.