← carlossanchez.me

Doctor24 Case Study: From MVP to Scheduled Calls

Context

Doctor24 was born as a service that allowed users to talk to doctors online. The initial idea was simple: log in and do a video call with one of our physicians online.

Visiting a doctor takes time and effort. As a result, many people self-medicate or just wait until they feel better. But prevention is better (and in the long term cheaper) than cure, so we wondered what could we do to remove friction between patients and physicians. The main hypothesis behind Doctor24 was: people will seek medical advice more often if we allow them to easily connect with a doctor anytime, anywhere.

The MVP

When you are building medical products, you can't just move fast and break things. You are dealing with highly sensitive data and you have to make sure you are complying with the law in the countries where you operate. With this in mind, we set out to validate our main hypothesis as fast as possible following a lean strategy. Our MVP was a law-compliant web app that allowed patients to do unscheduled calls with primary care physicians.

Why a web app? Because it was the fastest way of building the apps for both patients and doctors using the same technology.

Why unscheduled calls? Because scheduled calls are way more complex. More on that later.

Why primary care physicians? Because that way we could solve a high percentage of relatively simple medical cases with a small team of physicians.

With this MVP, we wanted to answer the following questions:

• Are users in Spain ready for telemedicine?
• What percentage of medical problems can be solved with video calls?
• What kind of medical problems will users try to solve with the service?
• What do users prefer: talking to any doctor as soon as possible or choosing their doctor?
• What is an acceptable waiting time for a patient?
• Will users sign up before they need to make a call?

MVP challenges

If you use services like Hangouts or Skype, you know that many things can go wrong during a video call. But when a video call is also a medical consultation, things get even more complex. Each call is a virtual visit with an input (all the information provided by the patient), the call itself, an output (the medical opinion or diagnosis and the treatment) and an associated cost. We could only guarantee a fast and stable internet connection on the side of the doctor so we had to deal with frequent interrupted calls. It didn't take us long to learn about the users expectations in these situations:

• Patients wanted to resume the call with the same doctor.
• Patients didn't want to provide all the information about their medical problem again.
• Doctors didn't want to rewrite the diagnosis or treatment if they had already done it.
• Patients didn't want to see a failed call on their medical records, they just wanted to see the output of the consultation (a solution for their problem).

The MVP didn't allow users to choose a doctor to talk to. All they could see was a "Talk to a doctor now" button. When a call was interrupted, there was no way to reconnect with the same doctor right away, but this wasn't a big problem in the beginning since most of the time there was only one physician online. If a call was interrupted and the user called again, chances were that the same doctor would answer.

If all doctors were busy, we displayed an estimated waiting time by the "Talk to a doctor now" button and moved the patients to a virtual waiting room until one of the doctors became available.

The pilot

Doctor visits cost 330€/year per employee to companies in Spain so we saw an opportunity to commercialize Doctor24 as a B2B service that companies could offer as a benefit, saving time to their employees and money to the company. We partnered with a pharmaceutical company to run a three-month pilot, giving access to the service to all of their employees in Spain.

These are some of the things we learned from running the pilot:

• Users were good at guessing whether their medical problem could be solved with a video call or not. Our doctors were actually able to solve 83% of the medical problems patients presented.
• Users were skeptical about the service until they tried it.
• Users wanted to do follow up calls with the doctor they first talked to about their problem.
• Recurrent users preferred talking to a doctor they already knew and trusted. At the same time, they loved the immediacy of pushing a button and connecting with a physician right away.
• If the video and the audio didn't work, users were fine using the integrated chat. This was interesting and it made us realize that we could have probably started with a much simpler MVP, offering a chat-based service.

By the time the pilot was over, the main questions we had when the project started had been answered; Doctor24 could solve real problems and patients found it useful. We were ready to start commercializing the service to validate the product/market fit while our product team focused on solving the problems detected during the pilot.

At this point it was decided to iterate the product in a direction that could allow us cover two different use cases:

• Connecting with a doctor right away, which was useful for first time users and users with emergencies.
• Talking to your doctor, which was useful for follow up calls and recurrent users.

Scheduled Calls

After the pilot we decided to start working on Scheduled Calls to try to solve the main problems detected so far. The idea was: if your doctor is available you can connect right away. If your doctor is not available, you can choose between talking to another physician or booking an appointment with your doctor. Scheduled Calls also opened the door to solve another problem mentioned earlier: reconnecting after a call is interrupted.

Scheduled Calls challenges

The main reason why our MVP offered Unscheduled Calls only was that things get much more complex when you start thinking about Scheduled Calls. These are some of the things that you have to take into consideration:

• You need to establish medical shifts.
• You have to confirm that doctors are actually online during their shift.
• You need to define time slots.
• You need to plan for overlapping appointments.
• You need to display and remind appointments to both patients and doctors.
• You have to consider appointment cancellations.
• Even if an appointment is scheduled, the patient can't enter the virtual room until the doctor is available on the other side.

The solution

Appointments overlapping was one of the hardest problems to crack. In order to schedule appointments you need to define time slots, but you can't just end a call if the conversation between patient and doctor isn't over when they ran out of time. Our medical team made that point very clear.

During the call there was a timer that was only visible to the doctors. In calls that exceeded their scheduled time, doctors were informed whether there was a patient waiting or not. With this information, doctors could decide among:

• Inviting the patient to book another call to continue the conversation later.
• Wrapping up the call to talk to the next patient.
• Continue talking to the patient knowing that nobody was waiting.

We agreed with our medical team to start offering 15-minute slots and then measure whether that was enough, too much or too little. We also allowed users to book appointments with a doctor up to 2 minutes before the appointment. This was the way we provided users to talk to their doctor right away if he or she was available.

During appointments, users and doctors could easily reconnect if the call was interrupted, solving one of the most annoying problems from the MVP.

To continue offering the "Talk to a doctor now" service, we used all the non-booked time during the shifts of some of our physicians. During service hours there was at least one doctor available for calls without appointment. Other doctors would only connect if they had appointments previously booked. This also gave us flexibility to work with both full-time and part-time physicians.

The results

Our solution for Scheduled Calls seemed to solve the main problems detected with the MVP and even though the complexity of the product had increased, user testing showed that both patients and doctors still found it quite intuitive. On top of this, solving the problem of reconnecting interrupted calls made the service much more scalable.

Unfortunately, sales were not taking off while we were working on Scheduled Calls. Whereas our users found Doctor24 useful, our clients (the companies) didn’t find the service valuable enough. We considered alternative pricing models and pivoting to B2C, but in the end the service was discontinued. We will never know if Scheduled Calls would have made the service more appealing to companies.

We didn't find product/market fit, but everyone involved in this project saw the potential of services like Doctor24. We strongly believe that in the near future, patients and doctors will only meet in the same physical space when strictly necessary. Focusing on prevention and early detection of health issues is in the interest of everyone; those providing the medical services will save a lot of money and patients will live healthier lives.

← carlossanchez.me