Idea Minimum Viable Product wydaje się prosta: stwórz podstawową wersję Twojego produktu, która będzie składać się wyłącznie z elementów niezbędnych do jej poprawnego funkcjonowania. Z naszego doświadczenia wynika, że to właśnie prostota tej definicji zwodzi właścicieli produktu; przychodzą oni do agencji uzbrojeni w niezdefiniowany jeszcze pomysł, a już przeliczają przewidywane zarobki, zamiast skupić się (chociażby) na przygotowaniu odpowiedniej dokumentacji projektowej.
Usługi związane z tworzeniem MVP świadczyliśmy od początku istnienia FROGRIOT – nie tylko w zakresie webdevelopmentu, ale również designu, analityki biznesowej, pricingu czy brandingu i marketingu. Wiemy z czym właściciele projektów borykają się najczęściej; wiemy też, jak można tego łatwo uniknąć. Tworzenie MVP jest procesem pełnym pułapek, na które można się jednak przygotować – ale najpierw trzeba je poznać.
Dzięki poniższej liście będziecie gotowi na najczęściej występujące problemy przy projektowaniu i wdrażaniu MVP 🙂
Wcale nierzadko zdarza się, że product ownerzy tworzący własne MVP przychodzą do nas z samym pomysłem na aplikację czy platformę. Czasem jest on poparty skromnym briefem, czasem nie. Na tej podstawie oczekują rzetelnej wyceny, która jest oczywiście niemożliwa – a nawet niewskazana. Zawsze staramy się sprowadzić klienta na dobrą ścieżkę i zrobić z nim analizę projektu, na podstawie której nie tylko wypracujemy dokumentację projektową, ale przede wszystkim: będziemy w stanie realnie ocenić czas i koszta.
Złota zasada: nigdy nie twórz MVP nie posiadając szczegółowej specyfikacji.
Tworzenie platformy internetowej bez dokumentacji projektowej jest jak budowa domu bez projektu – nie polecam.
Specyfikacja projektu powinna składać się z:
Dodatkowo, zazwyczaj zawiera się w niej także wymagania brandingowe, w tym brief dla designera.
Dokumentacja projektowa pozwala na precyzyjne określenie zakresu projektu i staje się sensowną podstawą do wyceny oraz punktem odniesienia podczas realizacji – zarówno dla wykonawcy, jak i zleceniodawcy. Co ważniejsze – taka dokumentacja pozwala na znalezienie najlepszej ścieżki dla realizacji funkcjonalności pod kątem przyszłych użytkowników.
Pierwszym produktem, który chcemy pokazać światu powinien być MVP.
No właśnie – pierwszym, ale z pewnością nie ostatnim 🙂 Po MVP powinny powstawać kolejne wersje, funkcjonalności, dodatki, a czasem nawet pivoty – wszystko na podstawie feedbacku userów, zgodnie z zasadą:
Tymczasem, często jesteśmy świadkami sytuacji, w której klient traktuje MVP jak finalną wersję, przez co każdą drobną zmianę odbiera jako zmianę jego pierwotnej idei lub (co gorsza) złe doradztwo przy tworzeniu MVP. Przyczyn takiej sytuacji jest kilka: brak finansowania, brak specyfikacji, oczekiwanie szybkich zysków czy brak zrozumienia tego jak powstają i ewoluują projekty internetowe. Niezależnie jednak od przyczyny należy pamiętać, że powstanie MVP to dopiero początek.
Coraz częściej MVP niezbędne jest jako Proof of Concept i dopiero projekt w takiej wersji pozwala na zebranie finansowania. Coraz mniej inwestorów wierzy w jakikolwiek pomysł “na słowo”; oczekują namacalnego produktu (wraz ze skalowalnym modelem biznesowym). Przykładem takiej sytuacji na rodzimym podwórku może być Znany Lekarz, który duże dofinansowanie zdobył dopiero po stworzeniu w pełni działającej wersji MVP produktu, następnie sporo środków poświęcił na szukanie odpowiedniego modelu (tak swojego produktu jak i biznesowego), a dopiero w chwili obecnej prowadzi ekspansję na kolejne rynki.
W biznesie chodzi o pieniądze, to jasne. Natomiast funkcjonowanie startupu przypomina raczej maraton, niż wyścig na 100 metrów. Dlatego przestrzegamy klientów przed próbą szybkiej monetyzacji swojego biznesu. Przy małej skali jest to niezwykle trudne i zwykle kończy się porażką – jeżeli celem jest szybki zysk, to siłą rzeczy drugotorowy staje się produkt w kontekście jego najlepszej wersji dla użytkownika. Dużo ważniejsze jest znalezienie sensownego modelu, ciągła ewolucja produktu skupiona na budowaniu skali i co ważniejsze dowody na to, że przy odpowiednim finansowaniu model da się skalować w dalszym ciągu. Właśnie takie startupy inwestorzy są skłonni finansować dalece chętniej – a o to przecież chodzi.
We wpisie o 10 błędach popełnianych przy tworzeniu startupu pisaliśmy o tym, jak zbyt często ulegamy ułudzie, że dobry w odczuciu foundera pomysł, to wystarczający powód i kierunkowskaz podczas tworzenia MVP. Choć posiadamy sporą wiedzę, to nikt nie ma monopolu na prawdę, a ta – zwłaszcza w szybko zmieniającym się świecie marketingu – może być zupełnie inna, nawet dla podobnych do siebie projektów.
Niestety wielokrotnie spotykamy się z niedocenianiem roli badań w procesie budowy MVP. Od tak elementarnych, jak badanie potrzeby produktu w grupie docelowej, które odpowie na pytanie czy nasi potencjalni użytkownicy są w ogóle zainteresowani naszym produktem, przez badania dotyczące chociażby person, czy ustalenia kim nasza grupa docelowa rzeczywiście jest, aż po bardziej szczegółowe badania UX i testy A/B podczas decyzji nad wyborem sposobu realizacji pojedynczej funkcjonalności. Wszystkie wyżej wymienione badania są regularnie pomijane.
Powody są przeważnie dwa: koszty i z góry poczynione założenia. Badania kosztują, co do tego nie ma żadnych wątpliwości. Niemniej, dalece bardziej kosztowny jest produkt, którego nie chce nikt, poza samym pomysłodawcą, albo dodatkowa funkcjonalność, która psuje przyjemność użytkowników z korzystania z produktu.
Świetnym przykładem na to może być aplikacja mobilna HotJar – firma stworzyła aplikację nie badając (zakładając z góry) potrzeby istnienia takowej. Efekt? Utopione 200 000 USD, a finalnie projekt, który został zabity.
W takim kontekście warto myśleć o tym czy badania są rzeczywiście drogie i czy warto opierać się na samodzielnie skonstruowanych tezach bez ich empirycznego sprawdzenia. We FROGRIOT zdajemy sobie sprawę, że founderzy często nie wiedzą jak się do badań zabrać, ale zawsze gorąco namawiamy naszych klientów do ich prowadzenia – jeżeli tylko możemy wspieramy lub realizujemy je w imieniu Klienta. Sami natomiast traktujemy badania jako jedno z narzędzi służące do budowy lepszych projektów – w tym MVP.
W biznesie na końcu zawsze chodzi o pieniądze – te się muszą zgadzać. Wiele omawianych tutaj problemów sprowadza się do niewystarczającego lub całkowitego braku budżetu. Problemy z pieniędzmi wynikają najczęściej z błędnych założeń początkowych i/lub braku wizji przyszłości.
Często błędnie zakłada się, że MVP to największy koszt jaki zostanie poniesiony w procesie tworzenia startupu. Jeżeli pod uwagę weźmiemy inne składowe, takie jak: marketing, wynagrodzenia, rozwój produktu czy infrastruktura, to szybko okaże się, że koszt MVP, to tylko początek wydatków – i wcale nie ich największa część.
Po drugie, próba szybkiej monetyzacji oraz założenie, że MVP to ostateczna wersja prowadzi do błędnego myślenia: “jak tylko odpalimy projekt to nie dość, że szybko zacznie się on zwracać (czyt. zaczniemy zarabiać), to jeszcze nie będziemy mieli żadnych dodatkowych kosztów, bo przecież MVP może być finalną wersją i nie trzeba go rozbudowywać”.
Błąd – trzeba! MVP nigdy nie jest ostateczną wersją. Podobne myślenie jest szybkim przepisem na porażkę i wyrzuceniem wydanych środków w błoto.
Na szczęście istnieje wiele źródeł finansowania, które dostępne są w zasadzie od samego początku ścieżki budowy startupu: środki unijne, fundusze publiczne i prywatne czy crowdfunding to tylko niektóre z nich. O przykładach takich finansowań pisał Mateusz, we wpisie “Skąd wziąć pieniądze na startup?”.
Ten punkt można rozwinąć szerzej i objąć nim cały proces User Experience.
Być może ciężko uwierzyć, ale jest to bardzo często pomijana faza projektowa; tymczasem to tutaj wykluwa się całe doświadczenie użytkownika związane z korzystaniem z produktu. W świadomych organizacjach jest to oczywiście nie do pomyślenia, natomiast w wielu innych jest to bieżący (i smutny) stan rzeczy.
Gdyby istniała instrukcja projektowania, to wszystkie serwisy wyglądałyby i działały tak samo – wtedy być może dałoby się ominąć ten etap. Jednakże, funkcjonujemy w stale zmieniającym się świecie wymagań użytkowników, coraz nowszej technologii, urządzeń oraz modeli biznesowych, dlatego stary, dobry proces UX – a prototypowanie w szczególności! – pozwala nam zaprojektować odpowiednie doświadczenie płynące z korzystania z serwisu, uzmysławia nam problemy i wyzwania przed jakimi stoją nasi przyszli użytkownicy oraz pozwala znaleźć najskuteczniejsze metody radzenia sobie z nimi.
Jaki wykonawca jest zły? Taki, który nie mając pełnej wiedzy o projekcie przedstawia konkretną wycenę.
Jaki wybór wykonawcy jest zły? Bazujący tylko i wyłącznie na przesłankach finansowych, bez ujęcia tego w kontekście sposobu wykonania, czyli specyfikacji lub analizy MVP.
Nie mam nic przeciwko dokonywaniu wyboru wykonawcy na podstawie przesłanki finansowej, ale należy pamiętać, że budowa MVP to usługa, której efektem jest produkt. I jako taka, będzie realizowana w różny sposób przez różnych wykonawców.
Pierwszym pytaniem przed dokonaniem wyceny powinno być “jak”, a nie “ile” – czyli wykonanie analizy i dokumentacji projektu (patrz pkt 1) i tej jej podstawie ocena czasochłonności realizacji. Brak działania w takim modelu sprawi, że jako klient zawsze będziesz w złej pozycji, ponieważ: albo poniesiesz koszty przebudowy projektu kiedy okaże się, że nie jest on zgodny z Twoimi oczekiwaniami, albo otrzymasz produkt z którego nie będziesz zadowolony, jak przez mgłę przypominający Twoją początkową wizję.
Tworzenie MVP to usługa, której efektem jest produkt i jako taka będzie realizowana w różny sposób przez różnych wykonawców.
Oczywiście istnieje szereg dodatkowych przesłanek, które powinny być wzięte pod uwagę podczas wyboru wykonawcy: doświadczenie, referencje, zaangażowanie, technologia wykonania, gwarancja, SLA, warunki rozwoju, czy posiadane kompetencje. To wszystko może i powinno wpłynąć na wybór wykonawcy, ale jeżeli na pierwszy plan wychodzi szybka i jak najtańsza wycena, to pamiętaj, że narażasz się na gorszy efekt końcowy.
Feedback użytkowników jest bardzo ważny – to dla nich tworzymy MVP i tylko od nich zależy nasze “być, albo nie być” na rynku. W dyskusji o rozwoju produktu na bieżąco powinny być uwzględniane zarówno zgłaszane przez użytkowników uwagi, jak i badania ich zachowania. Na tej podstawie możemy generować pomysły, nowe funkcjonalności i usprawnienia.
Tymczasem, czy to z braku badań (punkt 5), czy z braku budżetu, czy ze zwykłego zaniechania, zdanie tych dla których tworzy się produkt często nie jest uwzględniane. To główny gwóźdź do trumny każdego MVP.
Zupełnie osobną kategorią jest za to złe zarządzanie feedbackiem. Olbrzymią zdolnością jest ocena feedbacku; zarówno pod względem jego istotności, jak i tego, czy uwzględnianie nowych funkcjonalności oraz zmian nie sprawi, że pogorszy się odbiór produktu wśród bazy odbiorców.
Świetnie ilustruje to Jason Fried w swojej książce “Rework” pisząc o zarządzanym przez siebie Basecampie:
“Po jakimś czasie od wypuszczenia naszego pierwszego produktu na rynek zaczęliśmy dostawać sygnały od naszych pierwszych klientów, że zaczynają “wyrastać” z naszej aplikacji. Ich firmy ewoluowały, więc chcieli, abyśmy zmienili nasz produkt (…). Powiedzieliśmy “nie” (…). Dodanie paru zaawansowanych funkcji służących kilku użytkownikom może onieśmielić tych, którzy jeszcze nie zostali Twoimi klientami.”
Jason Fried
Większość aplikacji (w tym MVP) nie jest gotowa na sukces “w ciągu jednej nocy”.
Wzmianka na popularnym blogu, artykuł w prasie branżowej czy nawet tweet osoby ze sporym zasięgiem może sprawić, że staniesz w obliczu wolumenu ruchu, którego nie będziesz w stanie obsłużyć. Zamiast radości z zysków, pojawiają się problemy: od wolnego działania, przez utratę danych, po całkowitą niedostępność aplikacji. Zgodnie z badaniami Google 61% użytkowników nie daje aplikacjom drugich szans w przypadku złych doświadczeń, a 40% uda się wprost do konkurencji.
A przecież można temu łatwo zapobiec już na etapie planowania.
61% nie daje aplikacjom drugich szans w przypadku złych doświadczeń a 40% uda się wprost do konkurencji.
Co więcej, w przypadku nieodpowiedniego podejścia istnieje ryzyko, że całą infrastrukturę sieciową trzeba będzie stworzyć na nowo i ponieść koszty fizyczne (pieniądze) oraz niematerialne (opinia, czas, stres).
Przemyślane projektowanie aplikacji oznacza konieczność określenia przewidywanego ruchu – nie tylko w ciągu najbliższych tygodni, ale również w przyszłości. Jednocześnie architektura powinna być nastawiona na łatwą skalowalność. Całość można i należy potwierdzać testami obciążeniowymi.
Rozwiązań infrastrukturalnych jest wiele – ważne, aby mieć pewność, że w obliczu sukcesu nie padnie się jego ofiarą z powodu zaniedbań w zakresie infrastruktury technicznej.
Często spotykamy się z sytuacją, w której klienci trafiając do nas są już po nieprzyjemnych przejściach z dotychczasowym wykonawcą 🙁
Niestety, jest to często spowodowane sytuacją, w której w wyniku braku kompetencji po stronie Klienta, jego team nie jest w stanie odpowiednio przygotować, ocenić i doprecyzować specyfikacji działań, umowy oraz odbioru projektu – w rezultacie produkt końcowy odbiega od wizji tego, czym produkt miał być.
Właśnie dlatego zawsze otwarcie witamy specjalistów po stronie Klienta i zapraszamy ich do ścisłej współpracy z nami. Ostatecznie – posiadanie osób znających się na rzeczy sprawia, że finalny produkt jest lepszy – a o to przecież chodzi!
Oto i ona – lista 10 błędów podczas tworzenia MVP aplikacji. Można ją zawęzić do trzech kluczowych pojęć: wiedza, rozwój i budżet.
Uzbrojony w taką wiedzę każdy właściciel startupu jest w stanie w sposób świadomy podejść do realizacji MVP, zwiększając swoje szanse na odpowiedzialny rozwój startupu, utrzymanie realnego budżetu w ryzach, a finalnie: zdecydowanie podnosząc szanse na końcowy sukces.
