Validating Strategic Assumptions
Pursue Ecosystem-Potential-Platform Fit by surfacing leap-of-faith assumptions and designing minimum experiments to test them
Strategic intent: Before committing to detailed platform design, pursue Ecosystem-Potential-Platform Fit by identifying the assumptions that — if wrong — would invalidate everything, and designing the cheapest possible experiments to test them.
Overview
The Boundaryless framework names the goal of this phase: Ecosystem-Potential-Platform Fit. The PSM hypotheses produced in Platform Value Propositions all rest on assumptions. Some are safe (reasonable inferences from existing evidence). Others are bets — beliefs without evidence that the entire strategy depends on. This technique surfaces the leap-of-faith assumptions, prioritizes them by risk, and designs experiments to validate or invalidate them.
The output is not just data but decisions: which hypotheses survive, which need more evidence, which are killed.
When to use it
- After Platform Value Propositions has produced a set of testable hypotheses
- Before investing in MVP development
- Anytime a hypothesis cannot be confidently grounded in existing evidence
- After any major pivot or scope change
Composition
1. Surface assumptions
For each value-proposition hypothesis from the PSM, list every assumption it depends on. Use the form: "For this hypothesis to be true, X must be true."
Duration: 2 hours
Probe across these categories:
- Demand assumptions — does this entity actually want this outcome? (Jobs to be Done framing helps here)
- Supply assumptions — can the other entity actually deliver?
- Behavioral assumptions — will entities switch from current alternatives?
- Economic assumptions — at what price/cost is this viable?
- Technical assumptions — can the platform actually mediate this?
3. Design Minimum Viable Platform experiments
For each leap-of-faith assumption, design the cheapest experiment that could falsify it.
Canvas: MVP Canvas · Duration: 2–3 hours
Common experiment shapes Boundaryless practitioners use:
- Existing-Experience Scan — analyze what users already do (no intervention) using the Existing Experience Ecosystem Scan
- Concierge MVP — manual delivery to test demand without building tech
- Smoke test — landing page or pre-order to gauge interest
- Wizard of Oz — fake automation while you observe behavior
- Painted-door test — placeholder feature to measure click-through
Choose based on which assumption you're testing.
4. Run, learn, decide
Execute the experiments. Document evidence. For each hypothesis, decide: validated (proceed), invalidated (kill or pivot), or inconclusive (more evidence needed).
Duration: variable (days to weeks for field validation)
The result is a refined strategic brief: hypotheses validated/invalidated/refined, ready for the next pipeline.
Inputs
- Required: value-proposition hypotheses (the PSM) from the previous technique
- Required: access to potential users for interviews / smoke tests
- Recommended: budget and timeline for experiments (typically 2–6 weeks)
Outputs
- Assumption map — every assumption underlying each hypothesis, classified by evidence and impact
- List of leap-of-faith assumptions — top 3–5 to test
- Experiment designs — one per leap-of-faith assumption, with hypothesis, method, success criteria, disconfirming evidence
- Strategic brief update — hypotheses validated / invalidated / refined
- A clear decision to proceed to platform design, pivot, or kill
Process heuristics
Design for falsifiability, not for confirmation. A good experiment specifies what evidence would prove you wrong. If no realistic outcome could change your mind, the experiment is theatre.
- Cheaper is better — if the experiment costs more than building the feature, it's not an experiment
- Time-box explicitly — "we'll know in 2 weeks" prevents indefinite drifting
- Define disconfirming evidence in advance — "if fewer than X% of users show interest, we kill it"
- Run experiments in parallel when assumptions are independent
- Don't validate everything — only the leap-of-faith ones
- Existing-Experience Scans are underutilized — observing current behavior often gives more validation than asking users hypothetical questions
Validation criteria
- Each value-proposition hypothesis has its assumptions surfaced
- Top 3–5 leap-of-faith assumptions identified
- Each leap-of-faith has a designed experiment with clear success/failure criteria
- Experiments are time-boxed
- Disconfirming evidence is specified before running
- At the end, a clear decision per hypothesis (validated / invalidated / inconclusive)
Common mistakes
- Validating safe assumptions — wasted effort on things you already know
- Hypotheses that can't be falsified — "users will love it" isn't testable
- Sunk-cost commitment — running experiments to confirm what you've already built
- Over-elaborate experiments — a Concierge MVP for 5 users beats a fully built MVP for 0
- Skipping this technique — leap-of-faith assumptions don't go away because you ignored them
Used in pipelines
- Understanding Ecosystems — as Phase 4 (the validation gate)
Connections
- Requires: Platform Value Propositions
- Feeds: Designing Platform Experience — only validated hypotheses move forward
- Uses outputs of: Existing Experience Ecosystem Scan when running observational experiments
Related reading
- The PDT Platform Opportunity Exploration Guide — section on validation in Legacy PDT Exploration
- Discover Platform Opportunities with the Exploration Guide — the broader framing of the exploration → validation flow