I think teams get better outcomes when they stop asking, “What can we place this device on later?” and start asking, “What kind of physical system does this product actually need in order to work well?”
That is the better question.
It shifts the discussion from late packaging to early systems thinking. It changes the conversation from “where will this sit?” to “how will this really work?” And in MedTech, that difference matters, that's why I wrote the ebook, "The Hidden System Around the Device."
System Questions
A simple example makes this clear. Sometimes early in development, a team says, “We’re making a desktop device.” But what does that actually mean? Is that truly a device that a surgeon will use at a desk? Is it really a desktop device? Or is it only the size of a desktop device, while in reality, it may need wheels, movement, and the ability to travel between rooms while still being able to sit on a desk if needed?
Those are not minor wording questions. Those are system questions. And they all come from the same early assumption: “I want to make a small desktop device.”
That is what better questions do. They force the team to define what they really mean before the assumption hardens into a constraint.
What does “desktop” mean?
What does “mobile” mean?
What does “easy to move” mean?
What does “serviceable” mean?
What does “cleanable” mean in the real environment?
These are not side questions but rather design questions.
Asking them earlier forces the team to think about the real use environment sooner. It brings in the voice of the clinical technician, the service team, and the manufacturing team earlier. It surfaces things like power access, mounting logic, mobility expectations, battery requirements, storage needs, cable pathways, and cleaning requirements before they harden into late-stage design constraints.
It also helps teams separate what truly matters from what only seems important in theory.
Sometimes at the beginning, you have one brilliant idea that distinguishes you from your competitors. But in that same moment, you may not yet be thinking about how that idea will look physically, how it will move, how it will be supported, or how it will fit into the real workflow.
If, from the beginning, you also ask how the platform and mobility support that distinction, you will often find that it strengthens the device development itself and later strengthens reliability, serviceability, compliance readiness, and even the defensibility of the product.
This is one reason I have always believed that assumption registers and risk registers should start earlier than most teams think. From the napkin stage, teams should not only be documenting what they believe the product is supposed to do, they should also be writing down what they are assuming about the environment, the platform, the frame, the mobility, and the way the system will actually be used.
Many downstream problems are not surprises; they are assumptions that were never tested hard enough.
Advanced Systems
This becomes even more important in advanced systems. In products that involve AI-enabled systems, medical imaging, remote monitoring, surgical robotics, or deep learning MedTech applications, teams may be thinking heavily about software capability and model performance.
They may be thinking about what deep learning is, how deep learning differs from traditional machine learning, or how a CNN model improves imaging analysis. But the physical environment around the device still determines whether the system can actually be used confidently and consistently in practice.
That is where asking better questions earlier protects the team.
What does the user really need to see?
What do they need to reach?
What do they have to move, reposition, connect, disconnect, or interpret under pressure?
What service access will matter later?
What needs to remain stable?
What will create clutter if the architecture is not deliberate?
These questions are not secondary. They are part of product definition.
And they need to be asked more than once.
This is where teams often drift. Requirements multiply. Schedules get tight. People get buried in execution. Somewhere along the way, the real reason for designing gets blurred by process. The work gets heavier, and the early questions that should have stayed alive get forgotten.
That is why these questions need to be asked again before the design freeze, not only once at the beginning.
-
Who are the real users across the full workflow?
-
Is the system used by one person or several?
-
Does a technician interact with it? A service engineer?
-
How often is it moved?
-
What remains visible at all times?
-
What needs direct access?
-
What will need to be cleaned, serviced, or upgraded in the field?
-
What assumptions is the team still making about the environment that have never actually been tested?
Benefits of Asking These Questions
These questions do not slow strong development down. They help:
-
reduce redesign
-
reduce friction
-
reduce the amount of explanation and correction
They also make the compliance path cleaner. Not because asking better questions replaces formal medtech compliance work, but because many downstream compliance issues — usability burden, access burden, maintenance burden, verification burden — are the direct result of earlier weak assumptions.
So for me, this is not about overthinking the platform. It is about asking the right questions before the wrong assumptions become fixed decisions.
That is what makes development smoother. That is what makes the product stronger. And that is what helps the physical system around the device become an advantage instead of a problem discovered too late.
