The Hydrogen Remote Monitoring concept work started with an explicit, falsifiable hypothesis rather than a feature list: a standalone software play for hydrogen site management was sizeable and worth pursuing on its own. That hypothesis was tested against six operator interviews - and it broke. The market was too small to stand alone. That is the hypothesis doing its job.
A hypothesis is different from a requirement in one respect: it is written so that evidence can prove it wrong. "Users want a dashboard" is not a hypothesis - nobody can disagree with it in an interview. "Operators will pay for standalone remote-monitoring software separate from their existing platform" is a hypothesis, because six conversations can and did contradict it.
What held up
Sway’s bet that group decision paralysis is a bigger problem than restaurant discovery - validated by every persona interview landing on the same "just pick something" complaint.
What didn’t
The hydrogen concept’s bet that remote site management could be a standalone product - the addressable market at low site counts through 2030 didn’t support it, and the project pivoted to extending an existing platform instead.
Before research starts, write down:
- The bet, in one sentence, phrased so it can fail.
- What evidence would prove it wrong - decided in advance, not after the interviews are in.
- What changes if it does fail: kill the idea, narrow it, or pivot the mechanism.