Getting Internal Buy-in: How To Choose a New Product Management Software
There’s an unwritten rule that when a team doubles in size, all of your systems and processes will break. I’ve lived through this several times first-hand and have dealt with the aftermath of trying to rebuild processes and select new tools and software to use with rapidly changing variables.
In today’s ecosystem, I would argue there are more variables changing than ever before. So how can you approach making decisions about the tools your product management team will use? And how will you get buy-in from your product team and other internal stakeholders in the organization?
Starting off on the right foot
Before jumping into any decisions about tools and thinking about how to get people on board with using them, making sure you understand your foundational building blocks is crucial - what is the current context you’re dealing with? What are your constraints? What could both of these look like in the future?
This includes:
Making sure the problem you are solving is clearly defined
Understanding the company purpose, company goals, and “what success looks like”
Having a product vision, product strategy, product principles, and product roadmap
Understanding the current team makeup and key stakeholders that need to plug into product work and that product work needs to plug into
Knowing what the team and company constraints look like (i.e. technical capabilities, team bandwidth, team/company resources)
Knowing what internal processes currently look like (i.e. product development process, decision-making processes, leadership calibration processes)
Knowing how these variables could change over time (i.e. Could the team grow substantially? Could your product offering expand?)
(You can check out the Essential Context list here as well).
These things are important to understand because they help you frame the landscape you’re dealing with really well so you can know if bringing in new software at this point will be a good fit for you and actually help rather than hinder your team.
Criteria for choosing new software
When deciding whether or not a new software is right for your team, consider this - any new tool (and/or process that comes along with it) that you introduce should:
Be simple: If a new tool or process makes things significantly more complicated, it should not be implemented.
Provide transparency: Everyone in the company should be able to understand how it’s being used and where you are in the process at any given time.
Be easily communicated: If any changes need to happen, people should easily understand the thing that needs to change and why and easily adopt it.
Be adaptable: Things can change rapidly. A new tool should help you build flexible processes that can be scaled later.
Be timely: It should facilitate getting things done efficiently vs. slowing things down.
Foster collaboration: Each team should know when and how their input is needed and how it contributes to your larger objectives.
What is product management software buy-in?
Say you’re currently experiencing issues with your current product management software platform that includes roadmapping tools that are supposed to empower your team from product vision to delivery and you’re investigating new platforms to switch to. Once you think you have found some suitable alternatives, getting buy-in (the process of influencing those around you to convince them that an idea should be invested in) will be your next challenge. Without it, you're at a loss. Even if you implement the proposed change, if you don’t have buy-in and it isn’t widely adopted all of your efforts will have been for nothing.
When bringing new product management software into the fold at startups I’ve worked at, some of the common buy-in barriers have been things like issues with user access (i.e. not enough “seats” were purchased for all key stakeholders to access it, resulting in poor retention and adoption company-wide), processes were not clearly defined up-front (people were unsure how this would impact their daily workflows), not considering how it would fit in with other tools we were using (resulting in a “paralysis by analysis” situation where people were resentful of learning how to use “yet another” new piece of software), and not bringing stakeholders in early enough for feedback in advance of choosing a new tool to go with.
5 steps to guide you through the buy-in process
1. Identify key stakeholders
Who are the people who will be impacted by bringing new product management software into your workflow? While this will differ in each organization, some common ones are senior leadership, finance, customer care, engineering, design, marketing, and sales. Some important questions are “Who uses the current version?”, “Who doesn’t use the current version but should be able to?” and “Who needs edit access vs. just visibility?”
2. Explain why the change is important
How will it improve life for your team? How will it improve life for stakeholders? How will it improve outcomes for the business? How will it improve outcomes for your customers? One way of handling this is to list the current issues you’re having and their impacts on the business and customers and explain how removing these friction points would make things better.
3. Proactively bring stakeholders into the fold
Listen to their thoughts and concerns in advance. Gather and consolidate their feedback in an open and transparent way. Go out of your way to ask for it to make sure their input is incorporated into the decision and that they feel heard. Address concerns and work together to come up with solutions collaboratively. If you’re considering three new types of software, bring key stakeholders in and gather their input while you’re fleshing out the details to make sure you’re covering all of your bases vs. just “informing them” after the fact (doing this can create dissociated teams and a toxic culture where trust is lacking).
4. Paint a picture
Show tangibly, what the change will mean for everyone involved and “light the way”. Sometimes doing this visually works best. Sometimes it’s through a good story. Choose a way to do this that works best to communicate with your unique team. One idea could be to create a simple deck to show things like how the features of the new product will eliminate the need for “X complex, time-consuming activities that Y team members currently have to do”, how it will improve roadmap visibility for the whole company, how it can be used to organize and prioritize customer and dogfooding feedback, etc.
5. Be adaptable
Be open and flexible to incorporating feedback and making some course adjustments along the way. For example, know that implementing the software won’t be perfect and there will be some bumps along the way. Tell people who the point-people are to go to if they have a problem and ask them to submit feedback to help make your collective processes while using the software better.
Thinking about bringing new tools into your team’s workflow can be daunting - even when they are desperately needed.
Product management software can help you create amazing products while aligning seamlessly with your team on your priorities and roadmaps. airfocus is built exactly to do that. As a modular platform, airfocus adapts and scales according to your team's needs, offers unique features like Portal, Priority Poker and AI Assist that help you become more efficient, and has multiple integrations with many other tools, so that you have one home for your products.
Getting buy-in for new software doesn’t have to be a scary process to go through if you remember that you are part of a larger team working towards the same objectives. The input of your team members is incredibly valuable before making a decision around which software to go with to make sure you’re not missing any major requirements and addressing concerns preemptively.
You got this.
Lisa Zane
Read also
Experience the new way of doing product management
Experience the new way of doing product management