In 2025, I spent most of my time building products and services for people who were not looking for a new tool or a better workflow. They were navigating moments they did not choose, inside systems they did not fully understand, often while carrying fear, fatigue, or uncertainty about what came next.
Healthcare has a way of stripping away the assumptions product teams often make. People are not browsing. They are not optimizing. They are trying to make sense of what just happened to them and what they are being asked to do next.
Over the past year, what stood out to me most was not how complex the technology was. Even in a virtual care setting, the hardest decisions had very little to do with the technology itself. They were about judgment: what to build, what to hold steady, who to involve, when to slow down, and where complexity should live so patients did not have to carry it themselves.
As our product matured and our virtual clinic scaled, the questions changed. We spent less time asking what else we could add and more time asking whether the system we had built could be relied on when things were not neat or predictable. Somewhere in that shift, a set of lessons took shape. Not as best practices or frameworks, but as judgments formed under constraint.
What follows are a few of the ones that stuck with me.
Patients are not confused. They’re overwhelmed.
In healthcare, patients are often labeled as “confused” when what they’re actually experiencing is emotional and cognitive overload during moments of vulnerability.
A large portion of the population we serve is 65 and older. Many are recovering from a recent hospitalization, adapting to a new diagnosis, or managing chronic conditions they have been trying to control for years, often without lasting stability despite doing everything they were told to do.
These patients are frequently asked to navigate online forms, scheduling tools, and unfamiliar programs at a time when their cognitive and emotional bandwidth is already stretched thin.
This distinction mattered when we redesigned the referral and intake experience for our virtual clinic. Early on, we reused a screen-based flow that had worked well in a different context, an employer-sponsored health benefit where services were fully covered, decisions were relatively low-risk, and people could move quickly.
In the clinic setting, the same flow did not translate. Patients were being asked to consent to care, share insurance information, and make decisions with real financial and clinical implications. The same flow led to meaningful drop-off.
Our first instinct was familiar: something must not be clear enough. We tightened the copy. We added structure. We expanded FAQs. We clarified billing language and next steps. It helped, but far less than expected.
As we talked to patients and listened more closely, it became clear that most people understood what the screens were saying. What they struggled with was making decisions while carrying everything else that had just happened. The appointment. The diagnosis. The concern that led to the referral in the first place.
That shifted how we understood the problem.
Instead of optimizing the flow further, we tested a different hypothesis: What if someone could walk patients through the experience, answer questions as they came up, and tailor the conversation to what mattered most to them in that moment?
We designed that human guidance as part of the product, not as a support fallback. The flow still mattered, but it was wrapped in human presence. Someone who could explain what would happen next, answer questions in real time, and reduce the feeling of navigating a complex system alone.
The change was noticeable. Not just in completion rates, but in tone. People sounded calmer. More willing to move forward. And many shared, unprompted, how much they appreciated how easy the handoff and onboarding experience felt.
What that taught me was simple but lasting. In healthcare, uncertainty is unavoidable. What product controls is whether people feel alone inside it, or supported through the process.
Don’t make patients carry system gaps
That same uncertainty showed up again, just in a different way.
What we were seeing at the individual level kept pointing back to the system. In U.S. healthcare, gaps between organizations are common. From the health system’s perspective, a referral is complete once it is sent. From the patient’s perspective, it often feels like being dropped into a void.
We saw this quickly. Patients were not asking complex questions. They were asking basic ones: Did my referral go through? Who is supposed to contact me? What happens next?
Rather than exposing patients to those gaps, we decided to treat continuity as a product responsibility.
And timing mattered. Right after a clinical visit, when a doctor has just explained why additional support could help and referred them to Starlight, the conversation is still close. Patients remember what was said, what stood out, and what made them pause. Sometimes there is reassurance in that moment. Sometimes there is worry. Often it is both.
That moment passes quickly. Once people leave the clinic and life takes over. The intensity of the visit fades, but the questions do not always resolve. Without timely follow-up, uncertainty has room to grow and the reason for care starts to feel less urgent.
We designed the handoff around that reality.
Shortly after a patient was referred, often while they were still on their way out of the building, they received a text message. It came from a real person’s phone number. Someone they could reply to. Someone who would later call to walk them through next steps.
This was not marketing. It was meant to signal that someone was paying attention.
And in our care management platform, we built systems to support that human work. Follow-up was prioritized within a 24-hour window. Outreach could not quietly fall through the cracks. Next actions were clearly visible so care teams could focus on the conversation, not on remembering what to do next.
Patients noticed. One described the experience as “impressive” and unlike what they were used to. That feedback mattered because it reflected trust, not just execution.
The lesson here stayed with me. When systems are fragmented, someone always absorbs the cost. Treating continuity as a product decision is one way to make sure that cost does not land on the patient.
In healthcare product, sequencing risk matters
In any product work, risk mitigation is part of the job. Validating usability, feasibility, perceived value, and business viability is crucial. And in healthcare, legal and regulatory risk is layered in as well.
When we began designing a new transitional care model for acutely-ill patients, what became clear quickly was not that these risks existed, but that the order in which they surfaced mattered just as much as how they were addressed.
On paper, the program looked ready. Clinical partners aligned on the care pathway. Operations confirmed feasibility. Leadership supported the direction. Early research suggested we were on solid ground.
It felt like green lights across the board… until we brought legal into the conversation.
The idea wasn’t rejected, but it prompted a set of nuanced legal questions about how the program was framed and how certain elements might be interpreted once put into practice. Despite good-faith research and early validation, there were constraints that only became visible at that stage.
This is a pattern I’ve seen repeatedly in healthcare: The biggest risks don’t come from building the wrong thing, but from surfacing constraints too late.
That moment reinforced something fundamental. Product decisions don’t exist in isolation. Program design, pricing, positioning, and go-to-market strategy all operate inside institutional systems. In healthcare, regulatory risk is inseparable from product risk.
In larger organizations, legal is part of the operating fabric. In a small medical startup, that fabric has to be woven deliberately. Legal is not just a downstream reviewer. It shapes what can be offered, how it can be described, and how it can evolve. Those constraints exist whether they are surfaced early or late.
The lesson here wasn’t about compliance. It was about sequencing and judgment. Who you involve, and when, is itself a product decision.
Reliability Matters More Than Completeness
Ambiguity is inevitable in product management. But in healthcare, reliability is non-negotiable, and patients shouldn’t have to carry that uncertainty.
As we scaled into a real, billable clinical operation, it became clear that not everything would move at the same pace. Some operational and administrative pieces of the system had to be defined, tested, and finalized while care was already underway.
But the patient experience does not pause just because the backend is still evolving. Teams reorganize. Processes change. Systems break and get rebuilt.
None of that should be visible to the person at home, on their phone, trying to understand what happens next in their care. And none of it can be reframed as experimentation. We do not get to ship that internal uncertainty to patients.
This isn’t unique to healthcare. In any industry, good products absorb internal change so users don’t have to. The difference in healthcare is that even when breakdowns are minor or reversible, they still intersect with people’s health, their ability to receive care, and their trust in the system.
Early on, we were clear about what the experience needed to feel like. Onboarding had to be predictable. Expectations had to be consistent. Especially around insurance and billing, patients needed to understand what they were being asked to do and what would happen next.
So we decided to standardize the front door early. We rolled out a single, stable intake, insurance verification, and onboarding flow. The steps did not change based on payer, program, or our internal state. From the patient’s perspective, the process felt smooth and easy.
It also gave our care teams a shared baseline and a clear mental model, so they could deliver onboarding confidently and consistently. That baseline allowed us to start learning immediately. When a process or operational gap surfaced, we could see it clearly, fix it deliberately, and re-standardize.
As administrative details continued to evolve behind the scenes, the product and the process acted as a buffer. This was not about pretending the complexity did not exist. It was about containing it.
What we kept coming back to was that, in healthcare, reliability matters more than completeness. You do not need every backend detail resolved on day one, but you do need an experience that patients and care teams can trust.
Closing Reflection
Looking back, all of these lessons point to the same responsibility: deciding who carries uncertainty when systems are imperfect.
In healthcare, those decisions are not abstract. Every time ambiguity is pushed downstream, someone experiences it as stress, delay, or lost trust.
Over time, a clear philosophy took shape for me:
- Patients should never carry system failure
- Reliability is a product requirement
- Sequencing is a design decision
- Human support is infrastructure, not a fallback
This type of product work is not about eliminating ambiguity everywhere. It is about being deliberate about where it can live, and making sure it never lives with the patient.