Customer success teams are here to stay. It is inevitable that the vendor of a subscription based software application takes a keen interest in the success that has been achieved with that software. After all, even the most specialised software application is in danger of being "commoditised" with the technological advancements made possible with the cloud infrastructure. But what is customer success? In his excellent book "The Outcome Generation" (I have put a link to that below the article), Paul Henderson describes three distinct generations of customer success thinking. Generation 1 defines success on the achievement of features. Generation 2 defines success by the problems that are solved. And Generation 3 defines success by the outcome that has been achieved as a result of the program (or, future results enabled by the transformation).
We often sell at Generation 2, but deliver against Generation 1
With the introduction of "Solution Selling", the transition was made from comparing functions and features, to a definition of the problem that the software implementation was going to solve. Sounds logical, right? When was the last time you were fully convinced on the efficacy of a software application, merely by the number of features it has (even if that list is impressive). The right question to ask is: "So what?", as features don't solve problems, they are just tools in the toolbox, if unused, they go to waste. Fast forward to the delivery - look at the contract, the Statement of Work - how is the scope defined? Nine out of ten, you will see some description of the problem that is to be addressed, but the actual measurable scope, the piece of the statement of work that has any contractual value, is more often than not described in the form of features delivered. Changes to these features? In comes the Change Control process, and actual benefit is going to be measured against the budget of the project - not by dropping other requirements or features, but on top of everything else already contracted. Somehow, we are still surprised that implementations of business systems are notorious for their cost overrun...
What is success, and how do we measure it?
Before defining WHAT success is, we need to be clear for WHOM we are defining it. Customer Success Management kind of does that by its name... Does it? If so, then the success metrics used should be the metrics that are important to the customer. Defining an internal commercial metric, and attributing it to the success the customer has is shortsighted and lazy (yes, this is harsh critique, but necessary). For example, if your customer success team is measured on subscription licences at a customer, then you are taking the easy measurement, but not the meaningful one. Customer success is a specific outcome the customer can achieve with the introduction of the software. Retention, and possible expansion, of the licence subscription footprint is a logical result from that. Let's make a simple analogy with ice-cream representing customer success, and temperature (in degrees below room temperature) as the metric. If the degrees below room temperature is 24°C, then we conclude that ice-cream is the object. The fallacy being that "Ice-cream is cold, therefore something cold must be ice-cream." - this is of course nonsense. Therefore stating that the customer is reaching the outcomes for success, simply because they are subscribing to the software is equally nonsensical.
So what should we measure? It is hilariously simple - success is the attainment of the measurable outcome the customer is intending to achieve with the system implemented. If it is a reduction of Agent's time in resolving client's issues by 15%, then that is the measurement. If it is an increase of qualified leads into the sales funnel by 20%, than that is the measurement. Deciding what the customer success metric is, is simple - how to measure it? Certainly not by the traditional, myopic inward focused traditional metrics.
Enter: SCRUM - an effective way to deliver Customer Success
SCRUM needs little introduction, but it does require a good understanding. and I can certainly recommend reading Jeff and J.J. Sutherland's "SCRUM - The Art of Doing Twice the Work in Half the Time (linked below). Let's start with defining the roles - the Product Owner is found at the customer - this would be someone that is accountable for achieving the outcome. The Customer Success Manager is the most logical choice of being the SCRUM Master. The team? The people that are actually going to make the changes that will enable the outcome? That team consists of members from the customer, the vendor, and anyone that can work through the items (backlog) to enable the desired outcome (product).
Some key things to consider:
- The product owner sets the requirements, the SCRUM master converts it into a backlog, which is estimated in relative size by the team that is going to execute the work
- Each backlog item is identified with a measurable outcome value - 80% of the remaining value is achieved with 20% of the backlog - the backlog is prioritised accordingly
- Keep the sprints as short as possible with still achieving and outcome (deliver something of value)
- Team members are selected on their ability to work on the backlog with efficacy - they can come from the customer, vendor consulting team, and/or the vendor product team
- Keep measuring - the product owner will continuously capture the measurements on success, and add things to the product features that can enhance outcomes as identified by increased data
The Outcome Generation by Paul Henderson
SCRUM by Jeff Sutherland and J.J. Sutherland