architecture/skills/product-strategy/SKILL.md

name, description, user-invocable

name	description	user-invocable
product-strategy	Opinionated framework for translating manifesto into executable backlog through problem space analysis, domain modeling, and capability mapping. Use when planning product strategy or decomposing vision into work.	false

Product Strategy Framework

A disciplined chain from organizational values to executable work, preventing cargo-cult DDD and feature churn.

The Chain

Manifesto
  ↓ (constraints + outcomes)
Product Vision
  ↓ (events + decisions)
Problem Space
  ↓ (boundaries)
Bounded Contexts
  ↓ (invariants)
Domain Models
  ↓ (system abilities)
Capabilities
  ↓ (user value)
Features
  ↓ (executable)
Issues

Each step has a clear artifact and decision gate.

Step 1: Manifesto → Product Vision

Purpose: Decide what is worth building (and what not).

Artifact: 1-page Product Vision (per product)

Method: Translate values into constraints + outcomes, not features.

Manifesto Element	Vision Element
Value	Non-negotiable design rule
Belief	Product promise
Principle	Trade-off rule

Vision must answer (hard requirement):

• Who is this product for?
• What pain is eliminated?
• What job is now trivial?
• What won't we do?

Decision gate: If this can't be answered crisply → stop.

Step 2: Product Vision → Problem Space

Purpose: Understand reality before modeling software.

Artifact: Problem Map (language-first)

Do NOT start with DDD yet.

First, explore:

• Core user journeys
• Decisions users struggle with
• Irreversible vs reversible actions
• Where mistakes are expensive

Techniques:

• Event Storming (Big Picture)
• Jobs-To-Be-Done
• Narrative walkthroughs ("a day in the life")

Output: A timeline of business events, not entities.

Anti-pattern: If you don't see events, you're still thinking in CRUD.

Step 3: Problem Space → Domain Boundaries

Purpose: Decide where models must be pure and where they may rot.

Artifact: Bounded Context Map

How to cut boundaries (rules):

• Different language → different context
• Different lifecycle → different context
• Different owners → different context
• Different scaling needs → different context

Anti-pattern: "One big domain model" is not DDD; it's denial.

Step 4: Bounded Context → Domain Model

Purpose: Capture business invariants, not data structures.

Artifact (per context):

• Aggregates
• Commands
• Events
• Policies
• Read models

Process:

1. Identify invariants (what must never break)
2. Define aggregates only where invariants exist
3. Everything else becomes a read model or policy

Anti-pattern: If an aggregate has no invariant, it shouldn't exist.

Step 5: Domain Model → Product Capabilities

Purpose: Bridge domain thinking to roadmap thinking.

Artifact: Capability Map

A capability is: "The system's ability to cause a meaningful domain change"

Examples:

• "Validate eligibility"
• "Authorize execution"
• "Resolve conflicts"
• "Publish outcome"

Key insight: Capabilities ≠ features

Capabilities survive UI rewrites and tech changes.

Step 6: Capabilities → Features

Purpose: Define user-visible value slices.

Artifact: Feature definitions

Each feature:

• Enables or improves one capability
• Has a clear success condition
• Is demoable

Rule: If a feature doesn't move a capability, it's noise.

Step 7: Features → Work Items

Purpose: Make work executable without losing intent.

Artifact: Issues / Stories / Tasks

Decomposition order:

1. Command handling
2. Domain rules
3. Events
4. Read models
5. UI last

Golden rule: Issues should reference domain concepts, not screens.

Bad: "Create edit form" Good: "Allow policy to approve eligibility override"

Common Failure Modes

Failure	Result
Starting DDD before product vision	Elegant nonsense
Treating aggregates as data models	Anemic domains
Roadmaps built from features instead of capabilities	Churn
Tickets written in UI language	Lost intent

Decision Gates

After Vision: Can you answer the 4 questions crisply? No → stop and clarify.

After Problem Space: Do you see events, not entities? No → go deeper.

After Contexts: Are boundaries clear? No → re-examine language/lifecycle/ownership.

After Domain Models: Does each aggregate enforce an invariant? No → simplify.

After Capabilities: Can each capability be demoed? No → clarify.

After Features: Does each feature move a capability? No → cut it.

Brownfield (Existing Code)

At each step, compare intended state vs actual state:

Context Mapping:

• Intended contexts vs actual modules
• Identify leaky boundaries

Domain Modeling:

• Intended aggregates vs actual models
• Identify anemic domains

Result: Refactoring issues + new feature issues

Tips

• Don't skip steps (especially problem space)
• Each artifact is 1 page max
• Decision gates prevent waste
• DDD starts at step 3, not step 1
• Capabilities are the pivot between domain and product
• Issues reference domain language, not UI elements