Building amazing products for patients

Gustavo
Docplanner Tech
Published in
5 min readMar 24, 2020

Well, usually when people think about products for patients, itā€™s common to imagine a technical solution, with a lot of medical terms and complex features to use. Actually, it doesnā€™t have to be this way (it canā€™t be this way!) if you want a successful product in healthcare.

Coronavirus showed us how vulnerable we are, but also opened our minds to think that health is universal. We are not patients only when we are sick; we are patients every day, everywhere. Itā€™s about creating healthcare products, not disease-care ones.

Our mission in Docplanner Group is really clear

Iā€™m the Product Manager of the Patient Experience area on Docplanner Group, and as a team, our goal is clear: make patientsā€™ lives easier and remind them that they love us. Of course, itā€™s not an easy task. As I mentioned, more or less accessible healthcare is everywhere, so to deliver an amazing experience in all touchpoints with patients is complex and requires time.

So, what I want to share here is not a cake recipe. These are some lessons Iā€™ve had along the way, and tips of how our team is working to achieve great results for patients. Here we go!

Dream big but start small šŸš€šŸ›“

When you are working in a complex market like healthcare, itā€™s common to make the mistake of thinking that everything is essential in the first version of your product or feature. You create a big project and, in the end, spend a lot of time on it. In these cases, you have higher chances to fail because, finally, you find out that it wasnā€™t exactly what your users expected from you.

In our team, we always have space to dream and think about amazing solutions for patients, but even if we discuss a lot and create a concept design, in the end, everybody knows it wonā€™t be the final version. We are aligned that after this concept design, we will start developing the ideas with the best balance between more impact, high confidence, and low effort.

Why do we use this approach? Because we know that more important than the final version is how many times we iterate and learn with our users. With each new update in production, we can collect new insights and be more aligned with our userā€™s needs.

Especially in healthcare, you can find many cases of companies that failed to try to create complete (a.k.a complex) solutions since day one. Now they are part of the failure statistics in healthcare. Some examples are Health Vault from Microsoft and Google Health, big players with a lot of users, channels and of course money, that were not able to identify the dynamic of the market and how to help their patients.

Remember, we have more stakeholders in the healthcare game that need attention šŸŽ®šŸšØ

Itā€™s not always the patient side that needs improvements. Sometimes we depend on other stakeholders changing their routines to make a feature successful, so consider them when you are planning to develop new things.

A good example is a chat feature that we were planning on improving because our researcher interviewed some patients and discovered they really need to have better communication with their doctors.

šŸ’”Our first idea when we heard about it was: Wow! Amazing! Letā€™s improve this feature for patients.

It was super clear what patients needed, but we knew this project had the potential to fail if we were not able to engage doctors first. Thatā€™s why we decided to start with them. We worked on understanding doctorsā€™ needs as well, and building a better chat feature for them. Look at how much we increased only focusing on the doctorā€™s side (I hid the absolute numbers on purpose), we increased 3x the use of this feature for example in the short term.

Have a multidisciplinary team with you and trust them to deliver great results šŸ’ƒšŸ¼ šŸ•ŗšŸ¼ šŸš¶šŸ¼ā€ā™€ļøšŸŽÆ

Healthcare is one of the most challenging markets to create great products, but if you have an aligned team, you can do this.

Patient Experience daily

As a PM, I donā€™t have all the answers to decide what and how to build something, the same for our product designer, researcher, product analyst and developers.

My mission is to make clear for the team what we want to achieve, and which are our KPIs.

If the team is aligned with the mission, the rest is easier. We try to slice our goal into some ideas, prioritize and discuss as a team what we can do before building it, to maximize the results and reduce the risk of failure. On this step, everybody has their contribution:

  • Data Analyst starts to collect and analyze data to have a data approach;
  • The researcher gets the data from the analyst, targets users, interviews them and does benchmarks to bring insights for the rest of the team;
  • Product designer starts to think about the concept and the minimum product viable, aligned with all of the info we have on the table;
  • Developers investigate and discuss approaches to deliver faster or to increase the quality of the solution.

I need to be honest, Iā€™m so proud of how my team connects with each other to deliver what patients want, ā€” especially while working in two different offices (Barcelona and Warsaw). Even with this barrier, the communication and alignment of the team is smooth šŸ’š

Are you ready to develop an awesome product for patients?šŸ˜šŸŽØ

Design and simplicity are some of the primary keys to have a great product, but also don't forget other common insights from other markets such as understand your acquisition channels and have a balance between quantitative and qualitative data to make decisions.

I hope that these learnings will help you with your products, especially if you want to impact thousands or even millions of patientā€™s lives. Healthcare is a complex market but one that does not give up because, in the end, you will be so proud to see what you built to save lives or to make healthcare more human, that all effort is totally worth it.

If you enjoyed this post, please hit the clap button below :) You can also follow us on Facebook, Twitter, and LinkedIn.

--

--