Breaking adoption inertia: How to get teams to stick with new software

SaaS is fast paced and everchanging, much like your organization’s tech stack. Many of us have been part of teams that introduce a new software and utter the dreadful, open-ended phrase: “Just play around with it.” If you’re like me, that means not doing anything with the software until it becomes absolutely necessary to do so. At which point, I feel immediately behind and uncomfortable.

This procrastination isn’t a reflection of personal motivation, but rather, the ambiguity of the goal. Because when we don’t know how to start or where to start, we tend to avoid the task altogether.

To overcome this doubt-induced inertia, companies need to codify their strategies for effectively adopting new software, lest you end up with pricey shelf-ware or controlled chaos in a system that creates more issues than it solves.

In this article, I share five tactics you can use to encourage the positive adoption of a new software, whether that be ChurnZero or any product.

1. Establish your audience
2. Define clear expectations
3. Execute your rollout strategy
4. Collect feedback and adapt
5. Document everything

I’d be lying if I said I came up with these strategies on my own. I’ve had the pleasure of working with some incredible teams during my time in Customer Success. So, I’d like to give a quick shoutout to Lauren Dill, Director of Success & Services at Ellevation Education, and Kelly Jo Drey, Partner Success Operations Manager at FreeWill. While there are countless others who have inspired and shaped the advice I share in this article, these two Customer Success leaders stand out.

1. Establish your audience

Identifying your stakeholders should be quick and clear in theory but it can easily get out of hand when individual use cases for the software aren’t well-defined.

Typically, department tech stacks and the ranking of the tools within them don’t have a ton of overlap with one another. For instance, Sales doesn’t use a support system and call recording isn’t a priority for Development. For this reason, being overly generous with who you choose to include in your software rollout can cause more harm than good. You may think you’re doing a kind deed by involving those on the periphery or with edge cases but you’re likely causing them undue pressure. Instead, you want to specify who needs access to what parts of the system. Limiting permissions not only helps keep your data clean, but it also protects employees from stressing over additional tools that aren’t of sufficient relevance and value to them.

You also want to consider the timing of when you involve stakeholders. Playing show-and-tell with your new software too early can lead to extraneous feedback, unclear expectations, and a headache for you.

Moreover, rolling out the software to all stakeholders at the same time may cause more chaos than expected. Instead, consider using a phased approach that allows you to consolidate feedback and drive meaningful change early on. By selecting a smaller group of champions to help you with the rollout, not only will you generate subject matter experts, but you’ll also be able to identify candidates who could transition into leadership, ops, or other roles your team may need.

After your champions have piloted your software and provided their recommendations and endorsement, you can roll it out to the broader group. But first, you’ll need to set some guidelines.

2. Define clear expectations

If you have a laissez-faire attitude about your team’s software adoption, you’re doing your team a grave disservice. Instruct your team to “just play around” with a new software and I guarantee their minds will descend into madness. Giving your team a jumpstart on using new software without having any guard rails or constraints in place will only put them behind.

Instead, you want to go slow to go fast. Do the upfront work of organizing your rollout approach. Invest the time needed to make your plan purposeful.

Before you ever let someone get their hands on a new software, you need to:

• Announce the project
• Provide configuration updates
• Announce soft-start date
• Announce a hard-start date

If you’re introducing a brand-new software, clarify why you’re bringing it onboard and how it will benefit the user. Then, repeat this message many times. You can also identify and celebrate your stakeholders for the work they’ll contribute before they even start. Everyone loves a shoutout.

The success of your software’s rollout and its subsequent adoption by both your champions and your broader team hinges on your ability to set clear expectations. For your champions, you want to address each feature you expect them to use and reinforce how it relates to your overall process or goal. If that means assigning modules to specific users, then so be it. But at the same time, make sure you give your champions enough flexibility when testing your software to identify any pitfalls early on that could spare someone else from uncovering them down the line.

Lastly, assign a point person responsible for answering questions. Whether it’s a team effort or you have a primary admin, make sure everyone knows who to go to for related matters. With that in mind, let’s talk about that rollout.

3. Execute your software rollout strategy

Now that your team knows what you expect from them, it’s time you teach them what to do. Regardless of the tool’s complexity, try not to exceed 90-minute training blocks, though 60-minute blocks are even better. Take the perspective of the student and think about how long you can maintain focus during a training session. Be understanding and empathetic with your team in that aspect.

Encourage questions throughout training, or at least establish how and when questions should be asked – whether it’s speaking up in a smaller team or adding to a text chat for larger teams.

But no matter your team size, make sure you break up your learning objectives into small training modules or even separate sessions. You won’t enjoy planning or delivering your training when you’ve tried to cram everything into a single, comprehensive session. Plus, if your team has difficulty grasping specific areas of training, you’ll wish you had built in more flexibility and breaks to expound on or clarify concepts and answer questions.

And for rollouts where new software is replacing a legacy system, keep the use cases relatable; if you move into a new house, you don’t have to relearn how to use the kitchen.

If you’d like to incentivize your team training, and can fight for the budget, offer a small prize for the team member who meets an expectation first or practices a process the most. A gift card for food delivery or coffee goes a long way.

Now it’s time to establish a place for your team to have a voice in the process.

4. Collect feedback and adapt

Your team’s feedback is invaluable. My teammate recently said, “I can’t know if there’s a problem unless you tell me.” and I stand by that. Without your team’s involvement in improving your new tool, you’re more likely to see low adoption.

While you always want to encourage your team to speak up, there are also a few alternatives ways to source feedback from your team members who are less vocal. You can create a Slack or Teams channel dedicated to your tool to showcase new discoveries and improvements and answer user questions. If you have a project management tool, why not create a new workspace to allow your team to submit requests? This helps curb that irritating “black-hole syndrome” – when you submit feedback and never hear back – and brings visibility to user’s requests by giving their feedback an assignee, a priority, a due date, etc. Or maybe you love spreadsheets? A shared Excel or Google sheet is an easy way to submit feedback for everyone to see, though this method is slightly less trackable, and therefore actionable.

You also want to encourage your team to be transparent in their assessment. Giving up on a software when you’re only a year into its adoption doesn’t feel great. But forcing your team to use a software that doesn’t work for them only makes the situation worse. With that honesty, be the change your team wants to see.

And make sure you reflect on your work. I don’t know the last time someone in SaaS described their tool as being “set it and forget it.” That’s because SaaS and Customer Success are constantly changing. You’re not a Ronco Rotisserie™ oven, don’t act like one. Your tools need to scale with your team, so if you’re not already using a “Start Stop Continue” retrospective framework, then start now. I recommend conducting this exercise quarterly as to not overwhelm your team. Setting a recurring cadence ensures the continuation of your feedback loop which allows your team to multiply on their success. If you don’t set aside time to talk through the successes and the failures of your software’s rollout and adoption, then you’re hindering your team’s growth.

5. Document everything

Finally, write it all down. Document your processes as you build them – trust me, you’ll thank yourself for it later. Because in your line of work as a Customer Success professional, your context is always changing. Customers come and go. New product features launch. Your customer base diversifies and expands. The industry evolves. Your organization matures. And on and on it goes.

If your company is growing, new situations will arise that cause you to reexamine your processes. It will feel like you’re in a constant loop of either amending an existing process or creating a new one. So, document as you go. Don’t hold off on writing things down until you get to the end planning phase of your rollout or an arbitrary future state of “final.” Because as they say, the only constant in life is change. Plan accordingly.

On a more tactical level, make it a priority to maintain your learning resources such as knowledge bases, how-tos, FAQ’s, and hot tips. Keeping an up-to-date resource repository will save you a ton of headaches down the line and help guide your team as your business scales. Regardless of the workspace you use – whether it’s Confluence, Zendesk, Skilljar, SharePoint, or a Wiki – you need to have your processes and purposes documented (even with video if you get a chance) and easily accessible to your current and future team. And for foolproof accountability, make sure to assign an individual or team to be responsible for updating documentation – or else I promise you, it will not stay up to date.

Make adoption stick with a change management mindset

Now, you can’t talk about software adoption without mentioning change management. It’s not uncommon for software adoption efforts to be met with anxiety and opposition. A desire for control, a fear of uncertainty, and feelings of incompetence are just a few of the reasons we struggle with change.

Customer Success leaders feel the effects of change twofold when driving adoption with their customers and within their own internal organization.

Get a closer look at how Customer Success leaders can navigate this delicate territory and overcome change resistance in our blog: “How to guide your team and customers through the customer change management process.”