Cześć, tu Bogusz 🔥
MVP, czyli Minimum Viable Product to temat oklepany jak stara szkapa.
Nie chcę się tu zagłębiać w teoretyczne rozważania (teorie znajdziesz w książkach np. Metoda Lean
Startup).
My zajmiemy się praktyką.
Czym jest MVP?
W dużym uproszczeniu MVP to pierwsza wersja produktu, którą udostępniasz tzw. early adopterom.
Early adopterzy (po polsku: wcześni ewangeliści) to wyjątkowa grupa użytkowników, którzy lubią
być pierwsi, nie przeszkadza im niekompletność produktu i masa błędów.
Ba! Early adopterzy staną się Twoimi niepisanymi co-founderami. To oni pomogą Ci zbudować odpowiedni produkt. (oni chcą to robić!)
Największy problem z budową MVP
Budowa MVP wydaj się prosta.
Jednak wiele osób robi to źle.
Często wynika to, nie tyle z braku wiedzy teoretycznej, co z faktu, że młodzi founderzy.. nie do końca wiedzą co ich produkt ma robić.
Lub zakres funkcji
produkt jest zbyt szeroki. (nie masz jasnego obrazu co budować)
Budowa MVP jest świetnym testem czy Twój produkt ma w ogóle sens.
- Mówi się o walidacji pomysłów przez rozmowy z klientami.
- Mówi się, żeby prosić klientów o pieniądze przed pierwszą linią kodu.
Jasne, to wszystko może pomóc.
Jednak prawdziwa walidacja i droga do Product-Market Fit zaczyna się od MVP.
Od produktu, w który klient może sam poklikać.
Ładnym landingiem, rozmowami czy marką osobistą możesz przekonać klienta do zakupu (na krótką metę).
Jednak, żeby klient poczuł czy "to jest to" musi położyć ręce na produkcie.
Jak powinno wyglądać dobre MVP?
Celem MVP jest przeprowadzenie Twojego użytkownika jedną ścieżką od pierwszego kontaktu z produktem do AHA-momentu.
AHA-moment to chwila, w której użytkownik wstaje od komputera i wykrzykuje EUREKA z zachwytu Twoim produktem.
Rozpoczynając budowę MVP musisz:
- Wyznaczyć jedną ścieżkę, którą przejdzie klient (i zobaczy wartość produktu)
- Rozpisać co trzeba zbudować tylko i wyłącznie do obsługi tej ścieżki
- Upewnić się, że implementacja zajmie Ci nie więcej niż miesiąc (jeżeli jesteś sprawnym programistą).
Jeżeli masz problem z wyznaczenie podstawowej ścieżki do zaimplementowania lub wydaje się ona zbyt skomplikowana to musisz się zastanowić czy budowa tego produktu w ogóle ma sens.
Praktyka
Przy budowie AchieveGuru zakres MVP był tak duży, że w ciągu kliku miesięcy nie udało nam się go dowieźć.
To był duży problem.
Przy MailingR zakres MVP był na tyle prosty, że udało się wdrożyć pierwszą wersję poniżej miesiąca.
Pierwsze MVP MailingR dawało możliwość przejścia pojedynczej ścieżki do AHA-momentu.
Można było zintegrować:
- jeden system mailowy (ActiveCampaign),
- jeden system płatności (Stripe)
- jeden system fakturowy (Fakturownia).
Po wygenerowaniu linków do koszyka użytkownik mógł realnie sprzedać swój pierwszy płatny mailing (AHA-moment).
Pierwsza, najprostsza wersja produktu dawała użytkownikowi wartość, za którą już w tym momencie był w stanie zapłacić.
Dla osób, które nie mogły same przejść podstawowej ścieżki z MVP (miały inny system do maili czy do faktur) nagrałem demo, które pokazywało podstawową funkcjonalność z informacją, że wkrótce zaimplementujemy kolejne integracje.
MVP było szybkie, proste, w pełni zrozumiałe i funkcjonalne dla klienta.
I takie powinno być Twoje MVP!
Jeżeli masz problem z MVP, boisz się, że:
- nie da wartości klientom
--- lub ---
- implementacja zajmie wiele
miesięcy
Przemyśl jeszcze raz swoją koncepcję produktu.
Być może zmienisz jego zakres lub zbudujesz coś innego szybciej,
łatwiej i przyjemniej.
⏰ Życie jest zbyt krótkie na ZBYT SKOMPLIKOWANE MVP.
Pytania do Ciebie
1) Czy budowałeś już kiedyś MVP czy dopiero się przymierzasz?
2) Jaki stack technologiczny wykorzystujesz?
Do napisania w kolejnym mailu,
Bogusz
P.S. My w MailingR korzystamy z Firebase, Cloud Functions i Reacta. (serverless, cały codebase frontend i backend w TypeScript).
P.P.S. Jeżeli jeszcze nie dołączyłeś do mojej grupy Twórcy Aplikacji SaaS to zapraszam tutaj.
|
|
|
|
|