A health tech founder can spend years building a product that truly solves a very important problem, and still watch the customer experience wobble at the point where one team hands work to another.
The software may be doing its job. The handoff around it may not be.
That gap is especially easy to miss when you’re close to the product. You see a workflow that makes sense: information comes in, the system matches it, the right person reviews it, the next step happens. You’re so close to the product you can no longer see them, but the people using the system experience the seams. A clinic needs to know what to do. An operations team needs to explain the process. A technical partner needs to investigate an exception. Someone has to make the call when the normal path doesn’t work.
If nobody knows who owns that next step, the customer feels it.
The company is the workflow, too
Picture a growing health tech company selling software that helps information move between healthcare organizations. The product depends on integrations, permissions, data quality, and people following the right steps (and boy do we know this part is fallible). Not to mention all the regulations and red tape you have to navigate. Its customers aren’t all doing the same job. A front-line user needs practical instructions. An operations lead needs to understand the workflow. A technical team needs enough detail to diagnose what went wrong.
The founder knows all of this. She has spent years in the industry and can explain the product, the customer problem, and the edge cases in mega-impressive detail.
She’s also become the person everyone asks to translate. Whomp. Whomp.
A customer asks what happens next. The internal team checks with her. A technical question turns into a Slack thread. A process decision lives in someone’s memory. The same explanation gets rewritten for different audiences, sometimes slightly differently each time.
This is a made-up composite, based on patterns I’ve seen with 15+ years of health tech operations experience.
The problem in this example isn’t that the founder failed to communicate. She’s communicating constantly. The problem is that the company has made her the place where communication has to pass through.
That works for a while. Eventually, it becomes part of the product experience, whether the company meant for it to or not.
Find the seam where the work changes hands
The first step isn’t to buy another platform or write a giant process document. It’s to find the moment the work changes hands.
A customer completes one step. It’s time to ask:
Who owns the next one?
What information do they need?
Where does it go?
How do they know it’s complete?
What happens when the usual path breaks?
Those questions sound basic. And you know what, they are basic! They’re also where a lot of operational ambiguity hides.
In health tech, the answer may differ depending on whether the person is a clinic user, an implementation lead, a partner or an internal technical owner. A single “how it works” document may not help any of them. It can leave the people doing the work to interpret what applies to them, then ask the founder when they’re unsure.
A clearer system gives each person the information they need at the point they need it. The end user gets the next steps in plain language. The internal team knows who owns the follow-up. The technical team knows what information to include when something needs investigation. The founder can still handle exceptions and important decisions without being the default route for every question.
Make the work legible to the people doing it
Start by walking through the customer journey with the people closest to the work. Not to create a perfect map for a binder, but to see where real people pause, repeat themselves or have to ask for help.
Then the team could make a few practical changes:
Write separate, role-specific guides instead of one document for everyone.
Name an owner for each handoff, including what they receive and what they’re expected to do next.
Clarify what counts as a routine question, an exception and an issue that needs technical review.
Give the team a shared place to record decisions and unresolved questions, so answers don’t disappear into chat.
Set a regular time to review what keeps getting stuck and decide whether the process, product or guidance needs to change.
None of that is especially glamorous. It is also the work that helps a good product feel dependable.
In an early-stage company, the founder should still be close to customers and important decisions. We aren’t trying to make them fully unavailable. The goal is to stop routing ordinary work through one person simply because the rest of the system is unclear.
A founder becomes a bottleneck when the same question keeps finding its way back to her. That’s a signal about the company’s design, not a reason to blame the people asking.
The customer experiences your operating system
Health tech founders carry an extra kind of responsibility because it's so personal. A confusing handoff can affect a busy clinician, a patient waiting for information, or a partner trying to do the right thing without knowing which step comes next. The internal process may look like “just operations” from the inside. From the customer’s perspective, it’s part of whether the product feels safe to rely on.
That doesn’t mean every workflow needs layers of governance. It means the human path around the technology deserves the same care as the technology itself.
Your product may be the software. The experience is everything required to make the software useful: the instructions, the ownership, the follow-through, and the way the team handles exceptions.
Founders (in health tech and beyond), try tracing one important workflow from the customer’s first action to the moment they get value. Notice every place where someone has to ask, “Who has this now?” or “What am I supposed to do next?”
That’s probably where your operating system is showing through.
If you’re feeling too close to the situation, an extra set of outside eyes can be really helpful. I love sitting with founders to plot this out and make it simple for all.
The seam I run into at work is onboarding and sales. Our onboarding emails skip any account sales already owns, but that rule lived inside the email workflows. When I built a second thing that drafts emails, it didn't know.