MVP — co wyciąć, a czego nie wycinać?

Z naszej praktyki: najtrudniejsza rozmowa z klientem to wcale nie ta o tym, co dodać. To rozmowa o tym, co odłożyć na później. Każdy przychodzi z listą funkcji na dwa lata budowania, a MVP portalu powinno zawierać jedną rzecz: najkrótszą ścieżkę, na której użytkownik dostaje wartość, a Ty dostajesz dowód, że biznes działa. Wszystko, co tej ścieżki nie dotyczy, może poczekać. I zaraz pokażę konkretnie, co wycinamy bez żalu, a przy czym się upieramy — czasem wbrew klientowi, który chciałby na tym oszczędzić.

Żelazna zasada: wycinamy funkcje, nie jakość

Zanim przejdziemy do listy, jedno rozróżnienie, od którego zależy wszystko. MVP to portal o małym zakresie, a nie portal zrobiony byle jak. Różnica jest zasadnicza.

Mniej funkcji — jak najbardziej. Ale te, które zostają, mają działać porządnie: bez błędów przy typowym użyciu, szybko, bezpiecznie, na telefonie tak samo dobrze jak na komputerze. Bo pierwszy użytkownik nie wie, że patrzy na „wersję minimalną". On widzi po prostu Twój portal. Jak coś się wysypie przy rejestracji, nie pomyśli „to MVP, wrócę za kwartał". Pomyśli „nie działa" i już nie wróci.

Dlatego kiedy budżet ciśnie, tniemy zakres, a nie jakość wykonania. Krótsza lista funkcji zrobionych solidnie zawsze wygra z długą listą zrobioną na pół gwizdka. Tę pierwszą da się rozbudować. Tę drugą najczęściej trzeba pisać od nowa.

Czego nie wycinać, choć kusi

Są cztery obszary, przy których uparcie mówimy „nie" — bo oszczędność na nich jest pozorna i mści się w najgorszym możliwym momencie, czyli tuż po starcie.

Porządna rejestracja i logowanie. Nudny temat? Owszem. Ale to pierwsze drzwi do Twojego portalu i miejsce, w którym trzymasz dane osobowe użytkowników. Odzyskiwanie hasła, potwierdzenie adresu e-mail, zabezpieczenia przed botami, sensowna obsługa błędów — to musi być od pierwszego dnia. Wyciek danych albo konto, do którego nie da się wrócić, potrafi zabić młody portal skuteczniej niż brak jakiejkolwiek funkcji.

Płatności — jeśli Twój model na nich stoi. Spotykamy pokusę w stylu „na początku faktury będę wystawiać ręcznie, płatności dorobimy później". Czasem to nawet dobry pomysł (patrz niżej), ale nie wtedy, gdy cały model biznesowy polega na pobieraniu prowizji czy abonamentu. Bo wtedy MVP bez płatności niczego nie weryfikuje — najważniejsze pytanie („czy ludzie zapłacą?") zostaje bez odpowiedzi.

Panel administracyjny. Klienci często go nie widzą w wyobraźni, bo myślą tym, co widzi użytkownik. A potem startuje portal i nagle trzeba: zablokować spamera, poprawić czyjeś ogłoszenie, podejrzeć, dlaczego płatność nie przeszła, wyeksportować dane. Bez panelu każda taka drobnostka to telefon do programisty — i faktura. Prosty panel od pierwszego dnia zwraca się w miesiąc.

Podstawy SEO i techniczne minimum. Przyjazne adresy, poprawne tytuły i opisy stron, mapa strony, sensowna szybkość ładowania. To nie jest „pozycjonowanie" — to fundament, dzięki któremu Google w ogóle może Cię znaleźć. Dorabianie tego po roku bywa zaskakująco kosztowne, a ruch z wyszukiwarki buduje się miesiącami, więc każdy miesiąc zwłoki to miesiąc stracony.

Co spokojnie poczeka na drugą wersję

A teraz druga strona medalu — funkcje, które w pierwszej wersji portalu prawie nigdy nie są potrzebne, choć prawie zawsze pojawiają się na wstępnej liście życzeń:

• Aplikacja mobilna. Dobrze zrobiony portal działa na telefonie w przeglądarce i na start w zupełności to wystarcza. Aplikacja to osobny, spory budżet — ma sens, gdy użytkownicy już są i wracają, a nie wcześniej.
• Czat i komunikator. Wewnętrzna poczta albo zwykły formularz kontaktowy między użytkownikami załatwia sprawę. Czat na żywo z powiadomieniami to duży kawał pracy, a na początku i tak rozmawia ze sobą garstka osób.
• Rozbudowane profile użytkowników. Odznaki, portfolio, statystyki, ustawienia prywatności na dziesięć ekranów — to wszystko ma sens przy tysiącach aktywnych kont. Na start wystarczy imię, avatar i to, co niezbędne w Twoim procesie.
• Automatyzacje i integracje. Automatyczne fakturowanie, powiadomienia SMS, integracja z systemem księgowym. Dopóki masz dwadzieścia transakcji miesięcznie, zrobisz to ręcznie w godzinę. Automatyzować należy ból, który już istnieje, a nie ten wyobrażony.

Zwróć uwagę na wspólny mianownik: każda z tych rzeczy staje się potrzebna dopiero wtedy, gdy portal ma już użytkowników. Czyli wtedy, gdy będzie Cię na nią stać z dużo spokojniejszą głową — i gdy będziesz wiedzieć znacznie więcej o tym, jak ludzie naprawdę korzystają z serwisu.

Jak podejmować te decyzje w praktyce?

Prosty test, którego używamy na warsztatach z klientami. Bierzemy funkcję z listy i zadajemy dwa pytania. Pierwsze: czy bez tej funkcji użytkownik może przejść główną ścieżkę — od wejścia na portal do momentu, w którym dostaje swoją wartość? Drugie: czy bez niej dowiemy się, czy biznes działa? Jeśli obie odpowiedzi brzmią „tak, może" i „tak, dowiemy się" — funkcja wypada z pierwszej wersji. Bez dyskusji o tym, czy jest fajna. Fajna pewnie jest.

Pomocne jest też odwrócenie ciężaru dowodu. Nie pytamy „dlaczego to wyciąć?", tylko „dlaczego to musi być na starcie?". Odpowiedź „bo konkurencja ma" nie wystarcza — konkurencja ma też dziesięć lat przewagi i zespół na etatach. Ty konkurujesz na innym polu: szybciej się uczysz.

I rzecz ostatnia: odłożone nie znaczy skreślone. U nas rozwój po starcie toczy się w miesięcznych pakietach godzin, więc lista „na później" to po prostu plan kolejnych miesięcy — tyle że układany już z wiedzą, jak użytkownicy naprawdę korzystają z portalu. Bardzo często okazuje się wtedy, że połowa tej listy przestała być ważna, a na czoło wychodzą rzeczy, których nikt na początku nie przewidział. Cały proces — od pomysłu, przez MVP, po rozwój — opisaliśmy krok po kroku w publikacji tworzenie portalu internetowego krok po kroku.

Masz swoją listę funkcji i nie wiesz, co z niej zostawić? Przyślij ją nam — napisz do nas, przejdziemy przez nią razem i uczciwie powiemy, co naszym zdaniem może poczekać. Takie przycinanie listy to u nas normalna część pierwszej rozmowy, jeszcze przed jakąkolwiek wyceną.