Software is a tool to help you solve a problem, not a solution in and of itself. So when you do end up buying a new software tool, you’ve really only just begun your software journey.
Figuring out which tool to go with when you’re in the decision-making phase can feel like the most critical part of this journey. Of course, getting the right product is important, but if you can’t drive widespread user adoption among your employees, it doesn’t really matter how perfect a fit the software you purchased is.
Time and time again, you’ll hear stories of people regretting a software decision because it didn’t really do what it was they wanted it to do. Sometimes, that is actually the case, but more often than not, when people are dissatisfied with their software decision, it’s because they didn’t properly implement the tool and as a result had a low user adoption rate among their employees.
When a workforce doesn’t adopt a newly purchased software, this is what the software lifecycle looks like:
- Purchase new software
- Improperly implement new software
- See no results or changes in process
- Look at watch and count the seconds until the contract expires
If you don’t get rid of the new tool when the sales contract expires, you usually end up keeping the tool around, using it sparingly, and telling yourself that it gets the job done while avoiding at all costs any attempt to calculate your return on investment.
What is user adoption?
When we talk about user adoption for a software, we mean implementing the tool into your business processes, so that all the employees who have a reason to use it are using it.
User adoption is typically referred to as a rate or percentage. You can’t always get 100% user adoption, but if you only have 30% user adoption for a product, you’ve got a problem.
That rate only applies to employees who have a reason to use the tool. Someone in human resources probably has no reason to use your sales analytics tool, so the fact that they don’t use it shouldn’t count against your user adoption.
Why is user adoption so important?
To reiterate the point: most of the time a new software fails, it’s due to lack of user adoption, not the functionality of the tool.
Chances are, when you were selecting a product, you demoed several, understood the features you needed, and discussed with different salespeople how you can apply their tool to your business. The product you ended up going with is probably capable of accomplishing what you need accomplished.
So if the tool is not the problem, its implementation probably is. The reason user adoption is so crucial to the success of a tool is that more often than not it’s an all or nothing proposition.
If half your team is using the tool properly, but the other half isn’t using it or is using it improperly, you might have a disaster on your hands.
Several years ago, I worked in the content department for a company that created animated videos. I would work on scripts for the videos and each script would undergo multiple iterations, making it important for us to keep track of every version of the script, so we could make sure that the animators were working off the right one.
After some time we decided to invest in a digital asset management system (DAM) to keep all the scripts in one place. Because there were sometimes ten versions of the same script, it was crucial that we had a consistent taxonomy for all of the scripts so that we could easily locate the most recent one.
After purchasing the DAM, our head of content sent out an email outlining the new processes that came along with the software. The email was detailed and had all the information you would need to use the DAM correctly.
But there was one problem. The email required every person in the organization to read a long email from beginning to end. Guess what? That didn’t happen.
Soon the DAM was full of scripts with three different naming conventions. This caused quite a bit of confusion, especially because someone who worked on version three of a script, might not work on version four. So when the new person went to start on version four, they might identify version two as the most recent one because the inconsistent naming conventions.
Ultimately this caused several instances of repeat work and some angry clients not sure why we were sending them a draft of something they had already seen.
It only took a few months for us to scrap that tool and move on to a new one. And not because the tool wasn’t capable of accomplishing what we wanted it to accomplish, but rather because we didn’t have consistent user adoption—so all of the useful features were rendered useless.
How to avoid low user adoption
“Okay, good to know, low user adoption is bad, but what can I do about it?” You say. I have good news for you. You have come to the right place.
While there’s no magic bullet to ensure a seamless software implementation, there are certainly things you can do to increase the odds things go smoothly.
1. Know Your Organization
There is no such thing as a one-size-fits-all tool. Which product is the right one for you is going to differ depending on the needs and competencies of the employees that are going to be using the software.
For example, if your workforce is one that struggles with something like Gmail, you’re going to need a solution that is extremely easy to use and has an intuitive user interface. Conversely, if you have a tech savvy workforce, you’ll have some more freedom in your choice of software.
Of course, technological capabilities aren’t the only thing you need to know about your employees. A major factor in whether a workforce adopts a tool is discipline. No matter how tech savvy you are, learning a new software isn’t something that can be done in a snap.
Some groups can probably be trusted to learn and adopt a new tool without heavy oversight. However, if your organization has a history of half-hearted software implementations, a strict schedule and plan for implementation might be necessary.
2. Look at More than Features
People tend to focus on features during the research and purchasing stages of their software journey. It makes sense, too. After all, the features are what your team is going to be using.
Resist the intuition that features are the only thing you need to focus on.
Do some research on the quality of customer support that the product you’re interested in provides. It’s almost guaranteed you’re going to need it, and you want to be sure you’re in good hands when that time comes.
To illustrate why customer support is so crucial, let me tell you a quick story about a business intelligence tool I used at the last company I worked for.
We were a data company. We had a lot of it, and it’s what made us valuable to our customers. In fact, we had so much that we struggled to utilize all of it. Eventually we decided we needed a tool to help us get the most out of our data.
After doing the research, the tool we went with seemed to make perfect sense. It did everything we needed it to do, and it was going to enable us to use our data in ways we couldn’t previously.
Implementation wasn’t quick, but that was to be expected. After several months, our data engineer unveiled the tool to us researchers, and at first, it was promising.
However, the more we used it the more questions and requests we had. These would often need to be relayed through the data engineer to the software provider. We wanted the tool to do things that it seemingly could with the assistance of the provider.
This is where things went downhill. Our data engineer was constantly frustrated because the software provider was neither responsive nor helpful. The things we needed to get the most (or really anything) out of the tool were not getting done.
We on the research team gradually stopped using the tool, and the thing had more or less become a relic 8 months after purchase. It might not surprise you to hear that we didn’t renew our contract with the tool and soon invested in another one.
This wasn’t an instance of an apathetic workforce or a lack of understanding of business problems. This was simply not considering all of the factors that contribute to a successful implementation.
User adoption is a difficult thing to achieve, and if you hope to achieve it, you’re going to have to look at more than features when you are considering products.
3. Have a Training Plan in Place
More often than not, when you purchase a new piece of software, the majority of the people in your organization won’t have used the product before. So, in order to drive a high rate of user adoption, you’re going to need a training program that gives everybody on your team the opportunity to learn how to use the tool.
To make sure your product training is optimized, it’s a good idea to have one person lead the training. This will likely be the main admin for the product and one of the few people who has spent the most time speaking to the software provider during the purchase process. Since this person has been along for the whole ride, they’ll already have better product knowledge and, ideally, a good relationship with the provider.
Once training sessions have begun, accountability is key. Nobody wants to spend an hour learning how to use a product. They all have work that needs to get done, and the value of the new product might not be immediately clear.
It doesn’t matter. If you want high user adoption, you’re going to need everybody on board. Make this training a requirement, not a choice.
Implementation is a Never-Ending Cycle
You purchased your product, you’ve trained your workforce, and now you’ve got your whole team using the tool. Job well done… Well, kind of. Most of the work is done, but some parts of implementing a new tool never end.
Your business is constantly evolving, so your software usage needs to evolve with it. When internal processes change, so might your uses for a particular software tool. Continue to evaluate your team’s use of a tool and whether it’s still effective and necessary.
If you can manage to do all of the above successfully, you are going to have high user adoption rates in your software stack, and probably a nice return on your investment.