Here's an innovative recipe for shaking up the medical device product development process.

Andrew Hyncik

When it comes to new product development, medtech companies are facing ever stronger headwinds. From higher regulatory hurdles to pricing pressure, or from talent shortages to the need for greater clinical validation, the prospect of shortening development cycles looks bleak.

That is one way of looking at things. Another way is to see an industry ripe for change or even disruption. After all, innovation doesn't apply just to how medical products work, it can also be applicable to how they get developed. 

Companies that are successful in changing how their products get developed stand a greater chance of reaping the rewards through increased speed to market, faster response times, and superior designs. Obviously, there are no magic bullets, but there are healthy practices which can significantly improve the odds of success. Here are a few which stand out for me:

Focus, Focus, Focus 

Be very clear upfront about what your product is intended to do, what benefits (and claims) it will offer and for whom. Don't try to please everybody, as this is perhaps the surest way to over-complicate and delay a release. This may require focusing on the needs of just one key market/region at first instead of designing for a global product right from the start. Above all, avoid scope creep. Lastly, product managers need to be 100% clear on what they absolutely need (with detailed priority lists) so that when the time comes to cut out costs/features to save the schedule they can be better prepared. Remember the old adage: "Don't bring a knife to a gunfight."

Design to Cost

Define your target price/cost and stick to these. Only deviate if there is compelling evidence and if the steering committee approves. Runaway costs and over-engineered products are far too common in medtech.

Embrace Agile Principles

Waterfall and V-model cycle development may be well-accepted processes but they are looking tired, excessively rigid, and increasingly outdated. Embrace any development approach which fosters rapid feedback cycles, informal vs. formal structures, visual vs. written planning, frequent but brief team meetings, new communication tools & sharing platforms, and parallel vs. sequential work.

Get Key Internal Stakeholders Involved Early

From the very onset of a project, all key groups need to be represented and involved. In this day and age and in addition to the usual suspects (marketing, R&D, finance, quality assurance, manufacturing, and purchasing), this should also include: clinical (for any trials/clinical claims), regulatory (for registration strategies and intended uses), risks (for hazards, mitigation, and testing), IT (for connectivity & cyber security issues), human resources (for staffing and special hiring needs), user experience (for the user-centered design and the overall product experience) and legal (for intellectual property and compliance).

Create Dedicated Project Teams

Placing key individuals across multiple projects can be a recipe for disaster. Better to have fewer, smaller, and dedicated teams than to have many large teams where everybody is partially involved and therefore, only partially committed to the outcome. Don't forget to also have clear lines of accountability. In larger teams, this can get diffused.

Invest in Early Prototypes and Demos

It's been said--and I wholeheartedly agree--that a working prototype is worth 1000 meetings. A good demo or prototype is the best way to get good and early user feedback/validation and to rally the development teams. Agile also feeds nicely into this as it can quickly get you working on a product or limited feature sets that you can show to your customers.

Create a Panel of On-Call Experts

These are the users, key opinion leaders (KOLs), or clinical experts that you can turn to on an almost daily basis with any feature, design, or usability questions you may have. Find people who share your vision and passion and who are good communicators. They can also be your internal ambassadors and bring context (i.e. the "why") to internal development & management teams. Better yet, get one or two top KOLs to act as project sponsors and attend project milestone reviews.

Plan for "Torture" and "Monkey" Testing

To avoid unpleasant surprises--which usually come after launch--bring a steady stream of product users & non-users to attempt to "break/abuse" the product in any way imaginable. These non-scripted "testing" sessions can be remarkably revealing and can save a lot of pain down the road.

Conduct a Limited/Controlled Release First

Don't go out with guns ablazing the minute you have your 510(k). Give yourself at least 1-3 months to work out any real-world kinks and bugs with a handful of friendly customers. Plan on a couple more iteration cycles after product release to address unforeseen bugs or issues. Be mindful not to immediately reassign the entire development team to a new project once you have released. There needs to be some transition time between the development and legacy/sustaining team handoff.

Get the Entire Development Team Exposed to the Users and Their Environment

Meeting with customers/users and visiting customer sites should not be the exclusive realm of product managers. Every team member, including engineers and testers, should be exposed at least once to the users in their environments. This is essential to help them gain a deeper understanding of what the project is about and who it is ultimately for. Connecting all project members to end users and to what is at stake has an incredible effect on team morale, productivity, and energy. This sounds simple, but you would be amazed at how many engineers I have met on projects who have never even set a foot inside a hospital.

Continuously Seek Internal Alignment

Management regularly changes, requirements get updated, and project members come and go. Over time, people and strategies can drift apart. That is why it is imperative for project teams to regularly seek and reaffirm alignment from all key departments and stakeholders. Without internal alignment, failure is almost guaranteed.

Conduct Lessons Learned Exercises

Regularly conduct audits, surveys, and debriefs to understand the things that worked and didn't on a project or during a particular phase. Out of these, seek to find new ways to improve internal processes. Black belts are great at this sort of stuff. Develop your own internal Six Sigma ninjas or hire some outside experts to help if necessary. Also, assign change owners and create reward systems to encourage continuous improvement of development processes.

Stay Close--Very Close--to Your Customers and Patients

Yes, it sounds like a cliché, but so few companies do it well and do it consistently. Travel budgets are the first things to get cut and field research is usually more frontloaded on a typical waterfall project. Product managers should spend at least 20% of their time year round visiting customers and observing patients and users. Attending trade shows doesn't really count. You have to be in situ and in the clinical context to really gather meaningful insights. The big answers to tricky questions are seldom found in the office. You need to get out there to discover them. Any findings or trip reports also need to be promptly shared internally so that everyone can benefit.

In medtech, every day is a competitive race to the finish line. Companies that are able to adopt new work methods and to continuously readjust how their products get developed stand a significantly higher chance of winning in the market. It starts with an open mindset and the determination to find and refine best-in-class methods.

Got any best practices of your own? Share them in the comments section.

Andrew Hyncik is an International Strategic Marketing & Product Development veteran with 20 years of experience in the medtech, healthcare, and pharma industries. To read more from Andrew Hyncik, visit or subscribe to Parifornia.com: Insights in international marketing and business.

[Image courtesy of HYWARDS/FREEDIGITALPHOTOS.NET]