Multi-Stakeholder Design: 5 Protocols for Real Stakeholder Conflicts

An insurance company develops a new claims management portal. Procurement wants to reduce cost per claim. Claims adjusters want faster processing times. IT wants standardized interfaces. Legal wants seamless documentation. The executive board wants to increase customer satisfaction. Five stakeholders, five different definitions of “success” — and those are only the visible five. Behind them stand distribution partners, regulators, end customers, data protection officers, and others who never sit in the workshop but decide whether the project succeeds or fails.

This is not a communication problem. This is a design problem.

Forrester surveyed over 16,000 B2B buyers in 2024 and found: an average B2B purchase involves 13 stakeholders, and 86% of all buying processes stall — not because of the vendor, but because of internal complexity on the customer’s side [1]. Gartner confirms this with a study of 632 buyers: 74% of buying groups demonstrate “unhealthy conflict” during the decision process [2].

Most stakeholder approaches treat this conflict as a facilitation problem — as if better sticky notes and a more experienced facilitator were the solution. This article argues differently: Multi-Stakeholder Design fails when it treats conflicts as communication problems. The real challenge is structural. Stakeholders have opposing success metrics, and the designer’s job is to design the decision-making process itself — not to find a compromise that satisfies no one.

What Is Multi-Stakeholder Design — and Why Isn’t Stakeholder Mapping Enough?

Definition: Multi-Stakeholder Design vs. Stakeholder Mapping vs. Stakeholder Management

The three terms are often used interchangeably. In practice, they describe fundamentally different activities:

Criterion	Stakeholder Mapping	Stakeholder Management	Multi-Stakeholder Design
Core question	Who is involved?	How do we keep everyone informed?	How do we design decisions when stakeholders have opposing goals?
Output	Influence/Interest matrix, stakeholder map	Communication plan, RACI matrix	Decision architecture, engagement journey, facilitation protocols
Assumption	Stakeholders can be categorized	Stakeholders can be managed	Stakeholders have structurally contradictory needs that must be designed for
Timing	Once at project start	Ongoing in project management	Ongoing as a design task across all project phases
Typical mistake	Created once and never updated	Confuses information with involvement	Not even recognized as a distinct task

R. Edward Freeman defined a stakeholder in 1984 as “a group or individual who can affect or is affected by the organization’s success” [3]. This definition revolutionized management thinking — but in Service Design it falls short. Service Design according to Birgit Mager (TH Köln, the world’s first professor of Service Design) “choreographs processes, technologies and interactions within complex systems in order to co-create value with relevant stakeholders” [4]. The verb “choreographs” is more precise than “manages” or “facilitates” — it implies a designed, sequenced coordination of multiple actors.

Multi-Stakeholder Design is the discipline that creates this choreography when the actors have different — sometimes contradictory — visions of the outcome.

Why “Understanding the User” Is Not Enough in B2B

Sanders and Stappers (2008) describe the shift from user-centered to co-creative design: the designer’s role changes from translator to facilitator, the researcher’s from specialist to connector, and “the person formerly known as the ‘user’” transforms from subject to partner [5]. But what happens when there isn’t “the user,” but five, ten, or thirteen — with contradictory definitions of success?

In B2B contexts, the person who uses a service is almost never the person who pays for it. And the person who pays for it is rarely the person who selects it. When you design a new customer portal for a bank, do you optimize for the end customer (wants simplicity), the relationship manager (wants retention), the compliance department (wants traceability), IT (wants maintainability), or the board (wants differentiation)? “For all of them simultaneously” is not an answer — it is the recipe for design by committee.

Stickdorn et al. (2018) formulate the co-creative principle: “Service design cannot be done for users — it always needs to be done with users, customers, and employees” [6]. That is true as an aspiration — but it becomes operationally naive when stakeholders refuse to work in the same room. Or when their success metrics are mutually exclusive.

We have written separate articles on the various user types in service design and their requirements for personas and prototypes. This article goes one step further: what do you do when you understand the user types — but their needs contradict each other?

The Buying Committee as a Design Challenge

5 Roles in B2B Purchasing — and Why Each Wants a Different “Good” Service

Webster and Wind developed the Buying Center model with five roles in 1972 [7]. In Service Design, each of these roles is an independent design objective:

Role	Function	What this role considers “good service”	Typical representative
Users	Use the service daily	Easy operation, quick completion, minimal friction	Case workers, specialists
Buyers	Formal contract responsibility	Best terms, standardized processes, comparability	Procurement department
Influencers	Provide information and criteria	Technical superiority, innovation potential, compliance	IT architects, subject-matter consultants
Deciders	Choose among alternatives	Strategic fit, risk mitigation, ROI	Executive management, division heads
Gatekeepers	Control information flow	Standards conformity, security, integration capability	IT security, compliance, legal department

The crucial point: these five roles evaluate the same service by different criteria. A claims management portal optimized for the user (fast processing) may be unacceptable to the gatekeeper (compliance documentation) — and vice versa. Multi-Stakeholder Design acknowledges that no optimization for a single role is sufficient. The task is to find a design that is functionally acceptable for every role — not maximally optimized for one.

The Numbers: 13 Stakeholders, 86% Stagnation, 74% Unhealthy Conflict

Research Insight: Forrester (2024, n=16,000+ buyers): An average B2B purchase involves 13 stakeholders. 89% of purchase decisions involve two or more departments. 86% of all B2B purchases stall during the process. 81% of buyers are dissatisfied with the chosen vendor [1].

These numbers turn Multi-Stakeholder Design from a methodological option into a business necessity.

Research Insight: Gartner (2025, n=632 buyers): 74% of buying groups demonstrate “unhealthy conflict” during the decision process. Groups that reach consensus report a high-quality deal 2.5 times more often [2].

These numbers come from sales research — but they describe a design problem. If 86% of B2B purchases stall, that is not a sales problem. It is a sign that the service (or the offering) is not designed so that 13 stakeholders can say yes simultaneously.

Three Structural Problems That Make Workshops Fail

Role Myopia: Everyone Sees Only Their Own Function

Flaig, Guyader, and Ottosson (2025) identified two specific barriers in their longitudinal study of a mobility service ecosystem: role myopia — stakeholders see only their own function — and role uncertainty — stakeholders are unclear about their systemic position [9]. Their DOSE framework (Design-Oriented Stakeholder Engagement) shows that stakeholders exhibit three degrees of reflexive capabilities: focused on the self-perceived role, on the current systemic role, and on the future systemic role.

In concrete terms: a telecom company designs a new self-service platform. The customer service director optimizes for call avoidance (their KPI). Marketing optimizes for upselling opportunities (their KPI). IT optimizes for maintainability (their KPI). Each is right — within their role. But no one designs for the customer experience as a whole, because everyone only sees their own function. That is role myopia, and it cannot be solved through better communication — it is a function of the organizational structure.

The HiPPO Problem: When the Highest-Ranking Person Dominates the Room

Farr (2018) investigated in two longitudinal case studies (hospital service design and municipal innovation) whether co-design processes can alter existing power dynamics. The result was sobering: while personal experiences improved (participants felt heard), “genuine equality of power difficult to achieve within uneven hierarchical structures” [10]. Structural changes remained small-scale, even though the personal impacts were positive.

What this looks like: when a division head expresses an opinion in a workshop, the team leads agree — not because they are convinced, but because the hierarchy dominates the room. Spark Market Research recommends as a countermeasure: “Bring in a 3rd-party facilitator who won’t pay much heed to interpersonal conflicts between departments, and whose outside viewpoint brings much-needed objectivity — not siding with any part of the business” [11]. But external facilitation is a workaround, not a structural solution. The structural solution lies in decision formats that exclude hierarchical dominance — such as the consent-based decision process from Holacracy (more on this in Section 6).

Design by Committee: Why “Everyone Gets a Say” Kills Innovation

Riddle and Treder (UXPin) put it bluntly: “Committee design is not collaborative. It’s a dictatorship of many, and you’ll be reduced to implementer rather than facilitator” [12]. Design by committee arises when multi-stakeholder involvement is organized without decision architecture: innovation gets diluted, scope creep replaces design decisions, and internal stakeholders crowd out the customer perspective [13][14].

Von Busch and Palmas (2022) go even further: “Designers tend to overemphasize the place of ideals in design, leaving them ill-equipped to deal with a social world of power-wielding and zero-sum games.” Their concept of “Realdesign” argues that co-design processes are “rife with betrayals, decay, and corruption” and that “designerly empathy has morphed into a new form of cunning statecraft” [15]. The problem is not a lack of empathy — it is a lack of realism about power.

Mapping Stakeholder Needs — Beyond the 2x2 Matrix

Power/Legitimacy/Urgency: The Mitchell-Agle-Wood Model

The classic Influence/Interest matrix (2x2 quadrant) is the most widely used stakeholder tool. It categorizes stakeholders along two axes: influence (high/low) and interest (high/low). For an initial orientation, it is useful. For Multi-Stakeholder Design, it is insufficient because it reduces two dimensions onto a complex reality.

Mitchell, Agle, and Wood (1997) developed a more differentiated model with three dimensions [16]:

• Power: Can the stakeholder deploy resources to impose their will?
• Legitimacy: Is the stakeholder’s claim recognized as justified?
• Urgency: How time-critical is the stakeholder’s demand?

The combination of these three dimensions produces seven stakeholder types [16]:

• Dormant: Only power, no legitimacy, no urgency — e.g., a board member who doesn’t know about the project but could stop it at any time
• Discretionary: Only legitimacy — e.g., end users who have a legitimate claim but neither power nor urgency
• Demanding: Only urgency — e.g., a complainant who is vocal but neither powerful nor legitimated
• Dominant: Power + legitimacy — e.g., the IT department that must implement and has a legitimate claim
• Dangerous: Power + urgency, but no legitimacy — e.g., a competitor exerting pressure
• Dependent: Legitimacy + urgency, but no power — e.g., customers with an urgent need but no influence on the decision
• Definitive: All three dimensions — these stakeholders MUST be included

For Service Design, the decisive advantage is: the model explains why certain stakeholders dominate and others are ignored, even though their claims are legitimate. Especially the “Dependent” stakeholders (legitimacy + urgency, but no power) are systematically overlooked in buying committees — even though they are often the actual users of the service.

Using the example of a new customer onboarding process for an industrial insurer:

Department	Power	Legitimacy	Urgency	Consequence
Compliance	High (can stop the project)	High (regulation)	Low (changes slowly)	Dominant — gets heard, but rarely actively blocks
Sales	Medium	High (customer proximity)	High (lost customers)	Dependent — legitimate and urgent, but without veto power. Systematically overlooked
IT	High (must implement)	Low (from the customer perspective)	High (release schedule)	Dangerous — can create facts on the ground without representing the customer perspective

The Mitchell-Agle-Wood model makes visible why sales is ignored in practice, even though it has both legitimacy AND urgency: it lacks the power to stop the project.

Dynamic Salience: Why Stakeholder Weight Shifts Across Project Phases

Lievens and Blazevic (2021) propose the concept of a “Stakeholder Engagement Journey”: a connection between service design phases and innovation process stages that makes explicit when which stakeholders should be included — and when they deliberately should not be [17]. Stakeholder salience is not static. It shifts over the course of the project.

Using the example of an insurance product: in the Discover phase, the customer perspective dominates (user research). In the Define phase, actuaries and compliance gain salience (feasibility, regulation). In the Develop phase, IT architects and process owners move to the foreground (implementability). And in the Deliver phase, sales determines the priorities (market readiness). Anyone who creates the stakeholder map once and never updates it is working with the wrong priorities in every phase.

The BMW i3/i8 project illustrates the breadth: BMW collaborated with urban planners, regulatory authorities, energy providers, universities, and research institutes — each group was relevant at different points and with different intensity [17]. A customer journey map for each individual stakeholder would be disproportionate — but an “engagement journey” across all stakeholders is the necessary complement to the classic stakeholder map.

Five Methods for Real Stakeholder Conflicts

The following five methods are not generic workshop techniques. Each addresses a specific structural problem when stakeholder needs conflict.

Method Navigator: Which Method for Which Problem?

Method	Structural problem	Group size	Timeframe	Facilitator competence
Consent decision-making	Decision blockade through consensus-seeking	5—15	60—90 min. per round	High (distinguishing objections from preferences)
Integrated co-design workshops	Groups too different for shared sessions	20—200+ (in subgroups)	Multiple workshops of 2—4 hrs.	Medium (group facilitation)
Dual-threshold voting	Dominance of large groups over small ones	20—50+ (in groups)	30—60 min. per voting round	Low (voting mechanics)
Conflict Sensitive Design	Stakeholders refuse joint participation	10—30 (in separate sessions)	2—3 hrs. per party + synthesis	High (mediation competence)
Engagement journey	Stakeholder relevance shifts across phases	Any	Project-accompanying (quarterly review)	Medium (project governance)

Use this overview as a starting point — in practice, you often combine multiple methods in the same project.

Consent-Based Decision-Making Instead of Consensus

When to use: When decisions fail due to consensus-seeking — everyone has a veto, no one moves.

What it is: Consent (from Sociocracy and Holacracy) shifts the question from “Does everyone agree?” to “Does anyone have a significant objection — a reason why this proposal would cause harm?” [18][19]. The range between personal preference and active objection — the so-called tolerance zone — is the space where most decisions live.

Protocol:

1. A concrete proposal is formulated (not “What do we want?” but “I propose that…”)
2. Clarifying questions — only questions for understanding, no opinions
3. Reaction round — each stakeholder shares their reaction, without discussion
4. Objection round — “Do you have a significant objection?” (Objections must be substantiated: What exactly would cause harm?)
5. Integration — every valid objection is integrated into the proposal, not voted down

Why it works: Consent eliminates the filibuster dynamic where a single stakeholder can block progress indefinitely. Objections must be based on the organizational role, not on personal preference [20]. (More detailed explanation in Section 6.)

What often happens in practice: A hierarchically senior stakeholder uses “objection” as veto power and justifies every objection with abstract “strategic risk.” Countermeasure: insist that objections must name a specific harm — “That contradicts our strategy” is not an objection; “That would lose our existing customers in segment X” is one.

From our governance practice: The biggest hurdle in the consent process is Step 4 — distinguishing between preference and objection. In our daily governance practice, we observe that roughly 80% of initial “objections” are actually preferences. What helps: before the workshop, hang a poster with the question “Would this proposal cause concrete harm — or would I simply prefer it differently?” This visual reminder reduces pseudo-objections immediately.

Integrated Co-Design Workshops: Groups React to Each Other’s Results

When to use: When stakeholder groups are too different to work productively in the same room, but their perspectives still need to be integrated.

What it is: Kerr et al. (2022) developed the “Integrated Co-Design” model in the inclusionED project (Australia), where teachers, special educators, students on the autism spectrum, parents, and education policymakers jointly designed a learning platform — over 200 stakeholders in nine initial co-design workshops with four different groups [21].

Protocol:

1. Each stakeholder group works separately in their own workshops
2. The results of one group are presented to the other groups
3. Each group responds creatively to the other groups’ results (e.g., education policymakers respond to workshop results from students)
4. Synthesis is performed by the design team, not through a joint compromise workshop
5. Blended formats (on-site + online) enable participation from groups that cannot be physically present

Why it works: The method preserves the authentic voice of each group while creating a structured dialogue between groups — without the power dynamics of a shared room. The result: the inclusionED platform combines results from over 25 research projects across 300+ Australian schools [21].

What often happens in practice: Group A rejects Group B’s results entirely because the context is missing. Countermeasure: never present results as finished proposals, but as “perspectives that your group should respond to.” Framing it as a call for response rather than an evaluation task prevents reflexive rejection.

Dual-Threshold Voting: >50% of Individuals AND >50% of Groups

When to use: When decisions need to be democratically legitimated without a numerically large stakeholder group dominating the smaller ones.

What it is: Daly-Smith et al. (2020) documented the first case in which practitioners, policymakers, and researchers jointly co-designed a framework from inception. 50 stakeholders in 9 groups (British researchers, public health specialists, school principals, teachers, Sport England representatives, and others) [22].

Protocol:

1. Proposals are developed and presented to all stakeholder groups
2. Each change is only accepted if >50% of all individuals AND >50% of all stakeholder groups (at least five of nine) vote in favor
3. If a proposal does not reach the dual threshold, the design team must develop an alternative solution
4. Rejected proposals are not simply discarded — they force creative reformulation

Why it works: The dual-threshold principle prevents two problems simultaneously: it stops the dominance of a numerically large group (researchers cannot outvote practitioners), and it simultaneously requires broad support across all groups. Of 8 proposed changes to the CAS framework, 6 were accepted and 2 were rejected — for the rejected ones, an alternative presentation was developed that passed the dual threshold [22].

What often happens in practice: A numerically small stakeholder group (e.g., 3 people) feels structurally disadvantaged by the group threshold compared to a large group (e.g., 15 people). Countermeasure: communicate beforehand that the group threshold solves precisely this problem — every group counts equally, regardless of its size.

Conflict Sensitive Design: Separate Sessions with Synthesis

When to use: When stakeholders refuse to sit at the same table — or when joint sessions are so distorted by power imbalances that honest input becomes impossible.

What it is: Ogunyemi et al. (2025) developed Conflict Sensitive Design (CSD) for designing community policing technology in Nigeria, where citizens and police refused to participate in joint sessions — out of fear and distrust [23]. The method adapts mediation techniques for the design process.

Protocol:

1. Tension reduction: Separate preliminary conversations with each party
2. Leveling: Ensuring that each group receives equivalent resources and attention
3. Common ground reminder: Explicitly naming shared interests as a starting point
4. Separate sessions: Each group develops their design requirements separately
5. Formalized agreements: The design team synthesizes the results and formalizes compromises

Why it is relevant for B2B: The extreme case of Nigeria’s police illuminates an everyday enterprise problem: when sales and operations have adversarial dynamics, when management and frontline distrust each other, when IT and the business unit inhabit different worlds — then separate sessions with professional synthesis are not the second-best solution. They are the only one that enables honest input.

What often happens in practice: One party refuses to participate in separate sessions because they fear the other party will “go behind their back” to influence the outcome. Countermeasure: transparency about the synthesis process — both parties receive a description in advance of how the results will be merged, and have the opportunity to comment on the synthesis before it is finalized.

Stakeholder Engagement Journey: When to Include — and When Deliberately Not

When to use: For projects that span multiple months and where the relevant stakeholders change across phases.

What it is: Lievens and Blazevic (2021) propose using Service Design as a “trigger” to develop activities that deliberately engage and disengage stakeholders — “(dis)engage” — across the entire B2B innovation process [17].

Protocol:

1. Identify all stakeholders across the entire project cycle (not just the current ones)
2. Assign each stakeholder to the phases where their salience is highest
3. Define for each phase: Who is actively included? Who is informed? Who is deliberately not included?
4. Plan the transitions: How do you bring a stakeholder into the project who was irrelevant in Phase 1 but becomes decisive in Phase 3?
5. Document the decision: Why is a stakeholder not included in a particular phase?

The service blueprint is the natural tool for making the backstage orchestration of this engagement journey visible: what internal processes and handoffs stand behind the stakeholder transitions?

What often happens in practice: Stakeholders who were deliberately not included in Phase 1 feel overlooked in Phase 3 and block the project. Countermeasure: document and communicate the engagement journey explicitly to all stakeholders — including those who only become active in later phases. The message “You are scheduled for Phase 3, because that is where your expertise matters most” is something entirely different from “You were not invited.”

Jonas, Roth, and Möslein (2016) found in their study of German Mittelstand companies that there are 35+ methods for stakeholder integration — but almost all are used only for internal stakeholders. External stakeholders, especially customers, are only consulted at the beginning (interviews) and tested at the end (pilot project). The entire middle section — where the actual design decisions are made — remains internal [24]. The engagement journey closes this gap by making explicit when external stakeholders must actively co-create — not merely be informed.

Integrative Decision-Making from Holacracy

The following formats originate from Holacracy — an organizational model that we at SI Labs practice daily. What works as internal governance can be directly transferred to multi-stakeholder design workshops. In the following sections, we share what we have learned — including the points where the transfer is more difficult than expected.

From Consensus to Consent: “Do You Have a Significant Objection?”

We introduced the basic mechanics of consent vs. consensus in Section 5. Here, the focus is on the Holacratic framing — and why it makes a crucial difference:

Criterion	Consensus	Consent
Guiding question	”Does everyone agree?"	"Does anyone have a significant objection?”
Threshold	Everyone must agree	No objection may remain unintegrated
What blocks	Any non-agreement	Only substantiated objections that demonstrate harm
Typical outcome	Lowest common denominator	”Good enough for now, safe enough to try”
Risk	Unambitious compromises	Requires facilitator competence to distinguish objections from preferences

In Holacracy, consent is not just a voting method — it is a governance principle [18][19][20]. The critical difference from a mere workshop tool: objections must be based on the organizational role, not on personal preference. For multi-stakeholder design workshops, this means: every objection must answer the question “What specific harm would arise for my role in the system?” — not “I would prefer it differently.”

Tactical Meetings as a Design Review Format

The Holacracy tactical meeting is a lean format for operational alignment: check-in, checklists, metrics, project progress, triage of open items, check-out. It typically takes 30-60 minutes and follows a strict sequence that prevents individual topics from dominating the entire time.

For multi-stakeholder design reviews, this format is directly transferable — a transfer we derive from our internal governance practice:

1. Check-in: Each stakeholder describes their current state regarding the project in one sentence
2. Checklist: Recurring questions are answered with yes/no, not discussed
3. Metrics: Relevant KPIs are reported, not interpreted
4. Triage: Open design questions are prioritized, not solved — each question gets a next step and a responsible person
5. Check-out: One sentence reflecting on the meeting itself

From our governance practice: Transferring from an internal governance meeting to an external design review requires three adjustments: (1) The checklist must be agreed upon with the stakeholders beforehand — internally everyone knows the recurring questions, externally they don’t. (2) Triage only works if the facilitator consistently stays with “next step + responsible person” — external stakeholders tend to want to resolve triage items immediately. (3) Check-out is the underestimated element: a reflection question like “What surprised you in this meeting?” often yields the most valuable hints about blind spots.

IBM’s Enterprise Design Thinking uses a related principle: “Playbacks” are structured alignment meetings at the end of each design phase. Draft playbacks (“Playback -2”, “Playback -1”) are held before the actual milestone playback to iteratively work toward alignment before commitments are made [25]. The principle is the same: structured, time-boxed formats prevent the endless discussions that make multi-stakeholder meetings unproductive.

Role-Based Rather Than Person-Based Stakeholder Identification

A common mistake in Multi-Stakeholder Design: stakeholders are identified as individuals (“Mr. Mueller from IT,” “Ms. Schmidt from procurement”). The problem: when Mr. Mueller falls ill or changes roles, the stakeholder map collapses.

Holacracy solves this problem by consistently distinguishing between roles and people. A role is a bundle of purpose, domains (areas of authority), and accountabilities (responsibilities). One person can fill multiple roles; one role can be carried by multiple people.

For Multi-Stakeholder Design, this means: don’t identify “the 13 individuals on the buying committee,” but the 5-7 roles that must be represented in the decision process. If one person drops out, the role remains filled — and the stakeholder map stays intact.

From our governance practice: Role-based identification often collides with German corporate culture, where “Mr. Mueller from IT” is a person, not a role. The shift to role-based thinking requires explicit framing at the start of the workshop: “Today we are talking about the role of IT Security, not about Mr. Mueller. What responsibilities does this role have — regardless of who currently fills it?” This simple sentence changes the dynamic of the entire workshop.

Reypens, Lievens, and Blazevic (2021) observed in the European Medical Information Framework (EMIF) — a pharma innovation network with 57 partners from 14 countries — that effective orchestrators practice hybrid orchestration: they dynamically switch between dominant modes (when speed or IP protection is needed) and consensus-based modes (when buy-in and legitimacy are required) [26]. The ability to situationally switch the facilitation mode requires role-based thinking: what does the role of the orchestrator need in this moment?

When You Should NOT Include All Stakeholders

Tokenistic Participation Causes More Harm Than No Participation

Not every stakeholder should be involved at every point in the process. Research identifies at least three scenarios where stakeholder participation actively causes harm:

1. Tokenistic participation: Inviting stakeholders whose input is never truly considered “may be worse than not involving stakeholders at all, as it creates false expectations and erodes trust” [27].

2. Decisions are made elsewhere anyway: “Decision-making always reverted to the design teams or proxies. Even though designers prioritized users’ ideas, it was the designers who determined project outcomes” [28]. When stakeholders realize their participation has no effect, not only does their engagement drop — their trust in the entire process erodes.

3. Privileging availability over relevance: “Confining participation only to a select few who can participate intensively runs the danger of over-privileging those social groups” [29]. Who can attend an all-day workshop? Not the technician on the construction site, not the case worker on shift duty — but management and staff functions. The voices easiest to integrate are not always the most relevant.

collaboratio helvetica, a Swiss multi-stakeholder facilitation organization, recommends as a minimum standard: two trained facilitators for multi-stakeholder workshops who explicitly watch for which voices are missing — not just which are present [30].

Group Beats Individual: Why Individual Relevance Reduces Group Consensus by 59%

Research Insight: Gartner (2025): Content tailored to individual relevance reduces group consensus by 59%. Content tailored to group relevance increases consensus by 20%. Buyers who experience group relevance report a high-quality deal 3 times more often [2].

This finding inverts the standard UX instinct: in multi-stakeholder contexts, optimizing for individual satisfaction harms group agreement. When you give each stakeholder individually what they want, you create 13 personalized perspectives that no longer share any common ground.

The consequence for Multi-Stakeholder Design: the unit of design is not the individual stakeholder — it is the group dynamic. Teams that try to make every stakeholder individually happy produce solutions for which no stakeholder feels collectively responsible. The Gartner data empirically confirm this finding (see Research Insight above).

Common Mistakes in Multi-Stakeholder Design

Mistake 1: Creating the Stakeholder Map Once and Never Updating It

Why it happens: The stakeholder analysis is treated as a project kickoff ritual — a mandatory document that disappears into the project folder.

What goes wrong: Gartner’s data show that buying committees change their composition across procurement phases [2]. The CFO is present for the strategic decision but not for detailed negotiations. New stakeholders emerge when the project affects their department. Anyone working with the stakeholder map from Month 1 in Month 6 is optimizing for the wrong people.

What to do instead: Review stakeholder maps quarterly. At every phase transition (Discover -> Define -> Develop -> Deliver), explicitly ask: Which stakeholders have gained salience? Which have lost salience? Who has newly joined?

Mistake 2: Treating Conflicts as Communication Problems

Why it happens: The facilitation literature emphasizes “active listening,” “empathy,” and “finding common language” — techniques that help with misunderstandings. But many stakeholder conflicts are not misunderstandings.

What goes wrong: When procurement wants cost reduction and the business unit wants quality improvement, they understand each other perfectly. They have a structural conflict of interest, not a communicative one. More empathy changes nothing about that.

What to do instead: Understand the conflict as a design task. The question is not “How do we get procurement and the business unit to understand each other?” but “How do we design a decision architecture that transparently weighs both interests — and makes explicit which trade-offs are accepted?”

Mistake 3: Engaging External Stakeholders Only Passively

Why it happens: Jonas, Roth, and Möslein (2016) documented the pattern empirically: German Mittelstand companies conceptualize stakeholder integration on a continuum from passive (inform), reactive (seek feedback), mutual (co-create), to pro-active (stakeholder-initiated). Higher integration modes (mutual, pro-active) occur almost exclusively with internal stakeholders [24].

What goes wrong: External stakeholders — especially customers — are consulted at the beginning (interviews) and tested at the end (pilot). The entire middle section of the design process, where the actual decisions are made, remains an internal process. The result: the service is optimized for internal logic, not for the customer.

What to do instead: Include at least one external stakeholder in the Develop phase as an active co-creator — not as a test subject, but as a co-designer. IBM’s “Sponsor Users” are a proven format: real users who are permanently embedded in design teams and provide continuous feedback [25].

Mistake 4: Treating the Facilitator as Neutral

Why it happens: The facilitation orthodoxy regards the moderator as a neutral entity who steers the process without influencing the outcome.

What goes wrong: Goodwin (2009) describes the designer as “translator, arbitrator, and negotiator of consensus among the many stakeholders” [31]. Arbitrator and negotiator are not neutral roles. Farr (2018) found that even in dedicated co-design processes, decision-making power ultimately remained with the designers [10]. The facilitator constantly makes micro-decisions: who gets to speak for how long? Which ideas make it onto the whiteboard? Which get “parked”? These decisions are not neutral — they shape the outcome.

What to do instead: Don’t declare the facilitator as neutral, but make their design power transparent. Explicitly state: “My role is to ensure that the end-user perspective is not steamrolled by the decision-maker perspective. That is not a neutral position — it is a deliberate design decision.”

FAQ — Frequently Asked Questions

How many stakeholders should I invite to a workshop at most?

There is no fixed upper limit, but research provides guidance: Daly-Smith et al. worked successfully with 50 stakeholders in 9 groups [22], Kerr et al. with over 200 stakeholders in 4 groups [21]. The key is not the absolute number but the structure: work in homogeneous stakeholder groups and synthesize the results, rather than putting everyone in one room. collaboratio helvetica recommends two facilitators as a minimum [30].

How do I deal with a stakeholder who dominates the process?

The HiPPO problem (Highest Paid Person’s Opinion) is structural, not personal. Three countermeasures: (1) Collect written individual contributions before group discussion — this prevents anchoring effects [11]. (2) Consent-based decision-making instead of consensus — objections must be substantiated, opinions need not be [18][19]. (3) External facilitation that consciously addresses hierarchical dynamics [11].

Does Multi-Stakeholder Design also work for internal services (not B2B)?

Yes. The buying committee is the B2B-specific trigger, but the structural problems (role myopia, HiPPO, design by committee) occur with any service that affects multiple departments. When you design an internal HR portal, you face the same conflicts: HR wants self-service, IT wants standardization, the works council wants data protection, management wants cost reduction.

When should I deliberately exclude stakeholders?

Three criteria: (1) When their participation would be tokenistic — you cannot or will not consider their input [27]. (2) When their presence prevents other stakeholders from speaking honestly (power imbalance) — then use Conflict Sensitive Design with separate sessions [23]. (3) When their salience in the current phase is low — schedule them for a later phase [17].

Methodology & Source Attribution

This article is based on a systematic evaluation of 30 directly cited sources: 10 academic studies (peer-reviewed), 7 books, 2 industry reports (Forrester n=16,000+, Gartner n=632), and 11 practitioner and contextual sources. All DOIs and URLs were verified before inclusion. The SERP analysis covered 10 competitor articles in German and English.

Practice assessments that go beyond the cited sources are based on operational experience with Holacratic governance formats, which we disclose in the introduction to Section 6.

Limitations: The Forrester and Gartner statistics refer to global B2B purchases; DACH-specific deviations are possible. We have been using Holacratic facilitation formats internally since 2017; their systematic application in external service design workshops has neither been documented in peer-reviewed studies nor have we published our own efficacy data. Jonas et al. (2016) studied three Mittelstand companies — generalizability to the entire Mittelstand is limited.

Disclosure

SI Labs advises companies on designing services. We have a commercial interest in the methods described in this article. In Section 6, we disclosed and marked our experiences with Holacratic governance formats. Beyond that, we have endeavored to base all recommendations on published sources and to honestly name the limitations of these approaches (see “When You Should NOT Include All Stakeholders” and “Common Mistakes”).

References

[1] Forrester. The State of Business Buying, 2024. Forrester Research, 2024. n=16,000+ global B2B buyers. URL: https://www.forrester.com/press-newsroom/forrester-the-state-of-business-buying-2024/ [Industry Report | n=16,000+ | Quality: High]

[2] Gartner. “74% of B2B Buyer Teams Demonstrate ‘Unhealthy Conflict’ During the Decision Process.” Gartner Press Release, May 7, 2025. n=632 B2B buyers (Aug-Sep 2024). URL: https://www.gartner.com/en/newsroom/press-releases/2025-05-07-gartner-sales-survey-finds-74-percent-of-b2b-buyer-teams-demonstrate-unhealthy-conflict-during-the-decision-process [Industry Report | n=632 | Quality: High]

[3] Freeman, R. Edward. Strategic Management: A Stakeholder Approach. Boston, MA: Pitman, 1984. [Book | Foundational — coined “stakeholder” concept | Quality: High]

[4] Mager, Birgit. “Service Design.” Service Design Network, 2012. URL: https://www.service-design-network.org/about-service-design [Expert Source | First SD Professor worldwide (1995), TH Köln (KISD) | Quality: High]

[5] Sanders, Elizabeth B.-N. and Pieter Jan Stappers. “Co-creation and the New Landscapes of Design.” CoDesign: International Journal of CoCreation in Design and the Arts 4, No. 1 (2008): 5—18. DOI: 10.1080/15710880701875068 [Academic Article | Citations: 24,500+ | Quality: High]

[6] Stickdorn, Marc, Markus Edgar Hormess, Adam Lawrence, and Jakob Schneider. This Is Service Design Doing: Applying Service Design Thinking in the Real World. O’Reilly Media, 2018. ISBN: 978-1491927182. [Practitioner Book | 54 Methods | Quality: High]

[7] Webster, Frederick E. and Yoram Wind. “A General Model for Understanding Organizational Buying Behavior.” Journal of Marketing 36, No. 2 (1972): 12—19. DOI: 10.1177/002224297203600204 [Academic Article | Foundational — Buying Center model | Quality: High]

[9] Flaig, Alexander, Hugo Guyader, and Mikael Ottosson. “Design-Oriented Stakeholder Engagement in Service Ecosystems.” Journal of Business Research 191 (2025): Article 115255. DOI: 10.1016/j.jbusres.2025.115255 [Academic Article | Open Access (CC BY 4.0) | Quality: High]

[10] Farr, Michelle. “Power Dynamics and Collaborative Mechanisms in Co-production and Co-design Processes.” Critical Social Policy 38, No. 4 (2018): 623—644. DOI: 10.1177/0261018317747444 [Academic Article | Longitudinal qualitative study | Quality: High]

[11] Spark Market Research. “Raising the Bar in Stakeholder Workshops.” Spark MR Blog. URL: https://sparkmr.com/raising-the-bar-in-stakeholder-workshops/ [Practitioner Source | Quality: Medium]

[12] Riddle, Ryan Thomas and Marcin Treder. “Design by Committee.” UXPin, cited via ProductPlan. URL: https://www.productplan.com/learn/how-to-avoid-design-by-committee/ [Practitioner Source | Quality: Medium]

[13] InnerView. “Design by Committee: Why It Fails and How to Avoid It.” URL: https://innerview.co/blog/design-by-committee-why-it-fails-and-how-to-avoid-it [Practitioner Source | Quality: Medium]

[14] LogRocket UX Blog. “Design by Committee Failure.” URL: https://blog.logrocket.com/ux-design/design-by-committee-failure/ [Practitioner Source | Quality: Medium]

[15] Von Busch, Otto and Karl Palmas. The Corruption of Co-Design: Political and Social Conflicts in Participatory Design Thinking. London: Routledge, 2022. ISBN: 978-1032250014. [Academic Book | Contrarian/Critical source | Quality: High]

[16] Mitchell, Ronald K., Bradley R. Agle, and Donna J. Wood. “Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts.” Academy of Management Review 22, No. 4 (1997): 853—886. DOI: 10.5465/amr.1997.9711022105 [Academic Article | Foundational — Stakeholder salience theory | Quality: High]

[17] Lievens, Annouk and Vera Blazevic. “A Service Design Perspective on the Stakeholder Engagement Journey during B2B Innovation: Challenges and Future Research Agenda.” Industrial Marketing Management 95 (2021): 128—141. DOI: 10.1016/j.indmarman.2021.04.007 [Academic Article | B2B-specific | Quality: High]

[18] Sociocracy For All. “Consent Decision Making.” URL: https://www.sociocracyforall.org/consent-decision-making/ [Practitioner Source | Quality: Medium]

[19] Sociocracy 3.0. “Consent Decision-Making Pattern.” URL: https://patterns.sociocracy30.org/consent-decision-making.html [Practitioner Source | Quality: Medium]

[20] Holacracy.org. “Values Integration via the Integrative Decision-Making Process.” URL: https://www.holacracy.org/blog/values-integration-via-the-integrative-decision-making-process/ [Practitioner Source | Quality: Medium]

[21] Kerr, Jemma, Megan Whelan, Oksana Zelenko, Karen Harper-Hill, and Catherine Villalba. “Integrated Co-design: A Model for Co-designing with Multiple Stakeholder Groups from the ‘Fuzzy’ Front-End to beyond Project Delivery.” International Journal of Design 16, No. 2 (2022): 75—90. DOI: 10.57698/v16i2.06 [Academic Article | Open Access | Quality: High]

[22] Daly-Smith, Andy, Thomas Quarmby, Victoria S. J. Archbold et al. “Using a Multi-stakeholder Experience-based Design Process to Co-develop the Creating Active Schools Framework.” International Journal of Behavioral Nutrition and Physical Activity 17 (2020): 13. DOI: 10.1186/s12966-020-0917-z [Academic Article | Open Access | n=50 Stakeholders, 9 Groups | Quality: High]

[23] Ogunyemi, Abiodun et al. “How Should We Design Technology with Diverse Stakeholders Who Wish Not to Attend Design Activities Together?” In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems. ACM, 2025. DOI: 10.1145/3706598.3714168 [Academic Article | CHI 2025 | Quality: High]

[24] Jonas, Julia M., Angela Roth, and Kathrin M. Möslein. “Stakeholder Integration for Service Innovation in German Medium-Sized Enterprises.” Service Science 8, No. 3 (2016): 320—332. DOI: 10.1287/serv.2016.0152 [Academic Article | DACH-specific | Quality: High]

[25] IBM. “Enterprise Design Thinking Framework.” URL: https://www.ibm.com/design/approach/design-thinking/ [Practitioner Source | Enterprise-scale | Quality: High]

[26] Reypens, Charlotte, Annouk Lievens, and Vera Blazevic. “Hybrid Orchestration in Multi-stakeholder Innovation Networks: Practices of Mobilizing Multiple, Diverse Stakeholders across Organizational Boundaries.” Organization Studies 42, No. 1 (2021): 61—83. DOI: 10.1177/0170840619868268 [Academic Article | EMIF case study, 57 partners, 14 countries | Quality: High]

[27] Johansson, Stefan, Per-Olof Hedvall, Mia Larsdotter, Thomas P. Larsson, and Catharina Gustavsson. “Co-Designing with Extreme Users: A Framework for User Participation in Design Processes.” Scandinavian Journal of Disability Research 25, No. 1 (2023): 418—430. DOI: 10.16993/sjdr.952 [Academic Article | Open Access | Quality: High]

[28] Hodson, Elise, Annukka Svanda, and Nastaran Dadashi. “Whom Do We Include and When? Participatory Design with Vulnerable Groups.” CoDesign 19, No. 4 (2023): 269—286. DOI: 10.1080/15710882.2022.2160464 [Academic Article | Quality: High]

[29] Hyysalo, Sampsa and Tomás Dorta. “Design Participation and Codesign: New Forms, Application Domains, and Representational Systems.” Designing 1, No. 1 (2025): 24—31. DOI: 10.1177/30497671251392167 [Academic Article | Quality: High]

[30] collaboratio helvetica. “Multi-Stakeholder Workshops.” Blog, July 27, 2021. URL: https://collaboratiohelvetica.ch/en/blog/27/07/2021/multi-stakeholder-workshops-bxxrz [Practitioner Source | DACH | Quality: Medium]

[31] Goodwin, Kim. Designing for the Digital Age: How to Create Human-Centered Products and Services. Wiley, 2009. ISBN: 978-0470229101. 740 pages. [Practitioner Book | Enterprise design | Quality: High]