MVP w 30 dni

Wprowadzenie — Czym jest MVP i dlaczego 30 dni?

MVP (Minimum Viable Product) to nie "tania wersja produktu". To najmniejszy możliwy produkt, który pozwala zwalidować kluczową hipotezę biznesową. Celem nie jest zbudowanie "wersji 1.0" — celem jest nauczenie się jak najwięcej, jak najtaniej i najszybciej.

Eric Ries (Lean Startup) definiuje MVP jako "tę wersję nowego produktu, która pozwala zebrać maksymalną ilość zwalidowanej wiedzy o klientach przy minimalnym nakładzie pracy." Kluczowe słowo: zwalidowanej — nie zgadywanej.

Najczęstsze błędy przy budowie MVP

• Za dużo funkcji — "MVP" z 50 funkcjami to nie MVP. Jedna kluczowa funkcja, zrobiona dobrze.
• Brak walidacji problemu — budowanie bez rozmów z użytkownikami to najdroższy błąd.
• Perfekcjonizm — MVP ma być "embarrassingly simple". Jeśli nie wstydzisz się pierwszej wersji, wypuściłeś ją za późno (Reid Hoffman, LinkedIn).
• Brak mierników sukcesu — przed startem zdefiniuj co oznacza sukces MVP (np. 100 aktywnych użytkowników, 10 płacących klientów, 40% retention D7).

Tydzień 1: Walidacja problemu (Dni 1–7)

Cel tygodnia: Upewnić się, że budujesz rozwiązanie prawdziwego problemu dla prawdziwych ludzi.

Dzień 1–2: Zdefiniuj problem i hipotezę

Zanim napiszesz linijkę kodu, musisz mieć krystaliczną jasność co do problemu, który rozwiązujesz.

• Kto: Dla kogo jest ten produkt? (konkretna persona, nie "wszyscy")
• Problem: Jaki problem ma ta osoba? (opisz w jednym zdaniu)
• Kontekst: Kiedy i gdzie ten problem się pojawia?
• Koszt: Ile czasu/pieniędzy traci przez ten problem?
• Hipoteza: "Wierzymy, że [persona] ma problem [X] i jest gotowa zapłacić za [rozwiązanie Y]."

Dzień 3–5: Rozmowy z użytkownikami (Customer Discovery)

Przeprowadź minimum 10–15 rozmów z potencjalnymi użytkownikami. To najważniejsza inwestycja tygodnia.

• Nie pitchuj rozwiązania — słuchaj o problemie
• Pytaj o przeszłość: "Jak ostatnio to robiłeś?" nie "Czy użyłbyś X?"
• Pytaj "dlaczego?" minimum 3 razy — pierwsze odpowiedzi są powierzchowne
• Szukaj workaroundów — Excel, ręczny proces = dowód że problem jest realny
• Notuj dosłowne cytaty — to złoto dla copywritingu i PRD

Dzień 6–7: Analiza i decyzja Go/No-Go

Przeanalizuj zebrane dane. Użyj Affinity Mapping — grupuj podobne insighty. Kryteria Go: 8+ z 10 rozmówców potwierdziło problem, przynajmniej 3 osoby mają aktywny workaround, przynajmniej 2–3 osoby wyraziły gotowość do zapłaty.

Tydzień 2: Design Sprint (Dni 8–14)

Cel tygodnia: Zaprojektować i przetestować rozwiązanie zanim napiszesz linijkę kodu.

Dzień 8–9: Mapowanie i szkicowanie

Zmapuj user journey — jak użytkownik przechodzi od problemu do wartości produktu?

• User Journey Map: Każdy krok od "użytkownik ma problem" do "użytkownik osiągnął wartość"
• Happy Path: Zidentyfikuj główną ścieżkę (core flow) — to budujesz w MVP
• Kluczowe ekrany: Lista ekranów potrzebnych do core flow (max 5–8)
• Crazy 8s: 8 różnych wariantów rozwiązania w 8 minut — ilość > jakość na tym etapie

Dzień 10–11: Prototyp w Figma

Stwórz klikalny prototyp. Nie musi być piękny — musi być klikalny i zrozumiały.

• Użyj UI Kitów: Material Design 3, Apple HIG, Shadcn/UI — gotowe komponenty przyspieszają 3x
• Skup się na core flow: Tylko ekrany potrzebne do głównej ścieżki użytkownika
• Dodaj interakcje: Figma Prototype — połącz ekrany, żeby można było klikać
• Nie projektuj edge cases: Stany błędów, empty states, loading — to na później

Dzień 12–14: Testy z użytkownikami (Usability Testing)

Pokaż prototyp 5 użytkownikom. Obserwuj, gdzie się gubią — nie tłumacz jak działa.

• "Pokaż mi jak byś [wykonał zadanie X]" — nie "Kliknij tutaj"
• Proś o myślenie na głos: "Mów co widzisz i co myślisz"
• Notuj gdzie użytkownik się zatrzymuje, cofa, jest zdezorientowany
• Nie pomagaj — frustracja użytkownika = cenny feedback
• Zasada 5 użytkowników (Nielsen Norman Group): 5 testów ujawnia 85% problemów UX

Tydzień 3: Development (Dni 15–21)

Cel tygodnia: Zbudować działający produkt z core flow. Tylko to co absolutnie niezbędne.

Dzień 15–16: Setup projektu i architektura

Wybrane stacki dla szybkości MVP:

• Web App: Next.js + Supabase (auth, baza danych, storage w jednym) + Vercel (deploy w 1 klik)
• Mobile: Flutter + Firebase (cross-platform iOS+Android, szybki start)
• Backend-as-a-Service: Firebase, Supabase, Appwrite — eliminują potrzebę własnego backendu
• Płatności: Stripe (najszybsza integracja, obsługuje subskrypcje)

Setup obowiązkowy: Repozytorium Git (GitHub/GitLab), CI/CD pipeline (GitHub Actions + Vercel/Firebase), środowiska dev/staging/production, error tracking (Sentry — darmowy do 5K błędów/mies.).

Dzień 17–21: Budowa core features

Kolejność budowania (priorytet):

1. Autentykacja (login/rejestracja) — bez tego nic nie działa
2. Core flow — główna funkcjonalność, dla której użytkownik przychodzi
3. Podstawowy onboarding — użytkownik musi wiedzieć co robić po rejestracji
4. Podstawowy UI — funkcjonalny, nie musi być piękny

Tydzień 4: Launch & Learn (Dni 22–30)

Cel tygodnia: Wypuścić produkt, zebrać dane i zaplanować iteracje.

Dzień 22–24: Polish, Testing & Analytics

• Napraw krytyczne bugi — te które blokują core flow. Reszta może poczekać.
• Testy na różnych urządzeniach — Chrome, Safari, Firefox, iOS, Android. BrowserStack jeśli nie masz fizycznych urządzeń.
• Analytics setup — PostHog lub Mixpanel. Kluczowe eventy: sign_up_completed, activation_event, feature_used, payment_completed.
• Onboarding — minimum: welcome email + 3 kroki które prowadzą do activation event.
• Landing page — jasny value proposition, CTA, social proof (choćby "Beta" badge).

Dzień 25–26: Soft Launch — pierwsi użytkownicy

Wypuść produkt do małej, kontrolowanej grupy (50–100 osób). Nie rób wielkiego launchu — chcesz feedbacku, nie viralności.

• Beta testerzy z wywiadów — mają kontekst, dadzą najlepszy feedback
• Product Hunt "Coming Soon" — zbierz waitlistę przed oficjalnym launch
• LinkedIn post: "Szukam 50 beta testerów do [produkt]. Kto chce spróbować?"
• Reddit (r/startups, r/SaaS, niszowe subreddity Twojej branży)
• Slack/Discord communities Twojego ICP

Dzień 27–30: Zbieranie danych i planowanie iteracji

• Monitoruj analytics codziennie: Ile osób się zarejestrowało? Ile osiągnęło activation event? Jaki jest D7 retention?
• Rozmawiaj z użytkownikami — szczególnie tymi którzy odeszli (churn interviews)
• NPS survey — wyślij po 7 dniach użytkowania: "Jak bardzo prawdopodobne jest, że polecisz [produkt] znajomemu? (0–10)"
• Priorytetyzacja iteracji: Sortuj feedback według: (1) częstości problemu, (2) wpływu na retention, (3) łatwości implementacji

Jak mierzyć sukces MVP — kluczowe metryki

North Star Metric

Jedna metryka najlepiej odzwierciedlająca wartość produktu dla użytkowników. Przykłady: Slack → DAU, Airbnb → liczba noclegów, Spotify → czas słuchania. Twoja North Star powinna rosnąć gdy produkt dostarcza wartość.

AARRR Framework (Pirate Metrics)

• Acquisition: Skąd przychodzą użytkownicy? Ile kosztuje pozyskanie (CAC)?
• Activation: Jaki % nowych użytkowników osiąga "aha moment"? (cel: >40%)
• Retention: Jaki % wraca po 7, 30 dniach? (cel D7: >20%, D30: >10%)
• Revenue: Jaki % konwertuje na płatny plan? Jaki jest MRR?
• Referral: Czy użytkownicy polecają produkt? NPS > 40 = dobry wynik

PMF Signal — jak poznać że masz Product-Market Fit

Sean Ellis Test: "Jak bardzo byłbyś rozczarowany gdyby [produkt] przestał istnieć?" Jeśli >40% odpowiada "bardzo rozczarowany" — masz PMF. Poniżej 40% — iteruj.

Inne sygnały PMF: organiczny wzrost (użytkownicy sami polecają), retention curve się spłaszcza (nie spada do zera), użytkownicy płacą bez namawiania, media piszą o Tobie bez PR.

Co dalej po MVP?

Po 30 dniach masz działający produkt i pierwsze dane. Teraz zaczyna się prawdziwa praca:

1. Analizuj dane — gdzie odpada funnel? Które funkcje są używane? Jaki jest retention?
2. Iteruj szybko — naprawiaj największe problemy, dodawaj brakujące funkcje. Cel: 1 iteracja/tydzień.
3. Szukaj PMF — Sean Ellis Test co miesiąc. Iteruj dopóki nie osiągniesz >40%.
4. Skaluj kanały — gdy masz PMF i pozytywne unit economics, czas na growth i marketing.
5. Buduj zespół — gdy masz PMF i revenue, zatrudnij pierwszych pracowników.