Managing medtech stakeholder expectations is an important element of medical device development success. Investors, Internal stakeholders, KOLs, Clinicians, Scientists and Engineers will all play a part in shaping and delivering a successful medical device. We asked key members of our team to share their best tips and lessons learned. Here are 8 tips to manage medtech stakeholder expectations from our engineers, regulatory and quality assurance, and system engineers, and project managers.

Create a Vision to Meet Investor Needs.

Collateral for investment purposes often involves choosing between a functional prototype or a great looking design. In early stages with short timelines and low budgets, it may not be feasible to have both. It’s important to have alignment on the investor priority. They may love the look of it, but creating a prototype and having it function as well as it looks are two different things.

The Benefits of Looking Good.

It’s good to create a vision of what the product eventually might be. Oftentimes investors or KOLs find it difficult to translate benchtop technology jammed together to prove a principle into a finished device. Connecting the dots from benchtop to what it might become is challenging without constructing a really clear and attractive vision. The way that journey is communicated is also critical.

Take wireframing as an example. When developing an early user interface, one strategy is to create a wireframe using a font like Comic Sans that looks “prototype-y”. Some audiences will understand that a wireframe allows one to go through all of the steps and try out the user interface. Because it looks prototype-y and feels prototype-y, they do not assume the interface is functional.

Others don’t like that model. They want something that looks pretty and polished. The lean startup model considers making things look nice as something to consider a priority later on. However, sometimes investors don’t pay attention until a prototype looks really nice.

For technically oriented investors, a wireframe is more appropriate because they understand the technology better. Whereas business oriented investors often find a finished or polished prototype more appropriate.

Investor-wise, it’s nice to have a mockup that provides a vision, direction and inspiration. As long as you communicate that it is a design concept, a mockup will help guide development of a similar property later on.

Identify Your Stakeholder(s).

Stakeholders with a background in product development speak the same language as engineers. If their background is in science, they’re going to be a little bit different. Engineers typically think of requirements as targets with pass-fail criteria. If a target price is $100 and the engineer doesn’t think that they can meet that target, it’s feels like a failure. Whereas, for scientists, the reaction is likely to be, “Are you in the ballpark, or somewhere close to $100? $150?” That’s acceptable, but in engineering terms, it’s not.

Clinicians, who are accustomed to using medical devices all the time and are often familiar with the finished product, may not understand or care about all the steps required to go from nothing to a finished product. In the wireframe example above, they did not understand the wireframe, but as soon as it was dressed in a representative image of the medical device, they responded “that looks great”.

Product or Technology Readiness Can Be Hard to See.

Sometimes a stakeholder wants a totally honed production ready device. And other times they just need enough for a clinical trial or a small batch build. Communicating the device readiness is important because it is not always apparent by visible inspection.

A prototype in alpha and beta and a pre-production unit can look almost identical, but one may be using cobbled together software or a Data Acquisition System embedded in the middle, off the shelf devices or prototype methods that are not intended to go into production. It is really important to communicate where the project is in terms of product or technology readiness.

Be Transparent.

Transparency and communication develop trust and confidence with stakeholders. They are a very important factor in the success or failure of a project.

It might seem easier in the short term to do many things quietly on the side or behind the scenes. That works great until things start to go wrong. Then being more forthcoming and bringing everybody along for the ride will seem much smarter. That way stakeholders would have seen the entire effort it took to get the program to its current state, including all of the things that went really well. In other words, transparency is not just the bad news or the good news, but lots of news. Transparency tends to pull difficult conversations up sooner. Start talking about issues as soon as the speed bump appears in the horizon rather than when gaining air flying over it.

Always Watch Out for the Scope, Schedule and Budget.

Use a project charter for transparency from the beginning of the project. Outline scope, time, budget and quality. It’s great to do this at the beginning and keep updating the charter as the project evolves, because priorities often shift or change. Make a Project Charter and keep reviewing it using lots of transparency and communication.

Establish true ownership of roles and deliverables. Sometimes one assumes the other party has something covered because they said they did, and then they don’t. That goes both ways. Keep the project charter green. “Do you truly own this? Are you on track of that?” That’s important as well.

QMS, QMS, QMS.

Define detail for QMS roles and responsibilities. When a project includes “510(k) submission”, what does that mean? Who is going to create the DHF and what things will it include? Who will create a regulatory submission from the DHF? Identify and then list assumptions.

Project Needs Change Over Time.

Deliver and deal with immediate need, but also plan for things you expect might be needed later. For example, startups often need specific collateral for fundraising or to satisfy a financial milestone commitment. Delivering that need is key, but once these initial deliverables are provided, it’s important to identify and understand future program needs. These usually relate to things delivered initially. IE, if a concept image and ideation are needed for an early milestone, a future step will be adding rigor around actual architecture and human factors risks.

We hope our tips to manage medtech stakeholder expectations will help you avoid pitfalls and navigate your medical device development successfully. Did we miss any tips you have identified? Our engineers, regulatory, quality assurance, system engineers, and project managers would enjoy hearing from you.