Minimalny produkt z wykonalnością to najmniejsza wersja produktu, która pozwala zespołowi dowiedzieć się czegoś istotnego o tym, czy klienci go chcą, co spopularyzował Eric Ries w książce „The Lean Startup”. Jego cechą definiującą nie jest to, że jest mały ani tani, ale to, że został stworzony, aby odpowiedzieć na konkretne pytanie, a pytanie to dotyczy zweryfikowanej wiedzy o zachowaniach klientów, a nie wewnętrznej opinii na temat wykonalności.
Najczęstszym nadużyciem jest traktowanie go jako synonimu pierwszej wersji z mniejszą liczbą funkcji. Pod presją terminów zespoły ograniczają zakres, wypuszczają coś niekompletnego, nazywają to MVP, a następnie nie mierzą niczego konkretnego, co nie prowadzi do powstania ani dobrego produktu, ani użytecznej lekcji. Kluczowym pytaniem jest, jaką konkretną hipotezę ta wersja przetestuje i jaki wynik skłoni zespół do zmiany kierunku. Jeśli nie ma odpowiedzi, wersja jest małym produktem, a nie minimalnie wykonalnym.
Zaniedbana zostaje również realna część terminu. Wersja, która jest minimalna, ale nie działa lub nie spełnia swojego pierwotnego celu, dostarcza dowodów na wdrożenie, a nie na popyt. Klienci odrzucający produkt z powodu jego powolności, awarii lub niejasności nie mówią zespołowi nic o wartości leżącej u jego podstaw. Wszystko, co jest zawarte, musi być wystarczająco dobre, aby poddać pomysł uczciwej próbie, nawet jeśli zakres wokół niego jest drastycznie ograniczony.
Kilka ugruntowanych wzorców odpowiada na pytania dotyczące popytu bez konieczności tworzenia pełnego produktu. Podejścia typu concierge polegają na ręcznym dostarczaniu usługi pierwszym klientom, aby dowiedzieć się, czego tak naprawdę potrzebują, zanim cokolwiek zautomatyzują. Implementacje Czarnoksiężnika z Krainy Oz oferują działający interfejs, w którym za wszystko odpowiadają ludzie. Testy landing page'y mierzą, czy ktokolwiek reaguje na propozycję przed rozpoczęciem prac. Każdy z nich dostarcza dowodów behawioralnych, które są znacznie silniejsze niż deklarowane intencje zebrane w ankietach i wywiadach dotyczących hipotetycznych produktów.
To podejście sprawdza się w niektórych kontekstach znacznie lepiej niż w innych. W regulowanych branżach, w systemach o krytycznym znaczeniu dla bezpieczeństwa oraz w sprzedaży korporacyjnej, gdzie jedno złe pierwsze wrażenie zamyka rynek na lata, celowe dostarczanie niekompletnego oprogramowania wiąże się z kosztami przewyższającymi naukę. W takich sytuacjach tę samą logikę lepiej zastosować poprzez prototypy, programy pilotażowe z udziałem poinformowanych uczestników oraz etapowe wdrożenia dla ograniczonej grupy odbiorców, niż poprzez publiczną premierę minimalnego produktu.
Wcześniejsze ustalenie, jaki wynik spowodowałby przerwanie pracy przez zespół, nadaje sens ćwiczeniu i jest krokiem najczęściej pomijanym. Bez ustalonego progu, każdy wynik można zinterpretować jako zachęcający: niskie wykorzystanie staje się problemem marketingowym, słaba retencja – problemem wdrożeniowym, a projekt jest kontynuowany w oparciu o wyjaśnienie, które je podtrzymuje. Przed uruchomieniem zapisanie, jaki poziom adopcji lub retencji uzasadniałby kontynuację, jaki poziom uzasadniałby zmianę podejścia i co uzasadniałoby całkowite przerwanie, przekształca wydanie w prawdziwy test. Chroni to również zespół, ponieważ udokumentowany próg uzgodniony przez interesariuszy jest znacznie łatwiejszy do zastosowania niż osąd wydany po fakcie.
Właściwie zastosowana koncepcja pozwala zespołowi zachować uczciwość co do różnicy między budowaniem a uczeniem się, a jest ona najbardziej wartościowa w sytuacjach, gdy niepewność co do zapotrzebowania jest naprawdę wysoka. W praktyce hipoteza i standard dowodowy są ustalane poprzez badania produktów, kompilacja jest z rozwój produktów, a dyscyplina polegająca na zdefiniowaniu z góry, jaki wynik wywoła zmianę kierunku, odróżnia to podejście od prostego, wczesnego rozpoczęcia. startupy w szczególności dyscyplina ta decyduje, czy ograniczony czas przeznaczony na naukę jest wykorzystany, czy też po prostu wykorzystany.