Aligning stakeholders without design by committee

Design by committee has an undeserved reputation as a taste problem. It's not. It's a governance problem. The committee doesn't ruin the design by having opinions — opinions are cheap and often right. It ruins the design by having ambiguous authority: nobody knows whose opinion is input and whose is a decision, so every opinion gets partially incorporated, and the design becomes a peace treaty between people who will never use the product.

The fix is not fewer stakeholders. Ambitious projects have real stakeholders with legitimate interests — legal has veto rights over claims, sales has knowledge nobody else holds, the founder's taste is why the company exists. The fix is making authority legible, early, and then running a process that respects it. Here's the system we install at the start of every engagement, refined over a decade of watching projects live and die in review meetings.

Week zero: map the authority, not the org chart

Before any design work, we run a decision-mapping exercise with the client's project owner. For each class of decision, we name exactly one approver. The exercise takes an hour and saves months. The output looks like this:

Decision classApproverConsultedInformed
Brand expression, visual directionMarketing leadFounder, design teamAll-hands
Claims, compliance languageLegal counselMarketingProject team
Product flows, feature priorityProduct ownerEngineering, supportSales
Budget, scope changesExecutive sponsorFinanceProject team

Three rules make the map work. One name per cell — "approver: marketing" is a committee reconstituting itself in a spreadsheet cell. Approvers can't delegate upward — if the named approver escalates every decision to the founder, the founder is the approver; update the map and enjoy the honesty. The map is public, pinned in the project channel where everyone can consult it mid-meeting instead of mid-grudge.

The hardest conversation is the founder. Founders often want to be consulted on everything but don't want to be the bottleneck — an emotionally coherent position that is operationally incoherent. The resolution we've found: founders get two designated moments (the direction presentation and the pre-launch review) where their input is the decision, and explicit opt-out of the weekly loop in between. Most founders take this deal gratefully. It buys them back their calendar and buys the project its speed.

Input is not a decision

The single most useful sentence in stakeholder management: thank you, that's input. Distinguishing input from decision is what keeps a review meeting from becoming a land grab. Input is anyone's observation, preference, concern or idea — all welcome, all recorded, none binding. A decision is what the named approver does with that input.

The practical mechanics: feedback is collected in one place (one tool, one thread, one document — never email) against a named round, with a deadline. Each item of feedback gets classified as it's addressed: incorporated, considered and declined (with reason), or escalated to the approver. The audit trail matters more than it looks. When week nine arrives and someone asks why their suggestion from week three isn't in the design, "considered and declined, because it conflicted with the mobile layout, decision by the marketing lead on 14 May" ends the conversation. Silence restarts it.

This discipline pairs naturally with a strong internal critique culture on the studio side — if the design hasn't survived a sharp design critique before the client sees it, no governance structure will save you from the meeting that follows.

Demo, don't present

The most reliable alignment tool we've found is replacing presentations of intention with demonstrations of reality. A static mockup invites debate about preference; a working prototype invites reaction to experience. Preference debates are unbounded. Experience reactions are fast and diagnostic — "the filter took me a second to find" is actionable in a way "I'm not sure about the colour" never will be.

So we demo working software weekly — in the browser, on a phone where it's a phone experience, with real content over lorem wherever there's real content to be had. (Our case studies make a point of this: Northwind Ledger was demoed weekly from week two, and the steering committee stopped asking for status decks by week four — the demo was the status.) The motion details get shown live too; motion that earns its keep can only be evaluated by watching it, and stakeholders who've never seen the thing move will confidently veto it from a screenshot.

For distributed stakeholders who miss the demo, a three-minute narrated recording travels well. What doesn't travel: forty-slide decks, which re-create the preference-debate problem in portable form.

The approval ladder

Large organisations need a mechanism for decisions to climb without stalling. Ours: every decision has a lapse date. Feedback rounds close on a stated day; items without response by the close are resolved by the approver's deputy or, failing that, treated as no objection. Announced in week zero, the lapse date changes behaviour immediately — people who need to weigh in, weigh in. Set them generously enough to be human (a week, not a day) and firmly enough to be real (the date closes, it doesn't glide).

Escalation follows the map, with one rule that saves projects: escalation costs something. The escalating stakeholder has to write the objection in two sentences — what specifically, and what outcome they need. Most escalations die at the cost of composition, which is the design working as intended: the ones that survive it are usually legitimate.

Rescuing a project stalled in review loops

If you're reading this from inside a project that's been "in review" for two months, the rescue sequence is:

  1. Name the stall. Say, in the steering meeting, "we are in a review loop, and here is the cost per week." Stalls persist in proportion to their politeness.
  2. Rebuild the map in one meeting. Not a process redesign — a single sixty-minute session to name approvers per outstanding decision. Present it as operational maintenance, not a coup.
  3. Reduce the decision surface. A stalled project usually has too many open decisions feeding each other's anxiety. Force-rank the open decisions, close the bottom half with the opinionated-default proposal ("unless we hear otherwise by Friday, footer links follow the sitemap structure"), and work the top half one at a time.
  4. Ship something. Anything. A single page, one flow, the error states. Momentum is the cheapest morale there is, and stalled projects are morale problems as much as governance problems.

What the agency owes the room

Alignment isn't only the client's discipline. The studio side has obligations: bring opinions (a designer with no recommendation is outsourcing their job to the meeting), show the work early and often, say the trade-offs out loud, and never let a stakeholder discover the project's constraints at the moment they'd have chosen differently. Our approach page describes the cadence we run by default; clients adapting it to their own reviews is the best outcome this article can have.

Key takeaways

  • Design by committee is a governance failure, not a taste failure. Ambiguous authority incorporates every opinion partially; legible authority decides.
  • Map decision authority in week zero: one named approver per decision class, published where everyone can consult it mid-meeting.
  • Separate input from decisions. Collect feedback against named rounds with deadlines, and classify every item incorporated / declined-with-reason / escalated.
  • Demo working software weekly instead of presenting intentions. Reactions to experience are fast and actionable; debates about preference are unbounded.
  • Give every decision a lapse date and make escalation cost two written sentences. Stalls persist in proportion to their politeness.
  • Rescue a stalled project by naming the stall, rebuilding the approver map in one meeting, shrinking the open-decision surface, and shipping something small.

FAQ

Our founder insists on approving everything. Can the map survive that? Yes, if it's honest. Name the founder as approver for the classes they truly care about, and have the direct conversation about what that costs: their calendar becomes the project's critical path. Faced with that sentence, most founders delegate to the two-moments model. The failure to avoid is the unofficial founder-approval layer — decisions made by the named approver and then quietly unmade in a corridor. That's the map lying, and a lying map is worse than a slow one.

How many stakeholders is too many? Wrong unit. Stakeholders aren't the load; open decisions with unclear approvers are the load. We've run clean projects with twenty consulted stakeholders and watched five-person teams deadlock for a quarter. Count decisions without owners, not people with opinions.

What if the approver is consistently wrong? Then you have a strategy problem, not a process problem, and the process isn't the place to fight it. Record the input, note the disagreement, and let the approver own the outcome — the audit trail exists partly so accountability is educational. Over time, outcome data earns the right to revisit the map. Agencies can and should argue hard before decisions are made; after they're made, ship the decision well.

How does this work with agile ceremonies? The map slots in above the ceremonies: sprint reviews are demos and input-gathering, but the approver structure decides what ships. The anti-pattern to avoid is letting the demo become the decision forum by default because no approver was ever named — agile didn't make decisions; it made the absence of a decision process feel like velocity for a while.

What do we do when legal or compliance arrives late with vetoes? Bring them onto the map in week zero in the consulted column for everything that touches claims — as early reviewers, not final-stage gatekeepers. Legal teams are usually delighted to be consulted early; what they resent is receiving finished work they'll be blamed for blocking. Their reputation as the Department of No is mostly an artefact of being invited last.


Keep reading