What is a website stakeholder workshop?

One “simple change” follows the other and the project takes a dramatic U-turn. Expectations, budget and deadlines are shattered.

A Website Stakeholder Workshop exists to align the entire team early and prevent such disappointments, while staying flexible enough for necessary pivots.

So what actually is it?

A Website Stakeholder Workshop is a facilitated session where the people who shape your website agree on direction before anyone designs a single screen. Reaching this sort of alignment first is the key to avoid derailing the project later on.

The idea behind it is simple: the answer is already in the room, because your team knows far more than it usually gives itself credit for. Our job is to ask the right questions, and then to pull that scattered knowledge onto one shared wall where we can make sense of it together.

We map the problem, interview the experts already sitting in the room, and convert the team’s nagging worries into “How Might We” questions. The goal is to flip the narrative and turn problems into opportunities, until everyone finally agrees what the project needs.

The theme of the workshop is “what should this website actually do, and who should it target?” Don’t worry – in some cases, “we shouldn’t build a new website” is a valid outcome. When that happens, the attention moves to making the most out of the existing one.

At NerdCow it’s how we start every website project. The workshop is the heart of The Foundation, our four-week programme for getting a website pointed the right way before a line of code is written. The name we give that part is plainer than the textbook one: a session where stakeholders stop talking past each other.

Why bother with a workshop at all?

Because the alternative is worse, and you’ve almost certainly seen it. Five people each carry a slightly different website around in their head. Marketing wants leads, sales wants the demo button on every page, and the founder wants the whole thing to feel “premium.” Nobody says any of this out loud until the designs land, and by then it’s too late.

That’s a perfect example of design by committee. The site ends up as an average of every opinion in the building, which means it serves nobody especially well. A good workshop drags the disagreement forward to the very start, where it costs almost nothing to resolve. Better a tense ten minutes on day one than a massive pivot after month three.

Who’s actually in the room?

Fewer people than you’d think. In practice we aim for somewhere between four and eight.

The mix matters more than the headcount. A team of three marketers and one outsider will only ever produce three marketers’ worth of ideas, however hard they try. Pull in genuinely different roles, from different corners of the organisation, and you get genuinely different perspectives.

The roles we look for:

• The decision-maker – someone with the real authority to say yes and make it stick.
• The customer expert – whoever knows your audience best. After the decision-maker, this is the seat that matters most. This role often pulls double-duty in the form of a Product person.
• The marketing voice – the people using your website day-to-day are critical, even if we advise against having too many.
• The sales representative – a person that knows what happens once a lead is sales qualified. Marketers can often do this by proxy, but it’s never the optimal solution.
• An engineer or two – usually from your web agency. You need to make sure that every “great idea” gets a quick “yes, that’s buildable” or “no, not feasible in your timeline.”

Inviting the decision-maker point is the one I’ll push the hardest on. If the person with final say isn’t truly in the room, you can run a flawless workshop and still watch the outcome get overwritten the moment they read the summary or see the prototype. We wrote more about who belongs in the workshop room and why authority can’t be delegated halfway.

One positive example sticks with me. A senior stakeholder warned us up front that he’d only drop in and out, “far too busy for the whole thing.” He ended up staying for every minute of BOTH days, and left happier with the result than anyone else in the room. That’s the pattern more often than not: people quietly dread giving up two whole days, and then discover it’s the most useful stretch of the entire project.

What actually happens?

It starts in week one, before anyone meets. Your team fills in a short survey, and then the facilitator follows up with one-on-one interviews to pick the responses apart. This adds up to about an hour of your time in total. It’s the warm up before the workshop, and the first “aha!” moment where you can notice everyone pulling in different directions.

If the challenge on the other end of the interviews still feels too broad, you narrow it down in these interviews. A challenge that’s too broad is the fastest way to ruin a workshop, because you end up mapping a dozen personas and deciding nothing.

Then come the two days of workshops themselves, where the rhythm throughout is “together but alone.” People work in silence, write down their own ideas, and only then vote on them. Less debate, more deciding. It feels strange the first time you try it, and it’s precisely why the quieter personalities in the organisation finally get heard, while the meeting itself stops sprawling in every direction.

By the end you’ve built something real: a clear list of the problems the site has to solve, a user journey map running from first click to conversion, a wall of rough sketches contributed by everyone who participated, and properly designed screens with genuine copy written on them. We call it a website blueprint.

Then we take it away and test it with five real users, and we do that twice over: once straight after the workshop, and again once we’ve sharpened the blueprint on the back of what those first sessions tell us. Alignment is only ever a hypothesis. Testing is how you learn whether the room was right.

How long does it take?

The whole programme runs over four weeks, but your share of it stays small. It’s significantly shorter than the war of attrition it replaces.

An hour for the interview, two full days in the workshop, and a final couple of hours for the handover. During the handover, you get the files and an executive summary so the rest of your organisation can pick up the full context immediately. Everything in between, the testing and the polishing and the writing, we handle internally and keep you posted on as we go.

What about in-person vs. remote?

In-person is better, if I’m honest. Two days in one room beats two days on a call, every time. We’ve run it remotely just as often, though, and it still works. Geographical distance alone is no reason to postpone the whole exercise, but if you can, do it in your office. One caveat – either everyone is in-person or everyone is remote. Mixing the two is like putting a square peg into a round hole.

How is it different from a normal kickoff?

A kickoff is people talking and trying to plan a complex project in an hour. The workshop is all about deciding on the right direction and initial details first.

In most kickoffs the most senior voice sets the tone, everyone nods along politely, and the real opinions only leak out later in private Slack messages. The structure here is built to prevent exactly that and give everyone a voice through silent writing, dot voting, and a facilitator whose only loyalty is to the process rather than the org chart.

You leave a kickoff with the shakiest “action plan” you’ll ever create. You leave a workshop with a direction you can build against.

Where it tends to go wrong

Workshops are a sharp tool, and sharp tools cut you if you don’t handle them properly. The usual mistakes:

• The decision-maker only “drops in.” It is a last-restort option and it will get you over the finish line, but half-presence risks a half-baked outcome.
• The challenge is too broad, so the team attempts to boil the ocean and agrees on nothing.
• The wrong people test it. Bad testers are worse than no test at all.
• Someone treats the blueprint as the finished website. It’s a tested direction and a foundation for an MVP, but not the final website. That still takes at least a couple of weeks to build.

We’ve made most of these mistakes ourselves. I wrote up the ways a Design Sprint can fail so you can skip the lessons we paid for.

Is it worth running a Website Stakeholder Workshop?

If you’re about to redesign and you can already feel the committee forming – the competing agendas, the meetings that end without a decision – a workshop is the cheapest fix you’ll find. It’s how we’ve kicked off redesigns like Doddle’s, usually when a business has pivoted and the old site no longer fits who they’ve become.

There’s a payoff in raw speed as well. Pair the validated blueprint with the build stage that follows it, and we’ve seen anywhere from 50 to 60% knocked off the delivery time. Settling the hard questions early, it turns out, makes everything downstream quicker rather than slower.

Get the disagreement out into the open early, while it’s still nothing more expensive than conversation. Drop us a message and we’ll figure out together whether your project actually needs one.