Commercialisation Starts in the Design Phase
Article Summary
Many medical devices fail because they weren’t designed for commercial reality. Early design decisions lock in manufacturing complexity, validation burden, cost structures, and scalability long before regulatory approval.Article Contents
Introduction
Even the earliest prototypes form the seeds from which commercial operations will sprout. A successful product development phase must consider not only safety and efficacy but also ensure that the design aligns with business goals. That is, you must start your design with the aim of creating a sustainable business.
Unsustainability can arise from multiple directions not accounted for in hazard analysis, quality systems, or development methodologies. A supply for key components might dry up. The durability of your design may lead to excessive warranty returns. User interface challenges may make clinical implementation infeasible. AI server costs could erode your profit margin. That is, your operational cost for a device can exceed your expected BOM and server costs.
Designing for commercial viability is an engineering problem, but one that often takes a back seat to clinical milestones. Startups want to get to trial, and then they want to get through trial. Completing a clinical trial proves nothing about the economics of commercial operations. Neither agile methodologies like Scrum nor Kanban nor exhaustive design “waterfall” approaches help avoid this trap.
It’s easy to think that once you have a working design, you can make minor revisions to accommodate any business needs. That’s a dangerous approach because there are trade-offs between design costs and operational costs. Medical device development occurs under strict time and budget limitations, especially in startups. These resource constraints make it challenging to revise designs to meet safety and efficacy requirements, particularly given the cascading activities associated with such changes. Yet surviving the design phase won’t matter if your product can’t support a profitable business.
In the worst-case scenario, you may have an approved product that increases your cash drain with every sale.

Business Factors Engineering
You may be familiar with Human Factors Engineering (HFE), which assesses a medical device’s usability with an emphasis on safety and efficacy. Like HFE, design factors also impact financial viability. I call these economic considerations Business Factors Engineering (BFE). As with HFE, the earlier you consider BFE in your design phase, the lower your implementation cost. In fact, BFE will reduce your R&D costs because many of the same expenses (e.g., delays, material waste) affect R&D.
Imagine the cost of cars if a BMW with a “Check Engine” light had to be shipped back to Germany for analysis by the design team rather than having a diagnostic computer plugged in at the dealership. That scenario works for an early prototype, but destroys commercial feasibility.
These BFE concerns extend beyond logging. Durability, reusability, cleanability, lifespan, training costs, and OR time all affect a product’s economics. You can also see how significant deficiencies in these areas create opportunities for competition. Clinics have budgets too, and they will naturally prefer to use products that deliver higher profits with fewer headaches.
Ultimately, many of these BFE considerations will benefit patients as well. They fall under a category that is seldom discussed in medical device contexts: user experience (UX). Does the patient want to take a bus to the clinic for diagnosis or to address an issue? No. They’d much rather have a device that is easy to use and maintain. However, as with BFE, UX often takes a back seat to HFE, which focuses on acceptability rather than a positive experience.
In short, many of these commercial considerations are procrastinated despite their strategic importance. It’s as if you let a toddler pick where you plant an oak tree in your yard because you can always move it when it becomes mature.
While you can move an oak tree, it’s ultimately much cheaper to plant the seedling with consideration for where your utilities enter your home, where acorns, leaves, and heavy branches will fall, and where you want to place a patio. The alternative may require exorbitant bills from an arborist and a crane operator – and possibly a roofer, plumber, or electrician – in the future.
As the product progresses through each design phase, R&D should consider how the design will impact the business in the commercial stage. How will these issues be diagnosed and resolved in the patient’s home, in the clinic, and by your support teams? Has this design considered maintenance and field durability? Today is the least costly time to make BFE changes, while the commercial stage is the most expensive time to identify revenue model challenges.
The Curse of Unprofitable Sales
For example, a startup I helped several years ago struggled to address field issues. In the lab, the system worked flawlessly. As with many investor demonstrations, a clever demo doesn’t always translate into profitability. In this case, the device couldn’t handle real-world conditions and required frequent manual interventions to meet specifications.
Reality was a harsh teacher. In short, the devices suffered unanticipated usage failures, mechanical failures, software failures, and performance problems.
Ideally, even a non-technical sales team can quickly diagnose and triage these problems in the field. The reality was a nightmare. The sales team functioned more like a field engineering team, traveling from site to site, performing manual workarounds, delivering replacement devices, and returning failed equipment to the lab for analysis. The devices had a high replacement rate and required a substantial operational budget. Every product sold meant a faster drain on corporate resources. Increasing sales would have bankrupted the company.
In addition, the data critical to diagnosing product failures wasn’t logged. The engineering team hadn’t contemplated it partially because it wasn’t needed for benchtop testing in R&D. Why log an event you could see with your own eyes? They also hadn’t anticipated how the product might fail in production. As soon as the devices were in the field, however, the law of large numbers enabled them to identify new, unanticipated failure mechanisms. This failure to design in adequate diagnostic logging prevented the engineering team from learning from their failures.

Trade-offs Between Design and Operational Costs
Streamlining investigations started with a simple yet large project: add a user interface for reading logs that provided a much closer-to-plain-English explanation of each event, and log every error and unexpected event we could think of. As the logs provided more insights, the team was able to more accurately simulate field conditions. Simulating field conditions led to more robust, new designs.
However, getting through the redesign took years. Improved hardware. Improved software. Better user interfaces.
Procrastination is expensive. Discovering field issues at the commercial phase is like discovering you bought plane tickets to the wrong destination after exiting the plane. “Oops. I landed in New Zealand, not New York!”
Time is a resource, and must be treated with even more care than funds. Choosing the wrong plane ticket has no cost if the mistake is noticed before payment. As time passes, the cost of the error grows and grows until you step into a terminal on the wrong continent.
The consequences of these problems at the last minute aren’t pretty. Tense conversations with the board of directors. Raising or borrowing more funds. Missed payrolls. Layoffs. Ceding market share to the competition. In the worst case, which does happen, the company shuts down.
Building a medical device to meet requirements may yield a safe and effective device, but it does nothing to ensure a commercially viable product.
Major Commercial Considerations
The best time to consider commercial factors is during the design phase. As with any engineering task, making these choices often requires more art than science. You will always face trade-offs and uncertainties. But uncertainty about the future doesn’t suggest ignoring it. Designing a product to treat or mitigate a disease can’t help anyone unless it can support a sustainable business.
Every aspect of a product faces uncertainty, so what is one more category? Just as your engineers must test their designs against known requirements, they must test your designs against known business challenges. As your product development process progresses, you will learn more about the commercial challenges it may face. These challenges include:
- Durability
- Manufacturability
- Cybersecurity
- Field service costs
- Interoperability
- Consumables model
- Update or replacement path
- Human factors for patients
- Human factors for clinicians
- Clinical buying criteria
For instance, under durability, you might find that your product’s case doesn’t provide adequate protection against a fidgeting patient, or that the contacts on your power cable clog with debris. Your products must be resilient across a broad spectrum of clinical and patient behaviours.
Under manufacturability, you might find that airborne particulate levels at your contract manufacturer are too high to achieve a yield above 65% for your optical sensor, or that your assembly process is too complex to meet your target manufacturing cost.
Cybersecurity brings an ever-changing challenge for all medical device businesses. The more interconnected your device is, the more frequently you will encounter new security vulnerabilities to patch.
Field service costs vary significantly by design, category, and class. The key here is to minimise, through design, training, and support, the frequency and duration of your staff’s in-person clinical visits.
Interoperability costs also depend on your device category. The more your device generates or interprets data, the higher the cost of integrating with IT, other devices, and EHR systems. There may also be compliance costs associated with your clinical relationships.
Your consumables model, while sometimes a revenue driver, can also pose operational challenges. If you sell supplies to clinics or patients, you will face additional overhead from inventory management, shipping, billing, and related functions.
Your update and replacement paths also have operational costs. For instance, an urgent security patch, depending on your design, might be deployed over the internet, or it might require scheduling on-site time and flying technicians to remote locations to update the software.
Human factors related to patients can significantly impact your product’s support and warranty costs. These costs can range from phone support to making unnecessary warranty claims.
Likewise, the human factors for clinicians can have the same impact. Physicians and surgeons don’t want to waste time troubleshooting or reading a manual; if the device seems broken, they’ll replace it.
Finally, clinics are complex businesses, with their own profitability, legal, and regulatory needs influencing their product choices. If your device appears more expensive or more onerous than competitors’, they won’t use it.
Bringing Commercial Insights Forward
Addressing these commercial considerations earlier in the development phase requires a disciplined approach. First, your team must identify potential areas of concern during the design phase. Go through the list of considerations as a group and brainstorm which specific scenarios your system might be exposed to. For instance, if your system requires the patient to perform maintenance tasks, what human factors issues arise? How will the patient obtain the consumables necessary for the task? What are the potential field service issues if the maintenance tasks aren’t performed?
Second, you must research these concerns. Ask colleagues or other receptive audiences to perform the maintenance tasks independently and identify where issues arise. Simulate missed maintenance cycles.
Finally, redesign and retest the areas where commercial concerns seem evident.

The Hazard Analysis Shortcut
Most medical device organisations focus on hazard analysis to improve device safety. However, the outputs of hazard analysis can be used not only to develop harm mitigations but also to navigate the path to commercialisation. For instance, each hazard scenario also provides a commercial question: how will the patient, clinician, or field representative diagnose each failure mechanism?
When cost isn’t a consideration, as in clinical trials, it may suffice to mitigate the hazard, replace or reset the affected components, and then rely on the engineering team to investigate the issue. In a commercial setting, this only scales at very low failure rates. Replacing more than a few percent of your product and increasing operational workload can incur catastrophic economic costs to a startup.
Consider a hypothetical in-home cardiac monitor. It has two components: a monitor with electrodes, and a handset that logs measurements and displays alerts to the patient. It might seem simple, yet the failure mechanisms are numerous. The connections between the monitor and electrodes can fail. The electrodes can fall off or be improperly placed. The monitor or handset may drain its battery. Communications between the monitor and the handset, or the handset and the internet, may be lost. The monitor or handset can be damaged or wear out.
Every failure mechanism can become more likely due to the device’s design. While a single red light to inform the patient or clinician that the system isn’t functioning correctly may suffice from a hazard-mitigation perspective, each time the light illuminates, the maximum possible cost is incurred. There is a significant economic difference between charging the handset’s battery and returning to the clinic.
Ideally, you design a system that minimises the total cost of a sale, not just the BOM. However, during the design phase, engineering organisations often fixate on BOM cost (red LEDs are cheap) without considering operational expenses. If the battery is low, operationally, we’d like the handset to instruct the user to plug it in. Only in the worst-case scenarios should a patient be required to return to the clinic to determine what went wrong. Trade-offs between BOM costs and operational costs are common. Using the hazard analysis to peek into operational expenses helps you make better commercial decisions.
Taking Action
No matter where you are in the product development process today, take time to consider what the commercial phase will look like. Develop a story to help your teams understand how you want the commercial phase to look. Explain the economics of your business model beyond the manufacturing costs. This must include the cost of sales, support costs, warranty claim costs, and the expectations clinics will have for your product.
With that vision of the commercial stage in mind, consider your hazard analysis and evaluate the user experience. Even your labelling, training materials, manuals, and work instructions can help you develop a clear picture of your product’s current state.
Most of all, perform experiments. Even informally, test your instructions, hardware design, and user interfaces with real humans. Perform rehearsals for each procedure associated with your medical device and record the time, material costs, and experience. Simulate failures and assess whether inexperienced users can understand what’s happening. Using low fidelity mockups is fine!
Reality is the best simulator. Don’t let your imagination substitute for getting feedback from unfamiliar eyes. Get that feedback and work through the implications for commercial deployment. Is it ok if a procedure takes that long? If that part breaks 33% of the time, what will it cost us? If the surgeon cannot align this probe, what are the consequences?
Many years ago, when I worked at Evernote, a user-testing experiment had our faces streaming with tears and laughter. We wanted the user to take a photo of the chair they were seated in and edit the image. We wanted to test a new editing interface.
Our designer thought their instructions were clear, but the tester couldn’t get past our first step. “Where’s the chair? I’ve looked on every screen, and I don’t see a chair!” The test was the worst UI test failure we had ever seen, but ironically, it failed due to misunderstood test instructions, not our product. It was the culmination of a challenging design and implementation process, and our flawed instructions underscored how difficult it is to anticipate problems without real-world testing.
Requirements aren’t reality. Building a medical device to meet requirements may yield a safe and effective device, but it does nothing to ensure a commercially viable product. If you want to improve health outcomes, you must design a product that will prove profitable in commercial applications.
Disclaimer. The views and opinions expressed in this article are solely those of the author and do not necessarily reflect the official policy or position of Test Labs Limited. The content provided is for informational purposes only and is not intended to constitute legal or professional advice. Test Labs assumes no responsibility for any errors or omissions in the content of this article, nor for any actions taken in reliance thereon.
Get It Done, With Certainty.
Contact us about your testing requirements, we aim to respond the same day.
Get resources & industry updates direct to your inbox
We’ll email you 1-2 times a week at the maximum and never share your information
