How to Get Buy in for Your Software Project

If you’re a product manager or product owner (or in the case of early-stage startups, the founder or CTO), one of the biggest hurdles to doing your job well is getting sign off for software projects. No matter what level of the company you’re in, if you’re responsible for product work, you have stakeholders you answer to. If you’re in a large or mid-size organization, it might be the C-suite or a high-level manager overseeing your division. If you’re an early-stage startup founder, it’s VCs or an internal stakeholder representing clients, like sales. So how do you get buy-in for a new software solution?

Here are six of our best strategies:

Develop an Elevator Pitch

The more time it takes you to explain why something will benefit someone, the less compelling the pitch. You should be able to distill your idea down into a few, clear, concise sentences that answer some version of “Project X will solve Y problem(s) by doing Z.”

What’s the most critical business pain point that can be addressed by not only new software but your software project. Why is your proposed solution the best way to solve that particular problem?

If you can craft a clear statement of intent that explains the challenge, the goal, and the solution, it makes it a lot easier to recruit supporters in both the board room and the break room.

Another note for your elevator pitch: If you can, tailor your elevator pitch to the specific decision maker(s). Get to know their pain points, what they value above all else, and then pitch to that preference. 

For example, some CEOs care less about money spent if there’s a huge addressable market or big upsell opportunity for a wide variety of current clients… so lean into how your solution opens up a huge avenue for increased revenue. 

For others, bottom-line cost cutting is the most important… so tailor your pitch to them by emphasizing how much money you’ll be saving by cutting out Y amount of lost productivity, or replacing Z headcount by automating some process, etc.

If your elevator pitch is concise, clear, and well tailored, you stand a muuuuuch better chance of getting buy in.

Align Software Objectives with Core Business Strategy

The more decision makers can see how your solution ties directly into their operations or their specific business initiatives, business applications, or business outcomes, the more successful the pitch will be.

If you can’t prove to the CIO why this project will help them accomplish their business goals and business initiatives, they’re unlikely to make the case to the other C-suite members. If you can’t prove to the director of sales why your solution will help them capture more clients or make larger sales, they’re not going to pitch it up the chain.

You have to align your project with core business strategies of relevant stakeholders to get them on board.

Recruit Supporters

If you know what problem your solution can solve, then you should be able to find stakeholders or rank-and-file colleagues whose lives would be easier/better or whose goals would be more achievable if you were able to proceed. Get them to say so during your presentation!

Get them to present during your pitch. Have them briefly explain the issue they’re facing or that they see customers facing and what happens if nothing is fixed. This helps prove you aren’t just coming to them with a solution in search of a problem, but rather are addressing a real issue as demonstrated by these staffers telling them so.

Also, encourage your colleagues to filter that same information up their respective chains of command so decision makers are hearing the same feedback consistently from different teams separately from just the presentation.

A word of caution, variety can be valuable when recruiting for these testimonials. Different staffers from different teams can make the pitch stronger. But, try to group the speakers by themes, things like, “loss of productivity” or “missing out on new business” because of this specific problem. That way the takeaway is clear and consistent, not just a list of gripes different teams have.

Present a Menu of Options

If possible, present a menu of ideas that the decision makers can choose from. Something like:

Behind door #1, it’ll cost this much, take this much time and solve Y problem Z way.

Behind door #2, it’ll cost more but take less time, and it solves Y problem X and Z way.

Behind door #3, … you get the idea

If there’s a menu of choices, the decision maker feels like they have more agency, and they’re not backed into a corner with a binary decision — yes or no. And if you control the menu of options, you’re only presenting multiple good-to-better options, and you’re more likely to get movement on at least one of them.

Highlight How Stakeholders Can and Should Contribute to Development and Ownership 

This one is more of a tightrope, because many stakeholders are busy, so the prospect of you putting more work on their plates could dissuade some. If you know that to be true about a particular stakeholder for your solution, then don’t emphasize this. But most of the stakeholders I deal with want to feel like they’re going to actively contribute to whatever is being built. 

How are you looping in their feedback and their guidance into what you’re planning to build? Play up how crucial they’re going to be to making your solution a success, and how much more the solution will benefit them with their input. 

This can give stakeholders a greater sense of ownership over the thing you’re building, which can be a huge plus. But again, be a little more careful on this one, because some leaders will only see more work for themselves and be turned off at that prospect. So do this only if you have a good read on your specific stakeholder(s).

Be Honest

The #1 way you can have a project shot down from the jump? Fudge the truth. Or don’t do the research.

Stakeholders know things cost money and take time (sometimes a lot of both). The best way to turn them off from a potential project is if they feel like you’re either lying to them, or don’t adequately understand the challenge you’re facing. 

If you come into the meeting with timelines and budget numbers that don’t pass the smell test, you’re dead in the water. Even if you do have the right idea for the right solution, it’ll be shot down because they either don’t trust you or they don’t have faith in you because you clearly don’t understand what it takes to do what you’re proposing.

Be optimistic but clear-eyed. Here’s a best case scenario, worst case scenario, and where you think it’ll land based on all the research you’ve done. If you’re honest, you’ll be taken seriously. If you’re unprepared or offering pie-in-the-sky, you won’t.

Closing Thoughts on Buy In

For any product person or decision maker, buy-in is one of the biggest hurdles you’ll face. This is also one of the places we can seriously help. Our Innovation Lab leverages a proven process that results in shorter development timelines, fewer costly reworks, and a tested roadmap to a product that truly innovates. We can help you conceptualize and cost plan software projects so you know exactly what you need to do to solve your problem… which will make these six steps above all the more potent when it comes time.



Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

15 + two =

Jeff Francis

Jeff Francis is a veteran entrepreneur and founder of Dallas-based digital product studio ENO8. Jeff founded ENO8 to empower companies of all sizes to design, develop and deliver innovative, impactful digital products. With more than 18 years working with early-stage startups, Jeff has a passion for creating and growing new businesses from the ground up, and has honed a unique ability to assist companies with aligning their technology product initiatives with real business outcomes.

Get In The Know

Sign up for power-packed emails to get critical insights into why software fails and how you can succeed!

EXPERTISE, ENTHUSIASM & ENO8: AT YOUR SERVICE

Whether you have your ducks in a row or just an idea, we’ll help you create software your customers will Love.

LET'S TALK

When Will Your Software Need to Be Rebuilt?

When the software starts hobbling and engineers are spending more time fixing bugs than making improvements, you may find yourself asking, “Is it time to rebuild our software?” Take this quiz to find out if and when to rebuild.

 

is it time to rebuild our software?