Desirability, feasibility, viability: deciding what to build

Surgeons have been asking for an ergonomic chair for robotic surgery consoles for years, and it's easy to see why. Procedures can run long. Surgeons deal with neck and back pain, struggle to find a comfortable position, or have trouble reaching the foot pedals while holding the posture they need to operate. A purpose-built chair sounds like the obvious answer.

So should a robotic surgery company build one? My first instinct isn't yes or no. It's to understand the problem behind the request, and then to ask whether the solution is something we can deliver and something that makes financial sense. A feature request is evidence of a need. It isn't yet a decision about what to build.

The framework I use for this is desirability, feasibility and viability, or DVF. It was developed by the design firm IDEO as a way to evaluate new products and features, and as Product School's Carlos Gonzalez de Villaumbrosia explains, it asks whether something solves a real user problem, whether it's technically and operationally possible to build, and whether it's profitable and aligned with business goals. At Intuitive, we use DVF regularly to evaluate products. As a product manager, desirability is mine to own, and I give input into viability. I've worked across medical devices, robotics and clinical AI, and I've found it holds up whether the product is physical or digital.

Desirability: is this the right problem to solve?

Desirability starts with discovery. With the chair, I'd talk to surgeons and watch them at the console. Where does discomfort show up, and how does it change over a procedure? Does the setup work for surgeons of different heights? What have they already tried? The issue might be the seat, the geometry between the chair, console and pedals, or just the strain of a long case. If it's the geometry, a better chair alone won't fix it.

Software works the same way. If a clinician asks for more information on an AI alert, we could add more fields. But the real problem might be that they can't see what changed or why the alert matters now. More information could help, or it could just add cognitive load.

Then I validate the problem. How often does it happen, how many people does it affect, and what are the consequences? A problem that affects fewer users can still matter if the clinical stakes are high. Finally, I look at portfolio fit. Even a real problem has to compete with everything else on the roadmap. Is this the most important ergonomic problem we could solve, or the most important workflow problem? The goal of desirability isn't to validate the requested feature. It's to validate the problem worth solving next.

Feasibility: can we deliver it, and what's the smallest version that works?

Once the problem is clear, I look at what we can actually build, validate and support. A purpose-built chair means design, manufacturing, testing across console models and body types, and long-term service. A redesigned alert might need new data integrations or clinical validation. In healthcare, patient safety, clinical evidence and regulatory requirements shape all of this.

Feasibility is also where I look for the smallest solution that still delivers real value. For the chair, console adjustments, positioning guidance or compatibility with existing ergonomic seating might address the core need. For the alert, leading with the risk trend and the key clinical changes might give clinicians the context they want without crowding the screen. If the full feature would take six months, I want to know whether something narrower could solve the most important use case sooner. The goal isn't to build less. It's to use the right amount of complexity for the problem.

Viability: does the investment pay off?

Viability is the financial question. Will this generate enough return to justify what it costs to develop, manufacture and support? For the chair, that might mean asking whether it drives system sales or can be priced to cover its costs, and whether partnering with a seating manufacturer or supporting third-party chairs would deliver similar value more economically. For the alert, it means asking whether a better experience drives adoption, renewals or new sales enough to justify the integration and validation work.

A feature can be desirable and feasible and still not be viable. That's often where the right answer becomes a partnership, a narrower version, or "not yet." It doesn't mean the need isn't real. It means we have to be deliberate about where we invest.

Putting it into practice

The chair and the alert are very different problems, one about hardware and physical ergonomics, the other about information design and clinical workflow. But the questions follow the same logic.

	Surgeon console chair	Clinical AI alert
Desirability	Where does discomfort start: the seat, posture, pedal reach, or how the chair, console and pedals fit together? How common and severe is it? Is it the most important ergonomic problem in our portfolio?	Is the clinician missing data, or missing context on what changed and why it matters now? How often does this get in the way of a decision? Is it the most important workflow problem on our roadmap?
Feasibility	Can we design, test and support a chair across console models and surgeon body types? Could console adjustments or compatible seating solve the core need with less effort?	Do we have the data and integrations to show the trend and key changes? What clinical validation would it need? Could a smaller design change get most of the way there?
Viability	Does a chair generate enough return to cover development and manufacturing? Is building it more economical than partnering or supporting third-party seating?	Does a better alert drive adoption, renewals or new sales enough to justify the investment?

None of these have predetermined answers. They're a way to avoid committing to a solution before understanding the need, the alternatives and the economics. A feature request tells us where to look. Product judgment decides what to do next, and that's the difference between managing a backlog and leading a product.

Reference: Carlos Gonzalez de Villaumbrosia, "DVF Framework Explained: Build Better Products," Product School, 2025. The DVF framework was originally developed by IDEO.