Introduction: The Challenge of Building Buy-In for Unproven Projects

Here’s what experience has hammered home for me: Skepticism isn’t just about missing metrics. It’s about competing priorities and your company’s deep-rooted aversion to risk. That’s not a footnote—it’s the lens through which every unproven project gets judged.

So how do you get buy-in when all you’ve got is a pain point, a gut feeling, and hope that others will see what you see? In this post, I’ll walk through practical steps—drawn from my own missteps and the few small wins that kept me moving—on turning vague frustrations into actual momentum. If you lead engineering or advocate for uncertain ideas, let’s talk about how story, rough data, and the right allies can tip the scales in your favor.

Start with the Pain You Can Measure

Let’s not sugarcoat it: Making an abstract problem feel real is tough. But in my experience, the breakthrough always starts with putting some kind of number—however rough—next to the pain your team or business is feeling.

Let me pause here—because this is where most people flinch: Yes, your estimates will be uncertain. That’s not a weakness; it’s honest. Project cost management best practices actually recommend adding a 15–20% contingency buffer for the unknowns (cost estimation best practices). Owning this doesn’t undermine your credibility—it shows stakeholders you’ve thought through the risk.

This approach became my wedge. It opened doors to conversations with people who never saw the daily grind but cared about inefficiency and wasted resources. The goal isn’t perfection; it’s momentum.

Take GE’s example: They used sensor data from industrial equipment to estimate maintenance needs even when their data streams weren’t complete. By making proactive predictions, they managed to cut downtime and costs (GE predictive maintenance case study). Perfect data isn’t the bar—enough data to move forward is.

If you’re interested in how engineers spot these inefficiencies before anyone asks, explore how proactive engineers solve unseen problems, which delves into the mindset needed to surface hidden pain points early.

Show, Don’t Just Tell: Prototypes and Early Wins

You can only talk about potential for so long before eyes glaze over. In my experience, building even the roughest proof of concept—or prototype—changes the game entirely.

Atlassian’s innovation team routinely builds ‘minimum lovable products’—basic prototypes users can interact with inside a week. It’s not about polish; it’s about making possibilities visible and inviting fast feedback.

We followed suit, spinning up basic dashboards—barebones and imperfect—that hinted at what better reporting could look like. Instead of talking about “faster insights” or “streamlined workflows,” we put something real in stakeholders’ hands. The reaction? Even skeptics started leaning in: “Can it do this?” “When can I try it?”

A prototype moves people from “Why should we?” to “How can we?” Suddenly, you’re not defending an idea—you’re collaborating on it.

Don’t skip this step—it’s where the mood shifts. A prototype moves people from “Why should we?” to “How can we?” Suddenly, you’re not defending an idea—you’re collaborating on it.

Research shows that interactive prototypes and visual demos increased decision-maker confidence in 78% of enterprise tech projects studied (role of data visualization in decision-making). In uncertain territory, a working demo is more persuasive than any PowerPoint.

Here’s the bit most people overlook—prototypes don’t just prove viability; they surface objections early and invite others into shaping solutions. That sense of shared ownership? Pure gold.

If you want to dig deeper into communicating ideas that actually land with your engineering audience, discover The Storytelling Playbook for Engineering Buy-In, which offers actionable frameworks for connecting technical work to broader impact.

Translate Tech into Executive Outcomes

Here’s the truth: Most execs aren’t interested in your new data pipeline or automated workflow—they care about results. Faster decisions, fewer surprises, reduced risk, happier customers.

I learned this the hard way. My first attempts at pitching our reporting platform were feature-heavy and packed with architecture diagrams. Unsurprisingly, leadership tuned out. It wasn’t until I reframed the story—talking about delivering insights in days instead of weeks, or eliminating errors from monthly reports—that things finally clicked.

Here’s a simple trick: Use The Ladder of Abstraction. Start with high-level outcomes (better decision speed), then connect each technical piece back to those goals. It keeps your pitch grounded in what matters most to decision-makers.

Translating business requirements into technical requirements is essential (translating business requirements). Tie your proposal to strategic goals—speed, agility, compliance, growth—and suddenly it’s not just a tech upgrade; it’s a business enabler.

Framing your story this way also brings cross-functional allies on board and keeps stakeholder priorities front and center. Here’s what gets missed: It isn’t about dumbing things down—it’s about speaking the language of impact.

Projects often fail when teams don’t align early on these executive outcomes. For a closer look at why even good ideas can stall without proper alignment, read Why Projects Fail (Even When You Build the Right Thing) for insights on common pitfalls and how to avoid them.

Pair Confidence with Curiosity

There’s one question I heard on repeat: “Will this actually work?” Early on, I felt like I had to project total certainty—have every answer ready and act as if failure was off the table.

But here’s what landed better every time: pairing honest confidence with curiosity. Rather than faking omniscience, I’d say, “We’re 80% confident this will cut reporting effort in half. And even if we don’t get all the way there, we’ll learn where our biggest bottlenecks are—and adjust.”

This is where adaptive leadership comes in—balancing conviction with openness to learning. When you show that you welcome feedback (not just agreement), you create psychological safety and invite real problem-solving.

Confidence matters—but humility is critical. People want to see that you believe in your solution, but also that you’re ready for surprises and willing to pivot if needed.

Set expectations upfront about what’s known, what’s uncertain, and how progress will be measured along the way. Bring stakeholders into the journey as partners—not just judges waiting at the finish line.

If fostering adaptability in yourself or your team is top of mind, explore Move Smarter, Not Just Faster: Resilient Teams Win to learn how high-performing groups balance velocity with learning and course correction.

Mobilize Allies and Early Advocates

Here’s something I wish I’d understood sooner: No matter how compelling your case—or how slick your demo—you can’t do it alone. Before we brought our new platform to leadership, I turned to an ally—a business user who’d already seen time savings from our prototype—and asked her to share her experience directly.

Her words about speeding up month-end reporting hit harder than any stat or slide I could have made myself. Early advocates don’t just validate your idea; they lend credibility and social proof that spreadsheets simply can’t provide.

In many organizations, peer influence trumps hierarchy. When respected colleagues share tangible benefits they’ve experienced firsthand, skepticism starts to fade fast.

One of the toughest hurdles is crossing “The Chasm” between Early Adopters and the Early Majority—a concept Geoffrey Moore explores in Crossing the Chasm (innovation adoption chasm). Early Majority folks need proof that goes beyond isolated wins; they want evidence that speaks directly to their day-to-day reality.

To mobilize allies effectively, involve them early. Let them test-drive prototypes; celebrate their wins; bring them into planning sessions where their input actually shapes next steps. Their stories become persuasive evidence—and their networks carry momentum further than any formal pitch could ever manage.

Want more on helping engineers think beyond their immediate tasks? Check out Coaching Engineers to Think Like Problem-Solvers for actionable ways to encourage systems thinking and advocacy among technical peers who could become your best allies.

Conclusion: Don’t Wait for Certainty—Build Buy-In Iteratively

I get it—the temptation is strong to wait until your case is bulletproof; until you have perfect data or universal consensus. But here’s what experience (and a few stumbles) have taught me: Waiting for certainty almost always means missing out on real innovation.

• Quantify pain as best you can—even if your numbers aren’t perfect.
• Build scrappy prototypes that make possibilities tangible.
• Reframe tech in terms executives value most.
• Pair optimism with humility—invite learning along the way.
• Bring early advocates into your corner; let their stories do some lifting for you.

Each step builds trust and momentum—even if not everyone is convinced right away. Over time, seeing becomes believing. By moving forward before everything is proven, you help your organization learn faster than competitors—and that’s where real value lives.

Ultimately, building buy-in is as much about shared vision as it is about results. Invite others to co-create—even when things feel uncertain—and you’ll foster a culture where innovation belongs to everyone. The next move is yours: Take that first step—and let momentum build from there.