How to drive speed and quality with your product development process

Most companies run product development under the Hero model. This is where a highly experienced medical device developer gives play-by-play direction on product development activities. This can work short term, but there are some major drawbacks. 

First, it deprives a younger and growing team of seeing the big picture. These team members need to understand where they are going and how they will get there. If this information is trapped in the heads of an individual, it will lead to confusion and frustration among the rest of the team. Team members will be operating at the whim of the Hero, who likely has a method to her madness but hasn't clearly articulated the thinking and the plan. If this problem exacerbates, it can lead to an "order-taking" mentality. When a process is micro-defined by one individual, it will be difficult - if not impossible - for others to 'own' sub-parts of the process. Without this ownership, team members may resort to a "what should I do next?" mindset, which is a dangerous place for companies to be. 

Second, the Hero may be the founder, but more often he is a principal level hire within the organization. And sometimes the hero leaves the company. When the development process was wrapped up in the Hero's head, and he moves-on, the rest of the team is left confused and wandering. Resourceful team members will try to pick up the pieces and assemble a path forward, but their lack of experience and knowledge will likely result in stalling and misdirection. That is until the next Hero is hired.. and then the team jumps onto a different merry-go-round.

Instead of the Hero model, it is better for companies to define and follow a consistent Product Development Process (PDP). Doing so will give the full team a clear picture of where they are going and how they are getting there. This alignment will provide team members the education, confidence, and ownership that they need to tackle their respective portion of the project. When a solid PDP has been developed, and all team members are following it, speed, quality, and an 'ownership mindset' will result.  And when a key person leaves your organization, the process will be documented, the team will see the path forward, and the progress will continue.

Following are some tips on how to create or refine your PDP to ensure that it is driving speed and quality in your company.

1. Start by defining the value

Most teams start product development by brainstorming, down-selecting to an idea, and then asking, "how can we prove this?" This is the model we are taught in engineering school, and it's the way that most companies operate. The problem is that this approach often results in solutions that miss the mark from customer needs.

Rather than starting at the idea and thinking "what's next," instead teams should define product development process by determining the value to the customer, and then work backwards.

So, what is value? Value can be defined by what a customer will pay for.

To define value in these terms, you need to first understand your customer. If you are at the beginning stages of development, and you need additional funding near-term to reach the commercial stage, then perhaps an investor will be considered your "initial customer." In that case, what is the investor hoping to see or learn that unlocks subsequent funding rounds? Teams need to be careful here, because not all early-stage investors are savvy about the medtech industry, and they may insert requests that don't add value to the end customer who pays for a device. More on that topic later.

If you are further along in the process and have adequate funding to advance your product to the market, then your customer is most likely a hospital, a clinician, or a patient. With these customer profiles, how is value defined? Typically, you will be solving a problem for them. You may be reducing the incidence of a negative health outcome. You may be improving the visibility of a chronic condition. You may be increasing the revenue stream for a private practice. The value to your customer is most likely not the product itself. Moreover, value is what your product does for the customer and/or their patient.

How will you demonstrate this value to your customer. You may need to run the clinical that shows a reduction in negative health outcomes. You may need to conduct an economic study that shows the reduced cost of care. This demonstration of value is the endpoint of your product development process.

Once you understand this value and how it is proven, you work backwards. You identify -- what is the earlier step that will lead to that value? And what is the preceding step before that? Starting with the value and working backwards is how the best PDPs are assembled. It's the opposite of what we learn in school and what most companies do -- that is, huddle, brainstorm, prove, pivot. 

2. Reduce non-value add steps

Chances are that your first PDP will be bursting with inefficiencies. Marketing, legal, manufacturing, engineering, clinical -- they all want their needs to be addressed. And of course, in most cases, they do need to be addressed. However, the complexity of medical device development often results in many non-value added steps that are simply embedded to appease internal departments or stakeholders within an organization. 

A stage gate is an example of a non-value added step. It does not contribute to the value that a customer will be receiving from your product development efforts. Many times stage gates are necessary to gain the approval of senior management, boards, and investors. So, they may be essential even though they are non-value add.

Similarly, companies often strive to create demonstration prototypes and/or visual models. In most cases, these prototypes do not reduce risk or contribute to the ultimate value that a customer is seeking. They are simply created as show-and-tell models that give investors and executives the confidence that may be needed to support the project further. Again, these steps may be necessary to achieve funding and/or leadership support, but they do slow down the product development process without adding value for the end customer.

The punchline here is that sometimes non-value add steps will be required. Again, sometimes your "initial customer" is the investor or the board -- the group that gets to determine whether or not your project receives subsequent funding and approvals. In these cases, the additional non-value added steps are essential. However, it's important to recognize them as such, and keep these non-value added steps to a minimum.

As you are developing or refining your PDP, each step should filtered through the value lens. If there are steps that don't add value and are nonessential, then they should be the first to strip out. Then, an effort should be made to minimize or consolidate the essential, non-value added steps. 

3. Eliminate dependencies

Sometimes, dependencies are necessary. For instance, you can't conduct bench testing until you have the prototype. But in other cases dependencies are artificial and unnecessary.

For instance, many teams require that documentation of user needs and design inputs occurs before conceptualization starts. While defining these foundational requirements is critical, this process can, and in most cases should, run in parallel with early conceptualization activities. Most teams do not have the foresight to think through all the requirements in advance. They may need to obtain data through pre-clinical testing. They may need to explore various use cases and workflows. They may need to consider various product architectures and cost models. Exploration of concepts is most often required before teams can define the right requirements. 

Similarly, some companies serialize product development such that engineering isn't started until industrial design is completed. If a team is optimizing for cost, then this approach may be the most frugal. But it will certainly stretch out the timeline. There are always things that engineering and design teams can be doing in parallel. In fact, there is significant benefit of doing so. Running these activities in parallel creates a push-and-pull dynamic that results in more realistic industrial designs and a more progressive engineering solutions.

Another example is the manufacturing team's involvement in the design process. It is often a significant mistake for manufacturing to be brought in after the design has been completed. When the manufacturing team gets involved, there will undoubtedly be changes required of the device design -- changes that could have been flagged and integrated during the design process if the manufacturing team was operating in parallel.

Try to avoid placing unnecessary linkages between different activities in your product development process. Run teams and sub-processes in parallel to ensure that the right cross-pollination is occurring and redo loops are avoided.

4. Define formal reviews

As a medical device developer, you need to hold design reviews. Is this a value-creating step, as defined by the customer's willingness to pay? Probably not. But it's an essential step for regulatory purposes, nonetheless.

Formal reviews, including Design Reviews, should be defined on your PDP. Make sure that the right reviews are in-place before large time and/or capital investments are incurred, but also be sure that the formal reviews aren't too frequent. Each one results in significant delays due to coordinating calendars of multiple team members, reviewing documentation, collecting decisions, and obtaining approvals. 

The formal reviews described here, such as Design Reviews, are not intended to include technical reviews or weekly team check-ins. Those meetings should occur regularly, but they should be focused and brief. Recurring project meetings are essential to gain team alignment and can be one of the most effective tools in accelerating process, but focus and purpose in meetings is key. More on this topic can be found in this article here: How to Run Meetings that Don't Suck.

5. Fit onto 1-page

Product development processes have the tendency to include jargon and acronyms that obscure the intent. A well-defined PDP should aim to align teams on the process that is undertaken to achieve a specific value-focused goal. This alignment occurs when the process is clear and simple.

It is a mistake to attempt to capture every micro-task in a PDP. Instead, the PDP should be a high-level guide of the activities that need to be undertaken. A good rule-of-thumb is to keep your PDP to a single page. At Archimedic, we find block diagram PDPs to be the most effective way to communicate process in a clear and simple format. (More on our PDPs below.) 

When PDPs get to be too dense, consider either eliminating tasks or breaking out a sub-process into it's own 1-page process map. This will keep your main PDP clean, simple, and understandable while providing the additional detail that may be needed for a team member to dive deeper.

PDPs should not be considered the "how to" guides for the entirety of medical device development. Each step still requires knowledge and skill to execute properly. A PDP is a map to gain alignment on the core activities and sequences, but it needs to be coupled with experienced personnel that can drive and coach others through the process.

6. Publish it

A PDP does no good if it is developed and then tucked away in a file directory. It needs to be published, accessible to the full development team, and reviewed regularly. If you are working in a physical space, get your PDP up on a wall. Blow it up so that everyone can see it. If you are working remotely, get your PDP up on your company's intranet site. Make sure that your team members are reminded of its existence. When there is confusion on process, PMs and other team members should point to the PDP. Does it provide clarity? Can it help team members understand where they are in the process and what comes next?

Along the lines of publishing PDPs, below are a couple of our PDPs (in draft mode). We are in the process of updating our PDPs to further simplify, clarify, and streamline our product development process at Archimedic. These aren't a significant departure from how we currently operate, but these versions aim to simplify and clarify our development process even further. As you are reviewing these example PDPs, here are a few things to keep in-mind:

• Archimedic is a contract medical device development and manufacturing firm.
• Our customers are startups and OEMs developing new medical devices
• We are contracted to develop research devices (non-GMP) and clinical devices (GMP). So, there are unique PDPs for each.
• The PDPs are intended to be high-level. For instance, testing could include many different types ranging from bench testing to preclinical testing and human factors testing. We opt to keep these PDPs high-level and use separate documentation to characterize the sub-processes rather than embedded extensive detail in our process maps.

The first process map shown below is for Research Devices (non-GMP). Our clients value and use these devices to evaluate pre-clinical efficacy, usability, investor demonstrations, and/or other non-clinical purposes. They are primarily for early-stage de-risking. We keep these non-GMP programs lean with minimal documentation, since these devices are not intended to support regulatory filings or clinical studies. 

This second PDP is for devices that are intended to be used clinically (GMP). These device include pre-market clinical devices and commercial products. This GMP process includes more documentation, risk management, and verification testing to confirm safety and support our clients' clinical validation processes. Additionally, these projects generate devices and documentation that support regulatory and commercial milestones.

Summary:

A solid product development process will help you team drive speed and quality. Defining your first PDP will likely require extensive input and iteration from many team members. But, it is time well spent. Once your PDP is in-place and followed by the team, your projects will benefit from improved alignment, focus, consistency, and an 'ownership' mindset.