Forward

Start smaller

Product & Design · 2022–2024

Start smaller: reduce the physical ambition early so the care model can be tested before the capital commitment is locked in.

The bet

Note pending.

What I owned

I worked on CarePods end to end, the physical product and the digital experience, from cardboard prototypes through low-scale production.

That included defining the requirements for each capability inside the pod: what a given capability had to deliver clinically, what it cost to build, and whether the margin worked. Arguing for which capabilities to build and in what order was a large part of the job, and it was never a purely clinical or purely design question. It was a question about cost of goods, throughput, and whether a patient would come back.

The tension

Every hard decision on CarePods sat on the same fault line: what made the product feel remarkable versus what made it economically survivable.

We traded ease of manufacturing for aesthetic appeal. We added complexity to add magic. Each of those calls was individually defensible. A pod that felt like the future was the whole proposition, and a pod that felt like a kiosk would have failed for different reasons. But the compounding effect was a product that got harder to build and harder to pay for at exactly the rate it got more impressive.

The place this showed up hardest was not clinical at all. Most of our physical product development time went into making micro-architecture work inside existing spaces: ADA compliance, fire and life safety, build logistics. That effort was real and necessary. It also meant the majority of our hardest engineering work went into the container rather than into the care delivered inside it.

What I argued for

Three things, consistently.

Understand the unit economics earlier. Not as a finance exercise late in the process, but as a design input from the start, shaping which capabilities were worth building at all.

Design for the second visit. The pod was compelling on first contact. My concern was what happened after onboarding, when novelty stopped doing the work. A product like this lives or dies on repeat value, and repeat value has to be designed deliberately rather than assumed.

Deliver value frequently enough to justify the model. Retention and growth had to clear a bar set by the capital intensity of the hardware. That bar was high, and I did not think our shipped capability set cleared it.

What we built, late

Before the company wound down, we had developed a substantially more cost-effective pod: roughly a 50% reduction in CAPEX per unit.

That was the right direction. It was not enough, and it came too late to matter. Which is most of the lesson.

How it ended

Forward wound down in late 2024, after raising roughly $400M and putting CarePods into the field. Public coverage attributes the failure to over-investment in technology relative to care delivery.

We launched a handful of capabilities. My honest read of my own work is that not enough of them delivered value high enough to drive the retention and growth the economics required.

What I would do differently

Start smaller, and buy time for the care to prove itself.

The version I would build now is a far more basic pod: enough to establish product-market fit, exercise the logistics network, and learn what people actually return for. Then add the magic once there is a reason to. We built the remarkable version first and spent our learning budget on making it physically possible.

The sharper alternative is to stop building within existing spaces and start building around them. Most of the difficulty in the physical program came from fitting micro-architecture into buildings that were never designed for it. A model that treats the space as a given rather than a thing to be conquered would have freed most of that engineering effort to go toward capabilities, which is where the value actually was.

Both versions are the same argument: reduce the physical ambition early so the care model has room to be tested before the capital commitment is locked in.