The 7 things I wouldn't do again building a healthtech startup as a COO

Delphine Groll

Cofounder & COO

Today, I can probably safely state that my sleep level is above the COO benchmark average. Of course, this does not mean that I sleep well (I still have two young children…). Let's just say that I'm less often awakened by the incessant thoughts related to the operational mayhem that is a startup on a daily basis. However dreamy this may sound, every entrepreneur knows that to get to that halfway decent level of sleep, the path is quite winding. Clients don’t grow on trees, neither do smooth operations. You have to jump over many hoops before you get to the finish line. Or what you think is the line, which is really the end of the first lap.

Overcoming these hurdles was difficult, and we are still doing it today. It took a lot of stamina to finally get successful with this product but we are now selling our platform to other healthcare companies. Now all inspirational bulls*** aside, I'll give you 7 pain points to consider early on to save you a lot of time and operational pain.

1 - Not having a clue what's going on with patients

Bear with me. Of course, as a non-healthcare professional, there is absolutely no way I would know what is going on with a patient. Doctor/patient confidentiality and the GDPR make it impossible. And while this is, of course, completely normal, it can also be quite frustrating when you are running medical operations. Launching a messaging app and not knowing how the conversations between your users and your medical team are going to make it impossible to find avenues for improvement. How do you do quality control? How do you ensure providers are using an empathetic tone? How do you monitor technical product issues? These are all questions you need to find answers to in order to grow and be better.

With this in mind, we decided to create different roles on our platform so that we can address these matters without ever compromising privacy. Providers have access to patient conversations and medical information, while reviewers or administrators can only see anonymized content. It has completely changed the way we understand not only our product but also our users, and I wish we had implemented it immediately.

The reviewer mode

2 - Using prehistoric physician scheduling tools

Ah, the good old scheduling conundrum. The perennial Excel sheet worked for a while, when we only had a few professionals working for us. But as time went on and the product grew in terms of users, we had to hire more providers to keep up with demand and diversify the specialties, and each one landed on the spreadsheet like an extra operational needle in my skin.

Fighting a lot of hours a day with little green rectangles to try to make it work for everyone was a major problem that required a magical product and engineering solution. To automate everything, we included a scheduling feature on the platform through which providers could select time slots during which they were available and have them validated by the operations team. This eliminated hours of daily back and forth and freed up valuable time to focus on improving the model. Since then, we have extensively optimized our scheduling feature to be able to provide a “Calendly for healthcare” to our clients. Okay, that's an analogy to a mega successful startup. Be glad I didn't pull out the "Stripe for health". Yet.

3 - Paying healthcare professionals on a per-hour basis

At first it seemed like a good idea. Until we quickly realized that we had created a major operational problem. When we started working with providers on our app, we decided to pay them on a per-day basis, in a fixed time slot. This was problematic for two main reasons: we needed the professionals to match patient requests throughout the day (or week) in terms of volume and specialty, and we also needed those physicians to be available in these time slots. However, with experience, we realized that professionals were mostly logging on to the platform between encounters, and that there was no point in having them sitting behind a screen waiting for patients' questions to arrive in their inbox. Especially given that, sometimes, there was not as many patient questions as we had anticipated and that, in that case, we were throwing money away.

Observing this, we introduced “flex slots”, meaning that professionals would commit to logging on and off for a day or half a day, and we would pay them on a flex slot-basis, not on a fixed amount of hours.

4 - Not realizing right away how different the cultures of startups and hospitals are

You think you know, because it seems obvious. But you don't know. Today, the DNA of startups is essentially asynchronous communication: asynchronous meetings, asynchronous decision making. When we first started managing our medical operations, we implemented hour-long "staff meetings" at the request of our care team, in which medical professionals would discuss patient cases and share their views. Which is, of course, good. However, these staff meetings eventually turned into two- or three-hour long discussions, with no real decision-making since they were, in fact, discussions.

We then realized that this was the result of trying to transfer synchronous hospital processes into a setting that, by nature, must be asynchronous. It was a huge waste of time and money and a great way to sink your business. In this case, informal synchronous discussions between providers are the way to go and you need to make a proactive and educational effort to instill the asynchronous culture in your care team, because as natural as it may seem to you, it is not natural to them.

5 - Being super slow to pick up on the added value of our product

As a very machine learning focused team, we always have exploratory projects outside of our "core" product and engineering development. We tend to think of them as "extra" features. Little AI-powered cherries on top of the cake of communication bricks. One mistake we made was to view the exploratory model that is now our core business as, well, exploratory. This machine learning model is our speech-to-text function: it extracts and structures encounter data to automatically deliver a report and update the patient's EHR. As we tested it, we found that it saved providers 40% of their note-taking and administrative time.

During our demos, we would show this functionality at the end, almost presenting it as "nice to have," like putting a ribbon on a gift. When in fact, the problem this feature solves is the lifeblood of our customers: saving clinical time on administrative tasks, and therefore driving business gains. Because this project was exploratory, and because we wanted to wait until it was almost "perfect," we didn't realize that not only was this functionality absolutely necessary for our customers, but it was also the core of our product. In a nutshell, what you put on the sidelines of your roadmap, or what you develop in your secret lab thinking "someday", might actually be what makes your business today.

The automated summary machine learning feature

6 - Not having more investors coming from the healthcare field

When we were raising funds for Nabla, we were incredibly fortunate to be supported by some amazing people in the tech world. They provided us with invaluable information along our journey as a company and as a team. However, in hindsight, perhaps we should have tried to connect with investors or business angels in the healthcare world to get a quicker understanding of its challenges and specificities.

7 - Being terrified of regulations

Finally, a big one. It's very easy - and very normal - to feel overwhelmed by the legal side of things when building a startup. Especially in healthcare where regulations are 1) many and 2) protecting patients. There's no way around them, you have to deal with it. When we first started diving into it, I did get that little scary feeling in my stomach of "Are we ever going to get out of this?". GDPR, HIPAA, FIHR... put the letters however you want, but to me it always spelled F***. Until I realized that I was looking at it the wrong way.

Health is, in essence, a matter of trust. Trust in your doctor, trust in the tools, trust in the processes. Regulations like GDPR are not a hindrance to your business. On the contrary, they are your best ally. And you need to take the most important ones into account from the start. This will allow you to build a privacy-by-design product that will reassure your users. They will trust you. It will also allow you to gain ground on the next set of regulations you will have to tackle. Building regulations into your product means building a user-centric product. And in the end, the user is all that matters.

There you have it folks

There you have it, the 7 things I would do differently to build Nabla as COO. But really, I would do them exactly the same. I wouldn't really have a choice. Running operations means always having your hands in the dirt, it means dealing with the unpredictable human component of running a business, every day. Sometimes you have to figure it out for yourself to really understand what's at stake and what it means for your product and your company. However, these are a few things you can be aware of, it might make running into the wall a little less painful. At least you'll see it coming.