There are many ways to successfully develop new and innovative product solutions. Projects can be oriented to meet a clinical need via a new technical approach or better satisfy a business opportunity. They can make previously unavailable treatments a reality and previously unaffordable treatments more common. No two product development programs are alike, but great innovation and product development efforts share certain characteristics and best practices. Likewise, failed development programs often share structural similarities and mistakes. Development teams must learn to emulate the positive and minimize the negative for the best chance of success.

Successful programs depend upon a firm foundation and a reasonably clear view of what constitutes success. Without these, even the most creative and committed development team will be hunting in the dark and likely doomed to fail. If the following criteria aren’t in place prior to starting a development program, it’s better to delay the start of the program and use a smaller team to finish laying the groundwork.

• Establish functional and clinical effectiveness criteria
• Identify anticipated human factors challenges and opportunities
• Imagine and envision an optimum user experience
• Study competitive products, including strengths and deficiencies
• Generate a detailed project schedule based on past experience and anticipated difficulty
• Ensure sufficient resources in terms of people and funding
• Have a qualified sense of the business environment and eventual sell price
• Generate a list of potential use hazards and risks to success
• Have a clearly established regulatory submission strategy

Innovation vs. Invention: Know the Difference
Invention implies discovering some previously undemonstrated function and often involves researching significant unknowns and gaining a new understanding of how things work. True invention is nearly impossible to predict and usually takes years to discover—and even longer to commercialize. Invention is usually limited to a component or function. For instance, lithium used in batteries has been an extraordinary invention leading to many previously impossible products.

Innovating, on the other hand, uses existing parts, methods, or software in a novel way. The process is as creative as invention; existing resources are used unconventionally. Like inventions, innovations can produce powerful patents to help ensure the product’s success. For example, a battery-powered vehicle is largely composed of pre-existing elements (like lithium batteries) combined in a novel way.

The design team for most development programs must be innovative, not inventive. A development program typically focuses on commercializing a novel approach to a clinical treatment and improving its outcome or business model. There may be underlying inventions in the approach, but inventing should end when development begins. Product development aims to get a high-quality, reproducible, and cost-effective product to market. A development program’s schedule, budget, and risk profile can’t afford the uncertainty of invention.

Put innovation in its proper place. Although it sounds great leaving an entrepreneur’s lips, designing a “cool and innovative” product isn’t a legitimate objective in the medical device field. Everything a development team does for a new device must be soundly reasoned and justified. This is clearly directed in the FDA-regulated design control process, but is also common sense. Innovative design features that user studies have shown as helpful are great, but some companies—especially startups—have the tendency to pursue “cool” features that don’t improve the product and perhaps overcomplicate it. Be wary of contradicting a clinical procedure or clinical field’s common use pattern paradigms.

Follow the ever-tightening helical design spiral. Multiple parallel but interdependent paths of work effort occur during a development program—including engineering, human factors and industrial design, quality planning, regulatory planning, and intellectual property concerns. In the beginning, these may work independently. But as decisions get made and the design takes form, changes along any of these paths may significantly impact overall success and viability. Most phase gate development processes understand this—there are occasional multi-disciplinary review points to ensure the success criteria are still in view or, if not, to adjust the project’s plan and balance.

Iterative vs. concurrent design approach—use the right one at the right time. Virtually every management book proclaims concurrent development’s power. There are good reasons to pursue concurrent work paths wherever possible, but when a significant risk or design impediment appears, the team may be justified in halting everything else until its resolution. Ideally, these “go/no-go” moments are already resolved when the development team receives the assignment. However, no project is perfect and sometimes it’s impossible to responsibly pursue a concurrent approach with a looming existential design threat. It’s better to temporarily pause non-threatened paths than pursue work that may need to be unraveled to resolve the issue. Nothing focuses a team like collaborating on the iterative problem so the program can resume.

Pursue “Plan B” paths to manage risk. Always have Plan B concepts or activities in place, especially during early concept generation and feasibility testing. Sometimes a carefully considered, innovative, and promising solution fails on some key criterion. It pays to pursue secondary solutions when the primary path includes significant unknowns or unproven concepts. There are several benefits to this conservative approach. An unexpected benefit is that the Plan B design may exceed the original, preferred solution or generate intellectual property to claim and defend against competitors. If the original design approach should fail, it can save months of delay due to starting from scratch. Of course, secondary or tertiary solutions can be moth-balled once it’s clear the primary solution will succeed. 

Open-mindedness—great product design needs it! Extensive experience and education are never bad but can sometimes lock a team into a “familiar territory” box. Experience certainly helps a team travel the development trail with less trouble or potential for significant errors. However, take care when jumping to the obvious solution. During early development stages, purposely trying to make alternative ideas work better is good practice. Asking “why” and “what if” helps challenge preconceived notions and reveal blind spots.

Know what you don’t know. Finding holes in one’s own plans can be difficult; humans are wired to notice errors, not omissions. A development team—no matter how innovative and diligent—is limited by collective knowledge and experiences and whatever it can learn about particular project objectives. If a team embarks down a path none have traveled before (a new technology or regulatory status or uncertain costing implications), it should list out what assumptions are being made and critically examine them to detect unacceptable risks. Engaging subject matter experts can be helpful in these circumstances as they may have experience and perspective the core team lacks.

The many faces of compliance. Design control compliance is not a new idea. It’s an essential part of the medical device development process and the requirements are clearly spelled out in FDA’s Code of Federal Regulations and the EU’s Medical Device Directive (soon to be the Medical Device Regulation). However, when to turn on the compliance tracking system and how much to add to a Design History File are still open for interpretation. During concept exploration and feasibility work, it’s clearly good to capture general ideas, their reasoning, and at least some of the data collected so a storyline can be attributed to the design’s genesis. As the program matures into engineering specifications, risk management documentation, and test reports, maintaining formal design controls becomes essential. Hopefully it is clear and obvious that waiting until the end of development and then “back filling” compliance-related documents and retroactively compile a Design History File can be very risky, expensive, and time-consuming. Startups risk getting this balance wrong by being too lax. On the other side, large multinational corporations can be too rigid too early.

Adjustments to the team and service providers. Product development resembles an elite endurance sport. It requires brains, skill, training, and significant grit and determination. During the development cycle, different skillsets and perhaps a different scale of effort and resources will be required. As in many sports events, specialists concentrate on particular work areas. They enter the project for a time, do their thing, and move on. There may also be team members better suited for early concepting work or later detailing and testing work. The team structure should adjust as needs arise. Likewise, different service providers may be used for certain development cycle aspects. Ensuring the team always has the best “players on the field” is important and the management team’s key responsibility. When changing team members, make a dedicated effort to ensure knowledge transfer of key design intent elements.

Maintain a sense of urgency, but avoid panic. This speaks more to culture than management technique. A team with a unified sense of urgency will collaborate efficiently toward their goal. As project management books relay, the model for urgency and devoted purpose comes from the top. Teams must see their bosses sharing their commitment to success. They will gain energy from seeing leadership taking an active interest in their work, especially if they see their managers investing time to understand what they are up against and advocating for their needs. Of course, deadlines may be missed due to something out of the team’s control, but this is common to life and should be resolved without undue drama.

On the flip side, a pervading sense of panic and doom is never constructive and must be resolved with an “all hands on deck” response. It usually occurs when a team strays from the original objectives or discovers a risk late in development that may be difficult to mitigate. Panic ensues when there seems to be no hope for success or when foundational issues that should have been dealt with at the beginning are discovered at the end of a project. The project, jobs, and the company’s future may all be at risk then, which can get team members running for the lifeboats. Hopefully, some of these suggested practices and advice help avoid such despairing circumstances. 

---

David C. Robson, a principal at Robson Advisors, has spent 30 years concentrating on medical device development. Seventeen of those were spent working for a full-service product development firm where he interacted with both large and small medical device companies and reviewed statements of work and requests for quotation, wrote proposals, and negotiated hundreds of work agreements. Robson and his partners now offer product development guidance and advocacy to early-stage medical device clients.