I read about this particular challenge from a response in my opt-in survey ( if you haven’t yet, I’d love it if you took the survey) and it resonated with me as I realized it’s a scenario I’ve had to face many times and had never really thought deeply about. Getting a client or your boss to buy into an idea you have — whether it’s bringing in new tech, initiating change, or whatever other scary thing you might have in mind — is something managers and entrepreneurs have to deal with frequently.
This article does not include a long list of things you should do to get buy-in. On the contrary, there are only two steps I think are crucial in making things happen — demonstrating value and getting feedback.
Granted, these two things are not as simple as they sound. The value of an idea that hasn’t been carried out basically has two parameters — the opportunity (positive value) and the risk (negative value) — and you’ll have to effectively assess, communicate, and work with both.
This concept is nothing new, really. The philosophies of lean and agile are built on pillars of demonstrating and delivering value early and incrementally. There’s a reason why this is so.
Implementing change is scary. When it’s your own idea, it’s probably even scarier. But somehow, you know something that makes you believe the opportunity far outweighs the risk. Your boss or your customer, on the other hand, probably doesn’t know what you know. To make matters worse, they’re probably already thinking of a hundred different failure scenarios. It might be a manifestation of a bad experience they had in the past, something they heard or read about, or simply fear of the unknown. Regardless of where it’s coming from, it’s absolutely fair for them to have their doubts.
You might think data is key to addressing this tension. Maybe it is. But let’s be honest, a lot of the data we pull up isn’t very relatable. Likewise, if your idea is something very new ( frankly, it probably isn’t), you’ll have a tough time finding real world data to back it. Here’s where what I call a minimum demonstrable prototype (MDP) comes in.
Minimum demonstrable prototype?
Creating a functioning prototype that your audience can see and feel definitely helps in generating the relevant and reliable data you need for your case. The best part is, it’s all coming from firsthand experience and it’s hard to argue with that.
This isn’t the same as a “minimum viable product”. The prototype might not be viable at all in any practical sense. But it should at least be enough to show what you’re getting at. For all it’s worth, this prototype could be a Powerpoint or a spreadsheet or a sketch on a whiteboard. It simply needs to visually and tangibly show how your idea works.
We humans are terrible at knowing what we really want. We’re even worse at describing it. Once we’re able to actually see and feel it firsthand though, it suddenly becomes really easy to recognize whether we’re on the right path or way off track. This leads us to the next and probably more important step of getting buy-in…
I tell this story in my e-book Risk Management Crash Course (click the link to get it for FREE!) and it’s the best story I have on getting buy-in. This is in relation to a system development project we did for a small local business. Even after closing the deal, I knew we didn’t really have buy-in yet at that point. There was definitely still a risk that the project would eventually be halted or that the software would end up unusable.
To address this situation, I managed to find out the biggest risks to the project from our client’s perspective. They had worked with software providers before, but none were able to deliver a usable system. They had a good idea what didn’t work and were able to easily communicate the two primary things that worried them — one being the huge amount of product data they needed to input and the other being the complex pricing calculations they used (so complex, they needed to do it manually.. huh.) Perfect. That gave us a starting point.
Moving in iterations, we started with these two things foremost. We held demos as soon as we had something working. You might think demonstrating buggy software would be a bad thing, but you’d be surprised. Seeing how the program’s calculations didn’t match up to their manual calculations opened up a lot of meaningful discussion on their pricing.
Same thing happened with the product data concern. The obvious solution would be to develop an import feature so they didn’t have to input everything one by one. More than that, we needed to also format the data so it was actually import-able. Working closely with the client and after loads of back and forth, we came up with great ideas from both sides and arrived at a relatively human-readable but likewise well-structured CSV format.
Other than delivering on their needs, the best part is that they got a chance to introspect on their current practices and came up with an improved way of doing things, beyond just dictating how the software should work. In the end, nothing gets people to buy in and feel at ease as much as having a say on its implementation. Needless to say, demonstrating frequently is critical to giving them that opportunity.
The cost of buy-in
Demonstrating value always comes at a cost. If it’s a personal idea you want to push, you might have to put in some extra time to work on the demo without compromising on your day-to-day responsibilities. If you’re a business, you’ll need to spend for the effort to build a prototype before you can even start pitching your product.
Getting feedback is no less painful. You’ll get a lot of criticism. You’re going to be questioned a lot. You might even get shut down completely. Despite all that, just remember that every criticism and question you hear out and deal with gets you a step closer to buy-in.
If you truly believe your idea is worth it, neither of these should be a problem. On the other hand, buy-in is a two-way street and despite your best efforts, you might just not get it. Just trying is already a win for you.