Why Startups Suck At Customer Success
Your customers aren’t going to love your product right away
It used to be you sold someone a product, handed them a wordy and confusing manual, and then walked away.
You can’t do that anymore.
It doesn’t matter if you’re selling a suite of productivity applications or an exercise bike, the level of user complexity baked into the average product increases perpetually and exponentially. Because it can.
Moreover, today’s customer — whether it’s your grandfather with his Fitbit or an executive vice president expecting the quarterly numbers to be reported with a snap of her fingers — they want to spend less time learning how to use the product than it takes to open the box. If there’s a box.
Customer success isn’t a new science — it’s something we’ve been doing for ages. Poorly. But when done right, it’s the difference between the 20-page manual that used to come with a clock radio and the little transparent sticker with the arrow pointing to the power button on your new smartphone.
Let’s figure out how we achieve that higher level of smoothness.
What is great customer success?
To get your brain wrapped around the concept of customer success, think of it as a process that begins at purchase and ends with the last support call.
Good customer success helps the customer get started, great customer success builds onboarding into the product. Good customer success instructs the customer, great customer success anticipates and automates. Good customer success offers built-in support, great customer success eliminates customer support.
Or at least 80% of it.
Good customer success is there to make sure the customer is doing exactly what they need to do to get maximum value out of the product. Great customer success does this too, and then makes sure the product is doing exactly what it needs to do to get maximum value out of the customer.
Why startups are terrible at making customers successful
There are basically two reasons why startups fail at customer success.
One: They think about the product first and the customer second.
This is especially true of B2B companies, which is why business software is usually so much less customer-friendly than its consumer counterpart. But B2C companies don’t get a pass here either, and neither do non-technical startups. I’ve used all kinds of products that have frustrated me to no end — and it quickly became obvious that the product was built for the builders, not for me.
As a builder myself, I still fall victim to this mistake more often than I care to admit. I will build the hell out of a product or feature just because I can. In fact, I’ll write the hell out of a post because I need to say just one more thing before I get to the next section. Then the next morning I’ll read the post back and it doesn’t make any sense.
There’s a moment in every product development cycle, even feature development cycle, when the builders need to stop thinking about features and start thinking about use cases.
Two: Startups need to travel light
Most startups don’t fill a customer success role because they can’t justify it. Their logic comes down to: If we can just sell a shit-ton of product, and then hire enough support people to manage the customers, we will make a lot of money.
Startups run on low fuel. So they usually either have sales fill the customer success role, which doesn’t work because once sales gets commission, they’re out. Or they have support fill the role, which doesn’t work because support isn’t equipped for the duality of maximizing both the product’s value and the customer’s value.
And anyway, that’s not how growth works.
Growth isn’t about volume. Well, it is, but the incremental costs of adding straight volume almost always eclipse the incremental adds to the bottom line. Growth is about selling more product to the same customers while spending less money and resources landing new customers.
In other words: Growth is about maximizing both the value of the product to the customer and the value of the customer to the company.
There. I justified customer success.
What does a customer success team look like?
Another mistake startups often make is substituting project management for customer success. Customer success is more about engineering than management, and it’s more about quality than timelines.
The customer success role requires a product background, and the more technical the person, the better. Customer success doesn’t have to code, or design, or formulate, or manufacture, but the role needs to know the science that makes the product unique.
They also need to be able to analyze the front end — what the customer interfaces with — and the back end — the machinery that makes the product. It doesn’t matter if that machinery is Ruby or a lathe or a pizza oven, customer success needs to be able to troubleshoot flaws in the user experience and source those flaws back to all the processes that made the thing.
But customer success isn’t just a team, it’s built into the product
The more customer success you can engineer into the product and the process of delivering it, the less time and money you’ll spend on customer success as a service. This is how startups scale — it’s essentially automating growth.
A good product team knows that the requirements for customer success will be surfaced in both sales and support. Those requirements need to flow through the customer success team, get prioritized, get designed, and then those designs are sent to engineering to build.
There are billion-dollar companies out there, two of them in my backyard, Pendo and WalkMe, evolving the concept of customer success in the software world from instruction manuals to help balloons to actual product features. They do this by using automation and machine learning to put structure around the process I just defined in the last paragraph.
You don’t need automation and machine learning to get started.
How startups create great customer success
Customer success starts at the ideation phase. At this point, most startups are usually just focused on building the product. Smart startups build the product, define the product’s path out to the market, and map another path path from the customer back in.
To map these paths, you need to know the problem and the solution backwards and forwards. I’m not just talking about the problem you’re trying to solve, but all the ancillary support for every variation of the problem. And I’m not just talking about your take on the solution, but the actual real solution, as well the competition’s take on that solution.
Then you can map the paths.
You have to be able to anticipate the use cases.
When you’re an expert in the problem and the solution, you’ll be able to determine the optimum path to solve the problem. Most of your customers will not take this path. Instead, they’ll take the easiest path. Between those two user flows, there will be a number of variations. Prepare for all of them.
You have to build flexibility.
You can make assumptions forever, but you will never be able to perfectly predict customer behavior. Thus, make sure your product, the transaction, fulfillment, and maintenance is as flexible as possible. Ideally, you’ll need to be able to alter the product on demand, as well as how the customer purchases it, receives it, and gets help with it.
You have to embrace simplicity.
I’d say about 90% of my mistakes building and delivering products come from adding complexity where complexity wasn’t called for. Like I said before, as builders, we fall in love with building. Always err on the side of simplicity, from the very first moment of ideation.
You have to be able to catch the feedback.
Getting customer feedback — whether it’s how often they use the product or what they tell the world about it — should be a mix of automation and manual input. Keep data on every aspect of sales, usage, and support. But also make the proactive effort to get feedback directly from customers.
Then build a virtuous cycle.
Start with small steps in each of the above areas, but make sure you close the loop. The feedback makes a more valuable product, the customers stick around longer and buy more. And make sure that when you act on the feedback, you don’t add complexity, but rather tweak the product to balance complexity and value.
Hey! If you found this post actionable or insightful, please consider signing up for my newsletter at joeprocopio.com so you don’t miss any new posts. It’s short and to the point.
