Zanim przejdziemy do rozwijania produktów i usług, a co za tym idzie testowania kolejnych pomysłów, warto podkreślić jaki jest główny cel prowadzenia firmy. Bezspornie możemy uznać, że jest nim maksymalizacja przychodu.

Oczywiście firmy definiują różne cele strategiczne (i przeważnie nie jest to zarabianie pieniędzy), lecz aby mogły funkcjonować, muszą pokrywać koszty związane z działalnością przedsiębiorstwa takie jak: podatki, wypłata wynagrodzeń, opłacenie przestrzeni biurowej, zakup sprzętu, licencji, itp. Oczywiście pozostałe pieniądze nie stanowią wyłącznie dochodu właściciela firmy i mogą być na przykład reinwestowane w rozwój przedsiębiorstwa, jak robi to m.in. Amazon.

Na pewno jednak prowadzenie działalności to nie przeciągające się projekty bez jasnego celu czy zdefiniowanego zakresu. Pamiętajmy, że każda akcja podejmowana przez zespoły (od dodania nowego feature’a, przez refaktoring, po zmiany w UX/UI) powinna być przemyślana, zaplanowana, mierzalna i weryfikowana pod kątem dostarczonych wartości, a wyciągnięta wiedza będzie stanowić podstawę do dalszego rozwoju organizacji.

Uważam, że zasadne jest aby każdy pracownik miał świadomość tego skąd biorą się pieniądze na jego wynagrodzenie. Pomoże to podejmować właściwe decyzje oraz usuwać z codziennych zadań rzeczy zbędne, które stanowią dla organizacji szeroko rozumianą stratę.

W tym artykule przedstawiam zagadnienia związane z iteracyjnym weryfikowaniem hipotez i najbardziej popularne metody stosowane przez zespoły produktowe.

Product Owner/Manager, Mini CE, Przedsiębiorca, …

Źródłem zysku w firmie jest przeważnie sprzedaż wytwarzanego produktu lub świadczenie usług z nim związanych. Za ich rozwój odpowiada właściciel firmy lub zatrudniony przez niego „właściciel produktu”. To jego zadaniem jest maksymalizacja zysku płynącego z podejmowanych działań. Warto zauważyć, że w korporacjach biznesowy właściciel produktu bardzo często nie jest bezpośrednio (a czasem nawet pośrednio) odpowiedzialny za wypłaty wynagrodzeń, czy rozliczenie kosztów związanych z projektami.

Prowadzi to do niebezpiecznej sytuacji, w której skupienie zespołów na dowiezieniu kluczowych funkcjonalności może się rozmywać na rzecz pobocznych działań. Pamiętajmy jednak, że przy obecnych kosztach pracy czas = pieniądz. Definiujemy więc zakres pracy w sposób przynoszący największą możliwą wartość i eliminujemy zbędne prace zjadające cenny czas naszych zespołów. Czy jeśli pokrywalibyśmy koszty pracy “z własnej kieszeni”, także pozwolilibyśmy na rozproszenie uwagi zespołu na rzeczy nie związane z celami firmy?

Aby sprawnie poruszać się w firmie oraz zapewnić wszystkie umiejętności wymagane do dostarczenia zmian na produkcję oraz ich marketing i sprzedaż, właściciel produktu musi być cross-funkcyjnym liderem zapewniającym sukces produktu zgodny z celami organizacji. Implikuje to konieczność współpracy z różnymi rolami/działami takimi jak biznes, marketing, produkt, graficy, technical writer’rzy, programiści, administratorzy, itd. To właśnie właściciel produktu stanowi radiator informacji dla zaangażowanych osób, wyznacza cele oraz motywuje do działania. Wymaga to umiejętności nawiązania kontaktu z pracownikami o różnych kompetencjach i może być dużym wyzwaniem dla lidera wywodzącego się z jednej konkretnej dziedziny (np. programista lub UX), który nie był wcześniej przygotowany do interdyscyplinarnej współpracy.

Kogo potrzebujemy aby rozwijać produkt i testować pomysły

W obecnej definicji cross-funkcyjnego zespołu dostarczającego zmiany „pod klucz”, developer to każda osoba dająca wkład w ten proces. Może to być więc programista, tester czy administrator, ale także osoba pisząca dokumentację produktową, sprzedawca który wprowadzi zmianę na rynek czy marketer przygotowujący kampanię uruchamianą po wdrożeniu kodu na produkcje.

Coraz częściej w firmach pojawiają się dedykowane Zespoły Wzrostu (Growth Teams) odpowiedzialne za generowanie i walidowanie hipotez mających na celu zwiększenie w systematyczny sposób ilości klientów, retencji oraz przychodów. W skład takiego zespołu wchodzą przeważnie:

  • Lider/Champion zespołu – organizuje i motywuje zespół, pomaga usuwać przeszkody oraz wspomaga komunikację z innymi zespołami
  • Project Manager – odpowiada za dostarczenie projektu zgodnie z przyjętymi zasadami
  • Growth Hacker – generator pomysłów
  • UX/UI – odpowiedzialni za zaprojektowanie wyglądu oraz interakcji ale także za analizę zebranych informacji oraz ewolucję interfejsu w oparciu o dane
  • Developer – rola tworząca kod rozwiązania dobrze rozumiejąc założenia biznesowe
    Tester – odpowiada za zapewnienie pożądanej jakości (nie oznacza to że sama prowadzi i pisze testy)
  • Content Marketer – rola zapewniająca wprowadzenie pomysłu na rynek za pomocą narzędzi marketingowych
  • Channel Guru – pomaga w sprzedaży i marketingu specjalizując się w różnych kanałach takich jak social media, youtube, itd.
  • Data Analyst – rola projektująca miejsca w systemie umożliwiające zbieranie danych oraz zapewniająca ich późniejszą analizę; w tym zakresie współpracuje z pozostałymi rolami które wykorzystają dane do dalszej optymalizacji rozwiązania

Zespół taki implementuje pomysły i waliduje je na środowisku produkcyjnym w sposób który nie zakłóca pracy zespołu rozwijającego produkt, jak i użytkowników, którzy już z niego korzystają. Ideą jest tutaj szybkie przetestowanie i unicestwienie nietrafionych pomysłów, oraz jak najszybsze odciążenie zespołu poprzez przekazywanie tych sprawdzonych eksperymentów do dalszego rozwoju i utrzymania pozostałym działom firmy. Tego typu podejście jest rozwinięciem koncepcji R&D zapewniających organizacji innowacyjność oraz przewagę nad konkurencją.

PoC, Prototyp, MVP, Produkcja

Zacznijmy od przyjrzenia się różnym etapom testowania pomysłu oraz oczekiwaniom pokładanym w każdym z nich. Pierwszym, najmniejszym i najtańszym projektem mającym na celu udowodnienie, że produkt (lub funkcjonalność) MOŻE zostać wykonany jest Proof of Concept.

Przeważnie są to działania wewnątrz organizacji służące weryfikacji postawionej tezy lub sprawdzeniu możliwości technologicznych potrzebnych, aby dostarczyć finalne rozwiązanie. Celem jest szybkie i tanie sprawdzenie pomysłu, więc koncentracja zespołu powinna być skupiona wyłącznie na rzeczach ważnych do podjęcia późniejszej decyzji co do kontynuowania prac.

Większym i prawdopodobnie kosztowniejszym podejściem jest wytworzenie prototypu odpowiadającego na pytanie: JAK może zostać zrealizowany projekt? W tym wypadku chcemy uzyskać znacznie większą ilość informacji, które posłużą do wyciągnięcia kolejnych wniosków. W pierwszej kolejności możemy identyfikować potencjalne problemy i trudności zanim napotkamy je w trakcie realizacji finalnego produktu. Dzięki temu możemy już na tym etapie zdecydować czy rozwiązanie ich jest opłacalne, oszacować koszt/czas w docelowym projekcie potrzebny na ich zaadresowanie lub poszukać wsparcie poza firmą.
Prototyp to także forma komunikacji takich elementów jak: wygląd, architektura, rozkład treści, nawigacja, itp. Dzięki niej już na wczesnym etapie mamy możliwość konsultacji i korekty. Co więcej jest to także możliwość pokazania że postawiony cel jest osiągalny. Przyda się to na spotkaniach z przełożonymi, decydentami lub potencjalnymi inwestorami chcącymi zobaczyć jak minimalizujemy ryzyko nietrafionej inwestycji.
Minimum Viable Product (MVP) to kolejne podejście do walidacji naszych teorii. Na tym poziomie mówimy już o minimalnym produkcie gotowym aby ujrzeć światło dzienne. Tutaj chcemy zebrać od użytkowników jak najwięcej informacji zwrotnej na temat naszego pomysłu. Minimalizacja projektu powinna odbywać się kosztem mniej potrzebnych funkcjonalności, które rozszerzają core’ową część. Nigdy natomiast nie powinna być osiągana kosztem jakości. Także w tym podejściu staramy się obniżyć cenę wytworzenia, aby ewentualna decyzja o zaniechaniu projektu/funkcjonalności wygenerowała jak najmniejsze straty. Poza weryfikacją naszych założeń na docelowym kliencie, MVP daje możliwość odkrycia nowych kierunków rozwoju czy podjęcia popartych danymi decyzji na temat tego które funkcjonalności i w jakiej kolejności rozbudują w produkcie to co stworzyliśmy w ramach MVP.
Oczywistym finalnym stadium projektu jest wersja produkcyjna. To pełna, stabilna wersja naszego pomysłu gotowa do podjęcia działań komercjalizujących. Poza funkcjonalnościami widzianymi z perspektywy klienta, od naszego produktu powinniśmy oczekiwać dojrzałości pozwalającej na jego utrzymanie, takich jak zapewnienie mechanizmów do szybkiej identyfikacji miejsc wystąpienia problemu (np. dobre pokrycie logami), prosty sposób wykonania i przywracania backup’u, czy przejrzysta struktura danych pozwalająca na wydajne raportowanie. Powinniśmy mieć także możliwość zbierania danych dotyczących zarówno funkcjonowania systemu jak i zachowania naszych użytkowników.
To oczywiście nie koniec rozwoju naszego produktu. Jego architektura powinna umożliwiać efektywne rozbudowywanie, modyfikacje lub usuwanie zbędnych funkcjonalności. Myśląc o dalszym rozwoju oraz rozumiejąc skomplikowanie obecnych systemów, oczekujemy iteracyjnego dostarczania kolejnych funkcjonalności, co także musi umożliwiać architektura systemu.

Testy A/B

Sposób testowania zmian zakładający porównanie dwóch wersji funkcjonalności różniących się jednym elementem. Umożliwia zbadanie tezy na odbiorcy oraz podjęcie decyzji w oparciu o wiedzę, co do tego która z zaproponowanych wersji spotkała się z lepszym odbiorem. Także wymaga wsparcia od strony architektury, która musi umożliwiać przekierowywanie klientów pomiędzy dwiema różnymi wersjami funkcjonalności działającymi w tym samym czasie oraz zbieranie danych, które później pozwolą ocenić oba podejścia. Wadą jest zwiększenie kosztu (musimy wyprodukować dwie wersje tej samej funkcjonalności) oraz brak możliwości znalezienia korelacji większej ilości elementów.

Crowdfunding

Mniej oczywistym podejście do testów biznesowych, ale o bardzo szerokich możliwościach – nieosiągalnych w innych metodach – jest crowdfunding. Umożliwia on podjęcie próby sprzedaży projektu jeszcze przed jego wykonaniem, pozwalając oszacować zainteresowanie potencjalnych klientów oraz ocenić gotowość rynku (wyszukiwarki zbliżone do Google powstały już wcześniej jednak nie było na nie wtedy zapotrzebowania). Wyjście do klientów to także możliwość ich zaangażowania w projekt produktu oraz zebrania feedback’u. Nie zapominajmy także o tym że ewentualne pieniądze możemy zarobić jeszcze zanim będziemy posiadać gotowy do sprzedaży produkt.
Badanie rynku

Wcześniejsze zebranie informacji o docelowym rynku może uchronić nas przed nieoczekiwanymi kosztami lub brakiem popytu. Pozwala ocenić dopasowanie produktu do odbiorcy oraz wykonać niezbędne poprawki. Niestety przygotowanie miarodajnego badania rynku jest niezwykle trudne, a zatrudnienie specjalizującej się w tym agencji może być bardzo kosztowne. Jeśli więc nie stać nas na pomoc z zewnątrz, spróbujmy wykonać DIY research organizując warsztaty lub prezentacje. Pomocne mogę być lokalne grupy meet-up’owe skupiające osoby z interesującej nas dziedziny. Poszukajmy także informacji w sieci. Dostępne są wyniki badań nakierowane na różne sektory oraz narzędzia prezentujące analizy zapytań (jak np. trends.google.com).

Business Model Canvas

Kanwy biznesowe to sposób prezentacji pomysłu dzielący go na dziewięć najistotniejszych obszarów:

  • Proponowane wartości
  • Segmenty klientów
  • Relacje z klientem
  • Kanały kontaktu z klientem
  • Kluczowe aktywności
  • Kluczowe zasoby
  • Kluczowi partnerzy
  • Źródła przychodów
  • Struktura kosztów

Cztery pierwsze punkty są bezpośrednio związane z generowaniem zysku (prawa strona kanwy). Kolejne trzy to koszty które musimy ponieść aby wytworzyć wartość (lewa strona). Analizując koszty i przychody (dół kanwy) szukamy układu w którym prawa strona będzie większa od lewej – czyli nasza firma będzie zarabiała więcej niż ponosi kosztów.

Ten zapis to doskonały sposób na przemyślenie produktu oraz jego spisanie w przejrzystej formie. Kolejność kolumn nie jest przypadkowa. Pozwala w spójny sposób zbudować narrację wokół pomysłu, a zwięzła forma zachęca do zbierania opinii i modyfikowania założeń. To jakby testowanie wirtualnego produktu poprzez opowieść. Darmowy szablon znajdziesz tu.

Customer Journey

Nietypowy sposób prowadzenia testów lecz technika wizualizacji pozwalającą „wejść w buty” naszego klienta. Opisuje interakcje klienta z naszym produktem z wykorzystaniem różnych kanałów. Może to być strona internetowa, Call Center czy IVR ale także kolejka w sklepie czy ulotka wyjęta ze skrzynki. Obecnie coraz większy nacisk kładziony jest na spójną, wielokanałową obsługę klienta (omnichannel). Kluczowe jest zrozumienie emocji i doznań klienta w każdym z dostępnych kanałów ale także kombinacji wynikającej z równoległego kontaktu z różnymi z nich. To narzędzie daje możliwość zaprojektowania krótkiego, prostego i atrakcyjnego dla klienta procesu obsługi. Rozszerzeniem mogącym poprawić zrozumienie jest zastosowanie person opisujących „modelowych klientów”.

Podsumowanie

To oczywiście tylko kilka najpopularniejszych podejść do walidacji pomysłów czy teorii. Zwięźle opisane mają dać obraz różnorodności i zachęcić do dalszego zgłębiania wiedzy w tym zakresie. Chciałbym aby zrozumienie tych opisanych i sprawdzonych metod zachęciło czytelników do tworzenia własnych testów, a wiedza na temat analizy pozwoliła na świadome budowanie projektu dostarczającego wartościowe dane. Pamiętajmy że w XXI wieku koszty prowadzenia projektu w IT są na tyle wysokie, że nie ma tu miejsca na ślepy traf, zgadywanie czy przerzucanie się pomysłami za którymi nie stoją twarde dane i logicznie wyciągnięte z nich wnioski.

➔ Rozglądasz się za nowa pracą? Zebraliśmy w formie ebooka najpopularniejsze pytania i odpowiedzi z rozmów rekrutacyjnych na produktowca.

Dołącz do naszych czytelników

Dołącz do 1 700+ subskrybentów otrzymujących nasz cotygodniowy newsletter z inspiracjami do tworzenia coraz lepszych produktów i rozwoju swojej kariery.
Piotr Wójcik
Od kilku lat zajmuję się rozwojem produktów od strony biznesowej oraz współpracą z zespołami developerskimi, marketingiem i sprzedażą. Dodatkowo prowadzę zajęcia w ramach akademii programowania oraz projekty ze studentami Politechniki Łódzkiej jako zewnętrzny specjalista merytoryczny. Moje wcześniejsze doświadczenia to rozwój i utrzymanie oprogramowania w roli developera, głównie w sektorze bankowo-finansowym.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.