211 lines
5.1 KiB
Markdown
211 lines
5.1 KiB
Markdown
---
|
|
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
|