rileyhilliard/planning-products

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.