The one-on-ones produce raw material. Each interview generates a perspective: one stakeholder’s view of the initiative’s priorities, risks, constraints, and organizational dynamics. Twelve interviews produce twelve perspectives. The Stakeholder Map requires something different. It requires a single organizational narrative that synthesizes those twelve perspectives into a picture the architecture team can use. The gap between interview notes and organizational narrative is where most Stakeholder Maps lose their value. Teams that conduct thorough interviews but skip rigorous synthesis end up with a collection of individual viewpoints rather than an integrated assessment. The architecture team receives volume without clarity. This article describes the synthesis techniques that turn raw interview data into the narrative layer of the Stakeholder Map. It is written for leaders whose teams have conducted the interviews and now need to extract the organizational story that shapes program design.
The Three Layers of Synthesis
Synthesis operates on three layers, each producing a different type of insight. The mistake most teams make is stopping at the first layer. Layer 1: Convergence and divergence. This is the pattern-matching layer. Which themes appear across multiple interviews? Where do stakeholders agree, and where do they disagree? Convergence identifies shared ground. Divergence identifies fault lines. Most teams can produce this layer because it requires comparison, not interpretation. Layer 2: Invisible structure. This layer asks: what organizational dynamics explain the patterns from Layer 1? If three stakeholders in different functions all express concern about the same timeline, what structural reality produces that shared concern? If two stakeholders define success in fundamentally different ways, what organizational incentive or historical experience drives the difference? Layer 2 moves from what stakeholders said to why they said it. Layer 3: Implications for program design. This layer translates the organizational dynamics from Layer 2 into architectural decisions. If the dominant pattern is fragmented authority across three functions, the architecture needs explicit governance for cross-functional decisions. If the dominant pattern is a conflict between two definitions of success, the program needs a prioritization mechanism before roadmap sessions begin. Layer 3 is where synthesis becomes actionable. Making the invisible visible describes why the invisible structure layer is where consulting engagements create the most value. Organizations already know what their stakeholders say. They rarely know what the pattern across all stakeholders reveals about organizational dynamics.
The Synthesis Process
The process follows a sequence that builds each layer on the one below it.
Step 1: Extract structured findings from each interview
For each interview, we extract four categories of findings: stated priorities (what this stakeholder wants the program to achieve); stated concerns (what they worry will go wrong); constraints held (what limitations they carry that the program may not know about); and success criteria (how they will personally judge whether the program succeeded). The extraction discipline matters. We capture what the stakeholder actually said, not what we interpreted. Direct quotes, where available, anchor each finding. The goal at this step is fidelity to the source material, not interpretation.
Step 2: Build the convergence/divergence map
With structured findings from all interviews, the consultants lay them side by side. Priorities that appear in three or more interviews become convergence themes. Priorities that appear in only one interview, or that contradict other stakeholders’ priorities, become divergence items. The same mapping applies to concerns, constraints, and success criteria. The output is a map that shows: what the organization broadly agrees on; what it broadly disagrees on; and what is held by individual stakeholders but invisible to the rest. This map is Layer 1 of the Perspective Map. It is necessary but not sufficient.
Step 3: Identify the structural explanations
For each significant divergence or invisible constraint, the consultants ask: what organizational structure, incentive, or history explains this? A VP of Operations who defines success as “minimal disruption to current processes” while a VP of Technology defines success as “full platform migration by Q3” is not a personality conflict. It is a structural conflict between operational continuity and technical modernization, driven by different performance metrics and different planning horizons. The structural explanation transforms the divergence from a problem to be managed into a design constraint to be addressed. The architecture does not need to resolve the conflict between these two VPs. It needs to design governance that acknowledges both definitions of success and creates a mechanism for prioritization when they conflict. Programs that failed with good plans documents cases where structural conflicts were visible in interview data but were not translated into architectural decisions. The programs proceeded with plans that assumed alignment that did not exist.
Step 4: Write the narrative takeaway
The narrative takeaway is the capstone of the synthesis. It is a concise statement (typically two to four paragraphs) that names: the dominant organizational pattern revealed by the interviews; the highest-risk dynamics for program execution; and the specific implications for architecture design. The quality bar for the narrative takeaway: a senior leader who did not attend any of the interviews can read the takeaway and understand the organizational terrain the program must navigate. If the takeaway requires context from the individual interviews to be meaningful, the synthesis has not gone far enough. A strong narrative takeaway names the pattern explicitly. “The organization is aligned on the need for transformation but divided on the pace of change, with operations-facing functions prioritizing continuity and technology-facing functions prioritizing speed. This division will identify during roadmap sessions unless governance includes a mechanism for pace-of-change decisions.” That statement gives the architecture team a design constraint they can act on. Stakeholder mapping beyond the org chart explains why the organizational narrative, not the individual interview notes, is what feeds architecture sessions.
Common Synthesis Failures
Three patterns produce synthesis that falls short of the quality bar. The summary trap. The team summarizes each interview and presents the summaries as the synthesis. This produces Layer 0, not even Layer 1. Summaries preserve individual perspectives. They do not identify patterns across perspectives. The consensus trap. The team identifies convergence themes and reports them as the synthesis, ignoring divergence. This produces a comfortable but incomplete picture. The architecture team designs for the areas of agreement and is blindsided by the areas of disagreement during execution. The abstraction trap. The team identifies the right patterns but writes the narrative takeaway at such a high level of abstraction that it is not actionable. “Stakeholders have different perspectives on the initiative” is true of every program. It tells the architecture team nothing they can use. The antidote to all three traps is specificity. Name the specific divergences. Name the specific structural explanations. Name the specific implications for program design. The narrative takeaway that changes architectural decisions is always specific.
How the Narrative Feeds Architecture
The Stakeholder Map’s narrative takeaway is a direct input to the Architecture Blueprint. Specifically, it feeds three architectural decisions: Governance design. The organizational dynamics identified in the narrative determine what governance structures are needed. If the dominant pattern is fragmented authority, governance needs explicit decision-rights allocation. If the dominant pattern is conflicting success criteria, governance needs a prioritization mechanism. Workstream boundaries. Dependencies and constraints identified through synthesis influence where workstream boundaries are drawn. A cross-functional dependency that the narrative identifies as high-risk may require workstream boundaries that keep the dependent functions within the same workstream rather than separating them. Risk register seeding. Organizational landmines and invisible constraints from the synthesis feed directly into the pre-mortem and risk register in Beat 4. The narrative identifies organizational risks that technical risk assessments will not reveal. The question is whether your stakeholder synthesis produces an organizational narrative the architecture team can act on: or whether it produces a set of interview summaries that confirm what everyone already assumed.
Go Deeper: The Stakeholder Map
This article covers one dimension of the Stakeholder Map, the second of nine artifacts in the Planning & Roadmapping method. The Stakeholder Map answers the board question: “Who sees what?” Explore the full Stakeholder Map →
Keep Reading
Explore the foundations and common gaps: