Map value chains from user needs to underlying components
Maps value chains from user needs to underlying components by decomposing requirements into dependency layers. Use when planning or designing systems to identify strategic components and their relationships before Wardley mapping.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install wardley-mapping@melodic-softwareThis skill is limited to using the following tools:
Map value chains from user needs to underlying components as the foundation for Wardley Maps.
Use this skill when:
Before mapping value chains:
docs-management skill for value chain patternsValue 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)
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.
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?
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
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
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 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
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?
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
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
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: [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 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 |
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?
When mapping value chains:
For detailed guidance:
Last Updated: 2025-12-26
This skill should be used when the user asks to "create a hookify rule", "write a hook rule", "configure hookify", "add a hookify rule", or needs guidance on hookify rule syntax and patterns.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.