Jak w Brainhubie rozumiemy Continuous Product Discovery?
Marzena Cygan-Bakoniak, Business Analyst w Brainhubie: Continuous Product Discovery rozumiemy jako podejście pozwalające na dostarczanie właściwych produktów i funkcjonalności w realiach VUCA. Podążanie za zmieniającym się otoczeniem biznesowym naszych klientów oraz rzeczywistymi potrzebami i oczekiwaniami użytkowników przekłada się na sukces produktu. Nie bez znaczenia są także kwestie technologiczne. Dzięki temu podejściu mamy dowody na zasadność budowania konkretnych rozwiązań, co z kolei przekłada się na to, że nie ‘przepalamy’ niepotrzebnie czasu na budowanie niepotrzebnych funkcjonalności. Realizujemy nasze decyzje z pewnością, bo są podjęte na faktach, nie domniemaniach.
Dlaczego zdecydowaliśmy się wdrożyć CPD do codziennej pracy?
M. C.-B.: Znaczna część produktów lub funkcjonalności się nie przyjmuje - dzięki CPD jesteśmy w stanie skupić się na realnych potrzebach użytkownika i na nie odpowiadać, co przekłada się na finalny sukces produktu. Znaczny odsetek organizacji skupia się dziś na dostarczaniu produktów i funkcjonalności, a my skupiamy się na dostarczaniu właściwych funkcjonalności, między innymi poprzez inwestowanie czasu w CPD.
Klasyczne podejście do product discovery często widziane jest mocno waterfallowo. W podejściu continuous walidujemy hipotezy biznesowe na bieżąco, co pozwala na dostosowywanie produktu jeszcze w trakcie pracy nad nim. Wiemy z doświadczenia, że niejednokrotnie w długich projektach wymagania ulegają zmianie lub wręcz dezaktualizują się. Podejście CPD zostawia przestrzeń na weryfikację założeń czy priorytetyzację roadmapy oraz najlepsze użycie zasobów wewnętrznych - aktualne wymagania zapobiegają dostarczaniu zdezaktualizowanych czy niedostosowanych odpowiednio funkcjonalności.
Jak wygląda proces wdrażania takiego podejścia?
M. C.-B.: Proces wymaga bieżącej pracy zespołów (upstreamowej lub teamu R&D, a także zaangażowania ról UX, BA oraz Technical Advisorów), klienta oraz użytkowników. Proces dostarczania zazębia się z pracą zespołów developerskich. To wspólne planowanie zadań, “wyrównywanie” pracy streamów nad rozwojem produktu, przygotowywanie PoCow, wymagań oraz designów. Nie pracujemy waterfallowo, tylko zwinnie. Development nie czeka na wyniki CPD - to raczej ekosystem.
Jak nasze zespoły projektowe odbierają wdrożenie tego procesu?
M. C.-B.: Podejście Continuous Product Discovery wymusza na nas niejako ścisłą współpracę, głębsze rozumienie problemu i produktu, który na ten problem odpowiada. Takie podejście wymaga otwarcia i zderzania wizji strategicznej z potrzebami użytkowników, oraz niejednokrotnie sposobami implementacji. Powoduje, że często członkowie zespołu developerskiego zaangażowani są w prace koncepcyjne. Nie izolujemy się, dużo współpracujemy i warsztatujemy się.
CPD pozwala także na skupienie się na funkcjonalnościach, co do budowania których mamy uzasadnienie, a sukces produktu jest w Brainhubie naszym celem. Dzięki temu nie musimy walczyć z presją czasu czy rezygnować z zapewniania jakości naszych rozwiązań, co dla nas jako partnera technologicznego w obszarze dewelopmentu jest szczególnie istotne. Dla klienta jest to fenomenalne podejście w uniknięciu zbędnych kosztów.
Jakie mamy rezultaty z wprowadzenia Continuous Product Discovery?
M. C.-B.: CPD z sukcesem wdrożyliśmy w jednym z naszych obecnych projektów dla innowacyjnego startupu. Pracujemy jednocześnie w kilku zespołach - developerskich oraz R&D -dzielmy się perspektywą użytkownika i produktową, członkowie zespołu developerskiego aktywnie i często uczestniczą w pracach R&D. Odkąd pracujemy w ten sposób, zaangażowanie użytkowników końcowych oraz pozostałych interesariuszy projektu wzrosło. Dążymy do walidowania naszych hipotez przed rozpoczęciem prac na konkretnymi funkcjonalnościami, co upewnia nas w słuszności podejmowanych decyzji.
Gdybyś miała wybrać jeden główny powód wprowadzenia CPD, to co by to było?
M. C.-B.: Odpowiadanie na realne potrzeby userów, szybka walidacja hipotez biznesowych, szybszy go-to-market. To trzy :)
Czy są jakieś koszty wynikające z wprowadzenia tego podejścia?
M. C.-B.: Z finansowego punktu widzenia, powiedziałabym, że koszt jest niższy niż developowanie niezwalidowanych funkcjonalności. Natomiast zdarza się dynamiczna zmiana priorytetów, więc ta zmienność wymaga dobrej adaptacji. Także umiejętność współpracy oraz nietrzymania się swoich opinii (to użytkownik ma rację, nie my) wspiera naszą pracę. Nie jest to na pewno podejście dla kogoś, kto lubi lubi spokojnie developowac, znając waterfallowy plan na najbliższe lata, ale czy ktoś widział produkt, który osiągnął sukces po kilku latach developmentu z zamrożonym scopem? :)
Gdy wprowadza się nowy proces do organizacji, błędy są nieuchronne. Jakie popełniliśmy do tej pory?
M. C.-B.: Cały czas się uczymy, uczymy się rozmawiać, pytać, pytać i jeszcze raz pytać. Nie zakładać - choć to częsta pokusa - i sprawdzać pojawiające się możliwości, nie przywiązywać się do naszych ulubionych ścieżek. Otwartość, ciekawość i komunikacja to chyba podstawowe aspekty w tej pracy. Istotne jest też patrzenie na wyniki badań. Możemy mieć świetny pomysł, a walidacja może brutalnie nam pokazać, że choć wiemy co i jak to zrobić, to nie będzie to przydatne. Częste, regularne włączanie użytkowników w nasz CPD jest najistotniejszym aspektem (co także podkreśla Teresa Torres). Jeśli mowa o naszych wewnętrznych projektach - tutaj na bieżąco przeprowadzamy wywiady i badamy słuszność naszych hipotez. Stale też udoskonalamy proces formułowania hipotez, walidacji i dostarczania.
Czy kojarzysz rynkowe przykłady wdrożenia Continuous Product Discovery?
M. C.-B.: Google, Facebook, albo Netflix, który ewoluuje, słuchając swoich użytkowników, dzięki czemu jest nadal na topie. Można znaleźć sporo materiałów czy talków na ten temat. Ich popularność jest najlepszym dowodem na słuszność tej decyzji.
.png)
