Decide early, learn early: building surgical robots

Imagine you're developing a four-arm surgical robot. Early on, the team has to decide on the physical architecture: arm geometry, range of motion, how the system sits around the patient, and its overall footprint. Those choices ripple into the mechanical design, motors, sensors, electronics and manufacturing, and they set limits on what the software and controls can eventually do. Most of them have to be made long before anyone can test the full system in a realistic surgical workflow.

That's one of the hardest parts of building complex hardware. You have to commit to big decisions while you're still learning about the product.

I've worked across surgical robotics, medical devices and software, and the core product principles don't change much. You still need to understand the problem, test your assumptions and make good tradeoffs. What changes with hardware is when you have to decide, how hard it is to undo, and how long it takes to find out if you were right.

Know which doors are one-way

Jeff Bezos has a useful way of describing this. Some decisions are two-way doors: if you get them wrong, you can walk back through and try again. Others are one-way doors, where reversing course is slow, expensive or close to impossible. Two-way doors should be made quickly. One-way doors deserve real care.

Software is full of two-way doors. Teams can defer implementation choices, ship something narrower and iterate. Hardware has far more one-way doors, and they come early. Mechanical and electrical architecture decisions usually have to happen up front because parts have procurement lead times, custom components need fabrication, and subsystems have to be integrated and tested. Software can be developed in parallel through simulation and test environments, but it can't always work around a limitation in the physical system. If the arm geometry doesn't support the workspace surgeons need, or the system is missing a sensor, the fix is often a hardware redesign, with new parts, supplier coordination and another round of verification.

Even a goal that sounds simple can be a one-way door. A smaller footprint would make the robot easier to fit into an operating room. But shrinking it can affect arm positioning, range of motion, stability, component packaging and service access. The question isn't whether a smaller footprint is good. It's what that choice constrains everywhere else.

So the first thing I do with any major decision is sort it. Is this a one-way door or a two-way door? If it's two-way, we move fast and learn. If it's one-way, I want to know which clinical requirements it satisfies, which other subsystems it touches, what assumptions we're making, and what it would really take to change later. Just as important, I try to keep two-way doors open. Not every hardware decision has to be locked early, and treating everything as permanent slows a team down as much as treating everything as reversible gets it into trouble.

Learn before the full system exists

If the one-way doors come early, the job is to reduce uncertainty before walking through them, without waiting for a fully integrated robot. Simulation can test kinematics and workspace limits. Mechanical prototypes can check physical fit and motion. A foam or wood mock-up of a surgeon console can surface ergonomic problems for surgeons of different heights long before the real console exists. Subsystem testing can expose reliability issues before integration.

The trick is matching the method to the decision. For arm geometry, I need evidence the configuration supports the intended surgical tasks. For a critical component, I need confidence in its performance, availability and integration requirements. None of this replaces system-level verification, usability validation or clinical evaluation. It just helps us find problems while there's still room to change the design.

I don't want to prototype everything. I want to test the assumptions behind the one-way doors, because those are the most expensive to find out were wrong later.

Plan around longer development cycles

Hardware runs on a different rhythm. Design, procurement, fabrication, integration, verification and manufacturing readiness all take time, and they depend on each other. One delayed component can hold up several teams. A late architectural change can trigger redesign, retesting, manufacturing updates and new documentation, and for a regulated medical device, updated risk assessments and additional verification too.

That makes cross-functional alignment critical. Product, engineering, clinical, quality, regulatory, manufacturing and supply chain all need a shared view of the requirements and how their decisions affect each other. But alignment shouldn't mean locking every detail down too early. I want teams to be clear about what's already committed, what's still flexible, and which open questions have to be answered before the next big investment. That keeps room to learn without pretending the physical constraints aren't there.

Longer development cycles don't make iteration less important. They make early, targeted iteration more valuable.

Same principles, different constraints

Whether I'm building software or surgical robotics hardware, I start with the same product questions. The difference is how fast we can learn, when we have to commit, and what it costs to change direction.

These are differences in degree, not hard rules. Safety-critical software has its own one-way doors, with long validation cycles and expensive architectural changes. But hardware adds physical constraints that change both the timing and the cost of product decisions.

Commit with the consequences in mind

A surgical robot brings mechanical engineering, electronics, software, controls and clinical workflow together in one system. Building it takes the same product judgment as software. The difference is that more hardware decisions are one-way doors. They show up in parts, suppliers, manufacturing processes and timelines, and once they're made, they're hard and expensive to undo.

The goal isn't to eliminate uncertainty before you decide. It's to know which doors are one-way, learn what you can before walking through them, and commit knowing what you're signing up for.

---

Reference: The one-way and two-way door framing comes from Jeff Bezos's 2015 letter to Amazon shareholders.