Product teams don’t invest in new product tools without a good reason—we’ve got way too much on our plates to add something else unless we think it will have a meaningful impact. Far more likely is that the product team identified a burning pain point, performed diligent research on the available options, carefully constructed a business case for management, and finally got the green light for a limited trial or a few seats to kick the tires.
But even after finally convincing the powers that be that a particular tool is worth the time and money to add it to the company’s arsenal, your work is hardly over. Now you must get people actually to start using it.
While this conundrum isn’t uncommon, it often takes people by surprise. We just bought this thing to make your life easier… why aren’t you dropping everything and using it ASAP? Let’s take a moment to consider the possibilities.
Why are your colleagues not using the new tool
A multitude of reasons and excuses for not adopting a new tool exists. Many of these same excuses probably hold for the products you’re managing for your company. But while strategic goals and KPIs motivate everyone to use everything in their bag of tricks to convert your product trials into adoptions and adoptions into heavy usage, there’s seldom the same focus on new internal processes and tools.
Everybody’s busy already, and they’re unwilling or uninterested in putting off existing tasks to get into it. The known benefits of using your new tool aren’t perceived as compelling enough to build that time into a busy schedule.
Perceived lack of ROI
Unless the benefits of using the new tool are overwhelmingly obvious and immediate, they may not think it’s worth their time and effort. Product team members must always be judicious with how they allocate their time—a new tool with a murky value proposition will have a tough time capturing their attention.
Even the most intuitive tools require some training, and some of your colleagues may find the prospect of mastering a new program intimidating. Nobody wants to be the guinea pig, and counting on team members to figure it out themselves or proactively use self-service training resources might be an unrealistic expectation.
It’s not that your colleagues are afraid of your new tool, but they are scared they’ll waste their time being an early adopter of something that doesn’t take root. Busy people don’t want to spend their precious hours migrating workflows, setting up schemas, and plugging away in a tool that ends up abandoned down the line. They’d rather wait and see how things pan out while letting someone else take those arrows.
Lack of critical mass
Many tools don’t show their value until enough people use them or a robust amount of data gets imported and configured. This is particularly the case with collaboration tools.
How compelling is Slack when you’re the only one using it? Why would I put files on SharePoint if everyone asks me to email those docs to them anyway? No one wants to be the first one to a party.
Overcoming internal resistance
Now that you’re familiar with the common objections, it’s time to shift the dynamic and get your team on board. That means using many of the same tried-and-true methods you already employ for your products.
Of course, since you’re talking about coworkers rather than customers, some more heavy-handed options are also available. We’ll lead off with some of those before exploring some less coercive approaches.
Brute-force hard cutover
If your new tool is replacing a different software product or process, the easiest—but not necessarily best—way to get everyone using it is to require them to do so. That means migrating data from the “old tool” to the “new tool” and shutting the old one down completely.
Your colleagues will now have no choice but to use the new one, but they may not be happy campers if this is an abrupt shift with little preparation, training, and explanation. However, if you’ve pursued other avenues and tactics but still have a few holdouts, it’s a highly effective way to cut the cord and get everyone in the same environment. But try to soften the blow by providing a little lead time and giving them some helpful hints on how to prepare for and seamlessly execute any transition.
Making it part of their performance goals
Tying tool adoption to compensation might feel like a dirty trick, but no one wants to get a smaller bonus or miss out on a raise because they didn’t meet an easily achievable objective. Creating a measurable target for each team member—not just that they tried the tool once but one that assesses their consistent usage—is not only an initial wakeup call to “get with the program” but also an ongoing reminder that they must stick with it.
Obviously, it should only be a small fraction of their overall performance goals. Still, the fear of even a minor ding in their employee rating or bonus calculation formula establishes an ongoing incentive for compliance and adoption. Since senior management had to sign off on adding this tool to the product stack, you can mention that as additional motivation for why it remains a priority.
Pleading and bribery
While it might ding your dignity, an impassioned plea to colleagues encouraging them to give your new tool a try could potentially create a few converts. But an actual incentive is the best way to spark behavior change.
Making this reward outside the normal compensation structure—think company swag, gift cards, a catered meal, etc.—creates a unique motivator for individuals still on the fence. And once some peers start showing off their new hoodie with a company logo or brag about the stuff they bought with their gift card on the team Slack channel, it can create just enough jealousy to get some holdouts to give it a go.
Extensive education around benefits and ease of use
If you’ve convinced senior management to purchase the new tool, you’re already familiar with why it’s so great. But those attributes may not be as readily apparent to your coworkers. So start acting like a product manager and demonstrate how this product will delight your colleagues and address current pain points!
Webinars, lunch-and-learns, pre-recorded video tutorials, live training sessions, FAQs… you know the drill. Be sure to create these training assets using your company’s instance, so colleagues see familiar names and terminology used throughout the new tool. This makes things more relatable and less generic.
Also, ensure this educational initiative encompasses more than just the “how-to” part of the equation. Illustrate how this tool can help mitigate headcount issues and make their lives easier.
Lead by example
We all know how important it is to “eat your own dog food” as a product manager, and the same goes for these tools. The more you use the tool, the more opportunities you’ll have to refer to it as part of the regular workday rather than as its own separate thing.
For example, if you’ve happened to adopt a brand new cloud-based visual roadmapping tool, send everyone links to the roadmap rather than sending it around as an attachment or handing out printouts. The same holds for issue trackers, project planning, and collaboration tools. Use system notifications, alerts, and links to keep nudging people to interact with the tool as part of their standard workflows.
This forces them to interact with the tool even if they’re not exactly “using” it yet, plus it demonstrates that you are truly committed to it. As a bonus, as more colleagues begin using it, getting those notifications and links from more and more people creates additional peer pressure to get holdouts on board.
Stay open to feedback
Even after you’ve employed your full bag of tricks to convince colleagues to use the latest addition to your product stack, don’t assume your work is fully done. You can continue boosting its value and visibility with a steady stream of tips, tricks, and shortcuts, as well as “case studies” about how it’s improving things in-house.
As a wider pool of coworkers begins using the tool earnestly, they will have feedback. Be open to their criticisms, complaints, and suggestions, as there may be some growing pains or needs for minor tweaks to how things should be labeled, configured, etc. Keeping the tool useful and adding value may demand more care and feeding, particularly as teams grow and evolve, processes change, and additional products get added to the portfolio.