MVP, czyli minimum viable product (minimalny wykonalny produkt), to najmniejsza wersja produktu, która pozwala sprawdzić najważniejsze założenie na prawdziwych użytkownikach. Nie chodzi o „tanią wersję aplikacji", tylko o najkrótszą drogę do odpowiedzi na pytanie: czy ktoś tego naprawdę potrzebuje i czy zrobi to, czego się spodziewasz.
Jeśli trafiłeś tu z gier lub sportu: tam MVP oznacza „most valuable player", najlepszego zawodnika. W tym artykule chodzi o produkt.
Skąd się wziął termin
Określenie pojawiło się na początku lat 2000, a spopularyzowali je Steve Blank i Eric Ries. Ries w „The Lean Startup" opisuje MVP jako wersję produktu, która pozwala zebrać jak najwięcej sprawdzonej wiedzy o klientach przy jak najmniejszym wysiłku. Ważne są tu dwa słowa: wiedza i wysiłek. MVP ma czegoś nauczyć, a nie tylko istnieć.
Co znaczą trzy litery
- Minimum — tylko to, co potrzebne, żeby sprawdzić jedno założenie. Każda dodatkowa funkcja wydłuża czas do pierwszej odpowiedzi.
- Viable — produkt musi naprawdę działać i dawać wartość. Rozsypująca się makieta nie powie Ci, czy ludzie chcą rozwiązania, tylko że nie chcą czegoś zepsutego.
- Product — coś, z czego ludzie korzystają albo za co płacą. Ankieta „czy kupiłbyś?" to badanie, nie produkt.
Najczęstszy błąd to trzymanie się tylko pierwszej litery. „Minimum" bez „viable" daje produkt, który nic nie udowadnia.
Rodzaje MVP
Nie każde MVP to aplikacja. Zaczyna się od najtańszego sposobu, który da wiarygodną odpowiedź.
Strona z zapisem (smoke test). Opisujesz produkt tak, jakby już istniał, i mierzysz, ile osób zostawia e-mail albo klika „kup". Sprawdza popyt, zanim powstanie choć linijka kodu produktu.
MVP concierge. Usługę wykonujesz ręcznie dla kilku pierwszych klientów. Wiesz od razu, za co płacą i co jest dla nich ważne, a dopiero potem automatyzujesz.
MVP „czarnoksiężnik z krainy Oz". Klient widzi gotowy produkt, ale za kulisami część pracy robi człowiek. Sprawdzasz, czy ludzie korzystają z rozwiązania, zanim zbudujesz kosztowną automatyzację.
Produkt z jedną funkcją. Działająca aplikacja, która robi jedną rzecz dobrze: na przykład tylko rezerwację, bez programu lojalnościowego, czatu i raportów. To najczęstsza forma, gdy założenie dotyczy tego, czy ludzie będą regularnie korzystać.
MVP z gotowych klocków. Formularz, arkusz, narzędzie do płatności i automatyzacja zamiast własnego systemu. Szybkie i tanie, ale ma granice, gdy ruch rośnie.
Znane przykłady
- Dropbox zanim zbudował pełny produkt, pokazał krótki film, jak ma działać synchronizacja plików. Lista chętnych urosła z kilku do kilkudziesięciu tysięcy osób w ciągu jednej nocy. To był test popytu, nie aplikacja.
- Zappos na początku nie miał magazynu. Założyciel fotografował buty w lokalnych sklepach, a po zamówieniu kupował je i wysyłał. Sprawdzał, czy ludzie kupią buty przez internet.
- Airbnb zaczął od wynajęcia materacy w mieszkaniu założycieli podczas konferencji w San Francisco, gdy hotele były pełne. Prosta strona, kilku gości, prawdziwe pieniądze.
We wszystkich trzech przypadkach pierwsza wersja sprawdzała jedno założenie, które decydowało o całym pomyśle.
Czym MVP nie jest
Nie jest prototypem do pokazania inwestorom. Prototyp sprawdza, czy rozwiązanie da się zrozumieć i obsłużyć. MVP sprawdza, czy ludzie z niego korzystają lub za nie płacą. Obie rzeczy są przydatne, ale odpowiadają na inne pytania.
Nie jest pierwszą wersją z połową funkcji. Jeśli lista funkcji MVP wygląda jak plan na rok podzielony na dwa, to nie jest MVP. To pełny produkt, który powstaje wolniej.
Nie jest bylejakością. Wąski zakres nie usprawiedliwia błędów, wolnego działania ani niebezpiecznego przechowywania danych. Mało funkcji, ale porządnie zrobionych.
Nie jest końcem pracy. MVP to początek cyklu nauki. Po nim przychodzą dane, decyzje i kolejne wersje.
Jak wybrać zakres MVP
- Zapisz założenia. Kto ma problem, jak go dziś rozwiązuje, ile go to kosztuje, dlaczego wybierze Ciebie.
- Wybierz najbardziej ryzykowne. To, które jeśli okaże się fałszywe, przekreśla resztę. Zwykle dotyczy tego, czy problem jest wystarczająco bolesny, a nie tego, czy da się go technicznie rozwiązać.
- Ustal, co uznasz za sukces. Konkretnie i przed startem: na przykład „10 z 50 osób z listy płaci za pierwszy miesiąc". Bez tego każdy wynik da się zinterpretować na swoją korzyść.
- Wytnij wszystko inne. Logowanie przez pięć serwisów, panel z raportami, aplikacja na dwa systemy: jeśli nie pomagają sprawdzić tego jednego założenia, poczekają.
Więcej o tym, jak prowadzić taki cykl krok po kroku, piszę w temacie o metodzie lean startup, a o porządkowaniu założeń na jednej kartce — przy lean canvas.
Ile kosztuje i ile trwa MVP
To zależy od rodzaju. Strona z zapisem albo MVP concierge może powstać w kilka dni i kosztować niewiele. Działająca aplikacja webowa z jedną główną funkcją, logowaniem i płatnościami to zwykle kilka tygodni pracy.
U mnie MVP aplikacji webowej o wąskim zakresie kosztuje 8 000–40 000 zł netto w stałej cenie i zajmuje 2–6 tygodni. Szczegółowo, z czego wynika ta rozpiętość i jakie są ukryte koszty, opisuję w artykule Koszt MVP w 2026 roku. Jeśli chcesz zacząć, zobacz jak buduję MVP.
Najczęstsze pytania
Czy MVP musi być aplikacją? Nie. Jeśli najważniejsze pytanie brzmi „czy ktoś tego chce", często wystarczy strona, rozmowy i ręcznie wykonana usługa. Aplikację warto budować, gdy chcesz sprawdzić, czy ludzie będą z niej regularnie korzystać.
Czy MVP można pokazać klientom, jeśli jest „niedokończone"? Tak, pod warunkiem że to, co robi, robi dobrze. Wczesni użytkownicy wybaczają brak funkcji, ale nie wybaczają, gdy podstawowa rzecz nie działa.
Co po MVP? Mierzysz, co ludzie zrobili, i decydujesz: rozwijać, zmienić kierunek albo zakończyć. O tym, po czym poznać, że produkt trafił w potrzebę, piszę w temacie o product-market fit.