Evaluate product/app ideas before and after MVP using north-star one-pagers, core-tech leverage, defining constraints, success criteria, opportunity mapping, RICE, and growth horizons. Use when deciding whether to build, continue, pivot, prioritize post-MVP work, define product success, or avoid feature-factory drift. Keywords: build or not, MVP, product idea, north star, product strategy, RICE, opportunity tree, roadmap, post-MVP, pivot, success criteria, narrative, one-pager, working backwards.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Evaluate product/app ideas before and after MVP using north-star one-pagers, core-tech leverage, defining constraints, success criteria, opportunity mapping, RICE, and growth horizons. Use when deciding whether to build, continue, pivot, prioritize post-MVP work, define product success, or avoid feature-factory drift. Keywords: build or not, MVP, product idea, north star, product strategy, RICE, opportunity tree, roadmap, post-MVP, pivot, success criteria, narrative, one-pager, working backwards.
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 READreferences/build-or-not.md. Three gates: one-page north star, separable core tech, defining constraint.
MVP shipped and too many next paths compete?
→ MANDATORY READreferences/post-mvp-crossroads.md. Sequence: Opportunity Solution Tree → RICE → Three Horizons.
Ambiguous product success criteria?
→ Start with references/build-or-not.md Gate 1. If the issue is broader than product/app success, switch to goal-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-setting when there is no product/user/market surface.
Why: product frameworks add false structure when the real work is personal direction or exploratory learning.