By 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.