Welcome back! Still, on MedTech over-engineering, I think this sentence from “The Elements of Style” is a great guideline for over-writing and can be transferred to over-engineering:
“A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.”
After analyzing the major causes of over-engineering in MedTech, now is the time to understand the consequences and the strategies to prevent it.
Let’s unfold that.
Consequences of over-engineering
There are many consequences from over-engineering a new product, but ultimately it limits the chance of product success by creating a misalignment between the product and the market.
The most significant damage over-engineering can cause is creating a medical product with features and functions that the user does not value because they add complexity and do not solve any real problem.
Moreover, over-engineering increases development time. If the engineers do not work on real problems or do not choose the simplest solution to address a problem, the development time increases, preventing the company from launching faster.
With longer development time, there will be an increased cost of development that will be transferred to the product’s price, resulting in a premium price for undesired features.
This can also have an impact on customer iterations since the pressure to stay on the planned time will prevent iterating effectively and frequently with customers.
The product complexity resulting from over-engineering can produce a higher error rate in the use of the product and, in some cases, increased maintenance costs.
Lastly, over-engineering is responsible for low team efficiency. If the team does not have clear goals and focus, it can become inefficient at successfully delivering the product as one team. This is because different visions support conflict development and eventually create lower team morale and motivation.
Examples of over-engineered MedTech products
The first example that comes to mind is some features of a Stryker’s power console called Core 2. This console has some features, like storing 100+ surgeon profiles. It can also run two drills simultaneously and assign two pedals to a single handpiece.
These are examples of over-engineering because they are not useful in 99% of the cases and do not produce extra value for the user.
In fact, these functionalities help differentiate the product on outputs and not on outcomes.
Another example of over-engineering is the integration of the monopolar and bipolar radiofrequency with the microdebrider technology into the DIEGO ELITE Multidebrider.
Although, there are some potential advantages derived from integrating radiofrequency technology, for example, the potential to reduce procedure time thanks to the readily available hemostasis.
I consider it an example of over-engineering because the hemostasis can be acquired differently, and the value generated is lower than the “sacrifice” made by the customer. The poor market penetration of this combined technology also confirms my reasoning.
Let me remind you that the customer doesn’t care about your output (features, functionalities, specifications). All the customers care about is solving their problem.
How to prevent over-engineering
From my point of view, the best way to prevent MedTech over-engineering is to develop a precise alignment on the founding principle of product development: solving customer problems.
In order to limit it, the team should clearly understand the deep meaning of customer focus. Moreover, involving and bringing R&D engineers closer to your customers’ real problems is always useful.
Related to the above, another key element is properly defining the customer needs through a solid VOC study. It can also mean determining and prioritizing the user’s requirements and translating them into design specifications.
This fundamental process, if correctly implemented, reduces ambiguity and allows the engineers to know the why behind a specification.
The more you can narrow down the problem, the less the team will have the opportunity to deviate and develop an over-engineered solution.
Since perfect information is only sometimes available because customer needs were not well explored, critical thinking and judgment should be used to avoid over-engineering.
Questions for early detection
The answers to the following questions will help you determine whether over-engineering is taking shape.
- How does this feature help solve our current user’s problems?
- What happens if we don’t do it?
- What is the user’s issue we are solving, and how does this feature directly solve it?
- What is the scenario that this feature will solve?
- What are the most critical user requirements that we need to deliver?
- Why did you choose this implementation/design approach?
- What are the alternative ways in which we could have approached the implementation/design?
- Is this the simplest way to satisfy this user’s requirement?
- Can we make this simpler and still fulfil this user’s requirement?
If the answers to these questions above are unclear to the entire team and you are not 100% confident about them, there’s a chance that some over-engineering can originate. Therefore, I suggest stopping and clarifying what the development team aims to achieve.
Conclusion
I believe over-engineering in MedTech is a risky practice that can even kill products due to the lack of good development practices.
Unfortunately, overengineering is not the exception, and it is common. For this reason, it is vital to know what it is and how to prevent it. This is also because every resource invested in developing a feature that doesn’t solve an actual customer problem is a waste.
My final remark is that having a development team aligned on the principles (for example customer focus) at the base of new product development can help prevent over-engineering.
Do you have experiences or examples to share? I’d love to hear any other questions or techniques you have found helpful in identifying over-engineering. Feel free to share in the comments below, and remember to subscribe.
Thanks for reading.