Hypothesis

---
name: hypothesis
description: >
  Activate for: assumption, hypothesis, assumption map, MVP, minimum viable
  product, lean startup, what assumptions am I making, test my idea, what
  could go wrong, assumption risk, validate assumption, kill my idea,
  stress test, what should I test first, MVP design, MVP scoping, what to build,
  minimum feature set, success criteria, failure criteria, pivot criteria,
  build plan, riskiest assumption, leap of faith assumption, critical assumption.
  NOT for: idea generation (use idea), customer discovery (use discovery),
  pilot results analysis (use validate).
license: Apache-2.0
metadata:
  author: Panaversity
  version: "1.0"
  plugin-commands: "/hypothesis"
---

## CONTEXT LOADING

Before executing, check for `innov.local.md` in the working directory.
If found, extract:

- venture: name, stage, type, problem_statement, target_customer, solution_hypothesis
- key_assumptions: all entries with IDs, risk levels, evidence, test status
- customer_profiles: personas and validated pains

If `innov.local.md` is not found:
Continue with conversation context. After first substantive output, prompt:
"I'm working without your venture context. Run Exercise 8 from Chapter 40
to build innov.local.md -- it will make every subsequent output specific
to your venture rather than generic."

## STAGE-AWARE CALIBRATION

Check venture.stage and calibrate:

- IDEA: Warning -- "You are mapping assumptions before discovery. Consider running /discovery first to ground your assumptions in customer evidence rather than guesses."
- DISCOVERY: Assumption mapping is appropriate -- you are transitioning from problem understanding to solution hypotheses.
- VALIDATION: This is your focus stage. Full assumption mapping and MVP design are the priority.
- MVP: Assumption mapping remains critical -- are you testing the right things with your build?
- GROWTH: Assumption mapping is still useful for new features or expansion hypotheses.

## DLA PROGRESSION CHECK

If no customer_profiles or discovery data exist in innov.local.md:
"You are mapping assumptions without customer discovery data.
Your assumptions will be based on guesses rather than evidence.
Consider running /discovery first -- the cost of bad assumptions
is building the wrong product."

## HYPOTHESIS AND MVP WORKFLOW

### Task Types

TYPE 1: ASSUMPTION MAP BUILD
  Purpose: Make all venture assumptions explicit; score by risk; design tests.
  Input: Venture context (from innov.local.md or conversation)
  Output: Full assumption map in three tiers with test designs

TYPE 2: ASSUMPTION PRIORITISATION
  Purpose: Identify the riskiest untested assumption to address first.
  Input: Assumption map
  Output: Prioritised test sequence with rationale

TYPE 3: MVP DESIGN
  Purpose: Scope the minimum product that tests the critical assumptions.
  Input: Top 3 assumptions to test; team; time budget
  Output: Feature set (in/out), success criteria, failure criteria, build plan

TYPE 4: VALIDATION PLAN
  Purpose: Design specific, cheap tests for a set of assumptions.
  Input: Assumption list with IDs
  Output: Week-by-week validation calendar with test methods and costs

### Assumption Map Output Structure

```
ASSUMPTION MAP
Venture: [Name] | Stage: [Stage] | Date: [Date]
================================================================
TIER 1 -- EXISTENTIAL (if wrong, pivot required):

  A-001: [Assumption statement -- specific]
  Risk: HIGH | Evidence: [ASSUMED / ANECDOTAL / VALIDATED]
  Why existential: [What fails if this assumption is wrong]
  Cheapest test: [Specific test -- ideally: talk to someone, not build something]
  Test cost: [Time + money]
  Status: [UNTESTED / TESTING / VALIDATED / INVALIDATED]

  [Repeat for each existential assumption -- typically 3-6]

TIER 2 -- SERIOUS (if wrong, product changes significantly):
  [Same structure -- typically 4-8 assumptions]

TIER 3 -- IMPORTANT (if wrong, optimisation required):
  [Same structure -- typically 5-10 assumptions]

TEST PRIORITY ORDER:
  Week 1-2: [A-00X + A-00X] -- zero or near-zero cost tests
  Week 3-4: [A-00X + A-00X] -- may require prototype or small build
  Month 2+: [A-00X] -- requires pilot or live test
================================================================
```

### Assumption Categories (use to ensure completeness)

CUSTOMER assumptions:
  -- The customer segment we identified is real and reachable
  -- They have the pain we think they have, with the severity we think it has
  -- They are currently trying to solve this problem (it's not just latent)
  -- They have authority/budget to buy a solution

PROBLEM assumptions:
  -- The problem is frequent enough to justify a dedicated solution
  -- The current solutions are genuinely inadequate (not just sub-optimal)
  -- Customers are willing to change their behaviour to solve it

SOLUTION assumptions:
  -- Our solution technically works as designed
  -- Customers can and will use it (adoption)
  -- It solves the problem at the quality level customers need

BUSINESS MODEL assumptions:
  -- Customers will pay our price
  -- We can acquire customers at our assumed CAC
  -- Customers will stay (churn assumption)
  -- Our gross margin is achievable

TECHNICAL assumptions:
  -- The core technology works at the required accuracy/scale
  -- We can build it with the team we have

### Assumption Risk Scoring Rule

Assign HIGH risk when: if this assumption is wrong, we either (a) have no
revenue, (b) cannot build the product, or (c) cannot acquire customers at
a viable cost.

The question to ask: "If I discovered this was wrong tomorrow, would I
change direction?" If yes -> HIGH. If maybe -> MEDIUM. If probably not -> LOW.

### MVP Design Output Structure

```
MVP DESIGN DOCUMENT
Venture: [Name] | Timeline: [N] weeks | Target: [N pilots / $X MRR]
================================================================
CORE PURPOSE OF THIS MVP:
Test [N] things: (1) [Assumption A-00X]; (2) [Assumption A-00X]; (3) [A-00X]

MINIMUM FEATURE SET (build these; nothing else):

  FEATURE [N]: [Name]
  Why minimum: [Why this feature is necessary to test a critical assumption]
  Spec: [Precise description -- what it does; what it does not do]
  Tests: [Assumption ID(s) this feature tests]

EXPLICITLY EXCLUDED (do not build):
  - [Feature]: [Why excluded -- what assumption it does NOT test]
  [Continue -- the exclusion list is as important as the inclusion list]

SUCCESS CRITERIA (pivot-or-continue decision at end of MVP period):
  - [Specific measurable outcome] -- validates [Assumption A-00X]
  [Each criterion maps to one or more critical assumptions]

FAILURE CRITERIA (triggers pivot conversation):
  - [Specific threshold] -> [assumption this invalidates] -> [what to consider]

BUILD PLAN:
  Week 1-N: [What gets built each week]
================================================================
```

### The Minimum Viable Test (MVT) Hierarchy

Before building anything, ask: can this assumption be tested more cheaply?

  LEVEL 1 -- CONVERSATION: Just ask customers (cost: 30 minutes)
  LEVEL 2 -- LANDING PAGE / WAITLIST: One-page description, measure sign-ups (cost: 1 day)
  LEVEL 3 -- CONCIERGE MVP: Do the job manually for a customer (cost: your time)
  LEVEL 4 -- WIZARD OF OZ: Customer-facing surface; back-end manual (cost: dev time + your time)
  LEVEL 5 -- FUNCTIONAL MVP: Build the minimum that works end-to-end (cost: full dev time)

  Rule: Go to Level 5 only if Levels 1-4 cannot test the assumption.

## ASSUMPTION TRACKING

After any hypothesis output:
- Surface the most critical untested assumption
- Propose innov.local.md updates for any new or changed assumptions
- Always distinguish between ASSUMED, ANECDOTAL, and VALIDATED evidence
- If an assumption has been tested, update its status and evidence level

## NEVER DO THESE

- NEVER proceed to MVP design without a complete assumption map --
  you cannot scope minimum if you don't know what you're testing
- NEVER build a feature in the MVP that tests no critical assumption
- NEVER use vague success criteria ("users like it", "good adoption") --
  every success criterion must be specific and measurable
- NEVER let the MVP grow to test a TIER 3 assumption before all
  TIER 1 and TIER 2 assumptions are tested -- this is called MVP bloat
- NEVER call something "validated" because a few people said they liked it --
  validated means: N customers paid $X for it OR used it N times in N days

ALL OUTPUTS REQUIRE REVIEW BY A QUALIFIED PROFESSIONAL BEFORE USE IN BUSINESS DECISIONS.