Three common elements can be observed in biomedical product development projects that are doomed to failure. I call them the Three “P’s” – Platform, Point of Care, and Program Manager.

This blog discusses each “P”, provides examples, and offers suggestions on how to avoid them during biomedical product development.

Over my 20 years in product development, I have witnessed many successful and several unsuccessful biomedical product development programs.  The products include complex electromechanical medical devices, novel microbe derived pharmaceuticals, diagnostic devices, ingestible diagnostic robots, implantable 3D printed tissues, antimicrobials, disinfectants, catheters and stents, wound care products, consumer good, food additives, and veterinary medicine products. The Three “P’s” – Platform, Point of Care, and Program Manager – always make a significant impact on project success.

1. Platform:

We often hear the term ‘platform’ thrown around in biomedical product development work (particularly in the field of developing diagnostics). I understand the origins and the desire to think about a product as a platform. Often the inventor (developer) has put a tremendous amount of effort into the system and spent countless hours thinking about applications and how to use the system for a multitude of use cases. This is what drives invention. The unintended consequence of this thought process can be a loss of focus or a shift from the true value proposition of the core technology. A technology improperly conceived of as a platform can expose the developer to four common causes of platform failure:

• The product is a ‘jack of all trades and a master of none’. By trying to fit into the role of a platform, the product may miss the focus required to fit the target product profile or TPP. Said another way, by attempting to service all the needs of the platform portfolio, the technology fails to perform its core function well. Think about the Swiss army knife example… if what you really need is a steak knife why would you use a small utility blade with tweezers and a corkscrew in the handle?
• Designing the product to be a platform and attempting to fit multiple TPPs or applications adds development time, complexity, and cost. Spending more time and money turning a technology into a platform state may push the technology cost, availability, and complexity outside of the desired TPP envelope.
• A true platform often requires input and engagement from outside developers (i.e. provision of diagnostic microfluidic cartridges with a far superior array of assays than could be developed in house). If this is not fully considered during the development of the product, the platform concept could be doomed to failure. As an example, think about the iPhone and the Appstore story. In the 1980’s Steve Jobs would charge application developers for toolkits essentially preventing innovation and adoption of the Apple platform and leaving Microsoft as the king of the platform hill with a near monopoly. Fast forward to the 2010’s and Apple iOS is now open to app developers and iOS is the poster child of a successful product platform. The Apple iOS example provides a powerful endorsement for a well-conceived platform play. However, building this open platform capacity into the first run of a device can be an expensive and time-consuming exercise. Also note that the requirement of the open platform concept may not align with intellectual property or TPP considerations.
• Having an open platform system requires careful thought into what part of the platform to emphasize and how the customers will engage with it. A classic example is Google Health.  Google, an undisputed technology leader, famously neglected to engage with the health care provider side of the platform when it launched the original Google Health. The doctors and insurers (who held the information) where not properly engaged and the required participation of that critical side of the platform did not materialize ultimately resulting in the failure of the platform.

The definition of platform is ‘a raised surface on which people or things can stand’. The very definition of the word suggests that a platform is just used to elevate the actual product and has the habit of getting stepped on or not having true value. Unless your product is an operating system or an actual ladder, think hard about your TPP and if a platform is the best choice for your biomedical product development path. Beware of the Platform Pitfall!

2. Point of Care:

What is the point of making your technology function at the point of care? The term ‘point of care’ often gets thrown around and, as medical device developers, we hear this term all the time. But what does it mean? The definition that I like comes from Prince et al (2004): Point-of-care testing (POCT) can be defined as the “provision of a test when the result will be used to make a decision and to take appropriate action which will lead to an improved health outcome.[1]” Taking this a step further by capping the time frame to “within the same encounter or visit” fully captures the essence of what POCT is.

Said another way, POCT can be defined as the provision of a test when the result will be used to make a rapid decision and to take appropriate action which will lead to an improved health outcome within the same encounter. The key objective of POCT is to produce a result more quickly. If this is truly the value case for the product’s TPP, then POC may certainly be the correct development path to take.

However, the most important point in point of care is where is the physical point that care is taking place? Often the quintessential point of care example is a very inexpensive lateral flow test (like a CoVID-19 test) or perhaps a fancy handheld cartridge-based tricorder (like in Star Trek). While these concepts are very appealing to the creative product developer mind, the first question should be where is this test taking place?

If the answer is at home or in a remote setting with limited resources, then those classic examples may hold.  If the answer is a clinic, pharmacy, hospital, or central laboratory, those examples may still hold, but the biomedical product development process should take place in a framework that considers TPP. The definition of POC test is agnostic of the device or setting.

A lateral flow test could be used by a minimally trained person outside traditional clinical settings and deliver actionable diagnostic results. That same test could be used by a highly skilled technician in clinical central lab setting to deliver actionable diagnostic results through a complex interconnected lab information management system (LIMS). In either setting, each user is utilizing a point-of-care test with actionable results.

Likewise, if the device is a complex system (such as a modern high-throughput molecular diagnostic system like a COBAS 8800) that delivers a test result used to make a decision and take appropriate action leading to an improved health outcome within the same encounter or visit, that test is considered a true point-of-care test.

Depending on the end-user and the actual setting, the purpose of POC testing may vary (i.e., diagnosis, treatment, monitoring, airport screening, at home use). This, of course, has critical implications for the assay and reader developers. For example, the tests across the use spectrum may have remarkably different sensitivity, specificity, and accuracy requirements. All of this must be carefully considered before falling for the Point of Care pitfall!

3. Program Manager:

Product development without a program manager is like attempting brain surgery without a brain surgeon or piloting an oil tanker without a captain. Not having a product manager at the helm is a major product development pitfall. The hesitation around bringing in a dedicated program manager for a product development process is understandable. An inventor (developer) has put a tremendous amount of effort into the product and has a vision for program success. Who would be better qualified than the inventor to intimately know the intricacies of what makes their product better, how it fits within the TPP? This is what drives successful product development.

But an unintended consequence can be loss of focus or a shift from the true value proposition of the core technology. A dedicated program manager brings an unbiased focus and clarity to program development that may be difficult for a founder/inventor to provide. A program manager can coordinate all the details and free up the inventor to focus on core technology and ultimately streamline the product development journey and greatly increase the possibility for a successful outcome.

A program manager is a strategic project-management professional whose job is to help oversee and coordinate the various projects, products, and other strategic initiatives across an organization. A program manager’s role in product development is to take a high-level view of the entire program. This view should encompass phase 0 development all the way through product launch, recall and end of life. The role includes coordinating multiple projects within the program, providing strategic guidance on the program (including to project managers if applicable), facilitating communication across the individual program teams. Some organizations consider the Program Manager a ‘Super Project Manager’ or Meta-Project Manager simultaneously coordinating all the individual projects and project managers of a large program. Here is a great blog on 9 ways project managers make or break medical device development.

A classic example of a break down in program management is the roll out of Target stores into Canada in 2013. There was a tremendous level of excitement, fear, and anticipation of the retail giant coming to Canada in the early 2010’s. The first store opened in March of 2013. Target rapidly expanded to 133 stores in less than a year and a half. However, the chain pulled out soon after on January 14, 2015, with Target Canada filing for bankruptcy. This failure in program management had an estimated cost of $7 billion. The major failure of the Target foray into Canada was the oversight of the program management on Canadian supply chain logistics. Supply chain issues led to empty shelves and stores being left in the red while new stores popped up leading to the ultimate demise of the program. This example highlights the critical need for strong program management and emphasizes the cautionary tale of not falling for the ‘we don’t need a program manager’ pitfall!