healthtech product management
In healthtech, you are not building for one user. You are building for a patient who is scared, a doctor who has four minutes, an insurer who wants to deny the claim, and a regulator who will shut you down if you get consent wrong. The PM who treats this like a consumer app will fail within two quarters.
Most product managers enter healthtech thinking it is a technology problem. Build a clean app, get the UX right, run some growth experiments. Then they sit in their first meeting with a chief medical officer and discover that the person who uses the product, the person who prescribes it, the person who pays for it, and the person who regulates it are four different people with four conflicting incentives.
This is the fundamental challenge of healthtech PM. Not the tech. The stakeholder geometry.
A patient wants the cheapest treatment. A doctor wants the most clinically appropriate one. An insurer wants neither and prefers that nobody gets sick in the first place. A government body wants all three of them to use a common digital infrastructure so it can measure population health outcomes. You, the PM, must build a product that somehow serves all four. If you optimise for one at the expense of the others, your product either does not get adopted, does not get paid for, or gets shut down.
The four-party problem nobody warns you about
In consumer tech, your user is your customer. In SaaS, your user and buyer might differ. In healthtech, you have four distinct parties:
| Party | What they want | What they fear | PM implication |
|---|---|---|---|
| Patient | Quick relief, affordable care, dignity | Being cheated, data misuse, wrong diagnosis | UX must build trust in the first 30 seconds |
| Doctor | Clinical accuracy, less admin burden, liability protection | Misdiagnosis blame, patient overload, losing autonomy | Doctor-facing tools must save time, not add it |
| Payer (insurer/govt/employer) | Cost control, fraud prevention, outcome data | Over-utilisation, fraudulent claims | Your product must generate claims data and outcome metrics |
| Regulator | Patient safety, data privacy, interoperability | Unproven treatments, data breaches, vendor lock-in | Compliance is not a phase. It is a feature. |
Every feature you build touches at least two of these parties. Most features touch three. The PM who optimises only for the patient experience will build a beautiful app that no insurer will cover and no doctor will recommend. The PM who optimises only for the doctor will build a clinical tool that patients cannot understand.
Practo learned this the hard way. Their early product was a doctor-booking platform optimised entirely for patient convenience. Patients loved it. But Practo had no pull with doctors because the platform added admin work without reducing it. The shift toward practice management software — where the doctor got value independent of patient bookings — is what made the marketplace actually work. The patient experience improved because the doctor experience improved first.
ABDM is India’s UPI moment for health
If you are building healthtech in India and you are not building on ABDM, you are building on sand.
The Ayushman Bharat Digital Mission is India’s national digital health infrastructure. Think of it as UPI for health data. It provides three things:
ABHA (Ayushman Bharat Health Account): A 14-digit health ID for every Indian citizen. This is the unique identifier that ties together a patient’s records across hospitals, labs, pharmacies, and insurers. As of early 2026, over 600 million ABHA IDs have been created.
Health Information Exchange and Consent Manager (HIE-CM): The protocol that lets patients share their health records across providers. A patient visits Apollo Hospital in Chennai, gets a blood test at SRL Diagnostics in Hyderabad, and fills a prescription at a 1mg pharmacy in Bangalore. ABDM makes it possible for all three records to be linked to the same ABHA ID — but only with the patient’s explicit consent.
Health Facility Registry and Health Professional Registry: The directories that verify that the hospital is real, the doctor is licensed, and the lab is accredited. This solves the trust problem that plagued Indian healthtech for years — patients had no way to verify that a teleconsultation doctor was actually qualified.
The PM implications are concrete:
Integration is not optional. Every hospital information system, every pharmacy chain, every diagnostics lab, every insurance company will need to speak ABDM. If your healthtech product does not integrate with ABDM APIs, it will be locked out of the interoperability layer. This is not a “nice to have” roadmap item. This is table stakes for 2026 and beyond.
Consent architecture is a product feature. ABDM uses a granular consent framework. A patient can share their blood reports with their cardiologist but not their mental health records. They can share data for six months and then revoke. Your product must implement this consent flow natively — not as an afterthought buried in settings.
Data format matters. ABDM uses FHIR (Fast Healthcare Interoperability Resources) as the data standard. If your internal data model does not map cleanly to FHIR resources, every ABDM interaction becomes a translation exercise. The earlier you design your schema around FHIR, the less pain you carry.
Telemedicine in tier-2/3 India is a trust problem, not a tech problem
Post-COVID, teleconsultation is mainstream in metros. Practo, Apollo 24/7, MFine, Tata Health — all grew enormously between 2020 and 2023. But the real opportunity and the real challenge is in tier-2 and tier-3 India.
The numbers are compelling. India has 1 doctor for every 1,456 people at the national level. In rural Rajasthan, it is 1 for every 10,000+. Telemedicine is not a convenience play in these markets. It is often the only way to access specialist care without a 6-hour bus ride.
But here is what most metro-based product teams get wrong: the barriers in small-town India are not what you think they are.
Trust, not tech, is the primary barrier. A 55-year-old shopkeeper in Jhansi does not distrust technology. He uses Paytm and WhatsApp daily. What he distrusts is the idea that a doctor can diagnose him without touching him. “Can you really tell what is wrong with me through a screen?” This is not irrational. It is a reasonable scepticism that your product must address directly — with visible credentials, with video (not just audio), with follow-up mechanisms that feel reliable.
Connectivity is intermittent, not absent. The problem is not that rural users lack internet. 4G coverage in tier-2/3 India is extensive. The problem is that it drops. Frequently. A teleconsultation that freezes mid-sentence destroys trust permanently. Your app must handle disconnection gracefully — automatic reconnection, session persistence, the option to switch from video to audio to text without losing the consultation context.
Language is non-negotiable. A doctor in Lucknow speaking English to a patient in Varanasi who speaks Bhojpuri is not a teleconsultation. It is a performance. Your product needs regional language support — not just translated UI strings, but the ability for the doctor to write prescriptions and clinical notes in the patient’s language.
The elderly patient has a proxy user. In many Indian households, a grandchild or daughter-in-law operates the phone for the elderly patient. Your UX must account for a proxy user who is navigating the app but is not the patient. This has consent implications. It has prescription implications. It has follow-up implications. MFine addressed this partially with their “family profiles” feature — one account, multiple patients. But the proxy user pattern runs deeper than account management.
Payment expectations differ. In a metro, paying Rs 500 for a teleconsultation seems reasonable. In a tier-3 town, the local doctor charges Rs 100 for an in-person visit. Your pricing must reflect local willingness to pay, or patients will walk to the local clinic every time. Practo’s flat-fee model struggled in smaller cities until they introduced variable pricing by city tier.
Product review meeting. The healthtech PM is presenting a new teleconsultation feature to a panel of doctors before launch.
PM: “We have built an AI-assisted symptom checker that patients fill out before the consultation. It pre-populates the clinical notes so you spend less time on history-taking and more time on diagnosis.”
Senior Cardiologist: “How was this AI trained? On which patient population? If it was trained on American clinical data, the symptom patterns will be wrong for Indian patients. Cardiovascular risk profiles are different here. Diet is different. Genetic predispositions are different.”
PM: “The model was fine-tuned on de-identified data from Indian hospital systems. We partnered with three chains — I can share the training data demographics.”
General Physician: “My concern is different. If the AI pre-populates notes, patients will assume the AI has already diagnosed them. They will come into the consultation expecting confirmation, not evaluation. That changes the doctor-patient dynamic in a way I am uncomfortable with.”
PM: “That is a fair point. What if the patient-facing language says 'we have shared your symptoms with the doctor' rather than showing a preliminary assessment? The clinical notes go to the doctor's screen only.”
General Physician: “Better. But you also need to handle the case where the AI summary is wrong. If I have to spend time correcting the AI's notes, you have not saved me time. You have added a step.”
Senior Cardiologist: “Show it to me as an editable draft with a one-click discard. If the summary is useful, I keep it. If it is not, I start fresh without fighting the interface.”
The PM came in selling time savings. The doctors reframed the conversation around clinical accuracy and patient perception. Both concerns were valid. The feature shipped with an editable draft that doctors could discard with one tap — and a patient-facing screen that said 'your doctor has received your information' with no clinical assessment visible.
Doctors are stakeholders with clinical expertise and legitimate concerns about patient safety. The PM who dismisses clinical objections as resistance to change will lose doctor adoption — and without doctor adoption, there is no product.
Health data privacy is where careers end
Health data is the most sensitive category of personal data. In India, the DPDP Act (2023) classifies health data as sensitive personal data requiring explicit, specific consent. But the Act is just the floor. The real constraints come from multiple overlapping frameworks.
DPDP Act requirements for healthtech:
- Consent must be free, specific, informed, and unambiguous. A blanket “I agree to data processing” checkbox will not survive a challenge. The patient must know exactly what data is being collected, who will access it, and for how long.
- Right to erasure applies. A patient can demand that their health records be deleted. Your system must honour this — including from backups, analytics pipelines, and any third-party sub-processors.
- Data fiduciaries (that is you, the healthtech company) are liable for breaches. Not “we will pay a fine” liable. “The founder and CTO can face personal criminal liability” liable.
Telemedicine Practice Guidelines (2020):
- Prescriptions from teleconsultations must follow Schedule H, H1, and X drug regulations. Your product cannot allow a teleconsultation doctor to prescribe Schedule X drugs (narcotics) remotely. If your prescription workflow does not enforce drug scheduling rules, you are building a compliance time bomb.
- The patient must be identified before consultation. This means your KYC flow is a clinical requirement, not just a fraud-prevention mechanism.
ABDM consent framework:
- As discussed above, consent artefacts have explicit durations and purposes. Violating a consent artefact is not just a privacy breach — it is an interoperability breach that can get your product delisted from the ABDM network.
The PM’s job is not to become a lawyer. It is to ensure that consent is a first-class product feature, not a legal annotation. The consent flow must be as carefully designed as the onboarding flow. It must be testable. It must be auditable. And it must be built before the first patient interaction, not retrofitted after launch.
At Narayana Health’s digital platform, the consent architecture was redesigned three times before launch. Each iteration was driven by a different regulatory requirement that the product team had not anticipated. The lesson: build your consent model by studying every applicable regulation before writing a single user story, not after.
Working with doctors requires a different PM playbook
Doctors are not users in the way product managers typically think about users. They are domain experts with years of specialised training, strong opinions about clinical workflows, and approximately four minutes of attention to give you.
Here is what changes when doctors are your stakeholders:
You cannot user-test your way to a good doctor tool. Consumer PMs are trained to observe users, find friction, and smooth it. With doctors, the friction is often clinically meaningful. A doctor who pauses before prescribing is not experiencing bad UX. They are exercising clinical judgement. The PM who tries to “streamline” clinical decision points without understanding what those pauses mean will build a dangerous product.
Doctors evaluate credibility instantly. If you walk into a meeting and say “our data shows that users prefer a simpler interface,” a doctor hears “this person does not understand my work.” If you say “our prescription turnaround data shows that 40% of consultations have a lag between diagnosis and medication order — we want to understand whether that is a workflow gap or a clinical decision point,” the same doctor leans forward. Specificity and clinical vocabulary earn you time. Generalities get you dismissed.
Design for interruptions. A doctor in an Indian hospital sees 60-80 patients a day in OPD. They are interrupted constantly — by nurses, by patients in the hallway, by phone calls. Any interface that requires sustained linear attention will be abandoned. Design for glanceability. Design for resumption after a 90-second interruption. Design for one-handed use while the other hand holds a stethoscope.
Involve doctors early, but structure the involvement. Do not put a doctor in a room with wireframes and ask “what do you think?” You will get two hours of opinions and no actionable insight. Instead, present three specific design choices with the clinical trade-off of each and ask them to choose. Doctors are trained to make decisions with constrained options. Give them constrained options.
E-pharmacy is a regulatory minefield with massive upside
The e-pharmacy segment — 1mg (now Tata Health), PharmEasy, Apollo Pharmacy, Netmeds — is one of the fastest-growing verticals in Indian healthtech. It is also one of the most heavily regulated.
Drug scheduling determines what you can sell and how. India classifies drugs into schedules: Schedule H requires a prescription, Schedule H1 requires a prescription and tracking, and Schedule X covers narcotics and psychotropic substances. Your product must enforce these rules at the cart level. If a patient adds a Schedule H drug to their cart, the checkout flow must require prescription upload and verification before processing.
Generics substitution is a product feature with clinical and business implications. When a doctor prescribes Brand X, can the pharmacy suggest Generic Y? Legally, in India, pharmacists can substitute generics — but the prescription must be for the generic name (INN), not a branded formulation. Your product can prompt generic alternatives, but the substitution logic must respect the clinical equivalence and the prescription wording. 1mg built this into their platform early, and it became a competitive advantage — patients saved money, and 1mg earned trust as a “patient-first” platform.
Prescription validation is harder than it looks. A prescription is a photograph taken on a phone camera in poor lighting, often with illegible handwriting. Your OCR pipeline will fail on a significant percentage of prescriptions. You need a fallback: human pharmacist review with an SLA. The PM who assumes OCR accuracy of 95% and builds a fully automated pipeline will discover that the 5% failure rate includes the most dangerous drugs — the ones where misreading a dosage is a medical emergency.
Cold chain logistics constrain your catalogue. Insulin, vaccines, and certain biologics require cold storage throughout the delivery chain. If you list these products, your fulfilment operation needs temperature-controlled logistics. The PM must decide: do you list the full pharmaceutical catalogue (including cold chain) or restrict to ambient-storage drugs? PharmEasy expanded into cold chain; it required different delivery partners, different packaging, and different SLAs. The product decision drove the operations strategy.
Pick one Indian healthtech app: Practo, Apollo 24/7, 1mg, PharmEasy, or any healthtech product you use. Walk through the complete patient journey from first interaction to post-consultation follow-up.
For each step, document:
- What builds trust at this step? (Doctor credentials visible? Verified pharmacy? Transparent pricing?)
- What erodes trust at this step? (Unclear pricing? No doctor photo? Generic AI responses? Unexplained data collection?)
- Where does the patient hand off control? (Entering symptoms, sharing records, accepting a prescription they cannot fully evaluate)
- Where would a tier-3 city patient drop off that a metro patient would not?
Mark the single highest-risk trust moment in the entire journey. Now ask: what does the product do at that moment to reinforce trust? If the answer is “nothing” — you have found the most important product improvement.
You are PM at Apollo 24/7's teleconsultation product. Your doctor utilisation data shows that the average GP consultation on the platform takes 9 minutes — 5 minutes longer than a typical Apollo clinic visit. Exit interviews with doctors reveal the reason: the symptom intake form, which patients fill before the call, is poorly structured and forces doctors to re-collect the same information verbally. Your engineering team can rebuild the intake form to cut re-collection time and get consultations to 6 minutes. The business case is clear: faster consultations means more capacity, more revenue, more doctor earnings. But the medical director raises a concern — for certain symptom clusters (chest pain, breathlessness, mental health flags), shorter consultations increase misdiagnosis risk.
The call: Do you rebuild the intake form to reduce consultation time, or keep the current flow that doctors find inefficient but clinically safe?
You are PM at Apollo 24/7's teleconsultation product. Your doctor utilisation data shows that the average GP consultation on the platform takes 9 minutes — 5 minutes longer than a typical Apollo clinic visit. Exit interviews with doctors reveal the reason: the symptom intake form, which patients fill before the call, is poorly structured and forces doctors to re-collect the same information verbally. Your engineering team can rebuild the intake form to cut re-collection time and get consultations to 6 minutes. The business case is clear: faster consultations means more capacity, more revenue, more doctor earnings. But the medical director raises a concern — for certain symptom clusters (chest pain, breathlessness, mental health flags), shorter consultations increase misdiagnosis risk.
The call: Do you rebuild the intake form to reduce consultation time, or keep the current flow that doctors find inefficient but clinically safe?
Career stages in healthtech PM
If you are 0-2 years in: Healthtech is a hard vertical to enter without domain knowledge. The fastest path in is through a healthtech startup (Practo, PharmEasy, and Apollo 24/7 all hire junior PMs) where you will learn the regulatory landscape on the job. Your first year should focus on understanding the clinical workflow your product serves. Shadow a doctor for a day. Sit in an OPD waiting room. Watch how patients interact with the hospital’s digital systems. The PMs who skip this fieldwork never develop the intuition that separates a feature-builder from a healthtech PM.
If you are 3-5 years in: At this stage, you should own a specific vertical — teleconsultation, e-pharmacy, diagnostics, or insurance claims. The differentiation comes from your ability to translate clinical requirements into product specs. The PM who can read a Telemedicine Practice Guideline and extract the twelve product requirements buried in it is far more valuable than the PM who waits for the compliance team to file tickets. ABDM integration experience is becoming a career accelerator. The PMs who go through a full ABDM integration cycle — sandbox, production approval, consent implementation, health record exchange — will have a skill set that is in short supply for the next five years.
If you are 5+ years in: You are building health platforms, not features. At this stage, the strategic questions are: should we build a horizontal platform (serve many healthcare verticals) or a vertical one (go deep in oncology or cardiology or maternal health)? How do we position relative to the ABDM ecosystem — as a building block, an aggregator, or a layer on top? What is the regulatory trajectory, and how do we build for where the rules will be in three years, not where they are today? Narayana Health, Apollo, and Manipal are all investing in digital platforms. The PM who leads one of those initiatives is operating at the intersection of clinical operations, technology, and regulation — a rare and highly compensated skill set.
Test yourself
You are the PM for a telemedicine app serving rural India. Your dermatology consultation feature requires patients to upload photos of skin conditions for remote diagnosis. Your analytics show that 60% of users in tier-3 cities have phones with less than 2GB of free storage. Image uploads are failing for 35% of rural consultations. The dermatology team says image quality below 2MP is clinically useless.
The head of dermatology wants high-resolution images. Your rural users cannot upload them. Product, clinical, and engineering are in a room together. What do you propose?
your path
Where to go next
- The ethical dimensions of health data decisions: Ethical PM
- Managing the four-party stakeholder complexity: Stakeholder Management
- Designing for the Indian user base your product actually serves: Designing for India
- Building for users with diverse abilities and constraints: Accessibility