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: Skill(ce:writing-plans) takes the product spec and produces task breakdowns with agent grouping
• UI/UX craft: Skill(ce:design) takes the experience requirements and produces the visual implementation
• Architecture decisions: Skill(ce:architecting-systems) takes the technical constraints from the spec and produces system design
• Strategy context: Skill(ce:strategy-writer) operates upstream, informing the "why this, why now" that feeds into discovery

Writing tone for specs and product docs: Use Skill(ce:writer) with The PM persona.