Jak zdefiniować zakres MVP w 3 godziny?

Kiedy zostałem zatrudniony jako kierownik produktu przez firmę zajmującą się przetwarzaniem płatności na wczesnym etapie, firma miała problemy z utworzeniem i dostarczeniem systemu zarządzania zapasami na czas. Rozwiązaniem była prosta aplikacja z klawiaturą, która nie była przyjazna dla użytkownika, co w rezultacie powodowało znaczne odejścia klientów. Moim zadaniem było kierowanie zespołem odpowiedzialnym za zbudowanie systemu inwentaryzacji, który rozszerzy możliwości aplikacji poza funkcjonalność klawiatury.

Ponieważ musieliśmy działać na skróconej osi czasu, stworzyłem proste, ale radykalnie skuteczne podejście do wymyślania, projektowania i budowania minimalnego opłacalnego produktu (MVP) z podstawowymi funkcjami, które pasowały do ​​​​oczekiwanych przez naszych użytkowników. Proces ten skondensował zakres MVP do jednej intensywnej trzygodzinnej sesji — zamiast dni lub tygodni — i zaoszczędził naszemu zespołowi miesiące czasu na rozwój.

Ten przyspieszony proces określania zakresu MVP może być wykorzystany do kierowania dowolnym zespołem produktowym i może być zastosowany do tworzenia dowolnego produktu typu zero-to-one.

Przegląd przypadku użycia

Problem: Prosta klawiatura aplikacji nie zapewniała użytkownikom, którzy byli dostawcami, możliwości zarządzania zapasami lub wybierania pozycji do dodania do zamówienia klienta.

Ograniczenia: Kierownictwo firmy chciało, aby rozwiązanie zostało dostarczone w ciągu ośmiu tygodni; potencjalna runda zbierania funduszy zależała częściowo od sukcesu ulepszonej wersji produktu.

Kontekst: Na podstawie analizy rynku i po spędzeniu czasu z wieloma naszymi użytkownikami ustaliłem, że ci dostawcy potrzebują systemu zarządzania zapasami, aby usprawnić przepływ sprzedaży. Obserwowałem, jak przetwarzają zamówienia klientów: najpierw zapisali żądane pozycje na kawałkach papieru, używali kalkulatorów do zliczania pozycji, a następnie wprowadzali zamówienia do aplikacji. Używali trzech narzędzi, podczas gdy powinni potrzebować tylko jednego.

Rozwiązanie: Musieliśmy opracować rozwiązanie, które umożliwiłoby użytkownikom ładowanie swoich zapasów do katalogu cyfrowego, zarządzanie tymi zapasami i dotykanie wybranych pozycji, aby dodać je do koszyka klienta — wszystko w aplikacji.

Decyzja o sprintach projektowych

Ponieważ już wiedzieliśmy, jaki produkt musimy opracować, zdecydowałem się zrezygnować z typowego sprintu projektowego – cztero- lub pięciodniowych warsztatów, podczas których zespoły współpracują w celu zidentyfikowania głównego wyzwania biznesowego, zebrania pomysłów od klientów na temat rozwiązania problemu, opracuj koncepcję produktu, zaprojektuj prototyp i zacznij go testować.

Sprinty projektowe to skuteczna metoda budowania MVP — dla tych, którzy muszą zidentyfikować podstawowe problemy i mają dużo czasu na opracowanie rozwiązań. Jednak we wczesnych firmach lub nowych jednostkach biznesowych w istniejących organizacjach podstawowe problemy są zazwyczaj oczywiste: koncepcje zostały opracowane, a dopasowanie produktu do rynku było zwykle określane przed zatrudnieniem menedżerów produktu, inżynierów i projektantów.

Poniższy schemat przedstawia kroki, które podjąłem, decydując, że najlepszym sposobem na kontynuację tego projektu jest pominięcie sprintu projektowego i rozpoczęcie od trzygodzinnej sesji, zwanej również rozpoczęciem pracy zespołowej. Podczas tego spotkania uczestnicy przeprowadzili burzę mózgów i wygenerowali dziesiątki pomysłów na funkcje, a następnie skrócili listę tylko do tego, co było wymagane dla MVP.

Proces rozwoju MVP

Przygotowanie

Przed trzygodzinną sesją będziesz chciał zebrać informacje o swoich personach użytkowników, rozmawiając i obserwując obecnych lub potencjalnych klientów oraz przeprowadzając badania rynkowe.

Następnie stwórz prezentację dla projektantów i inżynierów. Powinien wyjaśniać:

• Problem, który próbujesz rozwiązać.
• Produkt, który tworzysz.
• Jak produkt rozwiąże ten problem zarówno pod względem metryk, jak i UX.
• Przewidywany wpływ produktu na biznes Twój i Twojego klienta.
• Misje i cele na poziomie firmy i zespołu oraz kluczowe wyniki (OKR), a także sposób, w jaki produkt pomaga w realizacji tych misji i osiąganiu tych OKR.

Prezentacja powinna dać projektantom i inżynierom solidne zrozumienie produktu, aby móc kontynuować określanie MVP.

Trzygodzinne spotkanie inauguracyjne

Rozpoczęcie powinno obejmować cały zespół programistów, umożliwiając im udział na każdym etapie procesu, od tworzenia pomysłów i historii po opracowanie koncepcji MVP. Obejmuje to starszych, młodszych i stowarzyszonych menedżerów produktu; właściciele produktów; leady produktowe (jeśli dotyczy); projektanci UX; inżynierowie oprogramowania; i inżynierowie QA.

Szybka wskazówka: Chociaż jest to niekonwencjonalne, zalecam włączenie inżynierów przed etapem budowy. Zazwyczaj dostarczają świetnych pomysłów i pasjonują się produktem, który starają się ulepszyć. Większość z nich lubi angażować się w określanie MVP; pomaga im bardziej zainwestować w projekt i docenić je przez inne zespoły.

Zbierz wszystkich w sali konferencyjnej lub wirtualnej przestrzeni roboczej. W naszym przypadku mieliśmy 10 osób. Zablokuj trzy godziny.

Podróże produktu i użytkownika (60 minut)

1. Przeprowadź prezentację. (15 minut)

2. Zacznij identyfikować wszystkie persony użytkownika dla swojego produktu. Nawet jeśli nie zidentyfikowałeś jeszcze żadnych przepływów ani pracy funkcji, możesz zdefiniować liczbę przepływów, które należy zbudować. (10 minut)

   Szybka wskazówka: nie przesadzaj z dodawaniem większej liczby postaci niż to konieczne. Po wydaniu MVP opinie klientów pokażą, czy potrzebujesz dodatkowych ról.

   Przykład użycia: mieliśmy trzy osobowości: kierownika sklepu (lub administratora), kasjera i klienta końcowego. Istniały inne potencjalne postacie wyższego szczebla, takie jak właściciel sklepu, ale dla celów MVP, administrator mógł je pokryć.

3. Mapuj podróż użytkownika od początku do końca. Przypisz kolor do każdej osoby, aby pomóc zidentyfikować każdy etap przepływu, który napotka użytkownik. W przypadku spotkań osobistych umieść karteczki samoprzylepne na ścianie lub użyj tablicy. Do wirtualnych spotkań użyj tablicy FigJam lub czegoś podobnego. (35 minut)

   Szybka wskazówka: niech zespół podzieli się wszystkimi swoimi pomysłami — i uzyskaj szczegółowe informacje. Każdy krok przepływu stanie się funkcją do zbudowania — a każdy użytkownik będzie miał osobny przepływ — ale proces nakreślania kroków będzie taki sam.

   Przykład użycia: Oto lista funkcji dla naszej persony kasjera:

   • Otwórz aplikację w punkcie sprzedaży.
   • Zaloguj się za pomocą kodu PIN.
   • Zidentyfikuj pierwszy przedmiot do zakupu przez klienta.
   • Określ ilość towaru.
   • Zidentyfikuj wszelkie dodatkowe przedmioty do zakupu przez klienta.
   • Dodaj zniżkę na przedmiot (jeśli dotyczy).
   • Całkowity koszt wszystkich produktów w koszyku (w tym momencie wyświetlana jest pełna cena zakupu, w tym podatek od sprzedaży).
   • Zakończ realizację transakcji i płatności.
   • Potwierdź zakup.
   • Pozwól klientowi dodać napiwek.
   • Zamknij sprzedaż.
   • Pokaż sumę wszystkich dziennych sprzedaży.
   • Uzyskaj limit czasu po określonym czasie bezczynności (np. pięć minut).

   Uwaga: ta lista zawiera większość funkcji, o których pomyśleliśmy dla tej postaci. Opracowaliśmy łącznie około 60 funkcji we wszystkich personach, z minimalnym nakładaniem się, jako że kasjer, kierownik sklepu i klient końcowy korzystają z aplikacji na różne sposoby. W zależności od rodzaju opracowywanego produktu może występować znacznie większe nakładanie się funkcji między typami użytkowników.

   

Najważniejsze cechy podróży użytkownika (45 minut)

1. Grupuj funkcje dla każdego typu użytkownika w oddzielnych częściach każdej podróży użytkownika na rzeczywistej lub wirtualnej tablicy. Następnie narysuj poziomą linię na tablicy. Powyżej linii wskaż zestawy, które są wymagane do działania produktu. Poniżej linii umieść funkcje, które są przyjemne, ale mogą poczekać do późniejszych wydań. (30 minut)

   Szybka wskazówka: podziel projektantów i inżynierów na grupy, aby ukończyć ten krok, a następnie spotkaj się ponownie, aby porównać notatki. Jest to szczególnie pomocne przy spotkaniach 10 lub więcej osób.

   Przykład użycia: W naszej aplikacji mieliśmy w tym momencie 12 zestawów funkcji, które obejmowały ładowanie artykułów do katalogu zapasów, ustalanie ich cen, wybieranie artykułów do dodania do koszyka klienta, sprawdzanie i zamykanie wyprzedaży, ponowne zamawianie niskich zapasów, i więcej. Ostatecznie zmniejszyliśmy liczbę zestawów funkcji do czterech.

   Ten proces eliminacji pomógł nam ustalić, że logowanie bezpieczeństwa użytkownika nie było konieczne w pierwszej iteracji aplikacji. Nie dodawał też rabatu ani napiwku. Zdecydowaliśmy również, że kasjer nie musi być w stanie pokazywać całkowitej dziennej sprzedaży w ramach MVP, chociaż kierownik sklepu lub właściciel może.

2. Doprecyzuj listę funkcji. Zapytaj „Gdyby to zostało pominięte, czy produkt nadal będzie działał?” Jeśli odpowiedź brzmi tak, pozostaw tę funkcję poza MVP — zachowaj ją na późniejszą iterację produktu. Jeśli odpowiedź brzmi „nie”, musisz uwzględnić tę funkcję w MVP. Pod koniec tego procesu będziesz wiedział, co jest naprawdę wymagane, aby Twój produkt był funkcjonalny. Często będzie to składać się tylko z trzech lub czterech funkcji dla każdego zestawu. (15 minut)

   Uwaga: Unikaj budowania zbyt wielu zestawów funkcji w MVP. Chociaż powinieneś przewidywać różne opinie na temat tego, co jest najważniejsze do uwzględnienia, Twoim zadaniem jako menedżera produktu jest wykonanie połączenia. Zrobiłeś swoje badania i masz dane, aby poprzeć swoje decyzje. Z mojego doświadczenia wynika, że ​​wiele produktów jest początkowo zbudowanych solidniej, niż jest to konieczne, a większość firm wolałaby jak najszybciej przekazać coś w ręce użytkowników w celu przetestowania i uzyskania opinii.

Projektowanie, testowanie i inżynieria produktu (75 minut)

1. Poproś projektantów, aby zintegrowali podstawowe funkcje z projektem szkieletu MVP, który inżynierowie wykorzystają do zbudowania architektury produktu. (45 minut)

2. Pozwól specjalistom ds. produktu i projektantom współpracować przy lekkich testach UX projektu szkieletu. (15 minut)

   Uwaga: Istnieje bardzo niewiele scenariuszy zarządzania produktem, w których należy budować bez angażowania klienta końcowego, ale w przypadku szybkiego testowania i rozwoju prototyp projektu można przetestować wewnętrznie lub z przyjaciółmi i rodziną, którzy nie znają Twojego produktu. Jeśli są zdezorientowani, niektórzy z Twoich użytkowników też będą.

3. Przekaż zaprojektowane makiety inżynierom, aby rozpoczęli budowę architektury MVP. Nie będą mieli wszystkiego, czego potrzebują – ani czasu – do zbudowania pełnego rozwiązania, ale mogą zacząć, a konstruowana przez nich architektura zostanie wykorzystana podczas ukończenia MVP. W międzyczasie zespoły produktowe i projektowe mogą kontynuować testy na swoich modelach szkieletowych z wewnętrznymi członkami zespołu lub przyjaciółmi i rodziną w roli użytkowników. Współbieżna praca zespołów na tym etapie pozwala zaoszczędzić czas. (15 minut)

Gdy staniesz się bardziej biegły w korzystaniu z tego procesu, łatwiej będzie określić, które funkcje są podstawowymi składnikami MVP, a które można zbudować później. Ta praktyka powstrzyma cię również od budowania niewłaściwych rzeczy: możesz mieć coś na myśli na „późniejszą” listę, tylko po to, aby później dowiedzieć się, że żaden klient tego nie chce.

Wyniki i kluczowe dania na wynos

Przed naszymi wysiłkami nasza aplikacja była klawiaturą z numerami od 0 do 9, kropką dziesiętną i przyciskiem ładowania. Z powodu tego ograniczenia i nieefektywnego przepływu pracy, który stworzył, w ciągu roku nasza retencja była niska – około 20%. Chociaż pozyskiwaliśmy nowych użytkowników szybciej niż konkurencja, traciliśmy ich prawie tak samo szybko.

W trakcie procesu tworzenia MVP zbudowaliśmy cztery kluczowe zestawy funkcji, z których wszystkie miały minimalny zakres, ale wysoką jakość. Użytkownik może teraz:

1. Ładuj przedmioty do ekwipunku bezpośrednio z urządzenia mobilnego, po prostu używając aparatu, wprowadzając nazwę i wpisując cenę.
2. Wybierz te przedmioty i dodaj je do koszyka klienta.
3. Zamknij wyprzedaż podczas przeglądania sprzedawanych przedmiotów.
4. Zobacz liczbę sprzedanych przedmiotów w danym przedziale czasowym.

Klienci pokochali ulepszony produkt. Wskaźnik utrzymania wyniósł 45% wśród nowych użytkowników, którzy skorzystali z funkcji katalogu do realizacji transakcji co najmniej pięć razy w ciągu pierwszego tygodnia od wczytania produktów.

Dzięki wydajności naszego procesu określania zakresu MVP zbudowaliśmy i dostarczyliśmy naszą w pełni gotową aplikację w około dwa miesiące. Ten proces prawdopodobnie zajęłby cztery miesiące lub dłużej przy tradycyjnym podejściu do rozwoju — gdyby produkt w ogóle został zbudowany.

Ten przyspieszony proces oszczędza czas i pieniądze. Pełny sprint projektowy może być kosztowny. Rozpoczęcie od spotkania inauguracyjnego sprawia, że ​​mój proces jest od samego początku bardziej ekonomiczny, a te oszczędności są wzmacniane przez znacznie krótszy ogólny harmonogram rozwoju.

Jednak te dwa procesy mogą również działać w tandemie: jeśli Twój zespół zakończył sprint projektowy w celu zdefiniowania podstawowego problemu biznesowego i rozwiązania, które musisz stworzyć, możesz użyć mojego procesu do bardziej efektywnego zdefiniowania zakresu MVP.

Pamiętaj, że ten proces to dopiero początek: MVP to praca w toku, która zostanie dopracowana w późniejszych wydaniach. Gdy jest już w pełni zbudowana i gotowa do dostarczenia, polecam dodanie przełącznika beta, który użytkownicy mogą wyłączyć, aby powrócić do starego środowiska aplikacji. Wykorzystanie oprogramowania zachowań, takiego jak Heap, do śledzenia, ilu użytkowników korzysta z tej opcji, da ci dobre wyobrażenie o tym, co należy dodać lub zmienić, aby ulepszyć produkt w następnej iteracji.