MVP (minimum viable product)

Termin wiąże się z SyncDev, metodyką amerykańskiej firmy Product & Market Development, której prezesem był Frank Robinson. Spopularyzował go Eric Ries. Obaj definiują MVP inaczej i ta różnica tłumaczy większość nieporozumień. Dla SyncDev MVP to produkt o najlepszym stosunku zwrotu do ryzyka: na tyle duży, żeby klienci go przyjęli, byli zadowoleni i kupowali. Dla Riesa to wersja, która przy najmniejszym wysiłku daje najwięcej sprawdzonej wiedzy o klientach.

Marty Cagan, żeby nie mieszać eksperymentu z produktem, mówi o "MVP Test". Najstarsze sprawdzone użycie terminu to strona SyncDev z 2008 r. Rok 2001, podawany w wielu tekstach jako data wprowadzenia terminu przez Robinsona, pochodzi tylko ze źródeł wtórnych.

Bo zaczyna się od pytania, a nie od listy funkcji. Okrojona wersja 1.0 powstaje przez wycinanie funkcji z docelowego produktu, aż zmieszczą się w budżecie, i zwykle nie wiadomo, czego ma nauczyć. Steve Blank pisze, że founderzy traktują "minimum" jak cel, a w 2013 r. dodaje, że MVP nie zawsze jest mniejszą i tańszą wersją produktu końcowego. Rik Higham zauważa, że nazwę MVP często błędnie przypina się do pierwszego wydania prymitywnego produktu.

Najbardziej znany obraz tej różnicy narysował Henrik Kniberg w 2016 r.: w górnym rzędzie zespół buduje samochód z koła, podwozia i karoserii, z których klient przez długi czas nic nie ma, a w dolnym daje mu kolejno deskorolkę, hulajnogę, rower i motocykl, z których każdy już jeździ. Sam autor zaznacza, że to metafora, a nie instrukcja budowania samochodów.

Każde z tych pojęć odpowiada na inne pytanie. Proof of concept sprawdza, czy koncepcja się broni, prototyp pokazuje, jak rozwiązanie ma działać i wyglądać, a MVP sprawdza, czy klienci chcą z produktu korzystać i za niego płacić. Zwykle kolejność jest taka: najpierw proof of concept, a po pozytywnym wyniku rozwój w stronę MVP.

Źródła nie są tu zgodne. U Cagana prototyp jest jedną z technik MVP, a w definicji Riesa działający PoC testowany z pierwszymi użytkownikami też byłby MVP. W polskich tekstach firm budujących oprogramowanie pada za to często zdanie "MVP to nie prototyp". Obie strony mają rację w swojej definicji, więc zanim zaczniesz rozmowę o MVP z wykonawcą albo inwestorem, ustalcie, którą z nich macie na myśli.

W znaczeniu Riesa MVP nie musi być aplikacją. W polskim wydaniu jego książki, "Metoda Lean Startup", MVP nazywa się "minimalnie satysfakcjonującym produktem", a osobne podrozdziały opisują MVP w formie filmu i ręcznie obsługiwanej usługi. Najczęściej opisywane rodzaje:

Steve Blank opisuje w tekście z 2013 r. startup, który chciał miesiącami budować drona z kamerą dla rolników. Blank zaproponował, żeby zamiast tego wynajęli samolot, ręcznie przetworzyli zdjęcia i sprawdzili, czy rolnicy za takie dane zapłacą.

Nowe nazwy powstają, bo słowo MVP znaczy dla różnych osób co innego, a "minimum" bywa czytane jako zgoda na byle jaki produkt. Agile Alliance wymienia wśród typowych błędów przesadny nacisk na "minimum" kosztem "viable". Najczęściej spotykane odmiany:

Steve Blank pisze we wrześniu 2026 r., że MVP pełniło na jego zajęciach dwie role. Pokazywało kompetencje techniczne zespołu i jego wiedzę o problemach klientów, a do tego służyło do testowania całego modelu biznesowego. Skoro zespoły budują produkty przez vibe coding, MVP nie jest już dowodem kompetencji technicznych ani wiarygodnym dowodem pracy z klientami. Blank nie rezygnuje z AI, tylko zmienia program zajęć.

Zostaje pytanie, które Cagan stawiał już w 2012 r.: produkt minimalny działa i da się go użyć, ale produkt "viable" to taki, który klienci faktycznie wybierają. To drugie sprawdza się w rozmowach i zachowaniu klientów, a nie w samym fakcie, że aplikacja działa.