Planning Products
Core principle: Define the problem worth solving and the experience worth building before deciding how to build it. Research what exists, understand who needs it, scope what matters.
Planning Phase
Load the relevant reference based on where you are in the planning process:
| Phase | Load | File |
|---|---|---|
| Researching market, competitors, existing patterns | Discovery | references/discovery.md |
| Framing the problem, users, and jobs to be done | Definition | references/definition.md |
| Defining how the feature should feel (UX or DX) | Experience | references/experience.md |
| Drawing scope boundaries, MVP, phasing | Scoping | references/scoping.md |
| Writing the actual product spec document | Template | references/feature-spec-template.md |
Start with Discovery when beginning from scratch. Start with Definition when the problem is already understood. Load Experience alongside either when the feature has significant interaction design. Load Scoping when you need to cut.
The Planning Sequence
Discovery → Definition → Experience → Scoping → [Hand off] ↓ ↓ ↓ ↓ Research Problem How it What's in & patterns & users feels & what's out
Not always linear. Discovery can reframe the problem. Experience constraints can force scope changes. Scoping can send you back to discovery. But this is the default order.
Product Type Adjustments
Different products need different emphasis. Adjust the planning weight:
| Product type | Heavy on | Light on | Key question |
|---|---|---|---|
| Consumer (B2C) | Experience, discovery | Formal definition | "Would I use this?" |
| B2B / Enterprise | Definition, scoping | Visual polish | "Does this solve a workflow?" |
| Developer tools | DX experience, API ergonomics | Marketing polish | "Is this the obvious API?" |
| Internal tools | Scoping, definition | Discovery | "Does this save time?" |
| Platform / API | Definition, experience (DX) | Consumer UX | "Is this composable?" |
Universal Principles
Start with the customer's problem, not your solution
You are not designing features. You are solving problems for specific people. If you can't name the person and their frustration, you're not ready to plan.
Research before inventing
Before designing something new, find out what already exists. Users have expectations shaped by other products. Meeting those expectations is usually better than surprising people with novelty. Novelty costs learning; familiarity is free.
Hypothesis-driven, not conviction-driven
Frame decisions as hypotheses that could be wrong. "We believe [user] will [behavior] because [evidence]." If you can't state the evidence, it's a guess. Guesses are fine as long as you know they're guesses.
Type 1 vs Type 2 decisions
| Decision type | Characteristics | Planning rigor |
|---|---|---|
| Type 1 (one-way door) | Hard to reverse, high switching cost | Full discovery + definition |
| Type 2 (two-way door) | Easy to change, low cost to undo | Lightweight spec, ship and learn |
Most product decisions are Type 2. Don't over-plan reversible choices.
Define success before building
Every feature needs measurable success criteria before work begins. Not vanity metrics. Outcomes tied to the user problem you're solving.
| Bad metric | Good metric |
|---|---|
| "Page views" | "% of users who complete the core task" |
| "API calls" | "Time to first successful integration" |
| "DAU" | "Users who return within 7 days" |
Anti-Patterns
| Pattern | Problem |
|---|---|
| Solution-first planning ("Let's build X") | Skips problem validation, builds the wrong thing |
| Feature lists without user stories | No context for why, impossible to prioritize |
| Copying competitors without understanding why | Imports their problems along with their solutions |
| "Users" as a monolith (no persona distinction) | Different users need different things |
| Scope that only grows, never shrinks | Ship date slides, value dilutes |
| Planning without research | Invents patterns users already know differently |
| Perfecting the spec before testing assumptions | Spec fiction, not product planning |
| DX as afterthought ("devs will figure it out") | Developers are users too, bad DX kills adoption |
Handoff Points
This skill's output feeds into other skills:
- Technical implementation: Use Claude's built-in plan mode to produce task breakdowns from the product spec
- UI/UX craft:
Skill(design)takes the experience requirements and produces the visual implementation - Architecture decisions:
Skill(architecting-systems)takes the technical constraints from the spec and produces system design - Strategy context:
Skill(strategy-writer)operates upstream, informing the "why this, why now" that feeds into discovery
Writing tone for specs and product docs: Use Skill(writer) with The PM persona.
