evidence-backed-product-planning

# Evidence-Backed Product Planning Convert an ambiguous product request into a bounded decision with explicit evidence, options, ownership, metrics, and a verification plan. ## Frame the decision 1. Name the decision owner, target user, problem, desired outcome, deadline, and constraints. 2. Separate observed facts, user-provided claims, assumptions, and open questions. 3. Define success and guardrail metrics with baselines or note that the baseline is unknown. 4. State what the decision excludes and which missing input would materially change it. ## Run independent branches ### Customer evidence - Gather dated evidence from research, support, analytics, sales, usage, and direct user material available in scope. - Preserve source locators and distinguish frequency, severity, reach, and willingness to change. - Map evidence to the framed problem; do not turn an anecdote into a segment-wide fact. ### Solution and delivery options - Formulate two or three genuinely different options, including a bounded no-build or defer option when meaningful. - Compare user value, feasibility, dependencies, reversibility, time to learn, risks, and opportunity cost. - Split the work into concrete owned deliverables and dependency-aware milestones. Do not use placeholders such as “handle edge cases.” ## Join into a decision Read both complete branches. Select, reject, or defer with explicit reasoning. For the chosen option, define scope, non-goals, acceptance criteria, owner, dependencies, release or experiment sequence, success metrics, guardrails, risks, and the next decision date. Preserve unresolved contradictions and confidence limits. ## Verify before claiming completion Use fresh evidence tied to each acceptance criterion before stating that delivery or validation is complete. Record the command, run, data window, observation, or artifact locator and its outcome. Distinguish implemented, locally verified, externally verified, blocked, and unverified. A plan, old log, or model assertion is not current completion evidence. ## Provenance and adaptation boundary This method adapts bounded context gathering, option comparison, concrete planning, and fresh-evidence completion checks from selected MIT-licensed obra/superpowers Skills. It intentionally excludes the upstream global startup protocol, mandatory Skill invocation chain, worktree rules, commit rules, and process requirements unrelated to the product decision. Read `references/upstream.md` and `references/upstream-license.txt` when auditing provenance.