Medical tech product development: How to tell someone
their ‘baby’ is ugly

Editor’s Note: In her previous blog post, Lalita Abhyankar, MD, MHS, FAAFP, wrote about the need for family physicians to be involved in medical tech product development. In this follow-up post, she writes that giving feedback to product developers is a skill that takes practice.

I used to engage with tech designers and product engineers with incredulity. If I was beta testing a product I didn’t like, my feedback was harsh. 

Unsurprisingly, it was also often dismissed.

“Well,” I would hear, “as long as it does what we need, we don’t have time to make the changes you’re talking about.”

The irony was that I was commenting on how the product wasn’t useful and wouldn’t be adopted quickly. I was usually right.

A new approach: Show and tell

So I started telling developers stories about what I was looking for or how I was trying to beta test the product during a clinical day. I encouraged the team members to shadow me in the clinic. Instead of giving the product team my assessment, I decided to share my subjective and objective findings first, the same way I would when presenting a patient case. 

A remarkable thing happened. Instead of offering workarounds on how to use the product more efficiently and placing the onus on me, the team evaluated the facts of my use.

“Oh,” I was told, “based on what you’re saying, it’s just not going to work the way it is built right now.”

The team was now curious. I was able to offer more examples of use cases. Notes were taken furiously. 

Collaboration: Building a more usable tool

Product teams, like family physicians, are trained to be diagnosticians. The more a family doctor knows about a patient’s circumstance, the better we can create personalized plans for patients based on their home life, circumstances, symptoms, affordability, etc. Product teams do the same, expect they often don’t know the information they need until we give them the parameters within which they need to design. The best product people, like us, are excellent at assessing needs. Those with less experience need clear specifics and storytelling to understand the problem that they are solving for. As a non-product person, I don’t actually know the constraints or capabilities of the software. I tend to suggest solutions that replicate paper charts. But a fresh pair of technical eyes can create a more seamless solution that optimizes the technology we actually have.

When the product team got back to me, they had moved a few buttons around and changed the colors and the general flow. These minimal alterations suddenly made the tool usable and even effective. It wasn’t perfect, but it wasn’t, to quote the words I used originally, a “useless time-suck” of a product anymore.