---
name: product-strategy
description: >
  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.
user-invocable: 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