define-hypothesis
Define-hypothesis creates testable predictions about how product changes affect user behavior or business outcomes, transforming vague assumptions into explicit, measurable statements. Use this skill after problem framing but before experiment design, when team members disagree about user behavior, or when aligning on success metrics before investing engineering resources. It structures beliefs into target users, expected outcomes, success metrics, and validation approaches to prevent building untested features.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/define-hypothesis && cp -r /tmp/define-hypothesis/skills/define-hypothesis ~/.claude/skills/define-hypothesisSKILL.md
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> # Hypothesis A hypothesis is a testable prediction about how a change will affect user behavior or business outcomes. It transforms assumptions into explicit statements that can be validated or invalidated through experimentation. Well-formed hypotheses prevent teams from building features based on untested beliefs and create shared understanding of what success looks like. ## When to Use - After problem framing, before committing to a solution - When designing experiments or A/B tests - When team members have differing assumptions about user behavior - Before investing significant engineering resources in a feature - When pivoting direction and need to validate the new approach ## When NOT to Use - You are ready to design the actual A/B test (variants, sample size, duration) -> use `measure-experiment-design`; this skill frames what to test, not how - The problem itself is still unframed -> use `define-problem-statement` first - You want to organize many assumptions and ideas into a discovery structure -> use `define-opportunity-tree` - The team needs the full business-model picture, not one testable claim -> use `foundation-lean-canvas` ## Instructions When asked to create a hypothesis, follow these steps: 1. **State the Belief** Articulate what you believe will happen. Use the structured format: "We believe that [action/change] for [target user] will [expected outcome]." Be specific about the intervention - vague hypotheses can't be tested. 2. **Identify the Target User** Define who this hypothesis applies to. A hypothesis about "users" is too broad. Specify the segment: new users in their first week, power users with 10+ sessions, churned users returning, etc. 3. **Define the Expected Outcome** What behavior change or result do you expect? Frame it in terms of user actions (complete onboarding, make a purchase, return within 7 days) rather than internal metrics when possible. 4. **Set Success Metrics** Choose a primary metric that directly measures the expected outcome. Include secondary metrics that provide context and guardrail metrics that ensure you're not causing harm elsewhere. 5. **Describe Validation Approach** How will you test this hypothesis? A/B test, user interviews, prototype testing, cohort analysis? Be specific about sample size, duration, and statistical requirements. 6. **Document Risks and Assumptions** What could invalidate this hypothesis beyond the test results? What are you assuming to be true that you haven't validated? ## Output Format Use the template in `references/TEMPLATE.md` to structure the output. A complete hypothesis document fills every template section: Hypothesis Statement; Background & Rationale; Target User Segment; Success Metrics; Validation Approach; Risks & Assumptions; and Timeline. ## Quality Checklist Before finalizing, verify: - [ ] Hypothesis is falsifiable (possible to prove wrong) - [ ] Success metric has a specific numeric target - [ ] Target user segment is clearly defined - [ ] Validation approach is practical and time-bound - [ ] Pass/fail criteria are unambiguous - [ ] Hypothesis doesn't assume the solution works ## Examples See `references/EXAMPLE.md` for a completed example.
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.
Creates a cross-functional pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness, with owners, dates, and go/no-go criteria so nothing is missed before release. Use for significant or cross-team launches, not a small single-team change. For the customer-facing announcement of what shipped, use deliver-release-notes instead.