Od pomysłu do MVP: jak dowieźć produkt w 30 dni

Co to znaczy „MVP w 30 dni” i dla kogo to ma sens

Praktyczna definicja MVP, bez teorii z podręczników

MVP (Minimum Viable Product) to najprostsza możliwa wersja produktu, która spełnia dwa warunki:

• umożliwia prawdziwym użytkownikom rozwiązanie choć kawałka realnego problemu,
• daje tobie mierzalne dane i feedback, które pomagają zdecydować: rozwijać, zmienić kierunek czy zamknąć temat.

MVP nie jest „pierwszą wersją idealnej aplikacji”. To wersja testowa do zebrania dowodów: czy ktoś naprawdę potrzebuje tego, co budujesz, i czy jest gotów poświęcić na to czas lub pieniądze.

MVP w 30 dni oznacza, że w ciągu jednego miesiąca:

• definiujesz problem i hipotezy,
• wybierasz formę MVP (niekoniecznie aplikację!),
• budujesz minimalne rozwiązanie,
• pokazujesz je prawdziwym ludziom i zbierasz dane.

Jeśli po 30 dniach masz pierwszych użytkowników, rozmowy, wnioski i liczby – dowiozłeś MVP, nawet jeśli produkt technicznie „ledwo zipie”.

MVP, prototyp, PoC, gotowy produkt – gdzie są granice

Te pojęcia często się mieszają, a w praktyce oznaczają coś innego:

W kontekście 30 dni mówimy o MVP, a nie o gotowym produkcie. To nie jest czas na dopieszczanie interfejsu, automatyzację wszystkiego i budowanie „architektury na milion użytkowników”. Chodzi o sprawdzenie, czy warto w ogóle dochodzić do tej skali.

Kiedy 30 dni to realny horyzont, a kiedy nie

MVP w 30 dni ma sens przede wszystkim dla:

• produktów cyfrowych B2C i B2B o niskiej lub średniej złożoności (proste SaaS, narzędzia dla freelancerów, małe automatyzacje),
• usług opartych o technologię, które można na początku dowozić ręcznie (concierge MVP),
• pomysłów informacyjnych (kursy, newslettery, bazy wiedzy, marketplace’y niszowe w wersji bardzo ograniczonej).

30 dni rzadko wystarczy na sensowne MVP, jeśli:

• wchodzisz w produkty hardware (sprzęt, IoT),
• potrzebujesz ciężkich integracji z wieloma systemami korporacyjnymi,
• tworzysz coś o wysokim ryzyku prawnym/medycznym (systemy medyczne, fintech podlegający ścisłej regulacji).

W tych przypadkach w 30 dni da się zrobić raczej prototyp koncepcyjny lub PoC, a nie pełnokrwiste MVP z użytkownikami na rynku. Ale jeśli celujesz w prosty prototyp produktu cyfrowego czy usługę online – 30 dni to wystarczająco, by zebrać pierwsze twarde dane.

Jak pogodzić budowę MVP z pracą etatową lub studiami

Większość osób nie siedzi nad MVP po 8 godzin dziennie. Realniejszy model to:
1,5–3 godziny dziennie w tygodniu + 2 bloki po 3–4 godziny w weekend. Średnio daje to około 40–60 godzin pracy w miesiącu.

Aby taki rytm zadziałał:

• każdy dzień powinien mieć jedno konkretne zadanie (np. „napisać sekcję hero na landing page”, „porozmawiać z 3 osobami”),
• trzeba zaakceptować, że nie powstanie perfekcyjny produkt – tylko minimalna wersja, która działa,
• warto blokować w kalendarzu stałe sloty (np. 20:00–22:00 od poniedziałku do czwartku) i traktować je jak spotkanie z klientem.

Kluczowe jest odcięcie zadań „ładnych, ale zbędnych” (logo, branding, skomplikowane animacje), jeśli nie wpływają na walidację. MVP ma odpowiedzieć na pytania biznesowe, nie estetyczne.

Szybka weryfikacja pomysłu – zanim zaczniesz budować

Co to znaczy, że pomysł jest „wart testu”

Pomysł wart testu to taki, który spełnia kilka prostych kryteriów:

• Jasny problem – jesteś w stanie w jednym zdaniu opisać ból użytkownika (np. „freelancerzy gubią się w rozliczaniu małych zleceń”).
• Konkretny segment użytkowników – wiesz, kto dokładnie ma ten problem (nie „wszyscy”, tylko np. „freelancerzy marketingowi w małych miastach”).
• Istnieją jakieś obecne rozwiązania – czyli problem jest realny, bo ktoś już próbuje go ogarnąć (Excel, notatnik, inne aplikacje).
• Masz dostęp do ludzi z tej grupy – możesz z nimi porozmawiać w najbliższych dniach (grupy Facebook, LinkedIn, własne kontakty).

Z kolei pomysł warto odrzucić lub odłożyć, jeśli:

• nie potrafisz znaleźć realnych osób z tym problemem,
• problem jest zbyt ogólny i abstrakcyjny („ludzie chcą być szczęśliwsi”),
• rozwiązanie wymaga ogromnych inwestycji lub regulacji, do których nie masz dostępu.

Prosty schemat: problem → grupa → obecne rozwiązania → luka

Zanim cokolwiek zbudujesz, zapisz na jednej kartce lub w jednym pliku:

• Problem: jaki konkretnie ból rozwiązujesz?
• Grupa użytkowników: dla kogo dokładnie?
• Obecne rozwiązania: jak sobie radzą dzisiaj?
• Luka: co ich wkurza w tych rozwiązaniach, gdzie jest miejsce na coś lepszego?

Przykład dla prostego notatnika dla freelancerów:

• Problem: freelancerzy gubią czas poświęcony na małe zadania, przez co nie fakturują wszystkiego.
• Grupa: freelancerzy z branży kreatywnej (grafika, copy, social media) pracujący z kilkoma klientami.
• Obecne rozwiązania: Excel, notes, wpisywanie ręczne w aplikacje do faktur.
• Luka: narzędzia są albo zbyt rozbudowane (programy do zarządzania projektami), albo za mało dostosowane do szybkiego łapania drobnych zadań „w biegu”.

Rozmowy z użytkownikami w 3 dni – plan minimum

Customer discovery w praktyce nie musi być skomplikowane. Da się przeprowadzić 10–20 rozmów w 3 dni, jeśli podejdziesz do tego prosto:

• Dzień 1: spisujesz listę osób (znajomi, znajomi znajomych, osoby z grup FB/LinkedIn) + piszesz krótki, szczery komunikat: „Hej, testuję pomysł na narzędzie X dla osób takich jak Ty. Czy znajdziesz 15 min na rozmowę o tym, jak dziś rozwiązujesz Y? Zero sprzedaży, tylko research”.
• Dzień 2–3: robisz krótkie rozmowy (15–20 minut) na Zoom/telefonie/na żywo.

Celem nie jest prezentacja pomysłu, tylko zrozumienie rzeczywistości użytkownika. Jeśli nie jesteś w stanie złapać 10 osób z grupy docelowej w 2–3 dni, jest to pierwsza czerwona flaga co do skalowalności projektu.

Jak pytać, żeby nie dostać samych uprzejmych pochwał

Ludzie z natury są mili. Jeśli zapytasz „Czy podoba Ci się ten pomysł?”, większość odpowie „tak”. To nic nie znaczy. Zamiast opinii o pomyśle potrzebujesz historii o ich życiu i zachowaniach.

Lepsze pytania:

• „Opowiedz, jak teraz rozwiązujesz [problem]. Co robisz krok po kroku?”
• „Kiedy ostatni raz miałeś z tym problem? Co wtedy zrobiłeś?”
• „Z jakich narzędzi korzystasz? Co w nich najbardziej przeszkadza?”
• „Co się dzieje, jeśli nic z tym nie zrobisz?”
• „Gdybyś miał magiczną różdżkę i mógł jednym kliknięciem poprawić jedną rzecz, co by to było?”

Jeśli chcesz już pokazać pomysł, nie pytaj „Czy byś tego używał?”, tylko:

• „Gdzie to by się wpasowało w Twój dzień? Kiedy realnie miałbyś na to czas?”
• „Z czego musiałbyś zrezygnować, żeby używać tego narzędzia?”
• „Co sprawiłoby, że zrezygnowałbyś po tygodniu?”

Szybka decyzja: kontynuować, pivotować, odpuścić

Po 10–20 rozmowach wypisz sobie wnioski:

• czy problem jest faktycznie bolesny, czy raczej „fajnie by było”?
• czy ludzie już próbują coś z tym robić (dobry znak), czy wzruszają ramionami?
• czy pojawia się powtarzalny wzór – podobne historie, podobne frustracje?

Możesz przyjąć prostą matrycę:

• Duży ból + ludzie już „kombinują” z rozwiązaniami → idź dalej.
• Średni ból + ludzie myślą, że „by się przydało”, ale nic nie robią → przemyśl wartość lub segment.
• Mały ból + brak jakichkolwiek działań → rozważ odpuszczenie lub pocięcie pomysłu na inny problem.

W tym miejscu łatwiej zakończyć projekt, niż po 3 miesiącach kodowania. To właśnie minimalizacja ryzyka w procesie budowy MVP.

Ustalenie celu MVP i hipotez do sprawdzenia

Jedno zdanie, które opisuje obietnicę produktu

Bez jasnej obietnicy produkt rozlewa się na wszystko i na nic. Dobrze działa prosty szablon value proposition:
„Pomagam [konkretna grupa] zrobić [konkretny efekt] bez [główna frustracja]”.

Przykłady:

• „Pomagam freelancerom marketingowym łapać i rozliczać każde małe zlecenie bez siedzenia godzinami w Excelu.”
• „Pomagam małym gabinetom kosmetycznym zapełnić kalendarz bez dzwonienia do każdej klientki z osobna.”

Takie zdanie jest kompasem. Jeśli funkcja nie wspiera tej obietnicy – wypada z MVP.

2–3 główne hipotezy, które naprawdę trzeba sprawdzić

Na etapie MVP kluczowe są trzy typy hipotez:

• Hipoteza problemu – czy problem jest wystarczająco bolesny i częsty?
• Hipoteza rozwiązania – czy twoje podejście realnie ułatwia życie użytkownika?
• Hipoteza wartości / gotowości do płacenia – czy ludzie są gotowi poświęcić coś cennego: czas, dane, pieniądze?

Przykładowe hipotezy dla notatnika dla freelancerów:

• Problem: „Freelancerzy tracą część dochodów, bo nie notują małych zadań”.
• Rozwiązanie: „Prosty notatnik z przypomnieniami pozwoli im zapisać 80% takich zadań w ciągu dnia pracy”.
• Wartość: „Przynajmniej 20% aktywnych użytkowników będzie gotowych przejść na płatną wersję po 14-dniowym okresie próbnym”.

Przekładanie hipotez na mierzalne wskaźniki

Hipotezy bez liczb to życzenia. Każdą hipotezę sprowadź do konkretnego wskaźnika:

• problem → liczba osób, które w rozmowach przyznają, że realnie tracą pieniądze lub czas przez dany problem,
• rozwiązanie → odsetek osób, które po przetestowaniu MVP wracają do niego w ciągu 7 dni,
• wartość → liczba zapisów na listę oczekujących, liczba osób, które podadzą kartę (jeśli jesteś gotowy), liczba osób, które zgodzą się rozmawiać dalej.

Przykład prostego zestawu wskaźników dla 30 dni:

• min. 30 osób zapisanych na listę zainteresowanych,
• min. 10 użytkowników, którzy realnie korzystają z MVP przez co najmniej tydzień,
• min. 3 osoby, które deklarują gotowość do płacenia (np. akceptują wstępną cenę i chcą przejść na wersję płatną, gdy będzie dostępna).

Zawężenie zakresu – jak określić minimalny zestaw funkcji

Mapa historii użytkownika zamiast listy „ficzerów”

Zamiast zaczynać od listy funkcji, zacznij od jednej, konkretnej ścieżki użytkownika. Co ma się wydarzyć od momentu, gdy pierwszy raz o tobie usłyszy, do momentu, w którym dostaje obiecaną wartość?

Przykład dla notatnika freelancerów:

1. Freelancer widzi prostą stronę lądowania i rozumie, o co chodzi.
2. Zakłada konto lub zaczyna bez konta (np. jako demo).
3. Dodaje pierwsze zadanie z czasem lub kwotą.
4. Po kilku dniach dostaje podsumowanie: ile zł / godzin „odzyskał”.

To jest rdzeń produktu. Wszystko poza tą ścieżką jest kandydatem do wycięcia z MVP.

Kryterium „bez tego produkt nie dowozi obietnicy”

Stwórz listę funkcji, ale oceniaj je tylko jednym pytaniem:
„Czy bez tego użytkownik dostanie obiecaną wartość?”.

• Jeśli tak – to nie jest funkcja MVP, tylko „miły dodatek”.
• Jeśli nie – to jest kandydat do MVP.

Dla notatnika:

• Dodawanie zadań z kwotą/czasem → tak, w MVP.
• Eksport do Excela → można poczekać.
• Integracja z kalendarzem Google → na później.
• Automatyczne przypomnienia push → prosta wersja (np. 1 dzienny mail) w MVP, rozbudowa później.

Metoda MoSCoW po ludzku

Znana metoda MoSCoW (Must / Should / Could / Won’t) sprawdza się, jeśli nie robisz z niej korporacyjnej tabelki. W praktyce wystarczy prosta tablica:

• MUST – bez tego produkt jest bez sensu, nie da się spełnić obietnicy.
• SHOULD – przyda się, ale można to ogarnąć ręcznie lub obejściem.
• COULD – fajerwerki; odkładasz.
• WON’T (TERAZ) – nie wchodzi w grę w ciągu 30 dni, choćby nie wiem co.

Jeśli w kolumnie MUST masz więcej niż 5–7 pozycji dla prostego produktu, to jest mocny sygnał, że próbujesz zrobić wersję 1.0, nie MVP.

Odcinanie „ogonów” – funkcje, które kuszą, ale zabiją 30 dni

Najczęstsze pułapki, które wyciągają projekt poza 30 dni:

• Zaawansowane uprawnienia i role użytkowników – na start zwykle wystarczy 1 typ konta.
• Rozbudowane integracje – każda dodatkowa usługa to osobny projekt i debugowanie.
• Automatyzacje „dla wygody” – wiele z nich można na początku ogarnąć ręcznie (np. wysyłka PDF raz dziennie).
• Panel administracyjny na poziomie SaaS-owego kombajnu – na MVP wystarczy prosty wgląd w dane lub nawet zwykły eksport.

Jeśli dyskutujesz nad funkcją dłużej niż 10 minut, zaparkuj ją w liście „po MVP”. MVP to nie jest konkurs na idealny produkt, tylko test najważniejszych hipotez.

Wybór formy MVP – nie zawsze trzeba od razu budować aplikację

Spektrum form: od „udawanej” usługi do pełnej aplikacji

MVP to nie synonim „aplikacji webowej”. To najprostsza forma, która pozwoli zebrać twarde dane. Czasem wystarczy:

• formularz + arkusz kalkulacyjny,
• prosty chatbot na stronie,
• usługa „ręczna”, obsługiwana przez ciebie w tle,
• klikany prototyp w Figma.

Dobór formy zależy od tego, jaką hipotezę testujesz.

Kiedy wystarczy „MVP Concierge”

MVP typu concierge to sytuacja, w której użytkownik widzi „produkt”, ale większość pracy robisz ręcznie. Dobry wybór, gdy:

• proces po stronie użytkownika jest prosty,
• dużo pracy dzieje się „w środku” (analiza, dopasowania, ręczne decyzje),
• masz mało użytkowników na starcie (kilkanaście, kilkadziesiąt osób).

Przykład: narzędzie do optymalizacji stałych kosztów firm. Zamiast budować system integracji z bankami:

1. zbierasz od użytkownika PDF z wyciągiem,
2. analizę robisz ręcznie (lub pół-automatycznie w Excelu/Sheets),
3. wysyłasz raport mailem, jakby powstał z aplikacji.

Klient doświadcza efektu (niższe koszty, konkretny raport), a ty testujesz:

• czy w ogóle chcą ci wysłać dane,
• czy raport jest dla nich użyteczny,
• czy chcą za to płacić.

Landing page + lista oczekujących jako MVP

Jeśli hipotezy dotyczą głównie zainteresowania i gotowości do zapisania się, wystarczy dobra strona lądowania:

• jasny nagłówek z obietnicą,
• 3–5 punktów z korzyściami,
• prosty formularz zapisu (email + ewentualnie 1–2 pytania kwalifikujące).

W takim MVP testujesz np.:

• czy ktoś zostawi dane kontaktowe,
• która propozycja wartości konwertuje lepiej (A/B test nagłówków),
• z jakich źródeł ruchu przychodzą najlepsi potencjalni klienci.

To często wystarczy, żeby nie pisać ani jednej linijki backendu, a już mieć dane, czy ktokolwiek reaguje na obietnicę.

Prototyp klikalny zamiast działającej aplikacji

Jeśli chcesz sprawdzić głównie użyteczność interfejsu i sposób pracy, zamiast walczyć z infrastrukturą możesz użyć narzędzi typu Figma, Axure, Marvel:

• tworzysz prosty, klikalny prototyp kilku ekranów,
• dajesz użytkownikom zadania: „Dodaj nowe zlecenie”, „Sprawdź, ile zarobiłeś w tym tygodniu”,
• obserwujesz, gdzie klikają, gdzie się gubią, co jest dla nich nielogiczne.

Nie testujesz wtedy technologii, tylko czy sposób rozwiązania problemu ma sens z perspektywy użytkownika.

Kiedy faktycznie warto zbudować „prawdziwą” aplikację

Pełne MVP (działająca aplikacja) ma sens, gdy:

• hipoteza dotyczy codziennego używania, a nie tylko jednorazowego efektu,
• interakcje są częste (kilka razy dziennie / tydzień),
• bez automatyzacji użytkownik nie poczuje realnej różnicy (np. narzędzie do trackowania czasu).

Wtedy budujesz możliwie najprostszy, ale jednak używalny end-to-end przepływ, a nie makietę. Klucz w tym, żeby aplikacja robiła jedną rzecz dobrze, zamiast dziesięciu przeciętnie.

Narzędzia i technologia pod MVP – no-code, low-code i minimalny kod

Technologia jako środek, nie cel

W MVP technologia ma jak najszybciej dowieźć test, nie imponować architekturą. Kryteria