Product Strategy
Use product strategy when the question is whether a product/app should exist, continue, pivot, or prioritize one path over another. Product goals must be honest, falsifiable, and dated; if the user mainly needs general life/project direction, use goal-setting instead.
Routing
-
Pre-build or unsure whether to build? → MANDATORY READ
references/build-or-not.md. Three gates: one-page north star, separable core tech, defining constraint. -
MVP shipped and too many next paths compete? → MANDATORY READ
references/post-mvp-crossroads.md. Sequence: Opportunity Solution Tree → RICE → Three Horizons. -
Ambiguous product success criteria? → Start with
references/build-or-not.mdGate 1. If the issue is broader than product/app success, switch togoal-setting.
Boundary
Product strategy asks: “Should this product/app exist, continue, pivot, or prioritize X?”
Goal-setting asks: “What am I trying to make true, and how would I know?”
Do not force a personal, research, or learning project into product language unless the user is actually making a product.
NEVER
-
NEVER score or roadmap features before success criteria exist. Instead: define the north star, measurable success, and dated review milestone first. Why: prioritization without a goal optimizes for loudness, recency, or excitement.
-
NEVER let post-MVP planning become a feature factory. Instead: map opportunities and user problems before solutions. Why: scoring features directly can produce an efficient roadmap for the wrong problems.
-
NEVER treat product strategy as generic goal coaching. Instead: switch to
goal-settingwhen there is no product/user/market surface. Why: product frameworks add false structure when the real work is personal direction or exploratory learning.