The Challenge
Technical exploration is necessary but expensive. Without structure, R&D efforts drift: interesting tangents consume weeks, promising ideas die from neglect, and the organization can't distinguish "we tried and it doesn't work" from "we didn't try hard enough."
We needed a lightweight framework that would let engineers explore new ideas rapidly while producing clear, actionable conclusions.
The Framework
We call it Bounded Exploration — a four-phase process designed for 1-4 week technical investigations.
Phase 1: Framing (Day 1)
Before writing any code, answer four questions:
- What hypothesis are we testing? State it as a falsifiable claim.
- What does success look like? Define measurable criteria.
- What's the time box? Set it and commit to it.
- What's the minimum viable experiment? Strip away everything that doesn't directly test the hypothesis.
Example framing document:
## Hypothesis
A CRDT-based document model can support 50 concurrent
editors with <100ms merge latency on commodity hardware.
## Success Criteria
- Merge latency P95 < 100ms with 50 simulated editors
- Memory usage < 500MB for a document with 10,000 operations
- No data loss or ordering violations in 1-hour test runs
## Time Box
2 weeks (10 working days)
## Minimum Experiment
- Implement Yjs-based document sync
- Build a load testing harness with simulated editors
- Measure merge latency and memory under load
- No UI, no persistence, no auth
Phase 2: Spike (Days 2-N)
Build the minimum viable experiment. Rules:
- No production concerns: Skip error handling, logging, security, and clean architecture. This code exists to answer a question, not to ship.
- Instrument aggressively: Measure everything related to the success criteria. If you can't measure it, you can't conclude anything.
- Document surprises in real-time: Keep a running log of unexpected findings. These are often more valuable than the original hypothesis.
Phase 3: Evaluation (Final Day)
Evaluate results against success criteria. The outcome is one of:
| Outcome | Meaning | Next Step |
|---|---|---|
| Validated | Success criteria met | Write a proposal for production implementation |
| Partially validated | Some criteria met, others not | Document what worked, what didn't, and what would need to change |
| Invalidated | Hypothesis is wrong | Document why — this is valuable knowledge |
| Inconclusive | Can't tell from this experiment | Identify what additional work would resolve the ambiguity |
"Inconclusive" is the worst outcome. It means the experiment was either poorly designed or under-resourced. We treat it as a process failure, not a technical one.
Phase 4: Artifact (Same Day)
Produce a single document that captures:
- The original framing
- What was actually built
- Results with data
- Conclusion and recommendation
- Key surprises or side discoveries
This document must be understandable by someone who wasn't involved in the experiment. It joins our internal knowledge base and becomes a reference for future decisions.
What We've Learned
Time Boxes Work
In two years of using this framework, we've completed 34 bounded explorations. Average duration: 8 working days. Of those:
- 12 led to production implementations
- 9 were invalidated (saving months of wasted development)
- 8 were partially validated and informed architectural decisions
- 5 were inconclusive (we've gotten better at avoiding this)
The Framing Phase is Non-Negotiable
Early on, we tried skipping straight to code. The result was invariably scope creep and fuzzy conclusions. Taking one day to frame the experiment properly saves days of unfocused work.
Kill Your Darlings
When the time box expires, stop. If the results are promising but incomplete, that's a "partially validated" outcome — file it and decide later whether to invest more time. The discipline of stopping is what makes the framework sustainable.
Applying This Framework
This approach works for any team that does technical exploration. The specifics (time box length, document format, evaluation criteria) should be adapted to your context. The non-negotiable elements are:
- State a falsifiable hypothesis before starting
- Define measurable success criteria
- Commit to a time box
- Produce a reusable artifact regardless of outcome
The goal is not to eliminate uncertainty from R&D — that's impossible and undesirable. The goal is to make uncertainty visible and bounded, so the organization can make informed investment decisions.