Claude
Skills
Sign in
Back

wardley-mapping

Included with Lifetime
$97 forever

This skill should be used when the user asks about Wardley Mapping, evolution stages, strategic positioning, creating maps, value chain decomposition, gameplay patterns, doctrine assessment, climatic patterns, build vs. buy, or inertia analysis.

General

What this skill does


# Wardley Mapping

A strategic mapping technique created by Simon Wardley for understanding competitive landscape, technology evolution, and making informed architectural decisions. A Wardley Map visualizes four dimensions: the **value chain** (components needed to meet user needs), **evolution** (how components mature over time), the **landscape** (competitive environment), and **movement** (how the landscape changes).

**This skill ships reference material, not runnable scripts.** Read the relevant section here (or the linked references) with `Read`, apply the OnlineWardleyMaps syntax, and write the map into the user's artefact. Do not `Bash`-execute anything from this skill — there is no script to run.

## Map Structure

The following diagram illustrates the conceptual axes of a Wardley Map. For the generation template with placeholders, see the Map Template section below.

```text
                    EVOLUTION

        Genesis    Custom     Product    Commodity
           ↓          ↓          ↓          ↓
        ┌──────────────────────────────────────────┐
        │                                          │
Visible │   User Need ●                            │  ← Anchor
        │       │                                  │
        │       ↓                                  │
        │   Component A ●──────────→ ●             │
        │       │                                  │
        │       ↓                                  │
        │   Component B    ●                       │
        │       │                                  │
Hidden  │       ↓                                  │
        │   Component C              ●             │
        │       │                                  │
        │       ↓                                  │
        │   Component D                       ●    │  ← Commodity
        │                                          │
        └──────────────────────────────────────────┘

        Y-axis: Visibility (to user)
        X-axis: Evolution (certainty)
```

## Evolution Stages (Summary)

| Stage | Position | Key Trait | Sourcing | Example |
|-------|----------|-----------|----------|---------|
| **Genesis** | Far left (0.0-0.25) | Novel, uncertain, high failure | Build (R&D) | Novel AI architectures |
| **Custom-Built** | Center-left (0.25-0.50) | Understood but bespoke, differentiating | Build (custom dev) | Bespoke trading platform |
| **Product** | Center-right (0.50-0.75) | Multiple vendors, feature competition | Buy (configure) | CRM systems |
| **Commodity** | Far right (0.75-1.0) | Well understood, essential, utility | Outsource (consume) | Cloud compute (IaaS) |

For detailed stage characteristics, indicators, and positioning criteria, see [references/evolution-stages.md](references/evolution-stages.md).

## How to Create a Wardley Map

Follow these steps in order when the user asks to create or analyze a Wardley Map.

### Step 1: Gather Context

Use the AskUserQuestion tool to interactively gather the information needed to create the map. Ask up to 3 questions at a time.

**First, identify the anchor and scope:**

Use AskUserQuestion to ask:

- **Who is the primary user?** — Options might include: "External customers", "Internal developers", "Business analysts", or let the user specify
- **What is the user need?** — e.g., "Purchase products online", "Deploy applications reliably", "Generate analytical reports"
- **What is the scope?** — Options: "Single product/service", "Business unit", "Entire organization", "Specific capability"

**Then, gather strategic context:**

Use AskUserQuestion to ask:

- **What is the primary goal?** — Options: "Identify investment priorities", "Evaluate build vs. buy", "Assess competitive position", "Plan technology evolution"
- **What industry/domain?** — Let the user specify (affects how components are positioned on the evolution axis)
- **What depth of analysis?** — Options: "Quick overview (5-10 components)", "Standard map (10-20 components)", "Deep analysis (20+ components with gameplay)"

### Step 2: Build the Value Chain

Work backwards from the user need. List every component required to deliver it, then arrange them by visibility (user-facing at top, infrastructure at bottom). For each component, identify what it depends on — dependencies flow downward.

- List **capabilities**, not just technologies
- Include **people, practices, and data** alongside technical components
- Map both **technical and business** components
- Ask: "What components are needed?", "What does each depend on?", "What is hidden from the user?"

If component identification is uncertain, use AskUserQuestion to ask the user about key capabilities, technologies, and processes in their domain.

### Step 3: Position on Evolution

For each component, assess its evolution stage using the indicators in [references/evolution-stages.md](references/evolution-stages.md). Place it on the X-axis accordingly.

Key questions for each component:

- How well understood is it in the market?
- How many alternatives exist?
- Is it commoditized or unique?
- What's the market maturity?

Avoid common mistakes: don't position based on age (use market maturity), don't confuse internal unfamiliarity with market-wide genesis, and always consider industry context.

If positioning is ambiguous for key components, use AskUserQuestion to clarify with the user — e.g., "Is your recommendation engine a custom differentiator or are you using an off-the-shelf product?"

### Step 4: Add Movement

Add arrows showing how components are evolving. All components naturally drift rightward over time, but some move faster or slower.

- `→` Natural evolution (component moving right over time)
- `×` Inertia (resistance to movement from past success, skills, or politics)
- `>>` Acceleration (forced rapid evolution from competition or disruption)

### Step 5: Analyze and Recommend

After drawing the map, apply the analysis checklist below, then review gameplay patterns in [references/gameplay-patterns.md](references/gameplay-patterns.md) and climatic patterns in [references/climatic-patterns.md](references/climatic-patterns.md) to identify strategic moves.

Use AskUserQuestion to confirm priorities with the user before finalizing recommendations — e.g., "The map suggests these three strategic moves. Which areas are most important to your organization right now?"

### Step 6: Quantitative Analysis (Optional)

When the user asks for numeric precision, scoring, or data-driven positioning, apply the mathematical models from [references/mathematical-models.md](references/mathematical-models.md):

1. **Evolution Scoring** — Calculate precise X-axis positions using Ubiquity and Certainty scores
2. **Decision Metrics** — Differentiation Pressure, Commodity Leverage, and Dependency Risk
3. **Weak Signal Detection** — Assess readiness factors to predict stage transitions

Present results as a table alongside the qualitative analysis — the numbers should confirm or challenge the intuitive positioning, not replace it.

## Common Gotchas

The highest-signal failures, collected from real maps. Check these before finalizing.

### Positioning mistakes

- **Positioning by age, not market maturity.** A 20-year-old internal system is not Commodity if the capability it provides is still bespoke across the market. Use *ubiquity + certainty*, never "how long we've had it." (See Step 3 and [references/evolution-stages.md](references/evolution-stages.md).)
- **Confusing internal unfamiliarity with Genesis.** "New to us" ≠ "new to the world." If multiple vendors sell it, it is Product/Commodity even if your team has never used it. This is the single most common error.
- **Treating the Y-axis as importance.** Visibility means *visibility to the user*, not business value or criticality. Power supply is invisible-but-critical → it belongs low on the map, not high.
- **Floating components with no anchor.** Every value chain must trace upward to the user need. A comp

Related in General