Konferencje
Mobile Trends

Dlaczego faza discovery jest istotna w procesie budowania produktu?

Product discovery jest pierwszą sformalizowaną fazą w tworzeniu produktu. Ten poprzedzają oczywiście idee i koncepcje, ale discovery jest jedną z pierwszych i najważniejszych rzeczy dla całego procesu! Dlaczego odkrywanie produktu jest takie ważne, czyli co warto zrobić przed rozpoczęciem developmentu aplikacji mobilnej?

Product Manager. Kim jest persona zarządcy produktu? Wiemy już kim jest Product Designer, który po części może pełnić także funkcję Product Managera. Tak naprawdę wszystko zależy od doświadczeń danej osoby oraz firmy, która jest twórcą stanowiska, ale przyjmuje się, że Menedżer produktu jest naturalną ścieżką rozwoju dla Project Managera. Product Manager bowiem, to jak podaje digitalx.pl, osoba, która tworzy wizję produkt poprzez określenie jego cech, specyfikacji, funkcjonalności i wyglądu. Jest to osoba, która będzie odpowiadać za strategię rozwoju i monitorowanie rynku oraz promocję i wdrożenia. To także osoba, która odpowiada za cały cykl życia produktu, ale też kształt rynku poprzez formowanie na nim trendów i produktów, które im odpowiadają. Różni się w tym od Product Ownera, którego zakres obowiązków ogranicza się do współpracy z zespołem w Scrum. Nie jest jednak niczym gorszym, gdyż ten musi odznaczać się sporym zakresem twardych kompetencji analitycznych, aby urzeczywistnić wizję Product Managera w projekcie. 

– U nas w Miquido nie mamy swoich produktów, więc ta rola Product Managera w software house jest dosyć specyficzna, bo w teorii Product Manager ma produkt, za którego rozwój odpowiada i się nim zajmuje. U nas jest tak, że to są produkty klientów, więc my mamy bardziej taką rolę konsultacyjną, doradczą, wspieramy tych klientów. – tłumaczy Anna Grabowska, Product Manager w Miquido – W dużej mierze to jest ta cała faza discovery, czyli kształtowanie pomysłu na produkt, robienie badań i różnych analiz, jak również planowanie tego co tak naprawdę ten produkt będzie robić i co będzie w jego pierwszym wydaniu, bo to sprawia dużą trudność klientom. Priorytetyzacja. Później wspieramy produkt w całym cyklu życia, jeśli klient zdecydował się u nas rozwijać ten swój projekt, to taki PM jest cały czas w tle, pomaga mu podejmować decyzje i rozwijać ten produkt. Zajmujemy się też analityką, dobieramy metryki, KPI, czyli co chcemy badać i po co, bo tak naprawdę często się też o tym zapomina, a bez tego po wypuszczeniu produktu na rynek jesteśmy w kropce, bo nie wiemy jak użytkownicy z tego korzystają. – dodaje.

Co klient powinien zrobić zanim przyjdzie do software house z prośbą o wykonanie aplikacji?

Odpowiedź na to pytanie brzmi jak zwykle: to zależy. Są różne rodzaje klientów, a więc charakteryzować się będą różnym stopniem przygotowania do pracy oraz znajomości swojego produktu. Anna Grabowska przytacza przykład klienta, który ma bardzo ogólny pomysł, czyli np. zidentyfikował on jakiś problem i zauważa, że w jego bliskim otoczeniu się on pojawia i ma pomysł jak go rozwiązać. Rola software house polega na stworzeniu koncepcji produktu, który taki problem pomaga rozwiązać, ale często należy zweryfikować czy problem, który zidentyfikował klient w ogóle jest realnym problemem wymagającym rozwiązania. – Często się komuś coś wydaje, bo znajomi i rodzina mają ten problem, a często się okazuje, że to jest jakaś wąska grupa osób, a poza nimi tak naprawdę ten problem nie występujetłumaczy Grabowskaczasem są nawet rozwiązania offline, które są wystarczające i nie ma potrzeby tworzenia produktów cyfrowych, ale są też klienci, którzy przychodzą do nas już po całej tej fazie discovery, którą zrobili sami albo z jakimiś innymi firmami i mają wręcz zdefiniowany już backlog, ale wtedy też potrzebują wsparcia. Chociażby po to, żeby pomóc spriorytetyzowac zadania, żeby uzyskać pomost między zespołem deweloperów, a klientem, żeby pomóc zrozumieć sam produkt i jego działanie oraz potrzeby jakie ma spełniać – dodaje.

Jak poznać potrzeby potencjalnych użytkowników produktu?

Generalnie, aby poznać użytkowników i ich potrzeby potrzebne są, a jakże, badania! Ważnym jest przede wszystkim umiejętność weryfikacji źródeł, z których korzystamy, aby wnioski, które nam dostarczają, były jak najbardziej rzetelne, ale z drugiej strony, równie istotnym jest, żeby nie zamykać się w konkretnych poszukiwaniach i problemach badawczych, ale spojrzeć na daną kwestię szerzej. – Są dwie części. Jedną z nich są badania w najróżniejszej postaci: od wywiadów z użytkownikami, skończywszy na ankietach. Ale z drugiej strony mamy tak zwany desk research, czyli możemy analizować użytkowników na forach internetowych, na jakichś grupach na Facebooku, czy na forach internetowych, możemy też bezpośrednio z nimi rozmawiać, ale to może być także analiza trendów czy konkurencji. mówi ekspertka – Przy analizie konkurencji warto sobie tę konkurencję segmentować na grupy, bo oczywiście jest ta bezpośrednia konkurencja, albo jej nie ma jeśli mamy łut szczęścia, co również może być złudne. Bezpośrednia konkurencja ma tę samą grupę użytkowników, ten sam problem i takie samo albo podobne rozwiązanie, ale tak naprawdę jak sobie to podzielimy na: użytkowników, problem i rozwiązanie, to warto przyjrzeć się innym produktom. Ten sam problem może rozwiązywać aplikacja, ale dla innej grupy użytkowników albo dla dokładnie tej samej grupy użytkowników, w podobnej technologii, ale zupełnie iny problem rozwiązuje. W pierwszej chwili takie systemy się odrzuca, bo to nie jest bezpośrednia konkurencja, ale warto się im przyglądać, bo po pierwsze mogą mieć ciekawe pomysły, które mogą nas zainspirować, ale po drugie dlatego, że takie rozwiązania mogą bardzo szybko stać się naszą konkurencją, gdy zaczną rozwijać swój produkt, potencjalnie niedużym nawet nakładem pracy, dostosowując go i przejmując naszą grupę docelową  – mówi PM z Miquido.

Co software house powinien zrobić przed developmentem?

W przypadku software house, klienci zazwyczaj przychodzą z gotowym dokumentem zgłaszającym chęć nabycia produktu, czyli tzw. briefem, ale product manager powinien gruntowanie przepytać klienta o wszystkie dokumenty, specyfikacje i pomysły, żeby zbadać na jakim etapie się znajduję i żeby mógł pomóc mu podjąć odpowiednie decyzje oraz dobrać model współpracy. – To bardzo zależy od tego z czym klient już do nas przychodzi. Staramy się zawsze robić chociażby minimalne wersje fazy discovery, czyli właśnie desk research i dwu lub trzydniowe warsztaty, żeby takie rzeczy doprecyzować. Często na takich warsztatach okazuje się, że są tam gdzieś jeszcze jakieś wątpliwości czy braki i przeprowadzamy dalej badania.mówi Anna – Zdarza się też tak, że klient przychodzi z na tyle ogólnym pomysłem, że on tak naprawdę jeszcze nie ma zweryfikowanego, czy istnieje jakiekolwiek zainteresowanie na niego i wtedy robimy taką bardzo poszerzoną wersję fazy discovery, co nazywamy product bootcampem. To już jest taki miniprojekt. Trwa to miesiąc, może nawet półtora. Robimy wówczas dogłębne analizy, warsztaty z klientem, strategiczne, takie kilkudniowe też, przygotowujemy prototyp produktu, robimy zwykle szybkie testy użyteczności, no i wtedy mamy bardzo jasne odpowiedzi, co dalej możemy zrobić. Czasem to jest tak, że pewne funkcje trzeba dopracować, dodać albo usunąć, bo okazuje się, że niektóre nie wzbudzają zaufania, a czasem jest też tak, że użytkownicy nie widzą sensu użytkownia danego produktu. No i tutaj powstaje pytanie czy szukamy dalej nowych funkcjonalności czy w ogóle rezygnujemy z tego produktu. Może się wydawać katastrofą, z punktu widzenia software house, jeśli tak wyjdzie, ale tak naprawdę oszczędzamy klientowi czas i pieniądze, bo to nie jest problem spędzić pół roku nad produktem, z którego nikt nie będzie korzystać, no ale nie na tym nam powinno zależeć. Motywacja zespołu do tworzenia takiego produktu jest też bardzo mała, jeżeli robimy produkt dla jednej osoby. Często zdarza się, że proponujemy zmianę produktu o 180 stopni, co dla klienta jest ogromną oszczędnością, aby wiedzieć coś takiego na etapie discovery niż po miesiącach pracy zespołu deweloperskiego – dodaje.

Z czego składa się product discovery?

Faza discovery jest trzonem każdej strategii projektowej produktu. Jest to bardzo złożony proces, którego składowe będą różnić się, w zależności od rodzaju produktu, ale sam proces stawia przed sobą konkretne wyzwania i cele.Specjaliści z Kiss Digital mówią, że w discovery procedury powinny umożliwiać:

  • ustalenie i usystematyzowanie wymagań klienta,
  • przeanalizowanie potrzeb grupy docelowej,
  • oszacowanie potencjału rynkowego projektowanego produktu,
  • określenie czasu i kosztu realizacji projektu oraz terminu zwrotu z inwestycji.

Słuchając Anny Grabowskiej możemy odnieść wrażenie, że discovery opera się na Design Thinking, co zauważają także twórcy wpisu z agencji Project:People. Ideą myślenia projektowego jest przecież generowanie pomysłów, funkcjonalności i rozwiązań zgodnych z oczekiwaniami użytkownika, a w fazie discovery chodzi o odkrycie pomysłu, jego potencjalnych funkcjonalności, zalet, korzyści rynkowych, ale także słabości. Mamy tutaj do czynienia z empatyzacją, której celem jest wejście w buty użytkownika końcowego. Odbywa się to na hipotezach i dostępnej wiedzy, którą sprawdza się w trakcie poprzez badania i obserwacje, później prowadzące do decyzji. Istnieje wiele metod odkrywania, ale zazwyczaj dzieli się je na pętle,, w których dobiera się metodologię do potrzeb, a każda z pętli musi zakończyć się podjęciem jakiejś decyzji. – Często przychodzą do mnie klienci, którzy wydawałoby się, że są świadomi, wiedzą, o co chodzi i, że chcą być challengowani, to potem w praniu wychodzi, że jednak to jest takie bardziej deklaratywne. Chcą, chcą, ale jak się ich challenguje, to już jest trochę gorzej. Są np. startupy, w których wizjoner jest zakochany w swoim pomyśle. Jest święcie przekonany o nieomylności, co do swojego produktu, w czym utwierdzają go ludzie z jego otoczenia, a my mu tu nagle wychodzimy ze swoimi wnioskami albo nawet z badań “co gorsza” wynika, że użytkownicy już tym produktem tacy zachwyceni wcale nie są. Dochodzi wtedy do ogromnej negacji. No bo jak to? To jest to moje dziecko! To ja nad tym myślę tyle czasu! To jest niemożliwe! No, ale te badania bywają bardzo pomocne w pokazaniu rzeczywistych reakcji na produkt i prawdziwych doświadczeń użytkowników, które można łatwiej przyjąć,bo odzwierciedlają realną wartość biznesową. No, ale drugą grupą są jeszcze wielkie korporacje, które również są problematyczne. Często wszystko jest w porządku, chcą robić badania, ale potem nagle się okazuje, że prezes już widział dotychczasowe projekty, które są już zatwierdzone. No i trzeba by było go kłopotać jeszcze, a im się spieszy, no to może w przyszłości zaimplementuje się dane rozwiązania, a teraz musimy zrobić taką wersję, jaka była przed badaniami. No takie sytuację też się często zdarzają, niestety. – wzdycha z uśmiechem PM z Miquido.

Czy w Polsce często korzysta się z discovery?

Polscy klienci są zwykle mniej świadomi i często “walczą” z product managerami odnośnie koncepcji swojego produktu lub nie są nawet świadomi konieczności fazy discovery, ale każdy trochę bardziej doświadczony w projektach klient zauważa wagę badań i ćwiczeń, które wykonuje się w trakcie warsztatów. Anna Grabowska dostrzega także, że jest coraz więcej początkujących klientów, którzy mówią wprost, że potrzebują badań., co jest efektem wzrastającej świadomości na temat badań i ich ogromnego znaczenia dla użyteczności z biznesie. Discovery i sam development są na tyle złożonymi pojęciami, że niemożliwe jest ich pełne ujęcie w trakcie jednej rozmowy, artykuły czy nawet konferencji, wobec czego gorąco zachęcamy do zgłębiania tej wiedzy. Zacznij od Mobile Trends Podcast i naszej rozmowy z Anną Grabowską, fach-mistrzynią z Miquido, z dziesięcioletnim doświadczeniem z zespołami, projektami i produktami! 

Udostępnij
Mobile Trends
Zobacz także