What CDH Can Learn from Product-Led Growth

An argument for the P&L owner

I've spent my career selling in finance, benefits, and SaaS. I'm proud of what the consumer directed benefits industry does: we help people pay for care they couldn't otherwise afford. But we've made the experience of adopting and running these plans harder than it needs to be, and it's quietly costing us.

For most of its history, CDH has grown on two engines: a channel sales motion that sells plans to employers, and teams of implementation, account, and member support to deliver the service. Both of those still matter, but leaning on them alone no longer gets us where we need to go.

The companies that scaled fastest over the last decade (Slack, Calendly, Dropbox, Stripe) didn't win because they out-sold everyone else. I've adopted half of those tools myself without ever talking to a salesperson. No contract negotiation, no kickoff call, no long onboarding. I just started using the thing, and somewhere along the way I became a paying customer. That approach has a name: product-led growth, or PLG. It's a well-established discipline in software, where the product itself drives acquisition, conversion, and expansion, and the go-to-market motion is engineered around adoption rather than persuasion. What strikes me is how directly its principles map onto a CDH business, more cleanly than most of us in the industry have recognized.

In CDH, every manual step between "employer says yes" and "accountholder spends their first dollar" is friction. That friction costs margin, it introduces errors, and it wears down the people we're counting on to renew. Today almost all of it is staffed by people: people to implement each employer, people to move data from a CRM into the recordkeeping system, people to work every call and ticket, people to push a plan through its lifecycle by hand. Every one of those roles is a cost line that grows with the book of business, and every one is a place where mistakes get in.

Take that friction out and three things improve together: margin, accuracy, and the accountholder experience. It's rare that cutting costs also improves service, but CDH is one of the places where the same move can do both, which is why I keep pushing on it. Keep those three in mind, because I'm going to come back to them at every step.

Here's what PLG looks like translated into CDH, step by step through the journey.

1. Turn the buying decision into a click

PLG tools win at the point of sale because there's barely a point of sale at all. You click "add," and you're in. CDH should feel the same way to the buyer.

Too often we position accounts as a separate product, with their own contract, their own pricing negotiation, and their own legal review. That's a lot to ask of an employer who already said yes to the relationship. We should bundle accounts as an add-on to that existing relationship instead. The moment a plan sponsor wants to offer an HSA or FSA, turning it on should be closer to flipping a switch than kicking off another sales cycle.

None of this means the compliance work disappears. Plan documents, ERISA obligations, the governing agreements, all of it still exists. The point is that it moves into the background and stops being a procurement project the buyer has to live through. Every week of contracting friction we remove is a week closer to funded, active accounts, and removing it costs us nothing on margin, accuracy, or experience. I'd start here, because it's the cheapest ground to gain.

2. Onboard data through APIs, retire the flat files

This is the step where I've watched good deals lose their momentum. The old enterprise motion for enrollment, eligibility, and contribution data is a flat-file project: scope a spec, build it, test it with the vendor, reconcile the errors, and wait weeks before go-live. I've seen signed employers sit idle through that whole cycle while the enthusiasm that closed the deal slowly faded.

API-based data exchange replaces all of it. Data moves in real time, mapping errors largely disappear, and there's no multi-week file setup standing between a signed employer and a working plan. This is the CDH version of "it just connects and works," and it goes straight at time-to-value. Buyers may not use that phrase, but it's what they're judging you on.

The numbers bear this out. When Rippling moved its consumer accounts onto a modern platform, FSA and commuter accounts ran on full API integration, and the partnership reached roughly 15 million API calls each week, with a sharp drop in the human hours needed to move data and fewer errors because the transmission was automated. That isn't only a payroll-vendor story, either. It applies to anyone who holds client data. Margin improves because the hours come out, accuracy improves because the hands come out, and the experience improves because the plan is live while the buyer still remembers signing.

3. Provision employers from data you already have

A manual implementation project for every employer doesn't scale. I've seen services teams become the ceiling on growth, because when your delivery org has to add a person for every chunk of new business, your margin is capped before you ever book the revenue.

The fix is self-serve provisioning. Pull employer information from your CRM and system of record instead of re-keying it, and standardize plan designs into templates so the system transmits the design and stands the plan up on its own. Onboarding becomes hands-off. This is how PLG products bring on thousands of accounts without a services organization growing right alongside them, and it's how a CDH business holds its cost-to-serve flat while volume climbs.

In the Rippling case, new business is now added automatically through APIs with no manual setup, and plan-design templates cut client setup time while still allowing customizations like rollover and grace-period rules. The same three wins show up: margin holds because headcount doesn't track volume, accuracy holds because no one is re-keying data, and the employer gets a plan that works on day one.

4. Let the full lifecycle run itself

Onboarding isn't the only high-touch moment, and it isn't even the riskiest one. Plan changes, renewals, and terminations are where manual handling creates the most risk, and renewals and terminations are where errors get most expensive. A mishandled renewal can undo a year of goodwill in a single billing cycle, and I've seen it happen.

One of Rippling's biggest frustrations with its previous vendor was that regulatory changes were cumbersome and forced expensive development work, which sometimes created downstream errors. In a PLG model, the product runs its own lifecycle. For CDH, that means these events are API-driven and event-triggered: a change in the source system kicks off the process automatically, with no human in the loop. Fewer hands means fewer errors, and the relationship runs on automated events instead of a queue of service tickets. Margin improves because the work disappears, accuracy improves because the handoffs disappear, and the accountholder never feels the seam.

5. Make self-service the default, and turn every ticket into product

PLG companies treat support volume as a backlog of product work to design away, rather than a cost center they keep staffing up. I'd love to see CDH adopt that same discipline, because every ticket our teams field is a tax on both sides of the relationship.

Employees and admins should get instant answers right where they already are, with no need to call in or open a ticket. And when something genuinely does require a ticket today, that's the signal: build it into a self-service capability tomorrow. I've watched the same question come into support over and over, and every one of those was really a product feature waiting to be built.

Every deflected ticket lowers cost-to-serve and improves the experience in the same motion. For the P&L owner, that's the whole thesis in miniature. Margin, accuracy, and experience, all moving in the same direction at once.

6. Demand real-time workflows

All of this rests on one technical choice many P&L owners never look at: batch versus workflow. A lot of the older systems in our space are batch-oriented, which was a reasonable design decision in its day. Work accumulates in a queue and runs on a schedule, often once a day. That architecture is the source of the language we've all heard from legacy partners, the "that'll go through in a couple of days," the "you missed the cutoff," the "let's wait until tomorrow and see if it clears." Workflow systems were designed to operate differently. Each event is processed on its own timeline, the moment it arrives, and the vocabulary shifts to "now," "already," "seconds," "real-time."

That distinction is the quiet precondition for everything in a PLG model. The API onboarding in step two, the self-serve provisioning in step three, the event-triggered lifecycle in step four: none of it works on a system that can only act overnight. An automated event that fires in a source system expects a response in real time, and a batch platform can only accept the message and go quiet until the next scheduled run. It's the kind of wall that stalls a modern integration against a legacy backend.

For the P&L owner, this is the question underneath all the others. You can layer self-service and analytics on top, but if the architecture is batch, the delays and manual reconciliation come right back, and margin, accuracy, and experience all pay the price. A workflow foundation is what lets those three improve together instead of fighting each other. Before adopting any of the steps above, I'd press a technology partner hard on this one: does the platform run on workflow, or is it still batch underneath?

7. Measure everything that runs the business

You can't grow what you can't see. I've tried to run forecasts off static monthly reports that were out of date the day they arrived, and it's a hard way to run a book of business. PLG companies win because every behavior is measured and fed right back into decisions. Rippling pointed to its old system's weakness in data access and report generation as a core reason to switch, and I've heard that same frustration from customers more times than I can count.

CDH needs the same real-time measurement and tracking. The P&L owner and the employer admin should both have flexible, self-serve analytics on the metrics that actually run the business: activation, funding, balance growth, investment adoption, cost-to-serve, and ticket deflection. The automation in the steps above moves the data in real time. Analytics turn that data into the levers you pull, so you can watch your margin, your accuracy, and your experience as they move instead of reading about them a month later.

The results are measurable

I've heard plenty of strategy that never survives contact with a real account, so the proof matters to me more than the pitch. When Rocky Mountain Reserve, a TPA administering 80,000 consumer directed accounts, moved to a modern AI-powered platform, the transition finished in under 18 weeks and moved more than $58 million in HSA and notional assets. Claims were processed twice as fast, file processing time dropped by 50%, and AI-enabled transfer automation took incoming HSA asset processing from two business days down to same day, clearing $8 million in transfers within minutes in the first week. The stated goal of that modernization, in the partner's own words, was to remove manual tasks and grow profit margins. That's the PLG payoff written right onto the P&L.

Why now

There's a reason this matters right now. The industry is consolidating, the larger players are compressing margins, and buyers increasingly want a single vendor and a seamless experience instead of a stitched-together set of point solutions. I feel this in nearly every deal I work now. And the technical tailwind has finally arrived: APIs and data are easier to use than ever, and connectivity is cheap and reliable enough to make a genuinely hands-off model real.

Put those together and the strategy becomes clear. Connectivity drives fewer human interactions, and fewer human interactions deliver higher margins, fewer errors, and higher satisfaction, because problems get solved the moment they appear. The technology has caught up to the strategy, and the market is already rewarding the companies that stop being high-touch and fragmented.

For the P&L owner, I've come to see product-led growth as more than a metaphor borrowed from software. I believe it's the most direct path to the three things we're all measured on: margin, accuracy, and the accountholder experience. Make the experience seamless and the economics work. That's been true in software for years, and it's becoming true here.

Fixing problems like this is what I care about most in this industry. I'd love to know what you think is holding CDH back, and what you'd fix first.

Proof points drawn from Elevate case studies: Rocky Mountain Reserve and Rippling.