Value Chain Mapping

Value Chain Mapping Skill

Map value chains from user needs to underlying components as the foundation for Wardley Maps.

When to Use This Skill

Use this skill when:

• Value Chain Mapping tasks - Working on map value chains from user needs to underlying components
• Planning or design - Need guidance on Value Chain Mapping approaches
• Best practices - Want to follow established patterns and standards

MANDATORY: Documentation-First Approach

Before mapping value chains:

1. Invoke docs-management skill for value chain patterns
2. Verify mapping methodology via MCP servers (perplexity)
3. Base guidance on Wardley's value chain decomposition

Value Chain Fundamentals

Value Chain = Components Linked by Dependencies

User Need
    │
    ▼
┌─────────────────┐
│ Component A     │ ◄── Visible to user
└────────┬────────┘
         │ depends on
         ▼
┌─────────────────┐
│ Component B     │ ◄── Less visible
└────────┬────────┘
         │ depends on
         ▼
┌─────────────────┐
│ Component C     │ ◄── Invisible to user
└─────────────────┘

Key Principles:
- Start with user need (anchor)
- Work backwards to dependencies
- Higher = more visible to user
- Lower = more invisible (infrastructure)

Step 1: Identify the Anchor (User Need)

Good vs Bad Anchors

GOOD ANCHORS (Needs):
✓ "I need to communicate with my team"
✓ "I need to process customer payments"
✓ "I need to deploy software reliably"
✓ "I need to understand customer behavior"
✓ "I need to manage my finances"

BAD ANCHORS (Solutions):
✗ "I need Slack"
✗ "I need Stripe"
✗ "I need Kubernetes"
✗ "I need Google Analytics"
✗ "I need QuickBooks"

Test: Can the need be satisfied multiple ways?
If tied to specific solution, you have a solution, not a need.

Anchor Identification Questions

Finding User Needs:

WHO Questions:
- Who is the user?
- Who benefits from this?
- Who are we serving?

WHAT Questions:
- What outcome do they want?
- What problem are they solving?
- What value do they receive?

WHY Questions:
- Why do they need this?
- Why does this matter to them?
- Why would they pay for this?

Test Questions:
- Is this a capability or a solution?
- Could this be satisfied differently?
- What's the underlying job-to-be-done?

Step 2: Decompose Into Components

Decomposition Method

Decomposition Process:

Start: User Need
Ask: "What is required to satisfy this need?"
Answer: List of components (first level)

For Each Component:
Ask: "What does THIS depend on?"
Answer: List of sub-components (next level)

Repeat until you reach:
- Commodities (electricity, bandwidth)
- Standard services (cloud compute)
- Well-known infrastructure

Stop When:
- Component is truly commodity
- Further decomposition adds no strategic value
- You've reached common industry infrastructure

Component Identification Checklist

For Each Potential Component:

□ Is it a capability (not just an activity)?
□ Does it provide value to something above it?
□ Can it evolve independently?
□ Does it have identifiable evolution stage?
□ Can you point to who/what provides it?

Component Boundaries:
- Should be cohesive (single responsibility)
- Should have clear interfaces
- Should be manageable units
- Should be meaningfully different from siblings

Step 3: Establish Dependencies

Dependency Types

Dependency Relationships:

REQUIRES (Hard Dependency)
Component A ───► Component B
"A cannot function without B"

Example: API Service ───► Database

USES (Soft Dependency)
Component A - - ► Component B
"A uses B but could use alternatives"

Example: Application - - ► Logging Service

ENABLES (Reverse Dependency)
Component A ◄─── Component B
"B enables/enhances A"

Example: Analytics ◄─── User Interface

Dependency Rules

Dependency Principles:

1. DIRECTION
   - Dependencies flow DOWN the value chain
   - Higher components depend on lower components
   - Users are at the top, infrastructure at bottom

2. VISIBILITY CORRELATION
   - Components closer to user need = more visible
   - Components further from user = less visible
   - Dependency depth ≈ invisibility

3. MULTIPLE DEPENDENCIES
   - Components can depend on multiple others
   - Creates complexity in the chain
   - Watch for critical path dependencies

4. CIRCULAR DEPENDENCIES
   - Should be rare/avoided
   - May indicate poor decomposition
   - Can create analysis paralysis

Step 4: Validate the Chain

Validation Checklist

Value Chain Validation:

COMPLETENESS
□ Does chain start with user need?
□ Are all critical dependencies captured?
□ Does chain reach commodity level?
□ No orphan components (disconnected)?

ACCURACY
□ Do dependencies reflect reality?
□ Is visibility ordering correct?
□ Are component boundaries appropriate?
□ Does it match how work actually flows?

USEFULNESS
□ Is granularity appropriate for purpose?
□ Can you position components on evolution axis?
□ Does it reveal strategic insights?
□ Can decisions be made from this chain?

Common Validation Issues

Problems to Watch For:

TOO SHALLOW
Symptom: Few levels, large components
Fix: Ask "what does this depend on?" more times

TOO DEEP
Symptom: Many levels, trivial components
Fix: Consolidate components, focus on strategic items

MISSING COMPONENTS
Symptom: Gaps in dependencies, magic jumps
Fix: Trace the actual work/data flow

SOLUTION BIAS
Symptom: Components are products, not capabilities
Fix: Reframe as "what capability does this provide?"

ACTIVITY CONFUSION
Symptom: Components are verbs, not nouns
Fix: Activities are not components; capabilities are

Value Chain Patterns

Common Patterns

Standard Value Chain Shapes:

LINEAR CHAIN
User Need
    │
    ▼
[A] → [B] → [C] → [D]
Simple, sequential dependencies

BRANCHING CHAIN
User Need
    │
    ├──► [A] → [C]
    │          ↓
    └──► [B] → [D] → [E]
Multiple paths to satisfy need

CONVERGING CHAIN
User Need
    │
[A]─┴─[B]
    │
    ▼
   [C]
    │
   [D]
Multiple components feeding one

PLATFORM CHAIN
User Need
    │
    ▼
   [A]
    │
┌───┼───┐
▼   ▼   ▼
[B][C][D]
    │
    ▼
  [Platform]
Common platform underneath

Domain-Specific Examples

E-COMMERCE VALUE CHAIN:

User Need: "Buy products online"
    │
    ├── Product Discovery
    │       ├── Search
    │       ├── Catalog
    │       └── Recommendations
    │
    ├── Shopping Experience
    │       ├── Cart
    │       ├── Wishlist
    │       └── Pricing
    │
    ├── Checkout
    │       ├── Payment Processing
    │       ├── Tax Calculation
    │       └── Address Validation
    │
    └── Fulfillment
            ├── Inventory
            ├── Shipping
            └── Notifications
                    │
                    ▼
            [Cloud Infrastructure]

SAAS APPLICATION VALUE CHAIN:

User Need: "Manage projects collaboratively"
    │
    ├── User Management
    │       ├── Authentication
    │       ├── Authorization
    │       └── Identity Provider
    │
    ├── Project Management
    │       ├── Task Tracking
    │       ├── Timeline/Gantt
    │       └── Resource Allocation
    │
    ├── Collaboration
    │       ├── Real-time Sync
    │       ├── Notifications
    │       └── Comments/Chat
    │
    └── Reporting
            ├── Analytics
            ├── Dashboards
            └── Export
                    │
                    ▼
            [Database] [Compute] [Storage]

Value Chain Documentation Template

# Value Chain: [Domain/Context]

## User Need
[The anchor - what users actually need]

## Users
- [Primary user persona]
- [Secondary user persona]

## Value Chain Diagram

```text
[ASCII diagram of value chain]
```

## Component Inventory

| ID | Component | Description | Depends On | Visibility |
|----|-----------|-------------|------------|------------|
| 1 | [Name] | [What it does] | - | High |
| 2 | [Name] | [What it does] | 1 | Medium |
| 3 | [Name] | [What it does] | 2 | Low |

## Dependency Matrix

|   | C1 | C2 | C3 | C4 |
|---|----|----|----|----|
| C1 | - | | | |
| C2 | X | - | | |
| C3 | | X | - | |
| C4 | | X | X | - |

## Critical Path

[Which dependencies are most critical]

## Assumptions

- [Assumption about user need]
- [Assumption about components]

## Open Questions

- [What needs further investigation]

## Next Steps

- [ ] Validate with users
- [ ] Position on evolution axis
- [ ] Identify strategic opportunities

Visibility Assessment

Y-Axis Positioning Guide

Visibility Questions

Assessing Visibility:

HIGH VISIBILITY (Near User):
- Does the user directly interact with this?
- Does the user know this exists?
- Is this a selling point to users?

MEDIUM VISIBILITY:
- Does this affect user experience directly?
- Would users notice if it failed?
- Is this mentioned in user documentation?

LOW VISIBILITY:
- Is this purely technical infrastructure?
- Could you swap this without users knowing?
- Is this industry-standard plumbing?

Workflow

When mapping value chains:

1. Define Scope: What are we mapping? For what purpose?
2. Identify Anchor: What is the user need?
3. List First-Level Components: What directly satisfies the need?
4. Decompose Recursively: What does each component depend on?
5. Draw Dependencies: Connect components with dependency arrows
6. Validate Chain: Check completeness, accuracy, usefulness
7. Assess Visibility: Position components on Y-axis
8. Document: Capture components, dependencies, assumptions
9. Prepare for Evolution: Ready to add X-axis positioning

References

For detailed guidance:

Last Updated: 2025-12-26