MVP Scope Checklist

assadante.com

MVP Scope Checklist

Lista kontrolna do definiowania zakresu MVP. Użyj jej przed rozpoczęciem projektu, aby upewnić się, że budujesz minimum viable product — nie "wszystko co chcemy mieć". MVP to hipoteza, nie produkt finalny.

1. Problem & Walidacja

• Problem jest jasno zdefiniowany w jednym zdaniu
  Test: czy możesz wyjaśnić problem 10-latkowi? Jeśli nie — jest za skomplikowany lub za szeroki.
• Rozmawiałeś z minimum 10–20 potencjalnymi użytkownikami
  Nie ankiety online — prawdziwe rozmowy 1:1, min. 30 minut każda. Pytaj o przeszłość, nie o przyszłość ("jak to robisz teraz?" nie "czy użyłbyś X?").
• Użytkownicy potwierdzili, że problem jest bolesny (pain score ≥ 7/10)
  Szukają rozwiązania aktywnie, płacą za niedoskonałe alternatywy, tracą czas/pieniądze przez brak rozwiązania.
• Wiesz, kto jest Twoim ICP (Ideal Customer Profile)
  Konkretna persona: branża, rola, wielkość firmy, budżet, narzędzia których używa. Nie "wszyscy" ani "MŚP".
• Zbadałeś istniejące rozwiązania (konkurencja)
  Dlaczego użytkownicy nie używają istniejących narzędzi? Co im w nich przeszkadza? To Twoja szansa.
• Masz dowód na gotowość do zapłaty
  Użytkownicy wyrazili chęć zapłaty (pre-order, LOI, wpłata zaliczki). "Brzmi świetnie" ≠ gotowość do zapłaty.
• Zidentyfikowałeś "early adopters"
  Kto ma problem najbardziej? Kto jest gotowy użyć niedoskonałego produktu? To Twoi pierwsi klienci.

2. Zakres funkcji — priorytetyzacja

• Lista funkcji podzielona na Must-have / Should-have / Nice-to-have / Won't-have (MoSCoW)
  MVP = tylko Must-have. Wszystko inne trafia do backlogu.
• Każda funkcja ma uzasadnienie w rozmowach z użytkownikami
  Nie "fajnie by było mieć" — konkretny cytat lub obserwacja z badań.
• Wyciąłeś 50% funkcji z pierwszej listy
  Potem wytnij jeszcze raz. Pierwsza lista zawsze jest za długa.
• Core flow można przejść w mniej niż 5 krokach
  Główna ścieżka użytkownika (happy path) jest prosta i bezpośrednia.
• Zdefiniowano "aha moment" produktu
  Kiedy użytkownik po raz pierwszy poczuje wartość? Np. Slack: "gdy wyślesz 2000 wiadomości". Zaprojektuj MVP tak, by do niego prowadził.
• Onboarding jest zaplanowany
  Jak użytkownik dojdzie od rejestracji do pierwszej wartości? Każdy krok onboardingu, który usuniesz, zwiększa retencję.
• Funkcje są ocenione przez pryzmat: wartość dla użytkownika vs. koszt implementacji
  Priorytetyzuj funkcje o wysokiej wartości i niskim koszcie. Odłóż funkcje o niskiej wartości i wysokim koszcie.

3. Technologia & Architektura

• Wybrano sprawdzone, "nudne" technologie
  Innowuj w produkcie, nie w stacku. React/Next.js, Node.js, PostgreSQL, Firebase — sprawdzone i z dużą społecznością.
• Architektura pozwala na skalowanie — ale nie jest over-engineered
  Zaplanuj skalowanie, ale nie implementuj go na start. Monolith jest OK dla MVP. Mikroserwisy — nie.
• CI/CD zaplanowane od dnia 1
  GitHub Actions, Vercel, Firebase Hosting — automatyczny deployment przy każdym push. Oszczędza godziny tygodniowo.
• Środowiska: dev / staging / production są oddzielone
  Nigdy nie testuj na produkcji. Staging = kopia produkcji.
• Baza danych ma schemat i migracje
  Prisma, Flyway, Alembic — zmiany schematu są wersjonowane i odwracalne.
• Zewnętrzne API mają fallback lub graceful degradation
  Co się stanie gdy Stripe/SendGrid/OpenAI padnie? Użytkownik powinien zobaczyć sensowny błąd, nie crash.
• Decyzje technologiczne są udokumentowane (ADR)
  Architecture Decision Records — krótki dokument: "wybraliśmy X zamiast Y, bo Z". Bezcenne za 6 miesięcy.

4. UX & Design

• Wireframes lub prototyp w Figmie gotowy przed developmentem
  Zmiana w Figmie kosztuje 5 minut. Zmiana w kodzie — 5 godzin.
• Design system / component library zdefiniowany
  Kolory, typografia, spacing, komponenty. Nawet prosty — zapobiega niespójności.
• Responsywność zaplanowana (mobile-first)
  Ponad 60% ruchu to mobile. Projektuj najpierw na małe ekrany.
• Empty states zaprojektowane
  Co widzi nowy użytkownik gdy nie ma jeszcze danych? To krytyczny moment dla retencji.
• Error states zaprojektowane
  Błędy formularzy, błędy sieci, błędy serwera — każdy powinien mieć sensowny komunikat i sugestię co zrobić.

5. Metryki sukcesu MVP

• Zdefiniowano North Star Metric
  Jedna metryka, która najlepiej odzwierciedla wartość dla użytkownika. Np. Airbnb: "noce zarezerwowane", Spotify: "czas słuchania".
• Zdefiniowano 3–5 kluczowych metryk (AARRR)
  Acquisition (skąd przychodzą), Activation (czy osiągają wartość), Retention (czy wracają), Revenue (czy płacą), Referral (czy polecają).
• Analytics skonfigurowane od dnia 1
  Mixpanel, Amplitude, PostHog lub GA4. Bez danych nie wiesz co poprawić.
• Wiesz, co oznacza "sukces" MVP — konkretne liczby
  Np. "100 aktywnych użytkowników w 30 dni" lub "10 płacących klientów w 60 dni". Nie "dużo użytkowników".
• Zdefiniowano "kill criteria"
  Kiedy uznajesz, że hipoteza jest błędna i pivot jest konieczny? Np. "jeśli po 90 dniach mamy mniej niż 5 płacących klientów".
• Mechanizm zbierania feedbacku od użytkowników
  In-app survey (Typeform, Hotjar), email po 7 dniach, rozmowy 1:1 z pierwszymi użytkownikami.

6. Timeline, Team & Budget

• Timeline jest realistyczny (6–12 tygodni dla MVP)
  Mniej = za mało zakresu. Więcej = za dużo zakresu lub za mały zespół. Jeśli więcej — wytnij funkcje.
• Role w projekcie są jasno przypisane
  Kto jest PM? Kto decyduje o zakresie? Kto robi design? Kto code review? Brak jasnych ról = chaos.
• Budget jest zdefiniowany z 20% buforem
  Niespodzianki zawsze się zdarzają. Buffer nie jest "zapasem na nowe funkcje" — to rezerwa na problemy.
• Koszty infrastruktury są skalkulowane
  Hosting, baza danych, zewnętrzne API (Stripe, SendGrid, OpenAI), CDN, monitoring. Policz miesięczny koszt przy 100, 1000, 10000 użytkownikach.
• Masz plan na post-launch (wsparcie, iteracje)
  MVP to hipoteza. Po launch zaczyna się prawdziwa praca: zbieranie danych, iteracje, poprawki. Zaplanuj 2–3 miesiące post-launch.
• Zdefiniowano proces decyzyjny dla zmian zakresu
  Kto może dodać funkcję do MVP? Jak wygląda proces zmiany zakresu? Bez procesu — scope creep zabije projekt.

7. Go-to-Market (GTM)

• Wiesz, jak dotrzesz do pierwszych 100 użytkowników
  Konkretny kanał: LinkedIn outreach, community, cold email, znajomi, Product Hunt. Nie "SEO" ani "social media".
• Landing page gotowy przed launch
  Jasny value proposition, CTA, możliwość zapisu (waitlist lub rejestracja). Testuj copy przed developmentem.
• Pricing jest zdefiniowany
  Nawet jeśli MVP jest darmowy — wiesz jaki będzie model monetyzacji. Freemium, subscription, usage-based, one-time.
• Masz listę 20–50 potencjalnych pierwszych klientów
  Imię, email, firma, dlaczego pasują do ICP. Nie "wyślemy newsletter do wszystkich".