Start With the Business Problem, Not the Website
Getting stakeholder buy-in for a website project starts before you ever mention the word “website.” The single most effective thing you can do is frame the project around a business problem that stakeholders already care about, then position the website as the mechanism for solving it. When you lead with “we need a new website,” you invite scepticism, budget debates, and the dreaded question: “Didn’t we just redo this three years ago?” When you lead with “we’re losing 40% of qualified leads between first touch and demo request, and here’s why,” you have a room full of people leaning forward.
Across dozens of projects, we’ve seen the same pattern. The teams that secure budget and executive support quickly are the ones who connect the website to revenue, cost reduction, or competitive positioning before they ever discuss design, technology, or timelines. The teams that struggle are the ones who walk into a meeting with wireframes and mood boards, hoping the visuals will sell the idea. They rarely do.
Understand Who Your Stakeholders Actually Are
Most people think of stakeholders as “the people who approve the budget.” That’s only partly true. Stakeholders are anyone whose support, input, or cooperation you need for the project to succeed. That includes people who will never sign a purchase order but whose resistance can quietly kill a project through delay, scope creep, or passive non-participation.
In a typical mid-market company planning a website project, your stakeholder map usually looks something like this:
- Executive sponsors (CEO, CFO, COO) who control budget and strategic priorities
- Marketing leadership who will own the website day-to-day after launch
- Sales leadership who depend on the website for lead quality and volume
- IT or operations who will need to support integrations, security, and hosting
- Subject matter experts in product, customer success, or technical teams who hold critical content knowledge
- External partners such as agencies, freelancers, or technology vendors already in the ecosystem
Each of these groups has different concerns, different definitions of success, and different fears about what the project might mean for their workload. The CEO wants to know the project will generate measurable ROI. The head of sales wants to know leads won’t dry up during a migration. IT wants to know you’re not introducing a platform they’ll have to babysit. If you pitch the project the same way to all of them, you’ll win some and lose others.
Map Concerns Before You Pitch
Before you schedule a single alignment meeting, spend time understanding what each stakeholder group cares about. This doesn’t require formal interviews. A 15-minute coffee chat or a quick Slack message asking “what frustrates you most about the current site?” will surface 80% of what you need. Document these concerns in writing. You’ll use them later to tailor your messaging and anticipate objections before they become roadblocks.
One pattern we see repeatedly: marketing teams assume the CFO’s primary concern is cost. It usually isn’t. CFOs worry about predictability. They’ve been burned by projects that started at £50,000 and finished at £120,000. If you can show them a process that produces accurate scope before major spend begins, the budget conversation becomes dramatically easier.
Build Your Business Case With Evidence, Not Opinions
A compelling business case for a website project rests on three pillars: what’s broken now, what it’s costing you, and what a better outcome looks like in specific terms. Opinions like “the site looks outdated” or “I don’t think it reflects our brand” carry almost no weight with decision-makers who are weighing your project against five other budget requests.
Here’s what actually moves the needle:
Quantified performance gaps. Pull data from Google Analytics, your CRM, and your marketing automation platform. Show conversion rates by page, bounce rates on key landing pages, form abandonment rates, and how those numbers compare to industry benchmarks or your own historical performance. If your site converts visitors to leads at 1.2% and your industry average is 2.8%, that’s not an opinion. That’s a revenue gap you can calculate in pounds.
Customer and prospect feedback. If you have recordings from user testing, quotes from sales calls where prospects mentioned the website, or NPS survey comments about the digital experience, compile them. Three or four direct quotes from customers saying “I couldn’t find pricing” or “I wasn’t sure what you actually do” are more persuasive than any internal analysis.
Competitive context. Show stakeholders what direct competitors are doing with their websites. Not to argue that you should copy them, but to demonstrate that prospects are comparing your site against these experiences and drawing conclusions. A side-by-side screenshot of your product page versus a competitor’s, with annotations highlighting specific UX differences, tells a powerful story without a single word of spin.
Translate Everything Into Business Metrics
The most important translation you can make is from website metrics to business outcomes. Stakeholders outside marketing don’t think in bounce rates and session durations. They think in pipeline, revenue, cost per acquisition, and customer lifetime value.
Here’s a practical example. Say your current site generates 200 marketing-qualified leads per month with a 15% close rate and an average deal size of £8,000. That’s £240,000 in monthly revenue attributable to the website. If a redesign improves conversion by just 30% (well within realistic range for a properly scoped project), that’s an additional £72,000 per month, or £864,000 per year. Now you’re not asking for a £80,000 website. You’re proposing an investment with a potential 10x return. That framing changes the entire conversation.
Address the Fear of the Unknown Early
Stakeholder resistance to website projects is rarely about the concept itself. Almost everyone agrees the website matters. The resistance is about uncertainty. Specifically, three kinds of uncertainty that experienced decision-makers have learned to fear through painful past projects:
Scope uncertainty: “Will this project keep growing until it consumes every resource we have?” This fear is well-founded. Website projects are notorious for scope creep, and most stakeholders have lived through at least one that ballooned out of control. The antidote is showing them a process that defines scope rigorously before committing major budget. This is exactly the approach we describe in our blueprint-first guide, where requirements are validated and documented before design or development begins.
Timeline uncertainty: “Will this drag on for months past the deadline?” Again, a legitimate concern. The best way to address it is by presenting a phased approach with clear milestones and decision points, rather than a single monolithic timeline that stretches into the distance.
Disruption uncertainty: “Will this break things that are currently working?” Sales teams worry about losing lead flow. IT worries about system instability. Customer success worries about broken links and confused clients. Acknowledge these risks explicitly and explain how the project plan mitigates each one. For example, running the new site in parallel with the existing one during testing, or implementing redirects systematically to preserve SEO equity.
Involve Stakeholders in Discovery, Not Just Approval
One of the most counterintuitive lessons from years of project work is this: the fastest way to get buy-in is to slow down at the beginning. Teams that rush to get approval and start building often face mounting resistance as the project progresses. Teams that invest time in collaborative discovery build a coalition of supporters who feel ownership over the outcome.
Collaborative discovery means bringing stakeholders into the process of defining the problem and the requirements, not just presenting them with a finished proposal to approve or reject. When the head of sales helps define what “qualified lead” means in the context of the website, they become invested in the project’s success. When IT participates in evaluating platform options, they stop being a blocker and start being an advocate.
This doesn’t mean every stakeholder needs to attend every meeting. It means each stakeholder group has at least one meaningful touchpoint where their expertise shapes the project direction. A 45-minute workshop where sales reviews the current lead journey and identifies friction points. A technical review session where IT evaluates integration requirements. A content audit where subject matter experts flag outdated or inaccurate information on the current site.
The output of these sessions serves double duty. You get better requirements and more accurate scope. And you get stakeholders who feel heard, respected, and personally connected to the project’s success. That second benefit is often more valuable than the first.
Present a Phased Approach, Not an All-or-Nothing Proposal
Large, monolithic project proposals trigger risk aversion in stakeholders. When someone sees a single line item of £100,000 with a 6-month timeline, their instinct is to find reasons to say no, or at least “not yet.” Breaking the project into distinct phases with separate decision points dramatically reduces perceived risk and makes it far easier for budget holders to say yes.
A phased approach typically looks something like this:
Phase 1: Discovery and scoping (4-6 weeks, modest investment). Define requirements, validate assumptions with data and stakeholder input, produce a detailed project blueprint with accurate costs and timelines for what follows. This phase is self-contained. If the findings don’t support proceeding, you’ve spent a fraction of the full budget to reach that conclusion.
Phase 2: Design and prototyping (6-8 weeks). Create the visual and structural design based on validated requirements. Stakeholders review and approve before any code is written.
Phase 3: Development and integration (8-12 weeks, depending on complexity). Build the site, integrate with existing systems, and prepare for launch.
Phase 4: Launch, testing, and optimisation (2-4 weeks post-launch). Go live with monitoring, fix issues, and begin iterating based on real performance data.
The beauty of this structure is that each phase produces tangible deliverables that stakeholders can evaluate before committing to the next stage. The CFO isn’t being asked to approve £100,000 on faith. They’re being asked to approve £12,000 for a discovery phase that will produce a detailed, costed plan. That’s a fundamentally different ask, and it gets approved far more often.
Handle Objections With Specificity
Every stakeholder group has predictable objections. Handling them well requires acknowledging the concern as legitimate and responding with specific, credible answers rather than dismissive reassurances.
“We don’t have the budget right now”
This usually means “I’m not convinced the return justifies the spend.” Respond with your business case numbers. If the numbers are genuinely compelling and the budget still isn’t there, propose starting with the discovery phase only. A smaller initial commitment is easier to fund, and the output of discovery often makes the full business case undeniable.
“We don’t have time for this”
Stakeholders worry about the time commitment required from them, not just the project timeline. Be honest about what you need: typically 2-3 hours per stakeholder over the discovery phase, then periodic review sessions during design and development. Frame it as a small time investment that prevents a much larger time sink later when poorly scoped projects require rework and constant firefighting.
“The current site is fine”
This is where your evidence does the heavy lifting. “Fine” is a feeling. Data tells a different story. Show the conversion gaps, the customer feedback, the competitive comparison. If the data genuinely shows the site is performing well, then perhaps a full rebuild isn’t warranted and a targeted optimisation programme would be more appropriate. Being willing to recommend a smaller project when the evidence supports it builds enormous credibility with stakeholders for future initiatives.
“The last website project was a disaster”
This is the most important objection to handle well, because it’s rooted in real experience. Don’t dismiss it. Instead, ask what specifically went wrong. In our experience, the answer almost always falls into one of three categories: the scope wasn’t properly defined, the vendor wasn’t properly evaluated, or internal stakeholders weren’t aligned before the project started. Then explain how your proposed approach addresses each of those specific failure points. You’re not promising perfection. You’re showing that you’ve learned from the pattern that burned them before.
Create Visible Momentum
Buy-in isn’t a single event. It’s a state that needs to be maintained throughout the project lifecycle. Visible momentum, meaning regular evidence that the project is moving forward and producing results, is what keeps stakeholders engaged and supportive over weeks and months.
Practical ways to create this momentum:
- Share weekly status updates in a consistent format. Even two paragraphs covering what was accomplished, what’s next, and any decisions needed. Predictable communication builds trust.
- Celebrate phase completions visibly. When discovery wraps up and produces a detailed blueprint, share a summary with all stakeholders. When design is approved, circulate the key pages. These milestones reinforce that progress is real and tangible.
- Surface decisions early. Don’t wait until a decision becomes urgent or blocking. Give stakeholders advance notice that a decision is coming, provide the context they’ll need, and set a clear deadline. Nothing erodes buy-in faster than stakeholders feeling ambushed by requests for immediate approval.
- Report against the metrics you promised. If you sold the project based on improving lead conversion, report on lead conversion from day one. Even if early numbers are noisy, showing that you’re tracking what matters reinforces accountability and seriousness.
Align on What Success Looks Like Before You Start
One of the subtlest but most damaging threats to stakeholder buy-in is misaligned definitions of success. The CEO thinks success means more revenue. Marketing thinks success means a modern brand experience. Sales thinks success means better lead quality. IT thinks success means a stable, maintainable platform. None of these are wrong, but if they’re never reconciled into a shared definition, every stakeholder will eventually feel the project failed to deliver what they expected.
Before the project kicks off, facilitate a conversation (ideally during discovery) where all key stakeholders articulate their top two or three success criteria. Write them down. Look for conflicts and dependencies. If sales wants more leads but marketing wants fewer, higher-quality leads, that tension needs to be resolved before it shows up as a design argument four months into the project.
The output of this exercise should be a concise success framework: a single page listing the agreed-upon success metrics, who owns each one, and how they’ll be measured. Pin it to the wall (or the project wiki). Reference it in every major decision. When a stakeholder proposes adding a new feature mid-project, evaluate it against the success framework. If it doesn’t serve any of the agreed metrics, it doesn’t belong in this phase. Having that documented alignment makes these conversations constructive rather than political.
What to Do This Week
If you’re preparing to pitch a website project internally, here’s a practical starting point. Spend this week doing three things. First, map your stakeholders and note each person’s primary concern and definition of success. Second, gather your evidence: pull conversion data, collect customer feedback, and screenshot competitor sites. Third, draft a one-page business case that connects the website’s current performance gaps to specific revenue or efficiency impacts, using real numbers from your business. Walk into your first stakeholder conversation with those three things in hand, and you’ll be further ahead than 90% of teams attempting the same thing. Buy-in follows clarity, and clarity is something you can build systematically before you ever ask for a single pound of budget.
Ready to get started?
