When I learned that my personal financial adviser at Merrill Lynch was on the line, and that he’d described the call as “urgent,” I figured that meant one of two things, neither of which was the least bit good. Either the stock market was taking a nosedive or one of my investments had flatlined.
Actually, the news was even worse than that. It was about Salesforce.
As it turned out, my adviser wasn’t calling about my portfolio, but rather to warn me that my company was on the verge of losing his company’s business. In 2013, Merrill Lynch wasn’t just any Salesforce client. It was our single biggest.
Merrill’s rejection would send the message that Salesforce wasn’t ready for the big leagues, prompting other important clients to dredge up their own complaints...
Six years earlier, when Merrill decided to install Salesforce software for its 22,000 client advisers, it was the first truly massive business to sign with us. At the time, I’d declared this a major coup and the surest sign yet that Salesforce was poised for growth. I’d reasoned that if this leading financial services firm trusted us to manage all their highly secure, technically sophisticated systems and transactions — in the cloud, no less! — there was nothing we couldn’t do.
Now we apparently had a problem. My adviser had just stepped out of a company-wide meeting during which John Hogarty, Merrill’s COO, had told thousands of advisers that the company ought to kick Salesforce to the curb — prompting the whole room to erupt in applause. “No one likes your product here,” my adviser explained, unnecessarily. “You need to get involved and fix this quickly.”
To make matters worse, the Merrill Lynch Mutiny of 2013 (as I’ve come to think of it) wasn’t the result of some outside circumstances that none of us could control. The company hadn’t been seduced by a competitor, or slashed its IT budget. The explanation was brutally simple: They didn’t like our software.
The problem was this: Merrill’s advisers, who were the guardians of its bedrock business, valued speed and functionality above all else. Salesforce software took too long, they thought, and the interfaces we’d built for them weren’t intuitive or easy enough to use. Simple tasks required too many small steps, siphoning off priceless minutes from their workdays. Even something like retrieving a contact from their address books, for instance, required three clicks, each with a six-second wait time. The more I learned about the nature of their frustrations, the worse it sounded. I wasn’t the least bit surprised that Merrill was livid and that we were on the verge of getting fired.
“No one likes your product here,” my adviser explained, unnecessarily. “You need to get involved and fix this quickly.”
This was a dark day for me on a number of levels. Losing Merrill as a client would be a disaster in and of itself, but the ripple effects could be catastrophic. Merrill’s rejection would send the message that Salesforce wasn’t ready for the big leagues, prompting other important clients to dredge up their own complaints and rethink their relationships with us. Beyond that, I was furious that we hadn’t been aware of these problems before they exploded into a five-alarm fire. Most of all, I just felt terrible that we had failed to live up to one of our core values: customer success.
At Salesforce, our mantra is that nothing is more important than giving our customers the tools and support to be successful. Sometimes it’s a matter of growth, raising revenue or net profit; other times it’s a matter of better reaching and connecting with their customers. Often, success simply means streamlining previously byzantine processes and operations — enabling a customer of ours to redirect more of its time and attention elsewhere. It might sound hokey, but our customers’ success is how we measure our own success at Salesforce. After all, we can’t grow unless our customers are growing with us.
Yet here we were at the edge of a cliff. We’d failed to uphold this value with Merrill Lynch. Shortly after that meeting, Mark Alexander, Merrill Lynch’s CIO, informed us that we’d been placed in “containment,” meaning that we could conduct no further new business with the bank until we’d fixed these usability issues. By “the bank,” he meant not just Merrill Lynch but also its parent company, Bank of America, one of the world’s largest financial institutions. We’d already landed some business with BofA and had been working hard to win more. Losing this account might shut that door forever.
Working on Borrowed Time
I knew my adviser was right; I had to step in and do something to address the situation — and fast. After clearing every other issue out of my brain, and off my desk, my first phone call was to Simon Mulcahy, a then 41-year-old London-born Salesforce executive we’d hired in 2009 to handle some of our most complex customer engineering projects. A former British Army officer, Simon had previously worked for the World Economic Forum, where he’d created an “Innovation Heatmap” that was so ingenious the Smithsonian wanted it for its collections.
So there was no one better than Simon to spearhead a “Get Well” program to put us back on track with Merrill Lynch. He joined me in San Jose for a dinner with John Thiel, head of Merrill Lynch Wealth Management, to whom I gave my word that we would fix these issues — and that Simon would have every resource necessary to do so.
Working on borrowed time, and under enormous pressure, Simon began hopscotching around the country on a grand tour of Merrill Lynch’s regional offices. He’d set up meetings with several dozen advisers, who he hoped could shed more light on which features and functions of the software they (and their colleagues) hated most, and what specific improvements they hoped we could make to them.
A couple of weeks into this journey, a funny thing happened. Simon discovered that his interview-style approach wasn’t yielding a lot of meaningful, actionable input. Most people in his position might have felt relieved by the fact that the majority of the advisers’ complaints amounted to small, relatively simple fixes to the software. But Simon couldn’t reconcile the fact that even when added together, these gripes didn’t seem to explain the intensity of the advisers’ frustration.
It seemed that Simon had a mystery on his hands.
See a Bear, Shoot a Bear
When I first started working in sales for Oracle, back in the 1980s, the notion of sitting down with clients to talk about how our products were working, let alone engaging in exhaustive bouts of problem solving, was rarely top of mind. Back then, Oracle and other fast-growing companies adhered to a simple strategy that went like this: “See a bear, shoot a bear.” In other words, if you were meeting with a customer, your singular goal was to leave the room with a signed contract — in as short a time as possible.
I’d never been a fan of this strategy. The problem was, it didn’t incentivize anyone to consider whether the customers on the other side of these transactions really needed the software they had purchased, or whether it helped them make progress on their own business goals. And it didn’t leave a whole lot of time to build trust, either.
When we founded Salesforce, I vowed to avoid that business model as much as possible. There were only a few companies selling enterprise products back then, and all of them required customers to lock into long-term contracts with hefty maintenance fees. If you didn’t like the results, in other words, you were pretty much stuck. So with Salesforce, we decided to sell subscriptions that could be canceled at any point, which meant that it didn’t matter how many bear pelts we collected. Our renewal rate became the measure of whether or not customers were getting what they needed from our software, and thus it also became our chief barometer of health.
It took a while to get this formula right. In the beginning, our customers were mostly small businesses who paid us monthly on their credit cards and could cancel at a moment’s notice. After a while, I realized we had an attrition problem, and we needed to make a fundamental shift in our operational philosophy. We weren’t about to turn our back on our fundamental business model, so we had to reorient our efforts to show our customers that our mutual interests were aligned — that our success depended on how quickly they achieved their own.
Our first step was to offer customers another point of contact beyond the sales department — a person whose job it was to listen, rather than to close deals. We created a team of customer success managers whose entire function was to understand how customers were using our software tools and, if they decided to bail on us, to circle back and find out why.
Merrill Lynch was so big, and its needs so specific, complex, and difficult to articulate, that we hadn’t been able to see that our products weren’t getting the job done.
Over time, our team of customer success managers continued to grow in importance, and in number. They became so much more than glorified customer service reps: They were the eyes and ears of our company, collecting the invaluable feedback that we used to not just improve our products, but also to tailor those improvements to the specific and unique needs of our customers.
In 2013, however, this system seemed to have fallen short. Merrill Lynch was so big, and its needs so specific, complex, and difficult to articulate, that we hadn’t been able to see that our products weren’t getting the job done.
See a Bear, Save a Bear
By this point, Salesforce was 14 years old and our engineering team had become a formidable force. We were confident that we had enough programming firepower to fix whatever was wrong. But even as Simon took meeting after meeting with Merrill’s advisers, he was still having a hard time figuring out exactly what the problems were, let alone what needed to be done to solve them.
Simon began to get the feeling that the advisers were only telling us a partial story. He had noticed that Merrill’s advisers had plenty to say about the small glitches, like address book navigation, that they thought we should be able to fix. What they weren’t talking about were the big, sweeping improvements that could fundamentally transform how they did their jobs — because they simply didn’t realize that our software might have the power to solve them.
So Simon decided to pivot. He tucked the script of questions he’d been asking back into his briefcase and started opening meetings by asking the advisers to forget about software for a second. He invited them to pull the camera back from the minutiae of their workflow and show him a more panoramic, zoomed-out view of the larger challenges they faced in their work. Now, finally, the truth began to emerge. For example, when they asked for faster speed in navigation, what they really needed was smarter “tasks” that could do things like triggering proactive alerts about their clients and guiding them to useful market data.
We knew we had to stop focusing on checking off boxes and start trying to figure out how to deliver breakthroughs.
When Simon told me about how this approach had immediately started generating scores of promising ideas, it reminded me of a quote attributed to my boyhood hero, Albert Einstein: “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.”
In the end, Einstein was right. If you focus the bulk of your time and effort on understanding the problems, solving them becomes the easy part. In the past, we’d been trying to help our customers simplify or automate all of the small, tedious business functions that ate away their time. That was important, but in a world where technology holds almost limitless possibilities, marginal improvements couldn’t come at the expense of stepping back and identifying the biggest, most urgent and potentially painful challenges our customers faced, and then figuring out how to address them.
It’s hard to overstate how important this shift would turn out to be. It allowed us to see that the real problem wasn’t the software we’d built for Merrill but the customer success infrastructure we’d built. What Merrill’s advisers showed us is that we were going about the process backwards.
By tackling the problems behind the problems, we could engineer the software to make our customers more efficient in ways they couldn’t have imagined. From that point forward, we knew we had to stop focusing on checking off boxes and start trying to figure out how to deliver breakthroughs.
This philosophy isn’t just applicable to the software business, or even to the technology world. Any company can provide its customers with features that can make them more successful than they ever thought they could be. They just have to stop shooting bears and start listening for what their customers really need.
* * *
From the book Trailblazer: The Power of Business as the Greatest Platform for Change. Copyright © 2019 by Salesforce.com. Published by Currency, an imprint of Random House, a division of Penguin Random House LLC. All rights reserved.
