Customer success exists for a clear reason. Get customers to stay longer, buy more, and advocate for us. If that happens, net revenue retention goes up, customer lifetime value compounds, and customer acquisition costs get more efficient. The business case is airtight.

The premise it's built on is not.

Here's what we actually built: a profession, an org structure, a set of workflows, playbooks, and SOPs all organized around one core activity. Getting customers to do the things they need to do to be successful.

Things they don't want to do.

Things they can't do well.

Things they have no desire to do, no time to do, and no particular skill in doing.

And then, even the customers who actually try — who follow the guidance, complete the onboarding, engage with the CSM, do the work — they're probably not going to do it as well as they need to in order to get the outcome they came for. Because they're not experts in your product. They're experts in their business, which is why they bought yours.

We built an entire profession around getting non-experts to do expert-level work. Then we measured ourselves on whether they did it. Then we were surprised when some of them didn't.

This is structural failure number one. Not because the people in CS are bad at their jobs. The opposite. The most driven, caring, relationship-oriented people in any company are usually in customer success. The failure is in the design. We pointed brilliant people at a fundamentally flawed premise and asked them to make it work through sheer effort and personal skill.

Some of them do. The best CSMs in the world have figured out how to coach, coax, guide, and cajole customers through complexity they never should have had to face. They've built personal relationships strong enough to compensate for a broken process. They've carried the weight of a structural problem on their backs and called it their job.

That's not a scalable model. It's not a fair ask. And it's not what customer success should be.

The right question isn't "how do we get customers to do what they need to do?" The right question is "what complexity are we forcing onto the customer that we should be absorbing ourselves?"

Those are very different questions. The first one accepts the premise and tries to optimize within it. The second one challenges the premise entirely.

When you start asking the second question, the answers get uncomfortable fast. Because it turns out a lot of what we ask customers to do — configure, implement, learn, adopt, maintain, optimize — is stuff we could do for them, or at least do with them in a way that actually produces results.

The customer signed up for an outcome. Not for a curriculum.

This is the foundation everything else in CS is built on. Get it wrong here and you're optimizing a broken system. The next two structural failures make it worse. But this is where it starts.

This is the first in a three-part series on the structural failures of Customer Success. Part 2: The Best People Are Doing the Wrong Work | Part 3: The Tools Have Boxed Us In