Assumption Mapping

Purpose

Assumption Mapping is a foundational diagnostic method from systems thinking and agile product development. It makes the often enormous gap between facts and wishful thinking in software architecture visible. Instead of launching major system interventions, such as a cloud migration, on gut feeling alone, it forces the team to break every part of the plan into falsifiable hypotheses. It measures the ice on which the architecture is standing.

Context of Use

This method is the tool of choice before any major architectural or organizational bet. When a team decides, "We will break up the monolith into 200 microservices and then we will develop twice as fast," that is not a fact. It is a massive bundle of toxic assumptions.

Step by Step

The mapping is typically done on a 2x2 quadrant whiteboard:

X-axis (Evidence): From "We have absolutely no data for this" to "We have solid metrics."

Y-axis (Risk/Impact): From "It does not matter much if we are wrong" to "The company burns down if this assumption is false."

1.Collect: Everyone on the team writes down assumptions about the new system on sticky notes. Examples: "Kafka will not worsen our latency" or "Developers are willing to do 24/7 on-call."

2.Map: Place the sticky notes honestly in the quadrant.

3.Focus: Declare the top-left quadrant, high risk with no evidence, the death zone of leap-of-faith assumptions.

4.Test: Do not write production code until those highly risky assumptions have been tested through cheap prototypes or spikes.

Example

A platform team is building an expensive internal developer portal based on Backstage. Their assumption is: "If we build it, the feature teams will use it immediately." In the diagnostic session, that sticky note lands in the high-risk, no-evidence zone. Before they invest six months of engineering time, they run a test: they build a simple CLI mockup in an afternoon and email it to three feature teams. Nobody responds. The assumption collapses before a million euros in salary cost are burned.

Diagram

How Diagnosis Turns into Action

One of the strongest cognitive biases in IT is confirmation bias. Developers and architects fall in love with a pattern and then look only for evidence that it will work. Assumption Mapping demands radical intellectual honesty. A senior architect must be able to say openly to the team: "The claim that event sourcing will solve our consistency problem is physically unproven and pure gambling."

When This Method Fits Best

Unlike System Dynamics Modeling, which simulates overall technical behavior over time, Assumption Mapping is lightweight, strongly psychological, and explicitly focused on the fracture points where the developers' mental model diverges from reality.

How to Use the Diagnosis in Everyday Work

As a principal architect, reject any big-bang pitch document that does not contain a section called "Our Critical Assumptions." An architecture document without explicitly flagged uncertainty is a fairy tale. Do not let people say, "Our users want this," in meetings. Ask back immediately: "Where is that on our assumption board, and what metric proves it?"

First Analysis Steps

When mapping, separate assumptions into three strict categories: desirability, viability, and feasibility. Does the developer even want the tool? Can we afford the AWS cost? Do we actually have the technical capability to build it?

How You Recognize a Useful Diagnosis

For the largest current architecture initiative, such as a service-mesh rollout, has the sprint plan reserved a dedicated spike that validates exactly the single riskiest networking-latency assumption before feature code is written?

Sources

David Bland & Alex Osterwalder — Testing Business Ideas (Wiley, 2019)

The Systems Thinker: Making Assumptions Explicit

Barry O'Reilly — Assumption Mapping (Blog)