Getting Buy-In from Stakeholders for New Software

"Deal's looking good. I'm in with the CMO." A colleague shared his excitement. I rolled my little eyeballs. "What?" he asked, confused. "Single-threaded deals die," I replied. Three weeks later: "CMO went on leave. Deal's stalled." I wasn't surprised. The average B2B purchase now involves 11+ stakeholders. Yet most reps are still playing the "one relationship" game. Old playbook: Find one champion. Let them "sell internally" for you. Hope for the best. Failure rate? About 80%. A recent client win taught me the better approach: Initial call with the VP of Sales. Great fit, but I asked: "Who else needs to be comfortable with this decision?" The list: - CRO (economic buyer) - IT Director (technical approval) - Sales Enablement (implementation) - 2 Regional VPs (end users) That's 6 people. Each with different: - Priorities - Objections - Questions Rather than pestering my champion to coordinate everything... I created a single digital room with: - Role-specific sections for each stakeholder - Tailored ROI calculations for the CRO - Security documentation for IT - Implementation timeline for Enablement - Quick-start guides for the Regional VPs My champion shared the link. The magic happened silently: Analytics showed the CRO viewed the ROI calculator 5 times. The IT Director spent 15 minutes on security docs. Both Regional VPs watched the training videos. I hadn't spoken to any of them directly. But they were all selling themselves. When we finally had the "decision call," everyone was already aligned. No last-minute objections. No mysterious "other stakeholders." No surprises. Here's what changed: Old approach: Pray your champion effectively represents you to people you never meet. New approach: Give every stakeholder what they need, even without direct access. Multi-threading isn't about scheduling more calls. It's about making yourself irrelevant to the process. The best deals close when stakeholders convince themselves...without you in the room. Are you still gambling on single-threaded relationships? Or building networks that sell for you? Agree?

A designer once told me, “This is amazing…but I already committed to a solution.” That’s when it clicked: Research doesn’t drive change. Alignment does. The best researchers I’ve worked with? They’re not just insightful. They’re influential. Here are 6 habits of researchers who consistently get buy-in and how to start using them today: 1. They never say “users were confused” They say: “This issue is costing us 12% of conversions.” ↳ Take one insight you’ve already shared and rewrite it using this format: Problem + Impact + Recommendation Then send it to one stakeholder as a Slack message, not a deck. 2. They don’t deliver research. They facilitate decisions They ask: “What’s the decision this team is stuck on right now?” ↳ Before every project kickoff, ask your PM: “What’s the riskiest assumption behind this decision?” Then shape your study around that. 3. They translate like hell Not “delight,” but “adoption.” Not “friction,” but “drop-off.” ↳ Pick 3 insights from your last study and rewrite them using business terms. Drop them into a meeting and watch who starts paying more attention. 4. They time it perfectly Not a 30-slide deck on a Friday. A one-sentence quote right before a roadmap review. ↳ Look ahead to next week’s big decision-making moment. Pick one insight and share it 24 hours before the meeting. Not during. Not after. 5. They repeat themselves intentionally They plant insights until someone else says it back to them. ↳ Pick one finding you want to stick. Mention it once in Slack, once in a retro, and once in a 1:1 this week. Different formats. Same message. Let it echo. 6. They stop trying to “educate stakeholders” They listen. They co-create. They shift the power dynamic. ↳ Instead of sending research after it’s done, invite a stakeholder to help design one question before it starts. You’ll double your buy-in before you even begin. You don’t need stakeholders to love research. You just need them to feel what it protects them from. If your insights are strong but your impact is quiet, making these into habits is your next step. Which of these habits are you building right now? Or what’s one you’d add to the list?

You might as well be speaking “Klingon” Just dropped from a meeting where the IT Director provided his update to the leadership team. The c-level folks and non-technical leaders had no clue what he was talking about… From my experience this is the #1 mistake technical professionals make when meeting with business stakeholders I'll be blunt… business stakeholders don’t care about your technical architecture diagrams, your configuration details, or how cutting-edge your solution is. They care about outcomes. They care about results. They care about impact. BUT most technical professionals go into meetings armed with technical jargon & acronyms and leave the room wondering why no one bought in. If you’re presenting to business leaders, here’s the reality check… you are selling and you’re not selling technology - you’re selling business value. I don’t like to present a problem without a solution – so let’s try this… Step 1 Start every conversation by answering this “How does this solve a business problem?” If you have a technical solution that reduces costs, increases revenue, mitigates risk, or makes life easier for users, lead with that. Everything else is just details that nobody cares about. Step 2 Translate technical features into business benefits. Instead of saying, “We’re implementing zero trust,” say, “We’re reducing critical risks to our top revenue producing critical business functions.” Step 3 Stakeholders want to hear about how your solution will reduce downtime, increase productivity, save $$$, or improve client satisfaction. Make your impact measurable and relatable. Step 4 Can you reframe your message using an analogy or better yet a story. Numbers are great, but stories are sticky and resonate. Frame your solution in the context of a real-world scenario, like something stakeholders can visualize and connect with. Step 5 No one likes a squeaky wishy washy technical expert. Take a position, back it with evidence, and be clear about the path forward. Confidence inspires trust. Stop talking about the “how.” Start owning the “why.” And STOP speaking “Klingon” When you shift your focus to business value, you’ll see interest, buy-in, alignment, and support. #ciso #dpo #msp #leadership

I’ve now been involved in buying software at 4 companies. I never realized how many mistakes I was making as an AE until I was on the other side. Why is “How we buy” not a part of every AEs onboarding? AEs listen up. Here is where I got it wrong and what I think is important to understand: 1️⃣ Your buyer has a full-time job. Evaluating software is an additional task that is time consuming, requires some internal political pull and can likely mean they are putting themselves (or their jobs) on the line. Understand this and don’t take it lightly. It’s important you understand whether this person has bought software before and HOW RECENTLY. Why? If I happened to just buy a software last month, I likely used up some of my “internal pull” and energy on it. This matters more than you think. 2️⃣ Buying cycles are slightly different based on whether somebody came inbound or outbound. If I request a demo, it may be out of curiosity, but usually this is an initiative that has already been talked about internally with various stakeholders, potentially a budgeted line item and half the decision has already been made. This person is likely a champion, needs less convincing of the problem/solution and is probably talking with other vendors. Focus on differentiation early here. For outbound, this potentially means a much larger uphill battle for your buyer. You must identify key stakeholders early and start multi-threading and helping that champion sell. One of my favorite things to do here is spin up a digital sales room like Aligned and uncover who is actually looking at the material I’ve sent over. 3️⃣ Buying software is not rooted in rationality. Humans are not rational actors. Your ROI numbers are likely irrelevant… especially if we didn’t specifically sit down and confirm them. Example: Let’s say your solution ultimately helps me get more qualified pipeline. There are HUNDREDS of ways that I can go about doing this. Better contact data, better signals, better research on accounts, better emails, better training etc. You need to help me prove that you are the BEST way to do that. 4️⃣ Make it extremely easy for me to sell internally. No exec watches demo recordings, reads case studies or has time for 20 slides in a deck. Gal Aga said it best in a post the other day: 1. Equip them with a CXO-ready business case 2. Co-build all internal assets (ROI, TCO, FAQs) 3. Pre-plan rollout (beyond just closing) 4. Pressure-test expected internal objections 5. Prep champions for CFO skepticism 6. Map risks openly—no deal is risk-free 7. Constantly challenge: "What could kill this project?" Please don’t just send over a bunch of links or PDFs. Get yourself Aligned and make it easy for buyers to have a hub with all documentation in one place. Try it for free here: https://lnkd.in/eqcE6G9r

We just closed a $480K deal at Aligned - our biggest ever. But twice in the final weeks, it almost died. It was brutal. Two execs came out of nowhere with objections. We had no access. No time to fix it. But 22 (!!) stakeholders had already been engaged… And they saved it. That’s when it hit me: Multithreading isn’t a tactic. It’s deal insurance. Here’s the exact playbook we now run in every complex deal: 1. Early Exec-to-Exec Sponsorship Don’t wait until sh*t hits the fan. Initiate VP-VP or CXO-CXO alignment early. We send short, supportive emails without direct asks. Time after time, that builds genuine trust and establishes a safety net long before we need it. 2. Identify ‘Hidden Stakeholders’ Buyers often silently forward materials internally. By using Deal Rooms, we uncover up to 68% more stakeholders, often the real decision-makers influencing budget approvals or strategic buy-in. 3. Isolate Stakeholders 11 people on a call? You’re NOT multithreaded - it’s about quality, not volume. Our team opens separate 1:1 convos. They follow up with each buyer with next steps, suggestions or value that ties to something they said. 4. Proactive Signal-Based Engagement When stakeholders interact with key assets in the deal room, we use those signals to trigger follow ups - e.g. RevOps spends 20min on CRM integration; they might need more info, or could benefit from a dedicated session. 5. Multiple Champions Strategy Nothing beats having an army of internal champions instead of one. Whenever we see an opportunity to build champions, we do it. It derisks the deal in case someone leaves. Plus, budgets are shared, or are just easier to pass. 6. Real-time Alerts on New Stakeholders Our deal room sends instant alerts whenever there’s a new stakeholder (see #2). We then leverage this event as an opportunity for exec introductions or quick alignment note—”Hey, saw you joined the project”. 7. Support the Above-the-Line (ATL) Met an exec early? Keep them looped into POC updates, key milestones, or call takeaways. When we give regular status updates, it builds credibility and keeps momentum - as execs don't join every call, and appreciate the visibility. 8. Never Underestimate Below-the-Line (BTL) Decision-making today is flatter; end-users/junior stakeholders are increasingly influential. I’ve lost count on how many times AEs (our BTL buyers) were make or break in our deals. Give them genuine attention. Don’t underestimate any buyer. 9. Late-Stage Exec Reinforcement If a deal stalls, a concise, confident, personal email from me as CEO resets urgency. The message isn't pushy; it reinforces our shared vision, driving commitment. —— Multithreading isn’t a tactic. It’s insurance. A deal defense system. Built thread by thread, stakeholder by stakeholder. So when things break, and they will - You’re not the only one left to save it. P.S. The Deal Room we used to multithread is Aligned. It's free to try: https://lnkd.in/dYksGnfb

Ever presented rock-solid research only to hear "Thanks, but we're going with our gut on this one"? Securing stakeholder buy-in is rarely about the quality of your work. It's about something deeper. When you’re dealing with a research trust gap, ask yourself 5 questions. 👽 Are you speaking alien to earthlings? When you say jargon like "double diamond" or "information architecture," your stakeholders hear gibberish. Business leaders didn't learn UX in business school—and most never will. Translate everything into business outcomes they understand. Revenue growth. Customer retention. Cost savings. Competitive advantage.  Speak their native language, not yours. ⏰ What keeps them awake at 3am? Behind every skeptical question is a personal fear. That product manager who keeps shooting down your findings? They're terrified of missing their KPIs and losing their bonus. Have honest conversations about what they're personally on the hook for delivering. Then show how your research helps them achieve exactly that. ❓Are you treating assumptions as facts? You might think you know what questions matter to your stakeholders. You're probably wrong. Before starting research, explicitly ask: "What questions do you need answered to make this decision?" Then design your research to answer exactly those questions. ⚒️ Are you dying on the hill of methodological purity? Sometimes you have 8 hours for research instead of 8 weeks. Being dogmatic about "proper" research methods doesn’t always pay off. Focus on outcomes over process. If quick-and-dirty gets reliable insights that drive decisions, embrace it. 🍽️ Are you force-feeding them a seven-course meal when they wanted a snack? Executives need 30-second summaries. Product managers need actionable findings. Junior team members need hands-on learning. Tailor your approach to each one. You can also use my stakeholder persona mapping template here: https://bit.ly/43R7wom What’s the best advice you’ve heard about dealing with skeptical stakeholders?

Stop delaying your EHS software go-live at the risk of perfection. I have seen implementations go in circles because teams can't make decisions together on the "correct" workflow. - Different sites with different processes fighting for the system to reflect their reality. - Someone higher up in the hierarchy wanting to impress leadership with a fully baked, seemingly "perfect" system. - Complaints that the system they bought can't be configured to their liking. When in reality, it's over customization. - Lack of real understanding of what's happening on the ground, in the plant and in the field. So system needs reflect imaginary problems. All of these things can completely derail your progress. They are all breakdowns in one thing: communication. Up and down the chain. To avoid running in circles to nowhere, try this: - Adopt an agile framework. Get a minimum "lovable" product and run. - Set a small but concrete steering committee with stakeholder representation. That can mean business units with different workstreams, geographic differences or regulatory requirements. Make sure you've covered 80% of the scope that the system is going to serve and make sure they are in the room. - Identify pilot sites and get testing done at a real site, incorporate that feedback into your backlog - PRIORITIZE your backlog. Not everything can or should be done. Put these inputs and requests into your agenda for that steering committee. Create SLAs so users feel heard and the feedback loop continues. Explain the why or why not. - Optimize for where the highest risk work gets done. The system doesn't need to fit the exact workflows of the office staff who interact once a month. It has to work for the ones in it multiple times day. - Set realistic expectations with yourself, your team and your vendor. Especially if you are rip and replacing. The new system may be an upgrade, but all technology has it flaws. - Build capacity so you can iterate and move. This can be additional support hours with the vendor or external help. But don't let the system be limited by your already overloaded headcount. The work doesn't end at go-live, it starts there. Perfect is the enemy of good enough. Don't let pride impact your ability to leverage EHS technology in your organization to its full ability. It's not magic, but it can change the way you make real-world decisions. But it has to get out into that world first.

🚨 Buying Tech is Easy. Getting Adoption is Hard. I’ve seen it time and time again in property management and beyond: company gets excited about new software, signs the contract, flips the switch…and then nothing changes. Why? Because buying tech is the easy part. Getting people to use it—really use it—is the hard part. Even the smartest, most intuitive platforms aren’t truly “plug-and-play.” People aren’t machines. If your teams don’t understand the why, don’t feel supported in the how, and don’t see results in their day-to-day workflow, adoption fizzles. And when adoption fails, the ROI disappears. Here’s what makes successful rollouts, successful rollouts: 🔑 Build a Rollout Strategy (Not Just an Implementation) Adoption doesn’t happen by accident. It starts with a plan: • Early champions: Identify team members who can test, troubleshoot, and advocate. • Updated SOPs: Bake the tool into your standard processes—if it’s optional, it won’t stick. • Milestone-based training: Ongoing, bite-sized training beats one overwhelming launch day session. • Real-time support: Create a safety net for questions, frustrations, and quick fixes. 🛡️ Create a Safe Space Too often, tech rollouts are met with fear: “Is this replacing me?” or “What if I can’t learn it?” Leaders need to make it clear: adoption isn’t about replacing people—it’s about freeing them up for higher-value work. The best tech amplifies human impact; it doesn’t diminish it. 📊 Track the Right Metrics If you don’t measure adoption, you won’t know if it’s working. A few indicators that matter: • Adoption rates (logins, active use, feature utilization) • Process time saved (turn times, work orders, reporting cycles) • Error reduction and accuracy improvements • Employee satisfaction with the tool (survey it!) These tell you whether the technology is improving the business and the people’s experience. 🔄 Build Feedback Loops End-users are your greatest consultants. Set up feedback channels so they can tell you what works, what doesn’t, and what would make the tool even better. When people feel ownership of the process, adoption skyrockets. 💡 The bottom line: If you want new tech to succeed, don’t just budget for the tool. Budget for change management. Because buying is easy—but adoption is what actually delivers the results.

The big Law Practice Management companies are getting this backwards. I’m watching a joint CLE right now presented by three of the big LPM vendors. I guess I shouldn’t be surprised by their “technology-first” approach, but the method they’re suggesting for researching, evaluating, selecting, and implementing new software is — shall we say — suboptimal. 👎 They’re falling into the classic top-down, hierarchical model of practice leadership. "The Boss" decides what software to buy, then pushes it down to the team — complete with a “change management” plan to get team members to buy in after the fact. I used to work in change management. And let me tell you, it’s a bear; especially in big organizations where it’s not practical to involve every user in upstream decision-making. The CLE presenters are following that exact playbook. And from experience, I can tell you: even when you get it “right,” it rarely works well. Because the people expected to use the tool weren’t part of shaping it, it takes a heavy lift to get their buy-in. But small firms have a huge advantage. You don’t have to follow that top-down, after-the-fact approach. You have the optimal size and flexibility to do what works far better: Engage and involve your team with the change before you make it. Start by listening — not just to complaints, but to everyday frictions. Where are the bottlenecks? The double entry? The confusing handoffs or inconsistent client communications? The long delays? And don’t stop at pain points — work with your team to understand opportunities: What would make their work easier? What would improve the client experience? Co-create your success criteria: What does “better” look like? Faster turnaround? Fewer errors? Less rework? Happier clients? Less stress? Then test. 🔹 Adjust a process. 🔹 Update a policy. 🔹 Try a new checklist. 🔹 Improve a template. 🔹 Change your internal language. See what improves. Iterate. Only after you’ve built some working solutions should you look at embedding them in your tech tools. And even then, it doesn’t have to be an all-in-one LPM platform. Often, a mix of simpler tools that match your team’s actual needs will outperform a monolith you have to bend to fit. When your team is part of the process from the beginning — identifying problems, defining success, and testing solutions — you don’t have to “manage” the change. They own it. And that ownership is what makes change stick. #lawfirm #legalops #legaltech #agileattorney #lawpracticemanagement Photo for the algorithm ;-)

Stop trying to sell your software's features. Nobody cares. Here's what I've learned after thousands of enterprise deals: Buyers are numb to feature-focused pitches. • They don't want your software. • They want outcomes. But here's the real challenge: Your buyers now face massive buying committees. A cool feature demo won't convince 15 stakeholders to sign off. You need a compelling business case. Try this: Don't pitch features. Instead, show how each feature drives specific outcomes. Because random "cool" features? They're noise. But features tied to business impact? They move deals forward. Remember: The more compelling the impact, the more likely your deal closes now instead of "maybe later." (Or worse, never) Want to win more deals? • Stop selling software. • Start selling outcomes. Because when stakeholders can't agree on priorities, they default to doing nothing. And nothing is your biggest competitor. Thoughts? 👇