/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]

MINIM