Hypothesis-driven development (rozwój oparty na hipotezach) to podejście, w którym funkcje produktu formułuje się nie jako pewniki do zbudowania, lecz jako hipotezy do zweryfikowania: „wierzymy, że [zmiana] przyniesie [efekt]; uznamy to za potwierdzone, gdy [metryka] osiągnie [próg]". Budujesz najmniejszą rzecz, która pozwala hipotezę sprawdzić - i mierzysz.
Analityk w tym modelu zmienia rolę: zamiast spisywać wymagania jako listę życzeń, projektuje eksperymenty. To wymaga zdefiniowania metryki PRZED budową, ustalenia progu sukcesu i - co najtrudniejsze - kryterium porażki, czyli zgody na to, że pomysł może nie wypalić.
W MediFlow tak potraktowano przypomnienia o wizytach. Hipoteza: „wierzymy, że SMS 24 godziny przed wizytą z linkiem do odwołania zmniejszy odsetek nieodbytych wizyt (no-show) z 14% poniżej 10%; zmierzymy to w 6-tygodniowym pilotażu w 2 przychodniach". Wynik: 9,2% - hipoteza potwierdzona, wdrożenie we wszystkich 12 placówkach. Druga hipoteza z tego samego projektu poległa: dodatkowy e-mail tydzień przed wizytą nie ruszył wskaźnika wcale (13,8%) i został wycięty, zamiast - jak to zwykle bywa - żyć wiecznie, bo „już jest zrobiony".
Częsta pomyłka: pisanie „hipotez", których nie da się obalić. „Wierzymy, że nowy portal poprawi doświadczenie pacjentów" - brak metryki, brak progu, brak terminu; cokolwiek się stanie, można ogłosić sukces. Jeśli z eksperymentu nie może wyjść „nie" - to nie eksperyment, tylko zwykły plan z modnym nagłówkiem.