The success of development programs in the medical device and equipment industry almost always relies on hitting technical milestones that coincide with internal or external fundraising efforts.

Especially early in the program, it is critical to hit technical milestones in a cost-sensitive and timely manner. This will eventually determine if a program has legs or will be terminated.

So, what do these first critical milestones look like? And what can we do to achieve these milestones as fast as possible without over-spending? Below, I provide four considerations to run lean and agile product development programs.

1. Are you designing a star player or a facilitator?

One of the first major milestones in any development program is the creation of the first working prototype. The actual goal of hands-on testing with early working prototypes is attaining technical feasibility (or “Proof of Principle”). This is the moment in which the technical team can confidently say that the underlying technology for the product concept delivers the required performance.

To develop a working prototype as quickly and cost-effective as possible, the first question to ask yourself is whether you are designing the star player or the facilitator? A star player is a product for which the design directly impacts product performance. Examples of products that are considered star players are an artificial knee, or a ventilator that keeps people breathing during surgery.

In contrast, designing a product that is a facilitator involves designing equipment or tooling that enables the “real” star player to do its job. Examples of these types of products are a diagnostic instrument (facilitating an assay to generate a diagnostic output), or a bioreactor (facilitating the production of a biopharmaceutical).

To make a working prototype for a star player product (for which the design is directly linked to its performance), we need to first understand the form factor and requirements of the desired product. We need this information to ensure the design and form factor are representative of the final design so that the prototype can generate meaningful data on product performance.

This is why a program for a star player product often starts with exploring product requirements/specifications, usability analysis and interviews with key opinion leaders. Only after this information is gathered, can the first working prototype be created.

In contrast, for a facilitator product, the final form factor is not required to test the performance of the “real” star player. For example, a crude breadboard system that is built using off-the-shelf (non-custom) components can be used to answer questions like: does my assay generate the correct diagnostic output? Or, is my drug product of sufficient quantity and quality?

Initially, the exercise of exploring product requirements, usability analysis and interviews with key opinion leaders is reduced to a minimum. Only the metrics that pertain to performance (e.g., sensitivity, specificity, quantity of active biopharmaceuticals, etc.) need to be defined upfront.

As long as the initial prototype components can achieve the pre-defined product performance, the first working prototype will provide tremendous value by delivering the first hands-on test results, even if some of the critical components need to be altered in later design iterations.

Not all products can easily fit the “star player” or “facilitator” categories. For instance, categorizing a custom drug delivery device really depends on the complexity. If the drug delivery device enables a therapy that could otherwise not be delivered (e.g. by delivering a drug to a specific part of the brain that is currently beyond reach), the device could be considered a star player.

Whereas, if the drug delivery device is providing a more cost-effective solution to a pre-existing treatment, the product could be considered a facilitator.

In short, almost every development program will aim to achieve technical feasibility as soon and cheaply as possible by creating and testing working prototypes. For star player products, it typically takes longer (and is more costly) to reach this major milestone because more product definition is required to create a meaningful working prototype.

For facilitator products, because so much of the design and form factor can be altered later, you can start creating a working prototype almost immediately while addressing product requirements and specifications in the background.

2. Design – test – design – test – design – test….. stop.

Although the first prototype is always designed with the intent of attaining technical feasibility, rarely does a first prototype hit all the marks. Multiple iterations may be required. This is why, at the core of lean and agile product development programs there are quick cycles of design iterations, testing, learning and incorporating the learnings into the next iteration.

Keeping all non-essential development activities at a minimum during this time helps focus the team and speeds up development. At this stage, tweaking and repurposing prototype builds for improved performance should be done freely without impedance of more rigorous quality systems.

To be clear, these rigorous quality systems are critical at a later stage in the program, but keeping documentation “light” early in the program helps speed up development.

Quick iterations are important for lean and agile early product development. But so is knowing when to stop iterating and celebrate success. I have yet to meet a technical team that does not believe that “more improvements would make a better product”. And so they should! It is their job to strive for the best possible design solution.

That is why the goal of hitting pre-defined performance metrics (e.g. detection of x amount of analyte is achieved, or the sample is stable for x amount of time, etc.) should be clearly stated from the beginning and re-iterated throughout the project.

When the desired performance is achieved, it means that technical feasibility is attained. This means that the program will transfer into the next phase of design (which involves building a more refined prototype).

This is also the right moment to start generating more detailed documentation outlining prototype architecture and start solidifying product requirements. This documentation remains relatively fluid (outside of design control) until later in the program.

Documenting this information helps internal and external communication, onboarding of additional team members and safeguarding the work until that point.

3. How to achieve program milestones with the nimblest team possible

There is often a temptation to throw more resources at a program, assuming that more smart people means faster and better solutions. Especially in regulated industries (like medical device and pharmaceutical industries), the prevailing organizational systems can also push for additional team members who do not yet need to be there.

Representatives of functions who are only required later may get included from the beginning, resulting in a large overhead and communication burden. The result is 20+ people sitting in meetings trying to move a program forward.

Despite the large team sizes, these programs are often slow to start. Thus, although this may sound counterintuitive, I have found that smaller, dedicated multidisciplinary teams can move faster and generate a disproportionate amount of innovation during early product development.

The concept of limiting team size to yield excellent output is not new. Jeff Bezos, founder and former CEO of Amazon, recognized this phenomenon and instituted the rule that every team should be small enough that it can be fed with two pizzas.

The “two pizza rule” is backed up by countless research articles and books indicating that small teams are more innovative and include happier team members [1, 2, 3].

In figure 2 you can see that team size is exponentially related to communication burden. Adding one extra team member may not look like much, but it can actually lead to significant additional burden and misalignments. Especially in early product development, limiting team size to no more than 5 members really aids rapid and lean development.

The apparent dichotomy in this concept is that the problems that need solving in medical device development often require expert skills. It is extremely rare to find all the required skills in a small number of individuals. So, the challenge is how to set up a small team that can execute nimbly and quickly while having access to deeper levels of knowledge/experience.

Unfortunately, there is no one-size-fits-all team, but I have seen the most successful teams exist of just a couple of technical leaders that own the design problems. Mostly, these technical leaders are well-rounded individuals with many years of experience. They know when to look for internal or external consultation in areas where they are not experts.

In this structure, the technical leader frames the problem definition and maps out the solution landscape before consulting.

The consultant (internal or external) is not part of the core team (thus limiting the communication burden) but is still able to provide expert knowledge for the proposed solutions. Often communication between technical leaders and consultants occur in small meetings that do not include the entire team.

The technical leader makes sure that the proposed solutions fit the larger prototype design plans and ultimately owns a significant portion of the prototype architecture.

An added benefit to this structure is that technical leaders feel a great sense of responsibility towards their technical challenges and can truly celebrate and own their successes.

4. Appoint a Program Champion

Technical leaders own part of the system architecture, but there also needs to be a program champion who owns success of the program. This person is ultimately responsible for the entire program and makes sure that the right people are working on the right design solutions.

A program champion can have many titles (e.g. product manager, program manager, director of R&D, CSO, CTO, etc.), but their role is not defined by the title. This is someone that feels responsible for a successful program outcome and is able to look at the different pieces of the puzzle in a more holistic manner.

The program champion will also navigate the healthy conflict between the technical team (with a desire to make further improvements) and the project manager (with a desire to deliver on time and on budget). Running a development program that includes innovation, lots of uncertainties and novel technologies, always demands compromises from both parties.

Ultimately, navigating that conflict effectively is a key component of running a successful lean-and-agile development team.

Another responsibility of the program champion is finding alignment between the technical team and the product manager. The product manager is responsible for the target product profile and for setting commercial targets.

In early development programs, I have found that the role of product manager may not be filled by a dedicated person, but instead the role often lives within multiple individuals.

Helping align these individuals to drive product vision and product requirements, and facilitating the conversation between the technical team and the product management team is essential to arrive at a product design that meets expectations and fills a market need.