Feb 19, 2026
Sailing to China
I've been using this analogy — "sailing versus flying to China." The idea that the gap between what AI can do today and what people expect it to do in 2-3 years is enormous. Everyone's sailing. Nobody's flying yet.
Doug extended this into something sharper: the internet analogy. He watched the internet come in during the early '90s. His observation: there were maybe four actual "internet companies" — Amazon, Google, a handful of others. Every other company in the world just had to figure out how to use the internet in their business. And they did, eventually. But it took a decade. Google wasn't founded until 10 years after the internet went mainstream.
If you buy the analogy — and it's a good one — then we're somewhere in 1996 or 1997 of the AI cycle. The "Google of AI" might not be founded yet. The companies that will matter aren't the ones building AI platforms. They're the ones that figure out how to use AI to solve specific, painful problems in specific industries. Healthcare has decades of painful problems.
Doug's version of this: every boardroom he sits in (he chairs four PE-backed healthcare services companies) is asking "how do we use AI?" Most of them are getting lip service answers. The CEO dispatches someone junior. Nobody in the room actually knows what they're doing. Frazier and Summit are the exceptions — they've been systematic about it. Everyone else is just checking a box.
This is the window. The window isn't "we know things about AI." The window is that nobody else in these rooms knows either, and the people who get embedded in the actual workflow — who sit inside the payer's tech stack and see where the pain really is — will be the ones who build the next wave of products.
Don't try to scale the first thing you build
Doug's warning was about the consulting trap. He started a managed care consulting firm in '93, grew it to 10 people, couldn't build product underneath because consulting consumed 98% of his hours. He sold it to the wrong people, didn't get paid properly until 30. The treadmill.
But there's a more interesting frame for this, and it's the Airbnb playbook.
Paul Graham's "Do Things That Don't Scale" essay (2013) is essentially about this: the unscalable phase isn't a failure mode. It's the research phase. You're not building a consulting business. You're learning what the product needs to be.
The Airbnb specifics:
The founders flew to New York, rented a camera, and went door-to-door photographing apartments. They lived with hosts. They hand-delivered checks. None of this scales. But it taught them the single most important thing: the bottleneck wasn't demand — it was supply-side quality. The apartments were nice; the photos were terrible. They wouldn't have known that from a dashboard.
Their weekly revenue during Y Combinator: $460, $897, $1,428. Growing from a base of almost nothing. Compound growth from manual labor.
The photography program — the scalable version of what they did manually — didn't launch as a formal pilot until summer 2010. By 2012 they had 1,000 photographers across 383 cities. The unscalable phase was roughly 18 months. The transition to scalable systems was gradual, not a switch flip.
Brian Chesky: "It's better to have 100 customers that love you than 1,000,000 that just sort of like you."
Reid Hoffman: "Handcraft the core service for them. Create a magical experience. And then figure out what part of that magical handcrafted thing can scale."
The mapping to us:
| Airbnb (2008-2010) | DaisyAI (Now) |
|---|---|
| Flying to NYC to photograph apartments | Sitting inside Premera's UR workflow |
| Living with hosts to understand the trust problem | Understanding clinical decision-making by doing it |
| Hand-delivering checks | Manually handling what the product will automate |
| Learning that photo quality was the bottleneck | Learning which parts of UR are the actual pain points |
| Photography Program (scaled) | Productized SaaS (scaled version of what we're doing manually) |
The consulting work isn't a detour. It IS the product research. Doug's right that you can't stay on the treadmill forever. But the mistake would be trying to scale the first thing you build, before you actually understand what you're building.
The trigger to scale wasn't "we have enough revenue." It was "we now understand the problem well enough to systematize it."
What this means for the next 6 months
- Don't feel guilty about consulting. It's the Airbnb photography phase. We're learning by being physically present in the workflow.
- Pay attention to what we learn. The insights from Premera's appeals workflow — what's actually hard, what's actually repetitive, what requires judgment vs. what doesn't — that's the product spec being written in real time.
- Don't try to productize too early. The trigger is understanding, not revenue pressure. We'll know we're ready when we can describe the product to someone who's never seen the workflow and they immediately get it.
- Keep the door open. Doug's mistake was bundling the buying group with the consulting business when he sold. Keep the product separate from the services. Even if they're intertwined operationally, they need to be separable strategically.
- The Shields model. Jack Shields embedded at UMass, built a 340B pharmacy product from inside the relationship, sold to Cigna for $3B. Embed, learn, build, sell to others. Leave yourself the ability to sell what you built to ten other people.