Your tool could be a walk in the park, and even then, people could fail to adopt your product.
We’re probably all familiar with Slack –– it’s easy, but even with products like Slack, change is still hard.
Rav Dhaliwal was the first member at Slack outside of the US, and in this recap, we’re going to look under the hood of Slack’s change management practices. In 2017, Rav shared how they manage change using a change and adoption methodology at a Totango event.
At the time, Slack, whose mission was to make peoples' working life simpler, more pleasant, and more productive, seemed to be on track. At the end of 2016, they had 4 million daily active users. On average, people spent 2.25 hours a day on it –– they got product stickiness right!
Product stickiness was critical to them, and the best way to ensure that was to make Slack really valuable to their customers. To create the value, they needed customers to actually use the product; that’s where adoption came in.
Customer adoption: the problem
Here’s the scenario:
Justin from engineering is a really cool guy who probably read about Slack on TechCrunch, fell in love with the tool, and purchased it with his own money. Before we know it, 300 engineers are on Slack, all thanks to Justin.
Justin’s company picks up on this, and now they want to roll it out to everyone –– yay!
But it’s not a “yay” for Bob. Bob works over at accounting, and he’s quite happy with his emails and SharePoint.
That scenario sums up the problem with adoption: Bob has been told to use Slack while Justin wants to use Slack.
When we're deploying a product or service, it's not about the technology; what’s really happening is that we’re asking people to change the way they work. And change is tough. That’s why at Slack, they created a change and adoption method.
Slack’s change and adoption method
This process was purposely created to be simple enough where customers can do things themselves.
The change adoption method is designed to do a few things:
Raise the awareness of Slack.
Create a desire to use it.
Give people knowledge about how to use it.
Sustain that new way of working.
Let’s break down this process, starting with people & purpose.
People & purpose
People and purpose is about defining the need for the change. People are much more ready to accept the change if they understand why the business is going through it.
The best way to define the change is by using business terms. Here’s a perfect example of using Slack: “Our goal for Slack is to connect our Sales, R&D and Production teams in order to ship our new products 20% faster”.
Since there’s a business metric involved, when you start asking people to participate in the change, you can go back to the metric to see if you’re moving the needle.
The other side of “people” is having internal buy-in to help drive the change; change can’t be imposed from the outside. In particular, executive sponsorship and middle managers are key.
We all know that we need an executive sponsor but at Slack, what they found was that the executive sponsor needed to be active and visible. Active members use the product, promote it, and sell it back to the business needs, all while explaining to people the cost of not changing.
Middle managers are also essential because they're going to be leading use cases in their department. They’ll also be showing by example, and they need to be available to help answer questions to the change.
Business uses
Business uses, or use cases is all about making Slack relevant for the employees.
One of the things they've learned is that business cases or use cases have a maturity level. If you start at a high level of maturity, you’ll be asking for too much change too early on, which impacts the user. It’s better to find lightweight use cases upfront, like publishing their newsletter on Slack.
Starting with simple use cases will have a minimum impact to get people to use it, and over time, the goal is to get them to engage in their day-to-day work. As time goes on, you can start introducing more sophisticated use cases. For example, if the use case is managing projects, you’ll want them to integrate all of their marketing tools into Slack. Ultimately, the ideal would be to have them embed Slack into their core business processes. For example, them initiating the order of a part or a process within Slack.
Slacked learned that if they start off with too sophisticated uses, it hurts adoption.
Setup
If you’re in Customer Success, you’re familiar with this part; This is where we spend our time setting up and configuring our product for our customers. In this process, "setup" ensures that as a product, you're following compliance and that users know where to go for help.
To help remove barriers for working, users can access Slack from wherever they need to on whatever device while still making sure it’s a compliant service.
The second part is making sure people know where to go for help and have a positive response when they get help. From their experience, this is the part that companies really miss out on unless they drive it home. Research shows that if you're in the change phase and have a poor experience when you reach out to support, you are less likely to follow through with the rest of the change.
Change
A change section in a change management process?
Yes, Rav admits it's kinda meta, but change actually underpins steps 1-3. The focus here is as we're doing all these things to raise awareness, drive a desire to use, and impart knowledge, we need to reinforce that change. Sustaining the change is crucial because if we don’t, we risk adoption decreasing after launch.
He breaks it down into three focus areas:
Communicating with execs and middle managers during pre and post-launch drives the engagement needed to get buy-in.
Training the team on the terminology and features and showing them how it translates into their day-to-day work.
Ongoing awareness to sustain the change post-launch.
What does this look like in real life?
At Slack, this method looks like this:
They take each step and run it in parallel. They spend several weeks with the customer setting it up (especially the change pieces which underpin everything.) Then they try this out with an early adopter group, and at that point, they pause for feedback. They want to know if communication is going well, whether they are talking to the right people, and any technical barriers involved. With the input, they make adjustments, and then they go on to the next group.
The impact of the adoption and change method is significant. After putting a customer who had a relatively average amount of usage, they saw a massive spike in their usage through these steps.
Ideally, this is what we're all looking for because it leads to revenue. Faster adoption is hopefully more incremental revenue and preferably a much bigger renewal.
Conclusion
Adoption is much more than just deploying the technology –– it's about introducing the change, and helping people with the change.
Research shows that customers who deploy software as part of an overarching change program are 6x more likely to achieve their business goals. Customer Success professionals need to educate these customers and start the change management process in the presales stage. Starting early makes for a happier customer and better outcomes when renewals come around.
Summary
Change isn’t about the tool –– it’s about the users who will be behind the tool
Use cases have maturity levels, and if we introduce a use case that’s too sophisticated early on, this could impact adoption.
The bottom line: “Faster adoption is hopefully more incremental revenue and preferably a much bigger renewal”.
Shout outs
Very special shout out to Rav Dhaliwal, who shared this video with me after I was looking for resources on change management –– I’ve featured Rav a few times here on keep the customer (How CS influences a company’s valuation and What CS can do to improve alignment with Sales).
Also, shout out to Totango for hosting the event!