Amy Kerdok on How to Build the Right Thing (Before You Build It Right)
Key Takeaways for Medtech Innovators & Investors
Build the right thing before you build it right. Early teams may not need every title on the org chart, but they do need the translation function: someone connecting clinical use, product requirements, validation, evidence, and intended-use claims.
Workflow observation beats assumptions. Observing the full workflow often reveals root causes and adoption risks that the procedure alone will not show. Without that view, teams can end up optimizing for the wrong problem.
Stand up the three-legged stool. Product, Clinical, and HF/UX need to stay connected so product direction, user workflow, and clinical proof move together.
Treat claims as strategic leverage. Clinical engineering is central to defining the validation work and evidence needed to support business-critical claims. That is where product definition, clinical proof, and the sales story come together.
Design for broader adoption. Strong products do not only work for KOLs. They reduce setup friction, workflow burden, and training complexity so more clinicians can succeed.
Introduction
In medtech, slipping milestones often trace back to a definition problem.
A team may be building quickly while the clinical use case, workflow assumptions, validation path, or intended-use claims are still being defined.
That is where clinical engineering becomes strategic. It helps teams translate clinical reality into the requirements, risks, evidence plans, and product choices needed to move forward.
That translation role was the focus of my conversation with Dr. Amy Kerdok at Coffeebar in Redwood City, a short walk from where she ran some of her first da Vinci cases. Over twelve years and four platform generations at Intuitive, Amy helped shape clinical engineering as a strategic function, then carried that lens into new domains, leading PM/HF/UX in dialysis, advising in structural heart, and now serving as Head of Product at Petal, newly out of stealth.
In this episode of Coffee with Clinical Engineers, we talked about two upstream moves that prevent expensive do-overs: build the right thing before you build it right, and stand up the three-legged stool of Product, Clinical, and HF/UX.
Q&A: Building the Right Thing (Before You Build it Right) with Amy Kerdok
Translation > Handoffs: The Clinical Engineering Advantage
Emma: Let’s start with the basics: what is clinical engineering?
Amy: It’s about translation. You’re translating between what a surgeon or clinician needs to do and the engineers who build it. That’s how you build the right product before you spend time and energy building the product right. CE has a role upstream and downstream — kind of birth to earth.
“Clinical engineers translate between the user and R&D. They’re a critical part of making sure the company builds the right product.”
Bilingual Problem-Solving
Emma: Take us back to the first time you felt the “translator role” in action. Practically, what does translation look like day-to-day?
Amy: My interview at Intuitive was unforgettable. They showed me the da Vinci robot, I think it was the S model, and walked me through a cholecystectomy on a pig. Then I flew to Ohio to observe a mitral valve repair where a clinical engineer was evaluating HD vision early on. I was hooked. I loved anatomy, loved how things worked, and I got to watch this surgeon operate . . . I was like, ‘Wow’. I realized this job was bilingual problem-solving. You take what you see in the field and turn it into things the team can act on to build the future of medicine.
From observation, you write requirements. From risk, you define mitigations and acceptance criteria. From intended use, you shape a claim hypothesis and the study design to earn it. That’s the work.
“Clinical engineering is bilingual problem-solving.”
Rust Lines & Root Causes: Why Observation Wins
Emma: Can you share a moment where field observation changed the product?
Amy: Early on at Intuitive, there was a complaint the system was rusting. A team of us went to observe and I stayed in the room between cases. A janitor came in with a mop, raised it, and sloshed water across the equipment. You could literally see a rust line where the water hit. Add Louisiana humidity and an exterior wall — there’s your root cause. If you don’t watch the whole workflow, you’re going to “optimize” the wrong thing.
The Three-Legged Stool of Upstream Medtech
Emma: How should medtech teams organize their upstream functions? Where does Clinical Engineering fit?
Amy: I think of it as a three-legged stool.
Product (what/why): value proposition, timing, market needs.
Clinical (does it work safely/effectively): requirements, risks, validation, label language.
HF/UX (how it’s used): workflow, error traps, training curve, making sure it’s an awesome experience.
The integration of these really matters. I see clinical engineers as the internal customer for R&D — we’ve been out there and bring the real-world use inside. Product is the external customer, helping with KOLs, conferences, publications, and timing.
Upstream Medtech Product Development: Three-Legged Stool
Product, Clinical, and HF / UX form the three legs of upstream medtech decision-making: what to build, what to prove, and how it will be used. When they stay connected early, teams reduce downstream rework and build a stronger adoption story.
Before You Build: Who Owns Translation?
Emma: For founders — when do you bring CE into the room?
Amy: Day one. Call it whatever you want, but someone has to define what it needs to do clinically and how you’ll prove it. You need someone to go figure out what tissue it’s going to interact with, what energy it needs to be, how sharp does it need to be, stuff like that.
If you’ve got a platform with multiple applications, you may decide to call that role a Clinical Engineer. If it’s a technology with one application, then a Product Manager plus Clinical/Medical Affairs can work too. Someone still owns the translation and validation path.
At a startup, one clinical engineer might represent all three. As you grow, you specialize. CE keeps integrating across them.
CPI Lens
Amy’s point is especially relevant for early teams: the title may vary, but the translation function cannot be missing. Someone has to connect clinical use, requirements, usability, validation, and evidence before adoption assumptions harden into product decisions.
Beyond Definition: Validation, Evidence, and Claims
Emma: After the product definition phase, how does CE help the business?
Amy: I see clinical engineers as responsible for the clinical claims—writing the validation test cases and doing post-market studies so the company can earn those claims. We’re also out in the field seeing misuse patterns, the things that will go bad if you don’t fix them, and bringing that back so the team solves it. That’s what moves adoption.
At the end of the day, people are either going to buy it or not, so make sure you’re getting the clinical safety and efficacy you claim the product can deliver. When your claims, requirements, and evidence are clear, sales has a grounded story.
“I see clinical engineers as responsible for clinical claims. That includes writing the validation test cases and going out and doing post-market studies so that you can get those claims for the business.”
Design for the Median, Not the Unicorn
Emma: What about designing for adoption beyond KOLs?
Amy: With da Vinci Xi, we lowered barriers: ports in a line, instruments that reach, fewer collisions. A superstar surgeon said, “You just took my job away — now everybody can do what I do.” That’s actually a sign that you’re on the right track. Of course you still need a skilled physician, but the tool should help more people do good surgery.
Early on we had users who didn’t mind the setup or the coordination. To grow though, you need to make design improvements that lower the bar and make the technology more accessible, so that more surgeons can do the case with ease.
So You Want to Be A Clinical Engineer
Emma: Any advice for people who want to get into CE?
Amy: Stay curious. Don’t let a title define you. Learn enough of both languages to translate honestly. You’re out there in the field, you’re learning, you’re writing the spec. Say yes to things that stretch you. Learn something from every project.
What This Means for Medtech Teams
Clinical engineering is not only a bridge between clinicians and engineers. At its best, it is a decision function.
It helps teams see whether the product is solving the right clinical problem, fitting the real workflow, generating the right evidence, and supporting a credible value story for the business.
For medtech founders and product leaders, the question is not simply, “Do we have clinical input?”
It is:
Are we translating that input into the product requirements, validation decisions, usability priorities, evidence strategy, and adoption story we need to move forward?
If your team is seeing gaps between clinical insight, product direction, usability, validation, evidence, or go-to-market readiness, CPI can help make those gaps visible earlier and translate them into clearer next decisions.
Related Links
CPI on LinkedIn— Follow CPI for insights, updates, and case studies.
