Planning Product Strategy
Markdown--- name: planning-product-strategy description: Develops product vision, roadmaps, feature prioritization matrices, and execution plans from user needs and business goals. Use when defining product direction, prioritizing a feature backlog, planning a roadmap, or translating user needs into an execution plan. --- # Product Strategy Planning
Given a product context (target users, business goals, known pain points, competitive landscape), produce these five artifacts in order:
- Vision — one paragraph, outcome-focused
- Roadmap — time-horizon buckets (Now / Next / Later)
- Feature Matrix — features scored against value & effort
- Priority Score — ranked backlog using a weighted formula
- Execution Plan — owners, milestones, dependencies for top priorities
Do not skip straight to features. Vision and user needs must anchor every downstream artifact — if a feature can't be traced back to the vision or a validated need, flag it instead of silently including it.
Progress:
- Step 1: Clarify user needs and business goals (ask only if truly missing; otherwise infer from context and state assumptions)
- Step 2: Draft Vision statement
- Step 3: Build Roadmap (Now/Next/Later, not fixed dates unless given)
- Step 4: Build Feature Matrix (Value vs Effort vs Confidence)
- Step 5: Compute Priority Score per feature
- Step 6: Write Execution Plan for top 3–5 priorities
Step 1: Clarify inputs
Identify: target user segment, core problem, business objective (growth/retention/revenue/efficiency), constraints (timeline, team size, tech debt). If unspecified, state explicit assumptions rather than pausing the whole output.
Step 2: Vision
One paragraph. Format: "For [user], who [problem], [product] is a [category] that [key benefit]. Unlike [alternative], we [differentiator]."
Step 3: Roadmap
Three horizons, not calendar dates:
- Now (in progress / next sprint-quarter): committed, scoped
- Next (1–2 quarters out): validated direction, not yet scoped
- Later (exploratory): bets and hypotheses
Each item: one-line outcome (not a feature name). E.g., "Reduce onboarding drop-off by 20%" not "Build new onboarding flow."
Step 4: Feature Matrix
Table with columns: Feature | User Value (1-5) | Business Value (1-5) | Effort (1-5, 5=hardest) | Confidence (Low/Med/High) | Notes
Step 5: Priority Score
Default formula (RICE-inspired, adapt if inputs given):
Priority Score = (User Value + Business Value) × Confidence Multiplier / Effort
Confidence Multiplier: High=1.0, Med=0.7, Low=0.4
Rank descending. Show the math, not just the final number.
Step 6: Execution Plan
For each top-ranked feature: Owner (role, not name unless given) | Milestone breakdown (2-4 steps) | Dependencies/risks | Success metric (leading indicator tied back to Vision)
Example 1: Input: "MusGo is a music collaboration app for indie artists. Users struggle to find collaborators and manage version conflicts on shared tracks. Goal: increase weekly active collaboration sessions."
Output:
Vision: For indie musicians who struggle to find and coordinate with collaborators,
MusGo is a collaboration platform that makes co-creating music as frictionless as
messaging. Unlike generic file-sharing tools, we handle version control and
discovery natively for music production.
Roadmap:
- Now: Ship version-conflict resolution for shared tracks
- Next: Launch collaborator discovery/matching
- Later: Real-time co-editing sessions
Feature Matrix:
| Feature | UserVal | BizVal | Effort | Confidence | Notes |
|---------------------------|---------|--------|--------|------------|-------|
| Version conflict resolver | 5 | 4 | 3 | High | Core pain point |
| Collaborator matching | 4 | 5 | 4 | Med | Needs matching algo |
| Real-time co-edit | 3 | 3 | 5 | Low | High tech risk |
Priority Score:
- Version conflict resolver: (5+4)×1.0/3 = 3.0 → #1
- Collaborator matching: (4+5)×0.7/4 = 1.58 → #2
- Real-time co-edit: (3+3)×0.4/5 = 0.48 → #3
Execution Plan (Version conflict resolver):
- Owner: Eng lead (backend) + PM
- Milestones: (1) design conflict-detection logic (2) build merge UI
(3) beta with 20 power users (4) full rollout
- Dependencies: requires track storage schema update
- Success metric: % of shared tracks with unresolved conflicts, target <5%
Example 2: Input: "prioritize: dark mode, export to Spotify, offline mode" (no context given)
Output: State assumption ("Assuming general productivity/consumer app, no stated business goal — scoring on user value and typical effort only"), then produce Feature Matrix + Priority Score only, and note that Vision/Roadmap/Execution Plan need more context to be meaningful — offer a best-effort version anyway rather than blocking.
- Always tie features back to the Vision; if you can't, say so explicitly instead of forcing a justification.
- Prefer outcome language ("reduce churn by X") over output language ("build feature Y") in Vision and Roadmap.
- Keep Feature Matrix scores relative and consistent — recalibrate if scores cluster all at 4-5.
- Show scoring math for Priority Score; unexplained rankings erode trust.
- Keep Execution Plans to top 3-5 items — a plan for everything is a plan for nothing.
- State assumptions explicitly when inputs are incomplete; don't block on missing info.
- Don't jump straight to a feature list without a Vision — it produces a backlog, not a strategy.
- Don't use fixed calendar dates in early-stage roadmaps unless the user provided them; horizons (Now/Next/Later) age better.
- Don't let Effort scores be guessed by feel alone — flag when Effort is uncertain rather than presenting false precision.
- Don't average scores when Confidence is Low — surface the uncertainty instead of hiding it in the final number.
- Don't include every requested feature in the Execution Plan; that's what the backlog/matrix is for.