Frame the bet.
Name the change, the audience, the outcome, and why you expect it to work. Decide what would prove you wrong.
The framework / 01
Turn uncertainty
into direction.
A practical way to decide what to build, learn whether it worked, and choose what comes next.
01Start with the destination
A vision is steady.
The route isn’t.
Start with the business you want to build. Choose a measurable milestone on the way there. Then make a small bet about how to reach it.
Your vision gives the work a purpose. Your mission gives it an outcome. A hypothesis tests the route. Tasks make it happen.
Vision→Mission→Hypothesis→Tasks
02The learning loop
Four moves.
No crystal ball.
Build to learn.
Ship the smallest useful change that tests the idea. Put it in real hands, with measurement in place.
Read the evidence.
Watch what people actually do. Compare the outcome to your prediction, including what surprised you.
Make the call.
Scale it, change it, or stop it. Record the learning and let it shape your next bet. Then go again.
03Anatomy of a better bet
“Let’s add a feature”
isn’t a hypothesis.
A good bet tells you what you’ll change, who it’s for, and how you’ll know whether it worked.
Try it with your product ↗Field note / a working hypothesis№ 001
Illustrative examples, not reported client results.
Write the prediction
before the code.
We believe that [action] will result in [outcome], validated by [audience] using [measurement], because [rationale].
Add a baseline, a target, a review date, and a result that would make you stop. Those details prevent a team from calling any outcome a success after the fact.
Start small enough to learn.
Keep each experiment focused on an uncertainty worth resolving. Use a prototype, a manual service, or a limited release when that can answer the question. When the experiment needs real software, keep it useful and reliable.
Measure what matters.
Choose one primary outcome, such as completed onboarding, repeat use, or paid conversion. Set guardrails for things you must not damage, such as error rates or customer trust. Define the audience and collect a baseline before interpreting change.
Give every bet a verdict.
At the weekly review, read the evidence together. Scale a promising change, iterate on what you learned, or stop a bet that didn’t hold up. If there isn’t enough evidence, say so and set a new read date. A deadline is not a substitute for a meaningful sample.
Let the learning change the plan.
If no finding ever removes something from your roadmap, you may be narrating the plan rather than testing it. Record the decision and its reason so the next experiment starts with more knowledge.
Keep the process honest.
Does every task need a hypothesis?
No. Fix broken payments, meet essential requirements, and do necessary maintenance. Save the hypothesis structure for meaningful uncertainty. Research that identifies a problem can lead to a bet; it isn’t automatically an experiment.
Is HDD the same as A/B testing?
No. A/B tests are one tool. Interviews, prototypes, concierge tests, and staged releases can answer different questions. Choose the method that can challenge the assumption, and be honest about what the evidence can establish.
What if we don’t have many users yet?
Begin with direct conversations and observed behavior. Test whether people understand the offer, complete the key task, or commit time or money. Small samples can reveal friction, but avoid treating them as statistically conclusive.
Does this mean abandoning the roadmap?
No. Keep your destination and near-term priorities clear. Treat proposed solutions as bets whose order can change as you learn. Commit to the problem and the outcome, then earn confidence in the solution.