What Fusia taught me about the gap between interest and adoption

One of the most revealing conversations I had at Fusia was about what should happen when someone replied to an email.

We were setting up outreach in Apollo. The first message could go out automatically. People who did not respond could receive a follow-up. But once someone replied, I wanted the sequence to hand the conversation to our clinical co-founder. A response needed someone who could understand the context, ask a useful question, and decide what should happen next.

That small workflow decision captured a much larger part of my experience at Fusia. We could make outreach more systematic. We still had to earn the next conversation and learn enough from it to make the product worth adopting.

I joined Fusia in a strategy and operations role, working across customer outreach, institutional connections, investor preparation, and pilot planning. The company’s early work focused on automating the administrative processes around home infusion, including insurance verification and prior authorization. Over time, the work expanded toward hospital discharge coordination and the delays involved in moving patients to skilled nursing facilities.

My responsibilities put me close to the questions connecting those efforts: whose problem were we solving, who could move a decision forward, and what evidence would justify the next investment of time?

01Learning the workflow

The team’s early discovery notes are a good example. A pharmacist described the complexity of figuring out coverage across different insurance plans, aligning clinical documentation, and tracking authorizations manually. Another infusion team described a workflow where denials were relatively uncommon, but submission, follow-up, and coordination still consumed substantial effort. Even after approval, drug availability and scheduling could delay the start of care.

Those conversations complicated the initial story. “Prior authorization is painful” was a useful starting hypothesis, but it left a lot unresolved. Was the expensive part assembling the documents, reaching the payer, correcting missing information, or coordinating everything that happened afterward? A feature aimed at one of those problems would not necessarily solve the others.

This is where customer discovery became concrete for me. We needed to understand the sequence of work, the people responsible for each step, and the exceptions that disrupted it. A broad complaint could open a conversation. A detailed workflow could inform a product requirement.

An advisor conversation gave us a useful way to connect that discovery to sales. Start by understanding the particular customer’s problems. Demonstrate the parts of the product relevant to those problems. Leave the call with a concrete next step, such as an introduction to the person who could make a decision or a follow-up meeting. Before a pilot, agree on the measures that would make its results meaningful.

Looking back, I can describe the approach we were working toward in five steps:

We did not begin with a perfectly formed framework. It emerged through stand-ups, outreach experiments, advice, and conversations that exposed gaps in our assumptions.

02Finding the right people

Institutional outreach made the second step especially important. My work included pursuing connections through UNC’s healthcare and entrepreneurship ecosystem and identifying relevant people in healthcare communities. In our UNC outreach, introductions eventually led to a conversation involving operations and medical leadership. We followed up with materials for the care-management team. Each step helped us reach people with a different view of the discharge process.

The person willing to explain a workflow might not own its budget. A senior leader might recognize the cost of discharge delays while depending on case management and IT to assess whether a proposed solution would fit. An innovation contact could help us navigate the institution, but the next conversation still needed a clear purpose.

In product language, this was stakeholder mapping. In practice, it meant being able to explain why we wanted to speak to a particular person and what we needed to learn from them. For each connection, I became more interested in the path to the relevant team: who experienced the problem directly, who could sponsor an evaluation, and who would have to make it work?

Apollo addressed a different part of the problem. It gave us a way to organize contact searches and build email sequences, making outreach easier to coordinate. We discussed searching hospitals state by state, filtering for seniority and operational roles, and building lists that we could refresh over time.

The limitations became visible quickly. Finding a hospital executive was easier than identifying the exact person responsible for its home infusion workflow. We still needed to check whether an organization had an infusion service and determine whether a contact was relevant. Sometimes the purpose of reaching a senior person was to obtain an introduction to someone closer to the work.

Defining our ideal customer profile required that extra work. A contact database could help us find people. Qualifying those people required an understanding of the organization and our use case.

There was also more operational work in automation than the word suggests. We had to settle on which sequence to use, which mailbox would send it, how responses would be handled, and how test emails would reach the right inbox. A test message produced a confusing mailing error. We discussed sending to a different inbox and checking both the received message and the sender’s outbox. That was a useful reminder to walk through the full experience before relying on a sequence.

The sequence clarified who owned the next action. It could not establish customer fit, build trust, or resolve a long purchasing process for us.

We also had to be careful about interpreting channel results. The team described LinkedIn outreach as uneven and had received investor responses through email, which helped motivate an email-first experiment. That did not establish how well the same channel would convert healthcare customers. Nor did a newly sent batch with no replies yet tell us much. Looking back, I would judge the system by the relevant conversations and concrete next steps it produced, with separate tracking for investor and customer outreach.

03Moving beyond the pitch

Some of the clearest lessons came from approaches that needed changing. By late August, the team’s planning explicitly confronted the fact that it had spent time building without securing customers. The response was a more focused push toward customer validation, clearer ownership, and a time-bound validation plan.

Our messaging needed work too. In a team debrief after an early demo, we discussed connection problems that affected what the audience could see and technical language that did not suit the staff listening. We also learned something useful about the workflow: the location sent prior authorizations to headquarters but still had to gather documents when more information was requested. The handoff left work at the branch. That was a much more specific problem to discuss than the general promise of “agentic AI.”

For me, this connected product positioning to the customer’s existing job. We had to describe the work the product would help someone complete: assembling a referral packet, checking its completeness, following up on an authorization, or knowing what was preventing the next step. A technically accurate description could still leave the person listening unsure how their day would change.

Investor conversations pushed us to explain the broader opportunity. In one team debrief, feedback from a VC call led to discussion of a larger vision and clearer differentiation. We were trying to articulate how the initial workflow could connect to a more substantial problem in healthcare operations.

In another investor conversation, the questions ranged from whether the accuracy we described was sufficient to who our likely pilot customers were and which milestones came next. We had to connect the technical story to a credible path toward use.

It also created a tension over where to spend our time. In an October meeting, I asked whether our priority should be customers or investors. The discussion surfaced a difficult fit: some healthcare investors focused on companies further along, while other funds wanted revenue or were wary of long sales cycles.

Later internal CRM notes made that tension tangible. Several investor and institutional next steps depended on reaching a milestone, sharing a pilot update, or producing a case study. A better pitch could clarify the opportunity. Some of the evidence needed to advance those relationships had to come from customer work.

04Thinking in health systems

The move toward hospital discharge coordination brought these questions together. Conversations with hospital leaders and case management teams drew attention to the work involved in finding an appropriate skilled nursing facility, preparing referral information, obtaining authorization, and coordinating the transfer. Delays affected staff workload and the hospital’s ability to make a bed available for the next patient.

The shift reflected a clearer pain signal from hospital leaders: a problem with identifiable owners and consequences for discharge delays and capacity. For a case manager, the value might be less repeated documentation and better visibility into responses. For an operations leader, the question was whether improving that work could reduce avoidable discharge delays.

It also changed how I thought about scale. Expanding into health systems required understanding more roles, implementation constraints, and dependencies. A larger potential contract came with a larger coordination problem. We needed a narrow enough starting point to evaluate, while understanding how it fit into the wider hospital operation.

Distribution raised its own strategic questions. Earlier, when the team discussed whether a large infusion organization might license Fusia under its own brand, I asked what that would mean for selling to other clinics. Access to a network could be valuable, but the arrangement would need to preserve our ability to serve a broader market. We were considering a possible model; the discussion taught me to examine the commitments attached to a promising route to scale.

Later case-management discovery made that starting point much more specific. The team learned about the central document used to assemble referral information, the way discharge decisions were communicated during team meetings, and the need to coordinate facility acceptance, authorization, and transport. These details mattered because a proposed workflow could not depend on a clean electronic trigger that staff did not actually use.

One action assigned to me was to investigate which facility information we could obtain from public sources and which fields would require direct outreach. That included thinking through a realistic process for keeping the information current. I found this particularly revealing: the value of a facility-matching feature would depend partly on an ongoing maintenance process. The source of a field, the person updating it, and how quickly it became stale were product questions as well as operations questions.

05Giving the pilot a question

Pilot planning forced similar specificity. In an early discussion, I argued for a shorter initial pilot rather than automatically offering a longer free period. We were discussing what could be learned from a bounded evaluation and how to preserve a clear decision point. Later proposals changed as the use case evolved, but the underlying question stayed useful: what would this particular pilot establish?

The hospital pilot proposal called for sample referral and authorization documents and a review of existing workflows. Those materials would let us assess whether information appeared in the right place, whether a packet contained the required material, and whether the sequence made sense to the people doing the work. That was a necessary foundation for evaluating broader operational effects.

The measurement challenge extended beyond the interface. A faster document-generation step might save staff time, while the overall discharge still waited on facility availability or transportation. To understand value, we needed to distinguish time spent working on a task from time spent waiting between tasks. We also needed to distinguish a promising workflow test from a demonstrated improvement in hospital throughput.

That distinction changed how I approached business cases. A model could help identify the assumptions worth testing: how often the workflow occurred, how much effort it required, what caused delays, and how an improvement would translate into value for the buyer. Its usefulness depended on making those assumptions visible and then refining them with customer evidence.

Fusia made the connection between product, strategy, and operations concrete for me. Choosing a customer segment changed the requirements. Learning the workflow changed the pitch. Assigning ownership and maintaining information affected whether either could work in practice. I now pay closer attention to the work surrounding a feature: who will use its output, what must happen before it becomes useful, and who keeps its inputs current.

Those are the questions I want to bring into the next team I join. At Fusia, they showed up in the everyday details: a reply that needed a person, an introduction that needed a purpose, and a pilot that needed a clear question.