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:

• Invoke docs-management skill for value chain patterns

• Verify mapping methodology via MCP servers (perplexity)

• 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

[ASCII diagram of value chain]

Component Inventory

Dependency Matrix

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 Level Characteristics Examples

0.90-1.00 Direct user interaction UI, Customer Portal

0.75-0.89 User-aware features Notifications, Search

0.50-0.74 Application services Business Logic, APIs

0.25-0.49 Platform services Auth, Messaging, Cache

0.10-0.24 Infrastructure Database, Compute, Storage

0.00-0.09 Utilities Power, Network, Physical

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:

• Define Scope: What are we mapping? For what purpose?

• Identify Anchor: What is the user need?

• List First-Level Components: What directly satisfies the need?

• Decompose Recursively: What does each component depend on?

• Draw Dependencies: Connect components with dependency arrows

• Validate Chain: Check completeness, accuracy, usefulness

• Assess Visibility: Position components on Y-axis

• Document: Capture components, dependencies, assumptions

• Prepare for Evolution: Ready to add X-axis positioning

References

For detailed guidance:

Last Updated: 2025-12-26