Science and art of building tech products for doctors

Building at the intersection of tech and health is always fascinating and I haven't seen more activity in this space than last 12 months. As they start in this space, many new health-tech founders have shared with me their challenges while building tech products for doctors. So, let me share a framework based on my learning over the years from building for doctors, specially the ones who are running their practices.

Doctors & medical practices are a unique customer segment when it comes to tech products. They behave differently than your typical SMB customers and to build for them, it’s crucial to understand the hierarchy of their needs.

So, what are these needs, you ask? Well, let me introduce you to what I call the “Pyramid of needs for doctors”, with four levels:

1. At the base of the pyramid is Price. Like any other customer, the economic value of what doctors get from your product vs what they have to give needs to work.?

But in the case of doctors, what they give is much more than just the money that you are charging. It is also whether their existing workflow needs to change or what patient info they need to give or what extra activities their staff needs to do. Unless the economic value that they get is substantially high, you need to minimize what they give.

This is the baseline, and if this need is not met, the product is dead on arrival.

2. Next comes their need for Protection. Doctors are conditioned to seek reliability & predictability and be risk-averse. This risk-averseness is particularly high when it comes to their medical practice, which they have worked tirelessly for years to build.

They have a strong need to protect their base, protect what they have already built. This includes protecting their existing patient base fiercely, protecting the reputation of their practice, and protecting the relationships that they have with their patients, as well as other stakeholders.

Anything that risks that protection (e.g. fear of losing their patients if another provider consults the patient - sometimes even when the other provider is of a different specialty), will not be successful even if the pricing need is met.

3. Next on the pyramid is the need for Proliferation. Like any micropreneur, doctors want to grow their business. This can be done by getting more patients, or driving tangible patient retention & repeat visits, or generating more revenue per visit by providing more comprehensive care, or getting patients with more complex health needs like surgeries.

For independent practices, proliferation is far stronger and top of mind need than something around reducing costs (which is far more impactful at larger setups like hospitals).

4. Finally, the top of the pyramid is the need of Perception. This is the most evolved need. Doctors are acutely aware of how they are perceived by their patients and colleagues.?

The definition of perception may vary for different specialties and doctors. Good perception for them can be (1) patients perceiving them as one who is conservative in treatment approach, or (2) as someone who is commercially not too aggressive, or (3) as a doctor who ensures the latest & the best standard of care and is tech-savvy, or? (4) colleagues perceiving them as academically sharp, and some.

If your solution can tangibly build & improve long-term good perception for them and their practice, then there can be a long and fruitful partnership in the making.

How to use this framework?

Now, how do you use this “pyramid of needs for doctors” while building solutions for them?

While building for them, think about these needs starting from the base and working your way up. The formula for building successful tech products for doctors is to create something that solves at least two, hopefully three, and ideally all four of those needs.

Most health-tech startups make one of 3 mistakes:

1. Their “pricing” (which is the base need) is not right. What doctors get from their solution vs what they have to give doesn't make sense. And hence, dead on arrival.
2. They are solving just 1 of these needs. That is not exciting enough most of the time for doctors and your solution gets lost in 100s of other things they need to do or think about.
3. Their solution solves a need higher in the stack but misses solving for something towards the base. E.g. building something that can really proliferate the practice but poses risk to the protection need, will eventually not scale.

This framework is from what I have learnt building for this segment over the last 10 years. Like all good frameworks, this too will evolve with time but has served as a good starting point for me and hopefully will help you think structurely while building in this space.