Kanav Jain

14 years in healthcare technology, most of them in product: I originated Doximity Dialer, led R&D at CancerCompass, co-founded Andwise, and since 2024 have built AI systems myself. Advisory and fractional product leadership for healthcare and AI ventures. I partner with technical founders to take complex clinical systems through review, unblock patient adoption, and build products that last.

RNA research

2009–12 Research Assistant

At Georgia Tech, I worked in Roger Wartell’s lab on how Hfq affects small regulatory RNAs and their pairing with target mRNAs. As an undergraduate, I was first author on an ACS Symposium Series chapter on that work.

Epic

2012–13 Technical Services Engineer

I deferred a medical school acceptance for a year to try healthcare technology. At Epic, I supported client organizations after installation, wrote custom Caché code for department workflows, and co-led the PQRS subject-matter group.

By the end of that year I was building the patient-facing portal, and I turned the medical school acceptance down. The case study describes the post-install work.

Doximity

2013–17 Head of Mobile Products & Growth

I originated the physician compensation model for Career Navigator, led its survey and modeling methodology, and directed the data-science team. I later originated Doximity Dialer as founding product lead.

Across four years I built an enterprise marketing platform for research hospitals, founded the search team, and brought nurse practitioners and physician assistants onto the platform. I left as Head of Mobile Products & Growth, responsible for every mobile app and user growth.

NYU Stern

2019 MBA

At Doximity, I saw how compliance, security reviews, and procurement could hold up a working product. I earned an MBA at NYU Stern to study the finance and organizational decisions behind those barriers.

I evaluated seed-stage healthcare and deep-tech teams for General Catalyst’s Rough Draft Ventures, then conducted seed and Series A due diligence at a three-person venture fund.

CancerCompass

2019–21 Director of Digital Products & Strategy

I was the first product and technical hire for a pre-CEO, pre-revenue Cancer Treatment Centers of America venture, and stayed through its growth from 2 to 25 people. I led a cross-functional R&D team of 14 across oncology navigation, hospital digital marketing, and patient engagement. The case study covers the rebuild.

Oncology runs through the record. I spent a summer researching cancer-derived exosomes at Memorial Sloan Kettering as an undergraduate, worked here on what a family does after a diagnosis, and later led the Cancer & Decision Support pod at Transcarent.

Transcarent

2021–22 Director of Product, Care Experiences

I joined as an early product hire and directed four specialty-care programs: Surgery, Everyday Urgent Care, Behavioral Health, and Oncology Care. I led the Cancer & Decision Support pod and replaced manual case coordination with routing tied to clinical roles. The case study shows the shared architecture.

Andwise

2022–24 Co-Founder and CEO

I co-founded Andwise and built software that flagged clauses in physician employment contracts for review. I raised the initial funding and convened its physician medical advisory board.

I did not work out who would pay until year two. Funding and sustained engagement fell short, and I wound the company down in 2024. The case study records the funding options and wind-down email.

Current work

2024– Independent Product Builder

After Andwise, generative AI and coding agents let me move from leading product teams to researching, prototyping, building, deploying, and evaluating end-to-end.

I used that ability to test ideas in healthcare evidence, AI-supported decisions, provenance, and agent behavior — some substantial, others small. The aim was to see what held up in practice, not to launch every idea.

As producing software and analysis got cheaper, one thing became clear: establishing what is true, deciding what deserves action, constraining who or what can act, and detecting and correcting errors remain the hard parts. Current work lists the projects, their stages, and what can be inspected.

  • I treat workarounds as a fault in the system.

    When a process works only because people keep pushing through, improvising, or doing unpaid work around it, I read that as a fault in the design, not proof of resilience. An institution does not get to claim efficiency just because someone else’s time disappeared from the accounting.

    • Epic: Installed, signed off, and live — and working only because the people around it improvised.
    • The Crumple Zone: My essays on who absorbs a system’s failures when its design lets the burden fall on them.
  • Whoever controls a system should answer for it.

    I don’t hold people responsible for outcomes they had no power to change. The people who design or control a system need to answer for its failures. Anyone expected to correct an automated decision needs the authority to change it.

    • Epic: After go-live, responsibility was split between Epic and the hospital, and the problems fell between them.
    • Andwise: Automated analysis fed the decision; a named reviewer with the authority to change it signed off.
  • Being able to do something isn’t permission to do it.

    I don’t take the fact that a person, an institution, or an AI system can do something as a sign that it should be allowed to.

    • Ambit: Ambit lists which tools an agent can reach and which it has used correctly, without assuming it is allowed to use any of them.
  • When cases don’t fit, I check the category first.

    When real cases keep failing to fit a category, I ask whether the category is wrong before I ask what is wrong with the person.

    • Refract: A source that stops matching its record is logged as a dated event to examine, not discarded as noise.
    • NextConsensus: Forecasts are frozen before the outcome is known, so one that turns out wrong is itself a result, not something to explain away.
  • I judge a system by what happens when it’s wrong.

    People affected by a system need a way to identify errors and challenge its decisions. Those challenges must be able to change the underlying rules. I look for a process that gives people that power and records what happens when they use it.

    • Refract: Downstream systems receive what changed and when, so a correction reaches everything the error touched.
    • Fast Harm, Slow Repair: A protocol measuring how far a wrong output travels before the correction catches up with it.

I explore these questions in Writing. The Framework gives a worked example and inspection guide.

Revised