Magnus Hedemark
3f03c6e327
Covers stakeholder mapping, question patterns, gap detection, conflict resolution, transcript-to-spec distillation, AI-conducted discovery, power dynamics, and time-constrained discovery. Ships 8 references and 5 templates.
3.8 KiB
Conflict Resolution for Incompatible Requirements
The Core Insight
Requirements conflicts are almost never about what they appear to be about. A surface-level disagreement is almost always a proxy for unstated differences in assumptions, risk tolerance, incentives, or values.
Foundational reframe: Treat requirements as hypotheses about what will solve the real problem. Conflicting requirements are competing hypotheses. The goal is not to pick the winner — it's to identify which assumptions differ and test those.
The Conflict Spectrum
| Type | Definition | Resolution |
|---|---|---|
| Preference conflict | Taste, style, opinion | Test it — let data decide |
| Value conflict | Principles, risk tolerance, what matters | Must be named and addressed explicitly |
| Incentive conflict | Incompatible metrics | Restructure incentives or make trade-offs explicit |
| Risk conflict | Different risk tolerances | Map the risk portfolio and decide which to tackle first |
Surfacing the Real Dimension
The Ladder of Inference (Argyris/Senge)
For any conflicting requirement, ask in order:
- Data: What observable facts does each stakeholder have?
- Interpretation: What meaning do they attach to those facts?
- Assumptions: What beliefs are they operating from?
- Conclusion: What action follows from their assumptions?
- Beliefs: What deeper values drive this?
Most conflicts resolve at Levels 1-3 with better data.
The Assumption Test
For every conflicting requirement, ask: "What assumption would make this the right answer?" Then test that assumption, not the requirement.
Facilitating Disagreement
Lead with curiosity (Torres): Assume the other person is smart and has good reason for their position. Your job is to find that reason.
"How Might We" reframing: Instead of "We should build X" (defense trigger), try "How might we achieve [outcome] given [constraint]?" (exploration trigger).
One-on-one before group: Meet stakeholders individually first to understand real concerns. One strong opinion derails group sessions.
Show your work, not conclusions: Share raw interview snapshots, early maps, messy prototypes. Stakeholders co-own what they helped shape.
Synthesis Patterns
| Pattern | When | How |
|---|---|---|
| Both/And | Both serve different use cases | Sequence: A first, then B. Or A for current users, B for different tier |
| Abstraction Ladder | Both are examples of broader capability | Build the broader platform, satisfy both |
| Horse Race | Neither has strong evidence | Prototype both, test with real users |
| Third Way | Neither option works alone | "What addresses both concerns?" |
Escalation Decision Matrix
| Situation | Escalate | Synthesize |
|---|---|---|
| Values genuinely incompatible | ✓ | |
| Time pressure; need direction | ✓ (for decision) | |
| Both untested; test is cheap | ✓ (test both) | |
| Conflict is about priority, not direction | ✓ (sequence both) | |
| One stakeholder blocking without data | ✓ | |
| Risk tolerance gap is wide | ✓ (prototype riskiest parts) |
Key Principles
- Conflicts are signals, not problems. A conflict means an unstated assumption worth surfacing.
- Data resolves what opinions cannot. Use customer data rather than arguing.
- The artifact is the alignment mechanism. Externalize thinking in maps and prototypes.
- Treat every requirement as a hypothesis. Defuses emotional investment and turns conflict into research.
Sources
- Continuous Discovery Habits (Torres) — opportunity solution trees, assumption testing
- Inspired (Cagan) — product discovery principles, dual-track agile
- The Fifth Discipline (Senge) — Ladder of Inference
- Specification by Example (Adzic) — collaborative specification workshops