At Blur, we’ve guided products across the full medical device design and development lifecycle, from initial concepts to FDA-cleared devices. It’s exciting, fulfilling, challenging, nebulous work. Along the way, we’ve seen what happens when clients get stuck in unhelpful patterns of thinking. Read on about the three most common engineering and design process thought ruts we see and how to coach yourself out of them to get your project back on track.
Planning vs. Execution: Stop Choosing Sides
One of the most persistent tensions in medical product development is the pull between planning and execution. Some teams want a fully mapped-out program before a single screw is turned. Others want to be in the lab by Monday morning, cutting metal and figuring it out as they go.
Focusing purely on either extreme can derail your project.
Over-planning gives you a false sense of control. You can build the most detailed Gantt chart imaginable, but in March you simply cannot know what your day-to-day work will look like in December. Suppliers fall through. Materials don’t behave as expected. Parts get stuck in customs. These aren’t failures, they’re just the reality of building something new.
On the flip side, jumping straight into prototype mode without a plan means you’re burning resources without a clear eye on risk. You’ll spend nights begging a machinist for a rush delivery only to realize a different critical part isn’t even ready yet.
The right answer is a dynamic balance, and that balance should be driven by one thing: risk. The riskier the project, the more urgently you should be building and testing, not planning. If the biggest unknown in your program is whether your core technology actually works, go prove it. Build it, break it, and learn from it. Once you have that kernel of proof, your plan becomes far more credible to your team, your investors, and yourself.
Start With the User. Every Time.
Here’s a pitfall that’s especially common in medical device design: teams start designing the product before they’ve clearly defined the problem. This is a human factors engineering problem as much as a design one.
A founder walks in with a working prototype, a solid business case, and a passion for solving a real clinical need. When you dig into the requirements, they’re written around what the engineering team knows how to build, not around what the user actually needs the device to do.
If your requirement says the device needs to be “24 by 36 inches,” ask yourself: why? If you can’t trace that number back to a genuine user need (say, fitting through an ambulance door or accommodating a specific patient population), you’re designing in a vacuum.
User needs should be the foundation of everything in medical product development. They drive your product requirements, your specifications, your test plans, and ultimately your FDA submission. The FDA cares about one thing above all else: that your device is safe and effective for the people using it. Your requirements should trace back to that.
The discipline of keeping requirements at the need level (not the solution level) also frees your engineers to be creative. Tell them the device needs to fit through a certain opening and they might rethink it entirely. Hand them a dimension and they’ll just hit that dimension.
“It Works on the Bench” Is Not the Finish Line
We’ve all seen it: a beautiful, painted, 3D-printed prototype sitting on a workbench, doing exactly what it’s supposed to do. Everyone in the room gets excited. Someone says, “We’re 80% there.”
They’re probably not 30% there.
Getting to a working proof of concept is genuinely exciting, and it’s a critical milestone, but it’s often the easier part of the journey. The hard part is taking something that works in the lab and proving it will always work. In many instances you need to test that it works in a clinical environment, assembled by a technician who doesn’t know your engineering team, serviced five years from now, and using components that won’t be obsolete in three months.
The off-the-shelf microcontroller you grabbed for a few dollars online might not be available in two years. Can you validate, calibrate, and guarantee its behavior within acceptable bounds?
These questions aren’t as exciting as a late-night prototype breakthrough, but they’re where real engineering lives and where the path to medical device manufacturing begins. This is where FDA confidence is built or lost.
The Takeaway
If you’re in the middle of a medical device design program right now, here’s the simplest thing you can do: step back. Ask where the biggest risks are, then put your energy there. Don’t focus your energy on the parts you already know work, but on the parts that are genuinely unproven.
Product development is learning. You haven’t gone too far, made too many mistakes, or fallen too far behind to course-correct. Risk drives schedule. Risk defines priorities. Keep your eye on the risks, stay honest about where you are, and keep moving.
Learn more about how Blur approaches medical device design and development, our prototyping process, and design and human factors.