Subscribe | Advertise | PRO Member Hub

TOGETHER WITH HIMS & HERS

Product management perspectives from builders in health AI…

We sat down with Mo Elshenawy, CTO of Hims & Hers, to unpack how the company is building AI directly into the care experience, from what patients see to the evaluation and safety infrastructure underneath it.

Before Hims & Hers, Mo was President and CTO at Cruise, where he helped put driverless cars on the streets of San Francisco commercially for the first time. Before that, he worked at Amazon. He’s spent more than a decade building AI systems, well before the current wave of generative AI.

At Hims & Hers, the challenge is different: building AI that can support patients throughout treatment while knowing exactly when a clinician needs to take over. We talked about the architecture underneath that experience, how clinical and engineering teams build together, the company’s approach to evals and staged rollouts, and why Mo thinks “the AI informs, the clinician decides.”

Here’s how it works.

Hims & Hers is introducing a new kind of AI care experience. How do you describe it in your own words?
Most AI in health today sits outside your care. It can give you information, but it isn't connected to your doctor, your treatment, or your plan. So the moment you actually need care, you're on your own.

What we've built is different: it's intelligence embedded into every step of the care journey, available first to Hers weight loss members. This is a new kind of care experience: if a customer opts in, it knows her treatment plan, delivers support that's specific to her, and is designed to bring her provider into the conversation whenever clinical judgment is needed. It's one continuous conversation instead of a dozen disconnected steps. The provider, the care team, and the AI are part of one ongoing conversation, grounded in clinical protocols informed by licensed providers. And the system knows its limits: we built it to know when to escalate to a provider, when to stay in its lane, and to say so when it doesn't know something.

See it in action —> watch Demo 1 and Demo 2 of the Hers AI care experience.

We're seeing a lot of talk around AI in healthcare, but wide variation in what it actually looks like for customers and clinicians. What makes your approach to AI-native care different?
The honest answer is that most conversations about AI in healthcare are about attaching a chatbot to the edges of an existing system and calling it AI-integrated. That's not what we're doing. We already understand our customers' journeys in real depth, years of data and outcomes across different treatments, and we're combining that with AI, our provider network, and our care teams into one seamless experience, not a bolt-on feature.

The system is also grounded. Many AI-in-health platforms only draw on broad, non-personalized information for advice. Ours has providers in the loop and is shaped by clinical protocols developed with licensed clinicians instead. What a customer gets back is specific to their treatment plan, not generic health content. The system is also proactive, not just reactive. Most AI in health waits for a question. Ours reaches out at the moments in the journey where attention actually matters, and the outreach itself is personalized, driven by each patient's own data and treatment plan, so no two patients get the same check-in at the same time.

And our AI support tool is built to direct patients to a provider or care team when a question calls for clinical judgment. It supports users throughout their treatment, but is designed not to guess, treat, diagnose, or replace a provider’s clinical judgment. That combination, embedded, grounded, proactive, and honest about its limits, is the differentiator. A lot of what's out there gets one of those right. Very few get all four.

Walk us through the technical foundation. What does the AI stack look like under the hood, and where do you think your real defensibility comes from?
There's a classifier that orients the conversation from the start. It decides whether something requires clinical guidance and should route to a human or calls for support that can stay with the AI. Then the AI itself is grounded in clinical guidelines that our doctors and clinical ops team have turned into actual guardrails, checked in as code, similar to how you'd manage configuration in any other engineering system. The architecture is deliberately neurosymbolic: deterministic where medicine demands consistency, AI reasoning where it benefits the customer. That's what every response is grounded to. You get the benefit of both reasoning and grounding, so the model knows what it can say, where the boundaries are, and when to escalate. On top of that, there's an LLM judge that checks and scores every answer in real time, before a customer ever sees it. Layer those together and you get real defense against hallucination, and support we can actually stand behind.

Underneath all of it is traceability by design. Every model call writes a structured trace: the prompt, each tool call, the intermediate reasoning, and the final output. The exact conversation a patient had in production can be replayed and judged offline, and if we can’t trace a decision back to its root, we don’t ship it.

As for where the defensibility comes from: it's not the model. Models commoditize, and faster than most people expect. Our data and workflow compound. We're not trying to build another LLM; plenty of others are already doing that well, and the economics favor us for not trying. The real advantage is in the workflow and the data: turning a closed loop, intake to treatment to outcome, into actual infrastructure you can build eval loops around and keep improving. That combination didn't really exist in healthcare before, and it's what we've built our AI organization around.

You've communicated that this approach requires engineering and clinical teams working together. What has that collaboration looked like?
We have dedicated clinical and AI engineering organizations built to work in lockstep. Our medical directors partner with AI leaders from day zero on any new capability, before any design work even starts, to determine where the clinical boundaries are, how eval loops get built, how escalation should work, and what QA and regression testing need to look like. None of that gets handed off after the fact.

Concretely, that means clinical guidelines get turned into the actual guardrails the AI runs on, not a policy document sitting adjacent to the product. And it means every rollout goes through both engineering gates and clinical review before it reaches a customer. That partnership is why I don't view what we're building as an engineering project that clinicians sign off on later. It's a shared build from the start.

To be specific about where clinicians sit in the lifecycle: they write the protocols the system runs on and review changes to them the way engineers review code. They define what passing looks like in our evals, and the gold datasets we calibrate our LLM judges against are labeled by clinicians and domain experts, so even the automated scoring traces back to clinical judgment. They run structured scenario testing on every release candidate, and once we're live, clinical sits in the triage rotation for safety alerts right alongside engineering. The decision structure matches: launch requires clinical sign-off by name, next to engineering, product, legal, and security. It's a hard gate, not a courtesy review.

What does "proactive care" actually look like for a customer? Walk us through a real patient journey.
In traditional healthcare, the weight loss journey is a series of disconnected steps in fragmented systems. The patient is left scrambling to sort through referrals, appointment scheduling, prescriptions, and pharmacy coordination, and has limited resources for managing side effects or updating their diet and lifestyle to accommodate their weight loss goals. The whole process feels tedious and outdated.

Now take a weight loss journey on the Hers app. If she opts in, this care experience already knows her treatment plan, her dose history, and anything she's shared about side effects, so she's not re-explaining her story at every step. It proactively reaches out at specific moments where we know attention matters: her first dose, to walk her through what to expect; the first time she logs a weigh-in on the connected scale, so she can start tracking her progress over time; a point where she's likely experiencing side effects; or a plateau in her progress that she might not think to flag herself.

That selectivity is deliberate. We're not optimizing for how often she opens the app; we're optimizing for her outcome, so it reaches out only when it will make a difference. In consumer tech you earn engagement. In healthcare you earn trust. When something does need clinical judgment, adjusting a dose or addressing a side effect, her provider and care team are brought directly into that same conversation, so she's not starting over fresh.

Healthcare AI lives and dies on trust. How do you think about safety, clinical quality, and knowing when AI should hand off to a human clinician?
When it comes to trust, we have an advantage most companies don't: an existing network of more than 1,500 providers we can bring into these conversations. That network doesn't just make hand-offs possible. It's who we build the clinical protocols with in the first place. We worked directly with providers across weight loss and women's health to determine when AI should step back and a doctor should step in to ensure the appropriate standard of care is met.

A concrete example: we have a system called MedMatch that leverages millions of anonymized data points from millions of customers to identify treatments that may be best suited for a patient's unique needs, but the provider always makes the final call. That's the model everywhere in how we think about trust: AI hands a provider a running start, not a verdict.

The principle underneath all of it is simple, and it's one we repeat consistently: the AI informs. The clinician decides. Always. AI can surface someone's history, medication details, and patterns in their data so a provider never starts from a blank chart, but the judgment calls, the prescribing decisions, stay with the doctor. And the loop compounds: our providers review and correct the AI at scale, so every interaction makes the system better.

How do you make sure a new model is actually safe and reliable -- from evaluation, through rollout, to what happens once it's live?
The process starts with evaluation, before anything gets near rollout. We run AI through a large automated eval suite covering unit tests tied to known failure modes, multi-turn clinical escalation stress tests built from years of real clinician escalations, adversarial scenarios covering attacker personas, prompt injection, and cross-lingual attacks, an independent external red team, and tone and personalization scoring. Simultaneously, teams across the company evaluated the model through domain-specific expert testing.

That suite is standing infrastructure, not a launch-time exercise, and my favorite principle runs through it: we test what fails before we verify what passes. A central AI platform team owns the shared evaluation framework, and each agent team owns its spec on top of it: the datasets, unit tests, rubrics, and pass thresholds for its surface, all versioned like code so any run is reproducible and comparable across model versions. A new safety test has to fail against the current system before it can merge, and every failure we find later, in red-teaming or in production, becomes a permanent regression test that runs in CI and blocks the merge if it breaks. The suite only grows, and we don't break the same way twice.

Our automated evals rely on synthetic patient models, grounded where possible in real historical interactions. This helps us understand how patients will behave with AI, but we know synthetic models have real limitations and we factor that into our eval process. We treat these eval results as directional and lean on a very careful staged rollout, not the eval score alone, to catch what synthetic testing can't see. And passing evals is necessary, not sufficient. Between a model passing evals and a feature going live sits a launch readiness review: named sign-offs from AI engineering, product, clinical, legal, security, and care operations, each accountable for their own lane, plus a full end-to-end QA pass, red-team closure, and internal dogfooding on production accounts. This is not an A/B experiment you iterate your way through. The gates are quality gates, and clinical quality is the only gateway.

Once a model clears that bar, nothing goes to the full base at once. We gate the rollout: roughly 1% of traffic for bug and event monitoring and evals on live traces, then ramp up from there in exposure intervals, which require gates at each interval. If the numbers at any stage look off, a shift in outcomes or an uptick in escalations to a provider, we will roll back before it reaches more customers. That staged exposure is really the whole philosophy: earn the next percentage point, don't assume it. We also keep a long-term holdout, because the metrics we ultimately care about are outcomes and retention measured over months, not launch-week engagement.

Once live, the scrutiny doesn't stop and monitoring runs on two tiers. Tier 1 checks the highest-criticality safety signals (crisis escalation, escalation integrity, guardrail resistance) on an hourly basis, and any failure triggers alerts for our engineering and clinical teams to triage. Tier 2 runs a more detailed evaluation daily, with weekly triage unless a result deviates meaningfully from baseline, in which case it escalates immediately. Safety events and escalation quality are treated as non-negotiable, zero-tolerance gates. Our aim is to catch regressions before they ever show up as a pattern a customer or provider would notice on their own. It's active monitoring the whole way through, not something that surfaces because someone happens to notice. All of it runs on the same tracing infrastructure we evaluate with: every production conversation emits a structured trace, and judges score live traffic against the same rubrics we use offline. Did it recognize risk, did it do what it said it did, did the guardrails hold? A failing check pages an on-call engineer the same way an outage would, and anything that fails becomes a new regression test in the suite. Production teaches the evals, and the evals gate what reaches production.

Frontier models keep leapfrogging each other. When a new model comes out, how do you decide whether to switch?
We’re deliberately model-agnostic: best model for each task, from any provider, no lock-in, because our advantage was never the model. A candidate runs through the exact same spec as the incumbent, same prompts, same tools, same datasets, and we compare them side by side on compliance, correctness, and groundedness, plus cost and latency, because at our volume those are real engineering constraints.

In medicine, model stability matters more than model novelty. Silent vendor updates are a real risk in clinical AI, so we pin model versions, and any model change, ours or a vendor’s, goes back through the full evaluation suite before it touches a patient. We requalify a model the way a lab requalifies an instrument, on one harness across everything we ship. Offline results gate the decision but they don’t make it: a candidate that clears the bar ships as an experiment behind a flag, with staged exposure and the same rollback gates as any launch. The AI engineering team makes the recommendation from that data, clinical reviews anything that changes patient-facing behavior, and a new model earns its way in the same way a new feature does.

Zooming out, where do you see AI in healthcare five years from now, and what role do you hope Hims & Hers plays in shaping that future?
Directionally, I think what's called concierge care today, the highly personalized, always-available care that costs tens of thousands of dollars a year, becomes something close to the default experience, at a fraction of the cost. Excellence in healthcare stops being a luxury. The economics of that kind of care collapse once you can deliver it through an integrated system of AI, providers, and care teams instead of a large dedicated staff.

I also think the range of choices available to providers to help people manage their own health starts to look much more diverse: for weight, for longevity, for hair loss, and more. That means the care experience has to get more personalized, not less, because no two people are optimizing for the same thing.

And I think we get there layered with more signals over time: wearables, connected devices like our scale, and ongoing blood testing, so a lot more is known about a customer in real time, in a system that already has their provider in it. The next five years won't be defined by who has the biggest model. They'll be defined by who closes the loop. We already run that loop today, from intake to outcome. That's the opportunity, and it's ours to lose. I don't intend to lose it.