Project Zygote: 5 Important Lessons (And What We’d Do Differently Now)

Project Zygote was a pre-accelerator for digital health startups. Here's what we learned about product-market fit, sales, and hospital adoption.

Table of contents


Back in 2014, I launched something called Project Zygote as an adjunct to the 4,000-member Health 2.0 chapter in San Francisco that I was leading. It wasn’t an incubator in the traditional sense, and we didn’t call it an accelerator, even though the goal was to help early digital health solutions with product-market fit and in gaining traction.

Think of it as a pre-accelerator experiment — built for healthcare founders who had strong instincts and early traction, but lacked structured exposure to the realities of hospital systems, payment models, and clinical workflows.

We brought together a small group of cross-functional teams — clinicians, engineers, operators — and created a short-run program designed to test assumptions, build MVPs with real context, and pressure-test go-to-market strategy. It was messy by design, but it worked better than we expected.

The model wasn’t perfect. We were inventing the process as we went. But ten years later, I keep thinking about what we learned — and what that kind of model could look like now, given how much the market has shifted.

If you’ve ever joined a healthcare accelerator — or decided to pass on one — this is for you. Maybe you’ve pitched in a room full of VCs while clutching a deck that took four days too long to make. Maybe you’ve listened to founders talk about “disrupting” healthcare while dodging basic questions about who pays for what. Or maybe you’ve backed out of a program because it felt like theater.

This is a working diagnosis of what I think accelerators could have been, and still could be. Not demo day polishing or group therapy for burned-out founders, but a place to build the actual scaffolding for product-market fit.

Especially for a system like healthcare: where the end user isn’t usually the buyer, and the buyer probably doesn’t care if your interface has beautiful gradients.

That’s the thread we’ll pull on here.


Why Project Zygote Even Existed

When we started Project Zygote, what stood out most wasn’t the abundance of ambition — it was the lack of infrastructure to match it.

There were plenty of smart, well-intentioned founders with clinical advisors and promising ideas, but almost no structured environments to build something real inside the constraints of healthcare.

Most programs taught pitch skills. What we needed was a safe zone to test actual operations — product design, regulatory exposure, payment alignment — before a founder burned through their first institutional check.

At the time, there was still a lot of ambient optimism that software could fix healthcare. We had apps trying to replace triage nurses and workflow tools that assumed clinicians would log into a separate portal multiple times a day.

What that era missed, and what we tried to create space for, was grounded experimentation — the kind that forced teams to sit with compliance officers, understand credentialing workflows, and simulate how billing codes would impact net revenue.

Finding product-market fit in healthcare has never been about elegance or velocity. It’s about credibility, integration, and solving a financial problem that actually exists.

Project Zygote wasn’t a fix-all, but it made those friction points visible early enough that some of the teams could course-correct. That alone was worth doing.


Five Lessons From Building It

Project Zygote shut down not because it failed, but because we were ahead of the infrastructure. We didn’t have the resources to formalize the model, and at the time, there weren’t enough institutional partners ready to build with us.

But the lessons stuck — and they’re still showing up in the conversations I have with founders today. Here are five of them.

1. You’re not the user — and you’ll get burned if you act like you are

One of the earliest red flags I saw in new teams was how often they built solutions they personally wanted to use. But most of us aren’t licensed providers. We’re not standing at a bedside with a discharge deadline, or trying to input vitals while a family member asks questions.

Building for healthcare means confronting how work actually gets done — not just what the software can do, but what the user is dealing with in that moment. Clinical workflows, credentialing friction, fragmented IT infrastructure — these are not edge cases. They’re the water your product swims in.

2. You need a cross-functional founding team

It’s not just about skill sets. It’s about lived experience. We tried to design Project Zygote cohorts around teams that included at least one clinician, one operator, one builder, and one PM. That balance gave them just enough friction to think through competing priorities.

When you build with only engineers, you often optimize for elegance. With only clinicians, you often index on relevance without delivery. You need the internal debate — early and often — or you’ll bake the wrong assumptions into your roadmap.

3. You need to know how health systems get paid

This is where most smart teams get tripped up. They’ll spend weeks refining the user journey but gloss over how care is actually paid for.

In U.S. healthcare, CPT codes are the currency — and knowing how a service maps to reimbursement isn’t just helpful, it’s existential. The difference between a scalable solution and a nice-to-have tool is often whether someone can bill for it.

And that financial path has to work under pressure — inside a clinic, a hospital, a value-based contract. It’s not a bonus to understand this stuff. It’s the job.

4. The buyer is not the user

We ran sessions in Project Zygote where teams had to pitch their solution to both frontline staff and C-suite leadership. What worked for one group usually flopped with the other. And that was the point.

A Chief Medical Officer doesn’t care about how smooth your UI feels. A CFO won’t be won over by patient engagement data alone. You need two different narratives — one for how the tool actually functions, and one for why it clears risk, generates revenue, or avoids penalties.

If you can’t tell both stories, your deal dies somewhere between the pilot and procurement.

5. If it doesn’t map to the EHR, it won’t matter

Clinicians live inside the EHR. Not because they love it — but because that’s where billing, documentation, task management, and communication largely happens. If your solution requires toggling out, logging in elsewhere, or managing a separate queue, it’s likely dead on arrival.

Digital health teams who learned this early could pivot to integration strategies. The ones who didn’t got stuck trying to solve a workflow problem with a second workflow.


From Then to Now

I stepped away from Project Zygote in 2018, and a lot has changed on the surface. We’ve seen the rise of digital health venture studios and more targeted incubators. Funding at the early stage has become less about raw enthusiasm and more about traction and team dynamics.

There are more structured paths to testing — regulatory consultants who don’t break the bank, go-to-market advisors who understand how selling into health systems actually works. That’s all real progress.

But in the rooms where deals still stall, not much has changed. Sales cycles are just as long. Procurement still drags. The handoff from a clinical champion to someone who can actually greenlight a contract still breaks down more often than it converts.

Health systems are more digital now, sure, but that doesn’t mean they’ve gotten better at integrating new tools. If anything, there’s more friction — more scrutiny, more competing priorities, more pressure to justify every new integration. More ‘no’s.

Founders are still getting tripped up in the same spots. They build something useful, sometimes even loved by end users — but they fail to design for the economics of adoption. Or they expect early traction with a department head to translate into an enterprise deal. That gap is where most pilots die.

A better accelerator model could step in here. Not by offering more mentors or more polished pitch days, but by creating embedded, friction-rich environments that simulate the actual blockers to adoption. That’s what was missing then. It’s still what’s needed now.


A Redefinition

If Project Zygote taught me anything, it’s that accelerators need to mature — not just evolve. We don’t need another batch-driven curriculum focused on pitch polish, or yet another mentor network made up of the same rotating cast of advisors.

What early-stage healthcare founders need is time inside the machine: real access, real exposure, real friction.

A modern accelerator should look less like an investor-led bootcamp and more like a pressure-tested proving ground — built to simulate the tradeoffs of getting something adopted inside a health system.

That means less talk about storytelling and more about pricing models. Less about design feedback and more about data governance and procurement hurdles.

The next version probably won’t call itself an accelerator at all. It might look more like a services-forward studio. Or a hospital-backed product lab that co-develops and co-tests ideas before the first seed check is written. That’s where we’re headed — or should be.


Accretive Edge works with digital health companies and investors to help their solutions gain adoption and generate revenue in U.S. healthcare. We translate market strategy into execution — not just positioning, but real-world traction across enterprise sales, incentive alignment, and go-to-market enablement. 

Get in touch today.

RECENT ARTICLES

Get In Touch

Move beyond strategy and start driving results.

Accretive Edge © 2025 All rights reserved. By Column.