This post is a part of Made @ HubSpot, an internal thought leadership series through which we extract lessons from experiments conducted by our very own HubSpotters.
As someone who manages HubSpot's learning technology, I've gone about buying software the wrong way at times. I've pushed ahead without the right technical partners, I've missed a contract auto-renewal deadline, and I've rolled out changes to my team without empathy for how it might affect their day-to-day.
From these experiences, and from working with others at HubSpot who procure and implement software, I've learned a lot. Today, I feel good about how I manage our technology and buying decisions.
I've come to realize a successful purchasing decision is less about vendor management and research (though those are important factors) and more about project management, change management, and getting buy-in for new ideas.
Here are some of my biggest lessons for those who are considering buying new software or are just curious to learn more.
Lesson #1: Establish a business reason before seeking buy-in.
In the past, I didn’t take the time to step back and assess what value my proposal would bring to the entire organization. Even if your new software’s user base will only be a small portion of employees, think about and communicate how it ties back to the company’s bottom line.
Here are some examples:
- A process is currently very manual, and you want to automate it. The business reason for this software would be to save time and money.
- Your team is trying to accomplish something, and you don't have the skills, time, or functionality. The business reason for this software would be to extend the team’s capabilities.
- Recently, our L&D team at HubSpot wanted to be able to track how new hires performed in their training courses. The business reason for this software was so that we could provide managers with more insight into how best to spend their time coaching their new hires as they ramped into their roles.
Once you establish your business reason, you’re more likely to garner support from stakeholders.
Another important business factor to consider when getting buy-in is the cost-to-value ratio. Adding more software means another vendor to manage, another contract to consider, and another system for your coworkers and teammates to adopt.
Make sure you've thought this through and feel confident that this new software will bring enough value to outweigh these considerations. This will help you handle any initial objections.
Getting buy-in should happen far in advance of when you plan to buy the software. This process takes time. You need to talk to people outside of your department and often outside your company to ensure you understand the landscape of what's already happening, what's possible, and what it's going to take to execute a new software.
Lesson #2: Understand you’re going to need help.
You might be the most experienced software buyer in the world, but you can't do everything alone. In my experience, the best help you can get for buying and implementing software is the team whose very expertise is software: your IT team.
Loop them in early in your process, see what they're already doing to solve the challenge you've identified, and ask at least one champion for feedback. Depending on your company, you may also need to loop in Security, Legal, and Finance so they can add their expertise and highlight any blind spots you might have.
You'll also need two key people: someone to serve as a project manager, and someone who has expertise in the type of software you’re considering buying (which could be you with enough research).
It’s important to remember that you can't make lone decisions about software and expect everyone to love and use it. You might think you know what's best for the team, but you truly need feedback, and you need to get it before you dive in too deep.
You don't have to take everyone's opinion on as a requirement, but you should take into account anything mentioned by multiple people and capture this feedback. The more you document and share how you're making your decisions along the way, the less pushback you'll face when you're ready to start finalizing the deal.
It might take some extra time up-front to write everything up and share it, but this process will save you a lot of time in the end.
Lesson #3 Be vulnerable and empathetic.
Change is hard for everyone. Even those who are most excited about using new software can get overwhelmed by the prospect of changing up what they're used to. It's important to be transparent and empathetic with your project team, coworkers, and the broader organization.
For example, if your team members generally love process and organization, acknowledge that a project is going to be hard because there will be a lot of things that will start out disorganized or unknown. A tried and true method for working through this as a team is to share your emotions openly and then collectively decide to press forward.
Encouraging your teammates to share their concerns can help further define your project's direction and build a feeling of camaraderie that will be helpful when things get tough.
Regardless of what team you’re on, who your user base will be, or how many vendor demos you’ve watched before, these tips should get you started on the right track. Buying software isn’t easy but if done well, it can bring a lot of value, connect you with your colleagues, and help you discover the art of change management.
