I talk to doctors all the time who want to innovate, but instead get stuck doing what they already do well. An unsolved problem has no experts. To solve a hard problem, you will have to do things you’re not good at.
I trained for 10 years to be a surgeon: 4 years of medical school, 5 years of general surgery residency, and 1 year of surgical critical care fellowship. After all that time, I’m pretty good at taking care of surgical and trauma patients — as I should be. I like surgery. It’s fun to do things that I’m good at. But Suki doesn’t need a surgical critical care specialist.
At Suki, we want to solve a tremendous, unsolved problem in healthcare. We want to relieve doctors of the overwhelming administrative burden they’re facing.
We’re early. We’re a team of engineers and a couple doctors. We have to tackle the simple stuff first.
At this stage, my team doesn’t need my knowledge about ventilator weaning, or balanced transfusion strategies. Suki needs me to keep us within guardrails that serve basic doctor workflow. The company needed me to learn a role I knew nothing about: product management.
When I joined Suki as the product lead, I wasn’t sure that I would be equal to the task. I do not have an engineering background. One day I went home discouraged after hearing an engineer say of his previous product manager, “I knew I had a good PM when he asked me about changes I made to protobufs.” I had no idea what protobufs were. I knew my understanding of software engineering would never be on par with that person.
It’s taken me nearly a year to grow into this role. Just last week, as we were preparing for a major product launch, that same engineer commented that my debugging efforts are particularly useful because “you know the code.” That was validation. I have come to know our product intimately. I have weathered its storms and stood by like a proud parent in the moments when it shines.
To be clear, I do not know the code. I know how the product behaves, and I insist on understanding why it behaves that way. Our team communicates well. But they don’t understand surgery, and I don’t really understand software engineering.
Solving the problem of physician documentation requires combining skill sets from medicine and technology. It’s not easy for experts from these two fields to work together.
I’ve found overlap with engineers in our linear approach to problem-solving. But it’s uncomfortable for me to be in the dark about the technical tools. Similarly, it’s hard for the technologists not to know what doctors need to do their jobs. We have to trust each other to chart a path.
It’s like running a three-legged race. It’s a game where my ankle is tied to another person’s ankle, and we have to coordinate our stride as we run to the finish line. It’s awkward to work with this other person. I could run much faster on my own. But then I would be running a different race. To win this race, we have to learn to run together.
When solving a hard problem, prepare to feel like a novice. Prepare to break the problem into its simplest components. Prepare to get your hands dirty and learn something new. Doctors, your expertise is a key ingredient, but it won’t fit lock-in-key into any startup.
