When it comes to adoption, there is a universal law any family will tell you: If everyone’s not on board, it’s not going to go smoothly…if at all.
The same is true for software product adoption. If a team is splintered across disparate tools, don’t expect their product to be unified.
This is where so many companies struggle: Every member of the team has their own tool, versus the team as a whole adopting a single tool.
We have run into both the struggle of getting the whole team to adopt a tool, and having our tool be fully adopted by other teams.
Both can be frustrating. But, we’ve picked up some best practices along the way to help.
Getting your team to adopt a new tool
We’ve all been there. It’s a happy day. You’ve just come from a session on Capterra or ProductHunt. Now you have the perfect productivity tool. The one that’s going to cure your every ailment.
You introduce it to your team with a company-wide post. Everyone chats back with 👍 emojis. A week later, only your three or four example entries are there. The engineers haven’t gotten around to integrating the JavaScript snippet.
A month later, and even you’ve forgotten. Later that quarter, (after a quick chat with the company bookkeeper), it’s all over. But this other new tool…
So what went wrong?
Well, adopting a new tool is a bit like adopting a new puppy. You can’t just show up with one and expect the entire household to be thrilled. There are other stakeholders involved.
Building consensus around what tool to use
People are more likely to use a tool if they agree that they want to use that tool. It’s the difference between, “Honey, let’s talk about getting a puppy,” versus, “Look, honey! I got us a puppy!”
This doesn’t necessarily mean you need to schedule a meeting. But it does mean you need input and buy-in from your team. Otherwise, it’s a bit like informing the office that you’re changing your hair color. It’s all well and good, but it doesn’t really affect me.
To get buy-in from your team, focus on answering these points:
- What’s the problem?
- What happens if we don’t address it?
- Why don’t our current tools work?
- What tools did we look at?
- Why are you recommending this tool in particular?
Let’s break that down:
1. What’s the problem?
It happens in software. There’s a temptation to take a brilliant solution and go looking for a problem.
But, there may not really be a problem to solve. And if it is a problem, does the solution make things easier or more complex?
A good example of this is data tracking. Sometimes people want as many data points as possible.
But, they’re not being used for anything. Nothing’s being done with the data. Collecting them adds cumulative man-hours to the team processes. But just in case, we pay for an awesome tool that helps us collect them.
2. What happens if we don’t address it?
The old “less is more” adage. Play it out and think it through. What happens if we don’t “fix” this perceived problem? Will it actually hurt us? Or is it just a minor annoyance?
Scale is an important point here. A minute of work from a three-person team is an inconvenience. A minute of work multiplied across a hundred people is downright expensive.
3. Why don’t our current tools work?
This is a classic blind spot. Why have a Dropbox account when we already use G Suite and thus have Google Drive? Why sign up for Monday if we’re already using ClickUp? Why not just take two minutes a day to update a spreadsheet versus signing up for Grow?
Don’t let a good discount or the appeal of a shiny new toy fool you. Don’t go to a completely new tool just because it’s new.
However, let’s say you’ve evaluated your current toolkit and it genuinely doesn’t fit the bill. If that’s the case, keep reading.
4. What tools did we look at?
The “rule of three” is a good one here. Present at least three options and take the time to do some math.
For example, let’s say your problem is that you need to be able to make phone calls.
This could mean you sign up for AirCall, since they have the nicest website and the most features.
But notice that “make phone calls” is a pretty limited scope.
You may not need all the bells and whistles. Decide on what “boxes to check.” Does it have a decent UI? What does setup look like? How about price?
Decide what’s important to you and filter for that criteria. You may find that a more minimal option like Toky is actually going to give you what you need for a much lower price.
5. Why are you recommending this tool in particular?
Make your case! Which one do you think wins and why? Your team should see that you’ve given this serious thought.
That being said, encourage dissent (that’s a whole other blog post) and be willing to lose. You’re presenting options and building consensus, not handing down edicts.
Implementing the new tool with your team
Congratulations! You’ve got the team on board.
But now the rubber needs to meet the road. First thing to do is add this tool to your internal knowledge base. New employees should be able to find a guide that will walk them through using this tool with minimal effort.
It helps to set a date on this beforehand.
So, the conversation isn’t, “Hey everyone, let’s start using ____ for our ____.”
The tone is much more, “Hey, as we discussed, we’re going to transition to using ____ for our ____ as of 2024. Here’s a link to our knowledge base for using that tool. Reach out to me or [person] if you have any questions.”
There should be some formality to this. Send reminders beforehand, then the day of implementation. Then follow up with anyone who’s not using it. A simple one-on-one chat should do.
“Hey, [name]! Just a friendly reminder that we’re using ____ now for all our ____. Let me know if you’re having any trouble with getting set up or have any questions using it! 🙂”
Be sure to shut down any alternatives as quickly as possible. The best way to ensure the wrong method isn’t used is to make it unusable!
Product adoption is a process
Bottom line: Getting your team to adopt a new tool is never as easy as “plug-and-play.” It takes effort, like anything else.
But if you’ve taken the steps above, you’ll no doubt see the payoff in the form of a smooth and (hopefully) permanent transition.
Here at Canny, we understand the challenges around product adoption. As with any tool, Canny users sometimes struggle to get their teams on board.
But, by going through this process outlined above, getting buy-in and company-wide product adoption is much easier. It’s ultimately up to users to drive product adoption with their teams and customers.
That said, we’re here to help—we hope this guide has been useful, and don’t hesitate to reach out with questions. You can also start by trying Canny’s product feedback software for free, and learn more about why collecting customer feedback matters.
