Systems Mapping

Purpose

Maps the full value-creating system and its dependencies before you design a solution — so the solution is shaped by the actual system it has to work in, not by an implicit, unexamined picture of "the customer" and "us."

Anchored in research

• Liedtka (1998) — systems perspective: strategists treat the organization as embedded in a system of relationships, not as an isolated unit whose environment can be analyzed away.
• Brandenburger & Nalebuff (1996), Co-opetition — the Value Net, a concrete way to structure the map: customers, suppliers, competitors, and complementors arranged around a focal actor, with value flowing between all of them, not just from supplier to customer.

Method

1. Name the focal value-creating activity. What specific value exchange are you mapping the system around (a product, a service, a decision)?
2. Place the four Value Net roles around it:
   • Customers — who pays, and who else derives value without paying directly (e.g. a free-tier user, a data source)?
   • Suppliers — who provides the inputs the focal activity depends on?
   • Competitors — who else could capture the same value from the same customers?
   • Complementors — who makes the focal activity more valuable by existing (the inverse of a competitor: someone whose success increases yours)?
3. Draw the flows, not just the actors. For each connection, name what actually moves: money, product, information, trust, attention. A system map with actors but no flows hides where the real dependency sits.
4. Identify the load-bearing dependencies. Which one or two connections, if they broke or changed materially, would force the whole system to reconfigure? Those are the ones worth stress-testing before you commit to a solution design.
5. Check for missing actors. The most common failure mode in this technique is treating "customer" and "competitor" as the only two roles that matter — actively ask who the unlisted suppliers and complementors are before finalizing the map.
6. Feed the map forward. Produce a structured map (see ../../references/ once populated) that the solution design can be checked against — does the proposed solution assume a system that doesn't actually exist?

What this skill does NOT do

• Doesn't make the final decision for you — it produces a structured draft to support a human decision.
• Doesn't confirm figures, market data, or competitor data from memory — it uses the inputs you provide, or marks an assumption clearly ([assumption — verify]).
• Doesn't produce an org chart or a process diagram — it maps value-creation logic, not formal structure.

Refinement notes

Areas to keep deepening with real practice:

• your own rules of thumb and heuristics for this technique
• concrete templates (into ../../references/)
• reference cases / your own examples
• what this skill deliberately does not do (guardrails, common mistakes) — add to the list above

This is an internal working note, not a claim about the skill's current usability. Track depth privately via the maturity field in skills_index.json (see ../../../meta/maturity_levels.md). Don't add new fields to the frontmatter — name and description are the only ones allowed (see ../../../meta/frontmatter_schema.md).

Continue from here

• Next in this pack: ../strategic-intent-framing/SKILL.md — Frames a clear strategic intent that focuses energy and cuts out noise.
• A ready-made skill chain for this situation: see ../../../playbooks/
• This pack's shared guardrails: ../../CLAUDE.md

References

• ../../references/ — the pack's shared background material
• ../../CLAUDE.md — the pack's shared guardrails