PM - Hypothesis Validation

Agent mode (--agent)

This skill's value is the live dialogue - --agent is not supported. If invoked with --agent, warn once ("this skill needs interactive back-and-forth; agent mode would hollow it out") and proceed interactively.

Artifact language

Checks state.json → artifact_language. Default (unset or "English"): no change in behavior.

• If set to a non-English language: write prose content (descriptions, rationale, rule text) in that language.
• Never translate: IDs, frontmatter keys and enum values, section headers other skills parse, file names - these stay English always, regardless of the setting.

Standalone run

Runs with or without a Pureinn workspace - it needs no other skill's artifact, so it works as a single tool from an install that never ran /pureinn.

• No workspace: create just the folder this skill writes into, or write to a path the user names, and say where the file went. Do not scaffold a project, do not invent a state.json, and do not send the user to /pureinn first.
• Read pureinn-variables.md / state.json where a value is actually used, not at the top of the run. Missing value: continue and name the capability it costs.

What this skill does

Turns raw assumptions into structured, testable hypotheses. Assigns the right experiment to each hypothesis. Tracks evidence as experiments run. Produces a Go/No-Go decision with pre-defined success metrics.

This skill runs in two modes:

• Plan mode (first run): structure hypotheses from design-thinking outputs, rank by risk, assign experiment types, define success criteria before any experiment runs
• Results mode (follow-up run): record experiment outcomes, update hypothesis status, issue Go / Pivot / Stop decision

Both modes use the same artifact - the Hypothesis Register - which is updated progressively.

Why validate this way

Most startups fail not because of bad ideas but because they build solutions for problems that are not painful enough. Skipping structured validation means:

• Months of engineering for a product nobody buys
• No ability to distinguish signal from noise in early feedback
• Confirmation bias: founders hear what they want to hear

The goal of validation is not to get a yes or no. It is to learn. Every experiment is a clue that reduces uncertainty before capital and engineering time are committed.

Validation stages

This skill covers the full 5-stage validation arc:

Stage 2 (Qualitative) feeds from Phase 2 outputs - pm-personas, jtbd-building, pm-problem-validation. This skill does not re-run that work. It structures the insights into hypotheses and designs the remaining experiments.

Dependencies

Recommended before running:

• design-thinking - outputs Validation Hypotheses draft, Value Proposition Canvas, HMW Questions
• pm-personas - ICP definition and pain intensity data
• jtbd-building - jobs and forces that inform what assumptions to test
• pm-problem-validation - Phase 2 evidence available as input

Produces artifacts used by:

• pm-prototype - builds the prototype for a hypothesis whose experiment is a no-code / clickable prototype, and returns a four-state verdict to this register
• pm-lean-canvas - validated problem, customer, and solution feed into Lean Canvas inputs
• pm-product-roadmap - hypotheses and risks section (v1)
• pm-prd - validation evidence and Go/No-Go verdict are PRD inputs

Step 0: Current state check

Check for an existing Hypothesis Register at pureinn-workspace/[project-slug]/artifacts/phase-3-define/hypothesis-register.md.

Show state table:

Interaction: Group related questions (2-4 per round) and confirm before moving on. For any A/B/C/D choice, use the AskUserQuestion tool with one option marked (Recommended) - never print options as plain text. Keep open-ended questions free-text (don't fake options). If the user is unsure, propose 3-4 concrete options plus "Other". Surface an assumption the moment you make one; never fabricate to fill a gap. (Full standard: CLAUDE.md.)

Use AskUserQuestion tool with:

• Question: "What do you want to do in this session?"
• Option A: "Plan mode - structure hypotheses and design experiments (Recommended if register is empty)"
• Option B: "Results mode - record experiment outcomes and issue Go/No-Go verdict"
• Option C: "Add a new hypothesis or update success criteria in an existing register"
• Option D: "Something specific - I'll describe"

Step 1: Gather inputs

Plan mode (Option A)

Before gathering inputs: check whether Phase 2 evidence (items 2-3 below) was generated via Path B (assumption-based) in pm-personas, pm-problem-validation, or design-thinking. If yes, surface this explicitly before structuring hypotheses:

If Phase 2 inputs are assumption-based, flag these specific risks before structuring experiments:

• Persona assumed: experiment recruitment criteria will target the assumed profile. If the profile is wrong, you will collect validation from the wrong people and the Go/No-Go verdict will reflect their reality, not your actual customer's.
• Problem urgency assumed: success criteria for problem hypotheses may be calibrated to a pain level the customer does not actually experience. A test that passes against assumed urgency can still fail in the market.
• Design Thinking outputs assumption-based: HMW questions and solution directions used as hypothesis inputs may have been anchored to founder intuition. Make sure at least one hypothesis is designed to falsify the current direction, not just confirm it.

None of this requires stopping. It requires being explicit: which of the 4 input areas below has zero external evidence? Those areas have the highest experiment priority - test them first, not last.

I need your current assumptions to structure the Hypothesis Register.

1. PRODUCT IDEA
   What does it do? For whom? (1-2 sentences)

2. PHASE 2 EVIDENCE (paste what exists)
   Key insights from customer interviews:
   [paste or summarize]

   Top pains identified (from JTBD / personas):
   [paste or summarize]

   Problem Validation Summary (if available):
   [paste]

3. DESIGN THINKING OUTPUTS (paste if available)
   Validation Hypotheses draft (from design-thinking skill):
   [paste]

   Value Proposition Canvas (core jobs, pains, gains):
   [paste or summarize]

4. YOUR RISKIEST ASSUMPTIONS
   What would have to be true for this business to work?
   What are you least confident about - problem, solution, customer, or market?
   [free text]

5. IDEAL CUSTOMER PROFILE
   Who specifically is this for? (role, company size, context, geography)
   Not "small businesses" - the specific person who feels the pain most acutely.
   [describe]

Results mode (Option B)

I need the experiment results to update the register and issue a verdict.

For each completed experiment, provide:
  - Hypothesis ID (e.g., HYP-001)
  - Experiment type run
  - What you measured (metric, volume, time period)
  - Result (number or observation)
  - Pre-defined success criteria (from the register)
  - Did it pass? (Yes / No / Inconclusive)
  - Key quotes or evidence worth recording

Paste results below or describe what happened:
[free text]

If a completed experiment was a prototype, take its result from /pm-prototype - the ## Result block in the prototype's findings.md (or spec file) - rather than re-judging it here: the verdict is one of the four states under "Experiment types", and only Supported within scope / Refuted within scope change a hypothesis. A prototype with no recorded verdict yet (Result: pending, or Decision: open in its meta.md) has no result to record - route to /pm-prototype first.

Step 2: Generate artifacts

Generate in English.

Hypothesis types

Experiment types

Decision rule for experiment selection:

• Problem hypothesis → Customer Interview first. If insufficient evidence: Survey.
• Customer hypothesis → Targeted Ads + Landing Page. Measure: conversion rate, cost per sign-up.
• Solution hypothesis → Smoke Test (fake door click rate) or Concierge MVP (payment + retention).
• Market hypothesis → Pre-order or Waitlist. Only strong signal: credit card pulled or explicit commitment.

No-code / clickable prototype → route to /pm-prototype. When the experiment assigned to a hypothesis is a No-code Prototype (or any clickable prototype, including the prototype side of a Wizard of Oz test), this skill does not design or build it. Record the hypothesis and its success criteria here as usual, then hand over: /pm-prototype runs its own intent gate (is a prototype the cheapest test of this belief at all), decides audience, depth and path, builds it, and records the result. Carry the HYP-ID across so the prototype's meta.md lists it under targets and the result can find its way back. The success criterion written in this register is the one the prototype is judged against - do not let a second, different one be written there.

A prototype result comes back as one of four verdict states, and only two of them update a hypothesis:

For the last two, leave Status and Decision as they were and add a dated note in Result that the attempt happened and why it carried no evidence - an attempt nobody can see gets repeated.

Three limits on what a prototype result can carry:

• It is behaviour on a prototype, not commitment. It never satisfies a Market hypothesis on its own - the commitment levels below still apply.
• Desirability is not settled by a prototype alone; it supplies the stimulus, target-user behaviour supplies the evidence.
• A workbench prototype (built wide, cut down by roadmap phase) produces decisions, not a verdict. A room agreeing over it is stakeholder alignment and updates no hypothesis.

What counts as commitment (in order of strength):

1. Credit card / pre-payment - strongest
2. Letter of intent (B2B) or signed pilot agreement
3. Email sign-up from targeted ICP (not friends)
4. Click-through from paid traffic (shows intent, not commitment)
5. Verbal agreement - weakest, do not count as validation

Signal validity rules (apply in both modes):

• A conversion metric needs a minimum denominator before it means anything: ≥100 visitors from targeted (not friends/family) traffic for a landing-page rate, ≥10 ICP interviews for a qualitative pass, a full natural decision cycle (or ≥2 weeks) for pre-order tests. Below the floor, record the result as Inconclusive - never Pass or Fail. "5% conversion" from 20 visitors is one person; it is noise.
• No moving the goalposts: the Results-mode verdict is judged against the success criteria recorded in Plan mode. If a criterion was genuinely mis-set, revise it explicitly as a new register version (HYP-00X v2, with the reason) - never silently reinterpret a miss as a pass.
• Watch the substitution error: engagement (clicks, likes, "sounds great") substituting for commitment. Only commitment levels 1-3 above count toward a Market or Solution pass.

ARTIFACT 1: Hypothesis Register

# Hypothesis Register - [Product Name]

> **Phase:** 3 - Define & Validation
> **Last updated:** [date]
> **Status:** [X hypotheses / X validated / X rejected / X in progress]

---

## ICP Definition

> The Ideal Customer Profile is the razor-sharp definition of who we are validating with.
> "Small businesses" is not an ICP. Define role, context, company size, and specific pain context.

**ICP:** [Role] at [company type/size] who [specific situation/context] and [specific pain/trigger].

**Example:** "Freelance UX/UI designers with 3+ active client projects who manage feedback via email and Figma comments and spend 1+ hour/day chasing scattered input."

---

## Assumption Map

Before hypotheses: the core beliefs that must be true for this business to work.

| Assumption | Type | Riskiest? | Why |
|---|---|---|---|
| [Belief 1] | Problem / Customer / Solution / Market | Yes / No | [What breaks if this is wrong] |
| [Belief 2] | | | |
| [Belief 3] | | | |

**Most dangerous assumption:** [The one that, if false, makes everything else pointless. Test this first.]

---

## Hypothesis Register

| ID | Type | Hypothesis | Riskiest | Experiment | Success Criteria | Status | Result | Decision |
|---|---|---|---|---|---|---|---|---|
| HYP-001 | Problem | We believe [specific pain] exists for [ICP] at [frequency/intensity] | Yes / No | [Experiment type] | [Pre-defined measurable target] | Not started / Running / Complete | [Evidence] | Confirmed / Rejected / Inconclusive |
| HYP-002 | Customer | | | | | | | |
| HYP-003 | Solution | | | | | | | |
| HYP-004 | Market | | | | | | | |

---

## Experiment Plans

### [HYP-001] - [Short hypothesis name]

**Experiment type:** [Customer Interview / Landing Page / Pre-order / ...]
**What we're testing:** [The specific belief being tested - one sentence]
**Method:** [How: target channel, message, call to action, budget if applicable]
**ICP targeting:** [Who specifically, where to find them]
**Duration:** [X days / X interviews]
**Budget:** [€X or time only]

**Success criteria (defined before running):**
- Quantitative: [e.g., ≥5% landing page conversion from targeted traffic]
- Qualitative: [e.g., ≥7/10 interviewees confirm pain without prompting]
- Financial: [e.g., ≥10 pre-orders at €29 within 30 days]

**Signals to watch for:**
- Positive: [e.g., unprompted workaround descriptions, immediate follow-up interest]
- Negative: [e.g., polite agreement but no sign-up, "I'd use it if it were free"]

**Interview approach (if applicable):**
Do not pitch. Ask about past behavior and specific experiences, not hypothetical reactions to your solution.
- "Walk me through the last time you had to deal with [the specific problem]."
- "What was the most frustrating part of that?"
- "Have you tried to solve this before? What happened?"
- "What do you do now when you don't have a solution for this?"

---

### [HYP-002] - [Short hypothesis name]

[same structure]

ARTIFACT 2: Go/No-Go Decision

Generate after results are in. Do not generate in Plan mode.

# Validation Go/No-Go - [Product Name]

> **Date:** [date]
> **Phase:** 3 - Define & Validation exit
> **Hypotheses tested:** [X total / X confirmed / X rejected / X inconclusive]

---

## Evidence Summary

| Hypothesis | Type | Result | Pre-defined criteria met? |
|---|---|---|---|
| HYP-001 | Problem | [1-sentence result] | Yes / No / Partial |
| HYP-002 | Customer | | |
| HYP-003 | Solution | | |
| HYP-004 | Market | | |

**Strongest signal:** [The most compelling evidence collected - quote or number]
**Weakest signal:** [Where evidence was thin or mixed]

---

## Decision

**Verdict: GO / PIVOT / STOP**

---

### GO - confirmed signals across problem, customer, and market

All three of the following must be true:
- Problem hypothesis confirmed: ICP describes the pain without prompting, rates it high-priority
- Customer hypothesis confirmed: ICP exists, is reachable, engages with targeted outreach
- Market hypothesis confirmed: meaningful commitment signal (pre-order, letter of intent, or waitlist conversion ≥5% from targeted ICP traffic)

→ Proceed to Phase 4 (Domain Modeling). Solution hypothesis can remain partially open - it gets tested further in the MVP phase.

---

### PIVOT - mixed signals, clear direction to change

Something specific is not working but the evidence points at what to change:
- Problem hypothesis confirmed but ICP was wrong → redefine target segment, re-run Customer + Market tests
- ICP confirmed but problem is different than assumed → reframe solution, run new Solution hypothesis
- Strong problem + customer signal but no willingness to pay → reprice, reframe value prop, or reassess market

**What changes:** [Specific assumption being revised - be explicit: Problem / Customer / Solution / Market]
**New experiment:** [What runs next and with what success criteria]

---

**PIVOT escalation rule:**

After each PIVOT, record which core element changed:

| PIVOT # | What changed | Problem | Customer | Solution | Market |
|---|---|---|---|---|---|
| 1 | [describe] | changed / same | changed / same | changed / same | changed / same |
| 2 | [describe] | changed / same | changed / same | changed / same | changed / same |

If by PIVOT 2 all four elements have changed at least once across the two PIVOTs, trigger a structured review before running new experiments:

> **Escalation review:** You have revised the core problem, customer, solution, and market at least once. This pattern indicates the original hypothesis was fundamentally wrong, not just misaligned on one dimension.
>
> Before continuing: is this still the same product idea or effectively a new one? If the problem, customer, and solution are all different from where you started, you are not iterating - you are starting over. A new project with a clean slate is more efficient than continuing to patch a broken premise.
>
> At this point use AskUserQuestion tool with:
> - Question: "This is iteration 3 - how do you want to proceed?"
> - Option A: "Continue with current direction - set a final deadline and budget ceiling (Recommended if one element is still solid)"
> - Option B: "Archive this idea and apply learnings to a new hypothesis"
> - Option C: "Narrow scope - one of the three (Problem/Customer/Solution) is still solid, rebuild around that anchor"

After PIVOT 3 on the same project without a GO, issue STOP unless A) was explicitly chosen and the deadline has not passed.

---

### STOP - weak or absent signals across critical hypotheses

One of the following is true:
- Problem hypothesis not confirmed after 10+ ICP interviews: pain is not severe enough to act on
- Market hypothesis failed: no meaningful commitment signal after quantitative test with adequate ICP traffic
- Willingness to pay not demonstrated after pre-order or concierge MVP test

This is not failure. It is a successful experiment that prevented years of wasted effort. Negative validation data has real value - it redirects attention to a problem worth solving.

**Key learnings:** [What was discovered that can inform the next idea]

Internal completeness checklist

Hypothesis Register (Plan mode) must cover:

• ICP defined with specificity: role, context, company size, pain trigger (not "small businesses")
• Assumption map complete: at least one hypothesis per type (Problem / Customer / Solution / Market)
• Riskiest assumption identified and marked - the one that, if false, invalidates everything else
• Every hypothesis has a pre-defined success criterion (quantitative OR qualitative + financial) set BEFORE the experiment runs
• Experiment type matches hypothesis type (see decision rule above)
• Interview questions follow The Mom Test principle: past behavior, not hypothetical future

Go/No-Go (Results mode) must cover:

• Every hypothesis has a result recorded (even "no data" is a result)
• Verdict is one of three: GO / PIVOT / STOP - not "promising" or "needs more time"
• If PIVOT: specific assumption named and new experiment defined
• If STOP: learnings recorded (what was discovered, not just what failed)
• Evidence includes at least one concrete signal (a number, a quote, or a payment)
• Prototype results recorded by their four-state verdict; Prototype or study failure and Inconclusive changed no hypothesis; a Supported result carries its scope

Notion

Read pureinn-variables.md key "Hypothesis Validation" → if URL present, remind user after saving: Hypothesis Register saved locally. Update Notion: [Hypothesis Validation URL]

Read pureinn-variables.md key "Open Questions" → if DB URL present, check state.json notion_ids.open_questions. Open questions and decisions from the hypothesis process can be pushed as entries to this DB. Remind user: Open questions can be logged to Notion DB: [Open Questions URL]

Save to

pureinn-workspace/[project-slug]/artifacts/phase-3-define/hypothesis-register.md
pureinn-workspace/[project-slug]/artifacts/phase-3-define/go-no-go.md

Handoff

Plan mode:

Čo si teraz má: Štruktúrovaný experiment plán s pre-definovanými success criteria. Hypotézy sú pripravené na testovanie - nezačínaj experimenty bez tohto registra.

Ďalší krok: 👤 Spusti experimenty podľa plánu (landing page / smoke test / pre-order / concierge MVP). Ak je experimentom no-code alebo klikateľný prototyp: /pm-prototype - postaví ho a vráti verdikt v jednom zo štyroch stavov. Po dokončení experimentov: /pm-hypotheses [Results mode] pre Go/No-Go verdikt.

Môžeš preskočiť experimenty a ísť priamo na Results mode ak: Máš už výsledky z predchádzajúcej validácie (externý workshop, Miro, iný nástroj) - povedz /pureinn "Phase 3a done elsewhere" a dodaj verdikt + kľúčové evidencie.

Results mode:

Čo si teraz má: Go/No-Go verdikt s evidenciou.

GO → Ďalší krok: /pm-kotler — začíname Phase 3b Commercial Definition. Spusti /pureinn pre gate check a potvrdenie.

PIVOT → Ďalší krok: /pm-hypotheses [Plan mode] — prepracuj riskiest assumption a navrhni nový experiment. Ktorú hypotézu meníš?

STOP → Ďalší krok: Zaznamenaj learnings. Projekt sa ukončuje. Čo ste sa naučili? (toto má hodnotu pre budúce projekty)