Highlights:

• The evolution of Customer Support to Customer Success
• The role of CS in the flywheel of continuous selling
• Correlating your distribution model to your CS model
• Avoiding the ‘do everything’ CS department
• The key metrics of TTV and NRR

Setting the scene

It’s fair to say that Rav has grown up with Customer Success (CS), starting his career in the Unix admin world. Moving on toAccenture and IBM, before being catapulted into the startup world at the then young company Salesforce. Since then he’s gone on to hold senior CS positions at Yammer, Zendesk and Slack, seeing first hand how CS has grown and matured as SaaS has exploded. Rav is probably one of the most experienced CS leaders in UK/EU, and kindly shared much of his thinking on the evolution of CS, what metrics matter, how to align the selling motions and avoiding the ‘do everything’ department. He’s now paying his experience forward as an investor and advisor for numerous young companies, helping them think through their business models and approach. A must listen for all founders and leaders as they build their business in the world of continuous selling.

Landing in my first customer success-type role

I graduated in the early 90s, and the year I graduated, graduate recruitment was down 65%. So, I started my working life as a builder/labourer/plasterer. My neighbour who was a builder, needed a hand and I needed the money! After doing that for about six months, I thought ‘I want to get a job that involves working indoors!” So I managed to land a job as a Unix admin in a public library service - I was 21 and it was full of ladies who were the same age as my mum so I just got mothered every day coming to work! I even tried to grow a beard and look older, but none of that worked! I was there for a couple of years and I really learnt about working with people in that role, even though I was a Unix admin, the library system had loads of problems after it had been moved to this new platform so I was constantly dealing with people and I found I enjoyed the people bit as much as the tech bit, which led me on to my first corporate job.

I then went to work at Anderson Consulting, (now Accenture). That was a little baptism by fire, because I'd come from public service and I was a Unix person who had recently retrained as a Novell Network engineer, which is what was a really in demand skill at the time. They hired me as a Novell engineer, and I came in on the first day and they said ‘you’ve heard of Lotus Notes, right?’ I said, ‘No, I've never heard of it’,  and then they put me on third line Notes support! I literally just got thrown into productivity and collaboration tools, and I didn't realise that’s actually what most of my career, up until becoming an investor, would involve.

The people who invented office collaboration and productivity, was Lotus Incorporated, but they are often remembered for inventing the spreadsheet. They actually invented a whole suite of office collaboration tools. In fact, prior to Microsoft Office, Lotus was dominant in office productivity software with its Smartsuite bundle - people forget about that. I went and worked for them in Australia for 10 years and went all around Asia, then SaaS started to become a thing and I was then lucky enough to land a role with the SaaS pioneer Salesforce - which ironically was in the building opposite the building at Lotus where I worked, it was literally on the other side of the car park! I left Lotus one Friday, and came back on the Monday, same time, same train but just walked into the building on the left - and I actually could see my old desk from my new desk, which was quite ironic. Through various circumstances, I then landed at Yammer, which was an early stage startup. It was a massive shock to the system going from these big companies to a startup. It was a lot to take in sometimes.

Yammer is  where I landed in my first named “Customer Success” role. Everything I'd done up to that point was working with customers, helping them to be successful, but not, overtly part of my role definition. I learnt a great deal there working for David Sacks, and the really great leadership team there. We eventually got acquired and ended up at Microsoft. That was actually a very positive experience, but by then I had the startup bug. One thing I was really looking to do at that stage in my career, was to really build the muscle of being a people leader. I'd been a team leader, I'd been a manager, but I wanted to take the next step. The opportunity to do that arose at Zendesk, which was small but very successful, and was growing rapidly, so it was a terrific opportunity to hone those leadership skills, and I had a really wonderful time there. The team was amazing and I learnt a great deal. Many of the people I hired are still there, and they're progressing in their careers, which I'm really happy about.

After Zendesk went public, the CMO of Zendesk left and became the CEO of this little company, no one had heard of called Slack. He took some of his team with him, and they knew I’d been at Yammer (the ‘Slack’ of it’s day) and every so often I would get a ping asking to chat. These conversations kept happening more regularly for longer. I would be in San Francisco and meet the team there and then one day I jokingly, just really flippantly said, “I talk to you guys more than I talk to my team at Zendesk. Maybe you should start paying me?!” - a completely off the cuff remark. They asked if I would seriously entertain that, and although I was really happy at Zendesk, I did have  an urge to get back into that collaboration, productivity space. I was interviewed by what felt like everyone in the company and I convinced them to have a London office because there were no plans for one, as well as hire me and to do this Customer Success thing and prove it out. Now, Customer Success is I believe either the third or fourth biggest function at Slack, if I remember correctly.

The transition from Customer Support to Customer Success

There's a lot of debate about where Customer Success  first started. There's some obscure software companies that claim credit, some people claim that it was Oracle that invented it, but regardless of where it came from, it was really Marc Benioff and Salesforce that popularised it and made it a ”thing”. It was a tremendous innovation at the time, but the way Salesforce went about it has completely unintentionally, set a template which doesn’t quite fit contemporary SaaS startups (and, which I seem to be on a one man mission to undo!) The reason, and I wrote about this recently in an article called The Missing Piece of Software Sales, is if you actually look at Salesforce back in 1999/2000, and look at a contemporary SaaS startup, all the ones that you and I spend our time looking at and working with Andy, structurally from a go-to-market perspective, they’re organised  almost exactly the same as they were 20+ years ago, despite the fact that contemporary Software companies have a completely different way of building software, distributing it, licencing it and then selling it. The organisation structure in sales, what I call in the article “the orthodox sales production line”, is almost exactly the same. Salesforce found that by changing the distribution method to cloud, switching costs for customers were really low, because the customers made an operating expenditure, not a capital one, so they needed to invest resources into retaining customers by adding Customer Success, however they still largely retained the orthodox sales production line.

Salesforce realised that they were doing great with selling, but they had 5/6/7/8% churn and rising. I think it was David Dempsey in Ireland who really looked at the numbers on that. He said, “before we all start slapping each other on the back, we've got a very leaky bucket, and we need to do something about it”. Their innovation was this idea of Customer Success. Now, Salesforce has obviously gone on and become a hugely successful enterprise software company, but it's unintentionally set a template for contemporary founders to go, ‘you can just do sales the same way as we’ve always done and just bolt this CS thing on at the end, then all your problems are solved’. I have found over the years that that is not the case. You can get away with it if you either have early entry and incumbency into a market and manage to scale or if you have giant financial resources to build a 5000 plus person customer organisation. What Salesforce did, and the scale of its customer business, you just can't make that type of capital expenditure anymore.

When I was at IBM, I don't think in the entire time I was there, I ever worried about the customer using the product. They bought data centre space, racks and backup solutions, and we'd train administrators, and because there was so much capital involved, no one at this business was going to put their hand up and say, ‘I think buying this product was a mistake. Let's stop this project.’ They're going to keep on going!

What I spend my time on talking to and helping founders with is, when you've sold the deal, the job of selling hasn't finished - you're moving into a “continuous sales” motion. How can we help you build a foundation where CS is a part of the sales motion so we don’t just sell once and consider the job done, but where we continuously sell? A lot of that has to do with unpicking the orthodox sales structure and helping people build incentive structures to make it worthwhile for people to continue selling. In the article I presented this idea of “mirroring”. It normally takes at least two sets of skills to sell for the first time: commercial skill and product/technical  skill. You need to mirror that after the first deal has closed and have commercial skills like an account manager, aligned with a product expert like a Customer Success person. That should help to create a nice flywheel of “continuous selling”.

Differentiating management from leadership

I was at Yammer, and I was sitting in a room with my boss, and he said ‘this is what I'm thinking, we should divide the team like this. This colleague will have this and you should lead this’. And I was like, ‘I've never really thought about that’. He could sort of see that I was thinking about it, and that being a leader hadn't occurred to me. He said to me ‘Look, you don't have to be a manager or a leader to be successful in your career. If that's not what you want to do, that's fine, you can have a really terrific career, just getting to the top of your game and doing what you're doing’. I almost instantaneously went, ‘well, if someone's got faith in me that they think I can do this, I should probably at least give it a go’. That was the first time that I realised, actually, this is a vocation, this is something that if you do it, it should be because you want to do it, not because you feel you have to or you should do it. I will be happy to admit I made every single rookie manager mistake there is to make, things like assuming the team could read my mind, trying to manage every person in the team exactly the same way, even though they're all different individuals. One of the reasons why I moved on to Zendesk was I realised, I think I've made enough mistakes, and learned from them now that I'm in a position to actually build that muscle of leadership.

For me, management is about focusing on productivity and tasks and delivering to an outcome, whereas leadership is actually about setting a vision and a direction, and getting everyone bought into following that vision where we'll build the machine together. It was a very interesting experience at Zendesk, because having that blank canvas was liberating but also scary because there's no roadmap; you look at what works, you go and talk to people who are doing similar things, you try to learn from peers, you make more mistakes. But I learnt that the idea of my job, actually as a leader, is to create the conditions for the team to do its best work and help them in their careers. That was actually where I think I added the most value, thinking about how to set the vision strategy, make sure they're all bought into it, and then get out of their way. Whilst creating an environment whereby they are fully on board with the fact that I'm here to help them with their careers. Hopefully, that career will continue to be either in the team or in the company. But in return, I really want them to be responsive and call out early, if there's a problem so I am best placed to help them.

Customer Success does not have an agreed definition

One of the key challenges with anything related to Customer Success is, first of all, it doesn't really have a strict definition. We can go to someone off the street and say ‘tell me what sales does?’ They’ll likely respond with some version of “they ring up strangers and ask them for money”. But there is no clear definition for Customer Success. What it takes to make a customer successful in one business can be  entirely different from what it is in another. I don't think enough people accept that because then what you often see in companies is that they have this cookie cutter thing of “we did this in a previous company, so we'll just do it here”. But, what happens if that company was a large enterprise top-down selling motion, and you're a freemium, bottoms-up motion? That previous company’s playbook is not likely going to work well. There is actually an incredibly strong correlation with your distribution and acquisition model, and how you service your customers. Which is why I have become less and less a fan of freemium models over the years, because what I've seen is that they often result in two general problems:

1. You very rarely get to a decision maker or an executive sponsor of sufficient weight to make a very large purchasing decision because it's bottom up led.
2. You tend to have people who, when they convert to paid, generally have very low proficiency in using the product, because they've been left to figure it all out themselves.

The latter is actually worse from a CS perspective, because you're going to someone who's used the free version of your product for a year, and saying, ‘I'm here to help you, because you're not really using this product, as well as you could’ and they said, ‘what are you talking about? We don't need any help! We’ve been using this for ages’ So, with freemium you've got two problems; one, not having an executive sponsor that you can talk to you to try and grow the footprint and two, the likelihood of encountering really low proficiency of usage amongst the users, which is going to make getting a renewal really tough. A free trial, I think works a lot better, because there's some intentionality there from the customer to participate, and you can actually bring people or in-product resources in to help them. There's also the model, where:

• You're a largely self service business
• You're largely inbound
• You have essentially a long tail of customers
• Your average deal size may be quite small
• But you've got 1000’s of these customers

The problems I see here are people trying to build a large “white glove” Enterprise style CS department for this kind of sales motion. Really, what you should be doing in this situation is customer marketing activities backed up by a smaller group of CS people and with more in-product guidance and learning resources.

I've been lucky, I've worked in different companies and have seen what works and what doesn't work in various models. I've also had the experience of  going from one model to another because we moved up market to enterprise and realised that the inbound self service model doesn't work as well  when you suddenly have to make the leap to selling to large enterprises. That transition can also not work because you may not have the right kind of experience in your sales team; you can get fooled in an inbound or self serve motion into thinking the product is so good that it just sells itself and that will also be the case when selling to a large enterprises, so when you are ready to sell large enterprise deals you just use the same people to do the large enterprise selling as were handling the inbound conversions. Actually you may have had more generalist sellers or sellers from advertising or other industries when the model was almost all inbound conversion, especially because you weren't doing any real negotiation, or any real discounting. It's hard for a lot of those people to make that transition from selling to one person in an inbound conversion motion to selling to multiple stakeholders in a large enterprise. I've seen the problem when the time between making the transition to the right enterprise sales skills took too long, or they just tried to bridge the gap with the same people who were doing inbound conversions.

You have to “unbundle” for substantial growth

We talked about this “orthodox sales production line”, and then bolting something onto the end of sales process to stop the “leaky bucket” of churn, but this thing at the end the production line, CS, doesn't really have a definition, and we often don't quite understand what KPIs it should have. The natural tendency then is for anything that doesn't have an owner in the organisation structure, (or stuff that isn't warranted in the organisation structure), to get pushed down to the CS department because they're at the end of the production line. The analogy I always give to founders is, if you were making cars, what you've basically done is you've taken the production line, and you've said to the person in the showroom, “well, your first job is to get the car delivered to the customer on time, but our car is slightly different from everyone else's, so, you have to teach them how to drive our car as well. Then, whilst you're teaching them to drive, can you sort out any manufacturing assembly defects that happened further back in the factory. Then, whilst you're doing that, get them to buy leather seats, a rear camera and some other add ons. Then, get them to come back next year and buy another car!” You would not do that selling cars, and you should not do that selling software.

There’s this idea of “unbundling”, where you get to a certain point in the startup's growth, and you have a lot of people wearing multiple hats. You have to do this initially because you haven't figured out what you need yet. Secondly, you haven’t got the resources to hire individual roles. What then happens is, you get into the motion of just continuing to hire people with bundled responsibility when really you need to “unbundle” it and start having more specialisations. The timing of when to do this is critical - it can be damaging to the business if you “unbundle” too early or too late.

Sales and CS - the most important relationship

I try to abstract it away from the organisational structure as much as possible because the thing with that linear production line structure is you actually do need it because as you scale, the business has to be much more about predictability and efficiency. If you go back and look in history, the org chart was invented by a guy called Frederick Winslow Taylor. He wrote this book called Principles of Scientific Management, and his idea was that almost all manufacturing is artisanal, and what we should do is take an artisanal job, divide it into 50 jobs that are unskilled that we can maximise the output of. So you need a hierarchical organisational structure as you scale, so that’s why I favour abstracting away from the organisation structure and thinking more about the incentive structure. If people are in two different departments, but we need both of their skills to achieve an outcome, I need to incent them to work with each other. Overall,, I try to get everyone from leadership down to philosophically accept this idea of ‘we're in this continuous selling motion - we don't stop selling’.

A really good example, and you could do this all the way through marketing, product and engineering, to sales and success, is don't pay an engineer on shipping the feature on time, but pay them on how much the features used - that's just one example of changing the incentive structure to think about a different outcome, similarly -

• Pay 80% of an AM’s compensation on new revenue, but 20% on NRR
• Make a CS person’s 80% NRR, but 20% ACV

The bigger part of the incentive is driving the primary behaviour you want to see. I always think less about organisation structure, where it sits and who needs to do what, and think more about what skills are needed to do X and how do we incentivize people to work together to deliver X. I say this to founders all the time, who say, ‘why can't I just have the CS person do everything?’ I usually respond with some version of, “can you explain to me why it took two sets of skills to sell the first time but it only takes one set of skills to do everything else?” It’s the simplest way to look at it.

A Chief Customer Officer is essential when complexity increases

I've seen that if you're successful as a business, a couple of things happen; you start accelerating from your A/B/C funding rounds onwards and the pace of everything just drastically increases, but the complexity also goes up. So, what I used to do to make an SMB customer successful does not scale at the large global enterprises we are now selling to, because they may need four or five different sets of skills to make them successful. They might need:

• An adoptions specialist who does change management
• A technical specialist to help them build on that platform
• An enhanced level of support because, because the solution is mission critical and without it they cannot do business

When the complexity of what they need gets bigger, that's normally the time where you want to think about having someone who owns all of those customer pieces; your VP Customer or Chief Customer Officer. Now that making customers successful has become multi-disciplinary, and we have had to “unbundle” from one role into several roles, and from several roles into several teams. The orchestration of building that machine and running it, making sure it's efficient and returning growth revenue back to the business needs to be owned by someone. That’s the signal that you need to have someone who owns those multiple facets, and they'll typically own customer support (or customer experience as it’s often called), customer success and professional services. The CCO may also own the partner organisation, technical teams and sometimes renewals, because if that leader has come from a commercial background, it can make sense to have that all in one organisation.

The two key CS metrics: time to value & net revenue retention

There are two key metrics I believe every CS team should focus on. One is time to value, which is highly contextual. That is, some kind of proxy for business value based on product usage characteristics i.e. when customers get to this level of product usage we’re confident they're seeing value from the solution. Ideally, we want to get them to value in 30/60/90 days, not 7 months or 10 months. You can't go on for months and months and months unless it's a multi year deal. Time to value will be different in every business, and will change over time as your product and customers change, so it’s important to keep revisiting it.

The other key metric is net revenue retention:

• How much revenue are we retaining?
• How much revenue are we growing from existing customers?

In other words, how much are we adding back to our company's bottom line?

This can actually be a challenge for some CS practitioners and leaders that have the historical mindset of, ‘I'm here to make the customer happy and prevent churn’. We really have to move on from that and focus on growth too. There's work to be done there in shifting the mindsets of some CS folks so they are comfortable acknowledging that it’s okay to have a commercial goal.

Prediction: Customer Success tech will continue to grow

One of the things that I've been doing personally is finding, working, nurturing and giving money to entrepreneurs who are building tech precisely for CS. I've made four or five personal investments in this space, and I'm going to make a few more. I believe the thing we're going to see over the next few years is more and more purpose built tech for CS - there's a whole other “stack” that needs to be invented for CS and it will be able to take much greater advantage of advances in things like AI and machine learning.

For example, if you can take the subjectivity out of customer sentiment, that's just as important as being able to track product use. I think COVID has been an accelerator for CS tech, as there was a period last year, when a lot of very panicked CEOs realised they would have to double down on their existing customer base. I don't think it's a coincidence that since the pandemic, I’ve started to see more entrepreneurs building products for CS use cases.

What are entrepreneurs in the CS space really thinking about right now?

Some of these entrepreneurs are really thinking about, ‘how do I build technology that helps CS practitioners, but ultimately benefits their customers?’. I've really admired some of the thinking about that. There's a company called Cast.App, who I've been working with closely and they have realised that one of the biggest pains is trying to do service reviews with customers; customers are too busy, don't have enough time and reviews are a nightmare of effort to prepare for Customer Success. CastApp has built this proprietary video tech that sucks up all your data and builds a custom review video for the customer on the fly. I'm really impressed with it because, from an engineering perspective, it's amazing and it's a massive problem that needs to be solved for CS teams and their customers. They're really building something world class.

I also really admire anyone through this pandemic period who has managed or led a team. I would find it so hard to manage a team and keep them motivated remotely - that is a whole set of skills that I do not have! I’ve talked to a lot of friends who are leaders, and I take my hat off to all of them.