Startup Medical Device Project Lessons Learned

From time to time, I like to share some lessons learned from current projects. We are in the middle of product development for a medical device startup project and have plenty of recent lessons learned to share.

In no particular order—

Dates Are Wrong

We all know this. Yet there is also a compelling need to drive towards completion of tasks. Does having a due date help or hurt? I can find plenty of people to support either argument. I don’t like dates anymore than the next person. But at the same time, my opinion is that without a target date for completing a task, a task could linger.

Of course if you are surrounding with people who are checklist oriented, accountable, and driven towards getting things done, dates probably don’t matter all that much.

However, I have rarely been involved with any initiative of any kind where all people involved were wired in this fashion. Because of this, dates are a necessary evil.

A trick as a project manager is to figure out each person’s buffer. I often refer to this as a “fudge factor” (I know this term was ingrained in my brain somewhere along the way; I just can’t remember when or where). What I mean by this is in my experience, when prompted to provide a date, most people will give you a best case scenario response. The challenge is to figure out how far off their best case is from reality. You won’t learn this initially. You will have to let the person give you false information a time or two first to establish their particular fudge factor.

Hierarchy & Order Are Important

What I mean by this is that it is important to have a process in place and to follow the process. I think this is especially true when startups are mostly virtual and rely heavily on suppliers. Some suppliers may have process in place. Others may not. To complicate it further, each supplier might have a slightly different process too. In all cases, it is important to establish at the beginning what process will be followed. It is important to outline and identify the specific deliverables, along with when each of these deliverables is to be accomplished.

Scope Creep Will Happen

Despite your best efforts, scope creep will happen on every project. To expect that you can clearly and completely articulate, communicate, and establish a scope of work at the beginning of a project and that this will not change as the project progresses is unrealistic.

Rather than resist scope creep, figure out how you can manage it. The most challenging scope creep issues pertain to the expectation that the budget and timeline won’t change. Scope creep, more than likely, will affect both budget and timeline. When a scope change is suggested, take a moment to evaluate what this means to the project and communicate this to the stakeholders.

Double Check Always

You would think I would have learned after the first few times a resource told me a task was done only to find out otherwise that I would have started double checking sooner. I mean, come on, I’m working with adults, right? When someone tells me they got something done, I should expect that it is done. Yes, that statement is true. However, it’s also true that people don’t always complete what they say they’ve done. I think this is because the person expects they will get the task done before you actually find out.

I now will do my best to always double check and to get objective evidence that a task is done.

Have a Back Up Plan Brewing

You never know when you will need a back up plan. I can tell you from experience numerous times on this project that developing a back up plan after it’s already needed is not fun. Yes, I want to trust all the resources I’m working with. However, this project has taught me that I always need to have a back plan in the works, just in case.

 

Project Schedules Are Wrong

As a project manager, I have a love / hate relationship with project schedules. Yes, it’s true that nearly every project I’ve ever worked on had a due date assigned to me before we even started the project. And as a project manager, I hate this. Because in those circumstances, I have to craft a project schedule that gives the assigned due date as a feasible option. You could argue that I’m doing myself a disservice and setting false expectations by taking this approach. This practice could give the stakeholder an incorrect assumption about the ability to actually achieve the due date assigned. Perhaps. And at the same time, not providing a project schedule with this approach also gives the impression that the due date assigned is not a possibility.

Let me expand by discussing an ongoing medical device product development project. This project started in December 2012. Prior to starting the project, I met a few times with the startup CEO. In previous discussions with others, he concluded that his device idea could be launched into the market within 6 months of starting product development. I asked several questions and advised the startup that 6 months was not realistic; a FDA submission would be involved and that alone could easily take 6 months. As a counter, I suggested that his project would likely take around 18 months. He challenged that notion, craftily talking me through the phases. I knew what he was doing and played along. At the conclusion, the startup CEO decided the project should take about 12 months. Realistically, 12 months was actually possible.

Possible, but not likely. I highlighted a few of the unknowns. It didn’t matter. We started in December 2012 with the CEO expecting to be ready for market launch by December 2013.

It’s February 2014, and we have not had market release yet. We are still a few months out but getting there. There have been lots of twists and turns along the way–all in the spirit of this is how product development goes. And of course if we had the foresight that an issue would happen, we would obviously address, mitigate, and prevent the occurrence.

Project schedules are perpetually changing and always wrong. Always. A project effort of any size with more than one team member is chock full of numerous variables and unknowns. So are project schedules really necessary? A potentially interesting question. One that was recently posed to me by project team members on another product development project.

I have been screaming for visibility and commitments on when project tasks would be completed. One of the first major issues on this project is a lack of centralized project management. Yes, it’s a startup and theoretically, each of the team members is motivated to get the job done. However, having no one assigned to project management is starting to become an issue, in my opinion from my perspective. I recently challenged the other team members to provide a target date of when a few of the major milestones would be completed. The project team members pushed back hard. Their main argument is that there are three major factors involved in their product development efforts: quality, speed, and cost. They pushed and told me to pick two. If I want it fast, then the quality would suffer.

But I wasn’t necessarily asking for speed. I was simply asking for a target–a schedule. More pushing with a response that they could not commit to any meaningful, realistic schedule. They cited some case studies from a large company who has been through product development thousands of times over the past 50 years. Okay, I understand that providing me a schedule means the dates will be wrong. However, telling me you have no idea of when I could expect a task is also wrong.

What is the happy medium?

Medical Device Perfection – Is It Possible?

Medical device perfection is a matter of perspective. And ensuring your product development team has similar point of view and perspective for your medical device is very important. I think it starts with the vision of the device. It also pertains to what you are trying to achieve and when you are trying to achieve it.

Perfection. Probably not a good choice of words. I’ll try to explain through a short story based on a current medical device product development project.

We are in the midst of a electronic medical device. Without getting into too many specifics, the device is class II. It has a custom designed PCB with embedded firmware (along with a few other electronic components). The electronics are contained within a custom designed enclosure. The device mates with single-use disposable components. We are approaching design verification and gearing up for system testing. But lately, we’ve kind of been chasing our tail (and not catching it) on the design. The device involves measuring pressures. The hardware / firmware resource provided a prototype advertised as ready for testing a few weeks ago. The prototype was delivered to the startup for testing. Within a few hours, the startup put the brakes on stating it was not ready. There was a short list of things to address, and the unit was sent back for tweaks.

A week or so later, the tweaks were made and the unit was given back to the startup. A day later, the startup said it still was not ready.

This happened another time or two until last week. The team sat down face to face to review the prototype. The prototype had all the latest tweaks and adjustments. The startup still had a few issues. The hardware / firmware resource took the device back to make the few minor adjustments. Once completed, I picked it I picked up the device. I walked through it, ensuring the features and functions were addressed. Satisfied, I delivered it to the startup. Within a couple hours, the startup called saying it still was not right. I was stumped.

I dropped everything I was doing and headed to pick it up. I walked through the device again. I felt as though it worked as intended. I decided to bring it home and test it for a few days. I confirmed the device works. Yes, I found a few bugs. But the device works. I let it run for over 2 days. I ran the battery down a couple times. I plugged it in. I changed settings. I communicated this to the project team. We had a meeting earlier today to discuss and review. Prior to the meeting, I hoped we would initiate some performance testing today.

The startup thought otherwise. They listed all the features and reasons the device is not ready. I reiterated that the device works and could be tested further–NOW–to verify performance. It was clear, though, the startup wanted a perfect device before starting testing.

I bit my tongue. During the drive back, I racked my brain. Eventually with my thoughts gathered, I had a chance to chat with the startup CEO. I shared my point of view and opinions. He then stated his: let’s continue moving forward. The near term goal is to prepare a FDA 510(k) submission. To do so we need performance testing. He continued by stating once we make the submission, we have a couple months during FDA review to fine tune and perfect the product. And perfecting the device is critical for this startup; they have no desire to launch an inferior device into the market. I agreed. We need to drive towards a viable device that is safe and effective.

The CEO indicated he relayed this to the other team members. I’m just not sure yet that everyone is on board.

Medical Device Startups Are Like a Craft IPA Beer

Those who know me know I’m a sucker for a good IPA. In my head I’ve been trying to figure out how to correlate my enjoyment for a good IPA and my passion for medical device startups. I’ll confess, I got nothing! Okay, maybe a few points (albeit it is a stretch).

  • Medical device startups are like IPAs. Neither is palatable to the rookie beer drinker.
  • IPAs have a bitter taste. Medical device startups often do too.
  • It’s my opinion that IPAs are highly sophisticated and reserved for the most discriminating of beer drinkers. In the startup world, medical device startups are the same way.
  • Once you get hooked on medical device startups, it’s often difficult working with any other type of company. I’ve learned the same truths about IPAs.

Okay, I could go on. And at the same time I realize comparing a medical device startup to an IPA is a little bit silly. But I’ll say the Black Swan Nugget-Hallertau IPA I’m drinking right now made me write this post. Not really.

Like a medical device startup which has their act together, I have learned to really appreciate the complications of an IPA. Yes, the post is a little in jest. However, IPAs are almost always unique with wonderful hoppiness, strong bitter bite, and an aftertaste that leaves my taste buds anxious for more. Medical device startups are similar.

 

Is Launching A “Me Too” Medical Device Within A Year Realistic?

If you ask an engineer whether or not something can be done, I’ve found that most will provide you with an optimistic response. You usually get an unequivocal “yes, that seems feasible”. And what the engineer fails to provide and you fail to hear is that there is not an infinite amount of money and resources at your disposal to make it happen. But you trek on anyway, believing, or probably better stated wanting to believe what you want to have happen (and likely what your boss expects).

When I was approached by a startup medical device client last winter, I was asked if it would be possible to launch a “me too” medical device within a year. Before answering the question (yes, I’ve been that optimistic engineer), I did give the suggestion a great deal of thought. I also chimed in with quite a few follow-up questions. Satisfied with the answers, I too had mine. Yes, it seemed very probable that we could bring a “me too” medical device to market within a year. And I was sincere.

Now we are about 6 months in. That year target is still within reach, despite all kinds of twists, turns, bumps, obstacles, roadblocks, etc. But the next few weeks will be the telling factor. We have to hit a CRITICAL July milestone to have any hope.

So I’ll push like crazy to make it happen.

8 Lessons Learned from Current Medical Device Product Development Project

The current medical device startup product development project is still in process. However, there have been several lessons learned already with this project. Here are 8:

  1. Finalizing Design Control documentation may lag a little (and it’s okay).
  2. A good project manager maybe should be a control freak.
  3. Trust project team members. Don’t trust project team members.
  4. Go to my network. Expand my network.
  5. A task is not completed until there is clear objective evidence to support it.
  6. Delivering bad news never gets easier but should not be avoided.
  7. When I’m comfortable, I’m being too complacent.
  8. Communicate, communicate, communicate.

 

INpact is May 31 – Keeping Product Development & Design Controls in Balance

I have the opportunity to speak this Friday May 31, 2013 at 11:30am during the INpact event. The topic is “Keeping Product Development & Design Controls in Balance”.

I’ll be sharing some recent experiences with startup medical device product development. I’ll also be talking about the struggles to make progress with prototyping and actual development without letting the documentation fall (too far) behind.

I hope you will consider joining and RSVP.

On Budget. On Task. On Time.

The other night, I was watching a home improvement show Rehab Addict, when the host, Nicole Curtis, stated: “. . . On budget. On task. On time. . .” I realize home improvements and do it yourself projects have zero to do with medical device product development. However, project management is remarkably similar across industries, genres, project types, etc. As Nicole made the statement, my attention drifted away from her latest remodel to thoughts about current and past medical device projects.

I remember once very early in my career touting that my projects were always on time. And at that time, my employer didn’t really track budgets, so I guess that metric doesn’t really count. But I remember being very proud of being on time with projects. I remember hitting deadlines. Many projects and years later, I’m not sure that those early projects are a good measure of my project management capabilities. Yes, we did bring some good medical devices to market. However, the on time claim was probably a little skewed. That, and the reality is that if you hit your deadlines, you probably aren’t being aggressive enough. And the reality was then the due date was often prescribed to me by my boss ahead of time. Fortunately, my boss either was naive enough or had enough foresight to set a fairly doable date for project completion.

Fast forward to my current project. Like nearly every project I’ve ever had, the due date for this one was also given to me by my “boss”–the entrepreneur behind the idea. The issue in this case is that this is the first time the entrepreneur has ever gone through medical device product development. From the beginning, I have been very critical of the timeline and the budget. I was able to reset the thinking about the budget to a more realistic value. Timeline, while aggressively established by the entrepreneur, continues to be technically possible. Of course nearly every thing has to go the right way the first time.

I think the entrepreneur really knows that launching when he stated will be a difficult and tough assignment to complete. However, he is also the type to push and push to get the most out of a team. And I’m on board. I know the next few weeks are critical to us meeting the overall launch date. But we are on track and the team is for the most part on board making great strides.

Product Development Happens Because of Teamwork

Okay, the title does sound a little cliche. But it really is true.

As you might know based on recent posts, I’m neck deep engaged as project manager for a medical device startup. In the ~5 months since the project was initiated, it has felt like two completely different projects. This can be partially explained because of the transition from one product development phase into another. However, we’ve also had two different teams engaged.

Team 1 was pretty good. Yet we had one set of resources who kept their work close and didn’t share all that often. Plus, they weren’t really hearing what the customer (a.k.a. startup client who writes the checks) was saying. Team 1 was disbanded and new resources had to be found.

Team 2 has been much better. While we still have some of the same design challenges as Team 1, the resources have been very responsive and are listening to the customer. Plus, we are making progress and still have a decent shot at launching the product in 2013, despite being delayed for over 1 month during the team transition.

As project manager for both efforts, Team 2 has been easier to work with. Each team member is starting to get into the groove of what their role is. I have the dubious responsibility to help orchestrate and bring things together at key points during the project.

There Is A Plan. I Promise.

The last few weeks have been a little stressful and hectic. Yes, I’ve felt the pressure as a project manager for a medical device startup. Our efforts had been stalled for too long yet started to make some real progress a couple weeks ago.

Right now, it feels like chaos. Organized chaos, maybe. There are quite a few components, resources, etc. involved in bringing this medical device closer and closer to market. Each day for the past week or so has been spent identifying the critical pieces–those items which either gate future development and/or are stalled for some reason.

And through all the chaos there is a plan. I’m approaching this a little differently than other medical device product development projects. Overall there will be two products–the main device and an accessory kit. Each product has a few components. And each component seems to have its own intricacies and nuances. Yes, there is a plan. But I’ll be honest, it feels very much like juggling right now.

Fortunately, we have a good team–maybe great if we can pull off the aggressive timeline. The team is committed to getting their parts done as quickly as possible without compromising quality.

Medical Device Product Development Is Like Going to the Eye Doctor

Have you ever been to the optometrist for an eye exam and been posed with the question which is better? Then the optometrist flips a lens or two while you stare at an eye chart. Sometimes the letters get clearer, other times blurrier.

My latest medical device product development adventure feels sort of like an eye exam. For a few weeks, we have been back and forth and up and down on the design of a medical device. Do you like this one? How about this one?

Some days, it feels like we are getting a step or two closer to ironing out the design. Other days, further away.

While I so wish we would be able to narrow in and define the industrial design of the device, we are making progress on the electronics design and other components. Soon, it will all come together.

Medical Device Startups – Keeping the Balance

Medical device startups need balance. Specifically, keeping quality, regulatory, manufacturing, product development, and business in order and harmony with one another is a challenge and a must.

Which one rules the medical device startup?

Trick question. None of the functional areas rule. The trick is to keep quality, regulatory, manufacturing, product development, and business in balance. And yes, it’s always a trick. And always shifting and requires adjustment. One day quality might have the ball. Another might be regulatory. And yet another, all functions might share it.

As a startup, keeping the balance is a frequent, often daily, challenge. I don’t possess the magic formula. I don’t have all the answers. Helping startups with this balance is a large part of what CQ does.

Don’t Shoot! I’m Just the Messenger.

A current product development project has me in a situation that is not very comfortable. A few weeks ago, the project needed to make a “pivot“. I was given the task of finding options. Meaning, I was tasked with finding product development resources who could assist with industrial design, mechanical engineering, electronics design, firmware, tooling, and manufacturing. As project manager for the startup medical device, this task was definitely within my scope. I tapped into my terrific network to try and figure out a path forward. The startup wanted a pretty quick turnaround for quotes. The startup was okay with having ballpark estimates to make a decision. But they wanted to make a decision as soon as possible; the project had already been delaued a few weeks.

I talked with probably a dozen resources. Some options were full turnkey. Others only addressed a particular functional area. I organized all into a matrix to ensure all areas of concern had been identified and to determine rough overall product development costs. I presented the options to the startup, who in turn asked me to provide and support my recommendations. Fine.

After making a decision, I then had the dubious responsibility of informing all the resource providers of the decisions. For most, this was a difficult message. I had to tell them that the startup chose to work with someone else.

And of course when these sources were told “no”, they wanted to know why. Was it cost? Was it schedule? Was it something else? Most took the decision pretty well–this is how the medical device product development business works. We have all been told that our firm was not selected. Others, though, got defensive and wanted detailed explanations. They wanted to schedule a meeting to better understand and have a chance to revise and so on.

I’ve been managing medical device product development projects for 15 years. I admit that delivering “bad news” is still tough for me. But it comes with the territory, like it or not. My job is to inform and communicate. Sometimes, I am just the messenger.

Medical Device Startups Get to Revenue

It’s refreshing to work with a medical device startup with a focus on getting products into the market as quickly as possible to help patients. This same approach will allow this startup to begin generating revenue from the sale of its own products. I say fresh because it is surprising how novel this concept seems to be.

Okay, of course every medical device startup I’ve worked with definitely wanted to get their devices cleared and sold as soon as possible. But this startup seems different.

  • Initial capital equipment will not have lots of bells & whistles and will be similar to other products in this space.
  • Realization that there are quite a few accessories, kits, etc. which could likely enter the market first and serve as a source of revenue to help offset product development expenses.
  • Makes decisions with enough “facts” and without getting too bogged down with minutia.
  • Trusts the resources hired to do the job. When it’s clear there is a mismatch in needs versus capabilities, makes tough decisions about next steps.
  • Focused on the end-goal: get products cleared and ready for sale.

It’s still early. However, I think we are on the cusp of some exciting things with this startup, especially when it comes to the approach and their business model.

New Product Development – Why Start with a Clean Slate?

I’m currently providing project management services for a medical device startup. We recently encountered a “roadblock” requiring we find additional resources to move forward. I was able to reconnect with several capable options within my network for possible solutions. Nearly each resource I spoke with wanted to start at the beginning, basically with a clean slate and blank sheet of paper.

The thing is, this medical device project doesn’t need to start with a clean slate. In fact it should NOT for a couple reasons:

  • We’re developing a “me too” device. Yes, there are likely to be a few features and benefits which are unique to this product. But there is a ton of existing products in this space, including a couple identified as benchmarks.
  • The project actually started a few months ago. While we haven’t gotten too far, we have made progress. Let’s leverage and use as much as this progress as possible.
  • We have an aggressive yet realistic timeline to launch this device in 2013.

Thankfully, there were a couple potential resources who get it and want to minimize the research phase and get right into development. They realized and listened to what we were trying to say. We should make a final decision about the next resource(s) later this week. I assure you it will be those who we feel can pick up where we left off and help us get back on schedule as quickly as possible.

There are very few product development scenarios where you start with a clean slate and blank sheet of paper. Beg, borrow, and steal from other products and technologies. It’s very cliche, but don’t reinvent the wheel.