S01E08 Od wersji do wersji, czyli jak rozwijać dojrzały produkt cyfrowy

Jak i gdzie szukać kandydatów na ekspertów domenowych? Jak pomóc im się rozwijać?

To jest dość ciekawy temat sam w sobie i godny specjalnego potraktowania. Nie chcę tutaj specjalnie trywializować problemu, ale z mojego doświadczenia wynika, że prawdziwi eksperci domenowi są praktycznie nie do zdobycia z zewnątrz, więc raczej trzeba założyć, że próby rekrutacji niewiele dadzą. Można oczywiście mieć mnóstwo szczęścia, więc nadal warto próbować. 

Ale faktycznych ekspertów domeny trzeba sobie w naszej firmie ukształtować. Ten mechanizm jest trochę podobny do formowania kryształów. W złych warunkach kryształy nie powstaną. Ale można takie dobre warunki wytworzyć. I potrzeb trzeba poczekać, aż kryształy wyrosną. Najpierw małe, potem większe. 

Czym są takie warunki w firmie?

To tzw. “atmosfera”: otwartość komunikacji, przydział tasków na zasadzie “co naprawdę chcesz robić” zamiast “eliminujemy bus factor i przerzucimy cię co pół roku w inne miejsce, bo tak”, przyzwolenie na popełnianie błędów i podejście “czego się nauczyliśmy” (tu przepięknie działa metoda 5xWHY) zamiast “kto zawinił”, nie zmuszanie ludzi do kontrybucji jeżeli nie chcą i przede wszystkim unikania zabaw typu “zebraliśmy się tutaj wszyscy i teraz zagłosujmy nad najlepszym rozwiązaniem”. 

Chętnie poopowiadam na ten temat w osobnej sesji, jeżeli organizatorzy pozwolą. 🙂

Jak uniknąć "confirmation bias" korzystając z opinii eksperta domenowego?

Jeżeli zapewnimy w firmie warunki komunikacji sprzyjając przejrzystości, dając prawo do wzięcia odpowiedzialności ale nie szukając “winnych” to zaobserwujemy ciekawe zjawisko.

Członkowie zespołu będą chcieli aktywnie uczestniczyć w projekcie nawet jeżeli ich wkład będzie ograniczał się tylko do konstruktywnej krytyki.

Pytania typu “czy możesz mi to wytłumaczyć?” oraz “a co jeżeli X zmienimy na Y?”, itp. są de facto uosobieniem całkiem naukowego podejścia do walidacji problemów: zadania sobie przywileju wątpliwości i próby konstruktywnego “podważenia” hipotezy na jej dość wczesnym etapie. 

Tu pojawia się ryzyko demokratyzacji dyskusji, co jest czystym złem (niestety, wbrew intuicji), więc ZAWSZE w takich wypadkach trzeba dobrać rzeczowego moderatora, który jest łagodnie (nie-fundamentalnie) ustosunkowany do hipotezy i kieruje nim/nią ciekawość. Tylko to i aż tyle wystarczy żeby confirmation bias mocno ograniczyć. 

No chyba, że ktoś wysoki szczeblem mianował się ekspertem domeny, tylko dlatego, że jest wysoki szczeblem i zaistniał efekt Dunning’a-Kruger’a [Wikipedia - przyp. red.]. Wtedy BARDZO trudno jest skonfrontować hipotezę z rzeczywistością (been there, seen that, decided to quit the company - seriously).

Czy przy szacowaniu backlogu / hipotez wskazujesz w jakiś sposób potencjalny przychód, który dany element backlogu może przynieść? Jeżeli tak, to w jaki sposób?

W moich projektach w momencie szacowania backlogu algorytmicznie (na etapie odsiewania plewów) modeluję zysk z projektu zakładając dla uproszczenia, że ten jest miarą ilości klientów, którzy z danej hipotezy skorzystają.

To spore uproszczenie, ale ma zalety, gdyż łatwiej jest ilościowo określić zakres impaktu w ten sposób (to raz) oraz eliminujemy / wypłaszczamy różnice pomiędzy wielkością kontraktów (to dwa). Mowa tu oczywiście o projektach i klientach dojrzałego produktu dla masowego odbiorcy B2B / B2C. 

Jeżeli jesteśmy typowym usługodawcą, to pewnie lepiej przyjąć miarę bliższą faktycznemu zyskowi w $$$. 

Tak przy okazji: tu się kłaniają firmowe OKRy. Większość firm stawia sobie cele w stylu “miejmy więcej userów” albo “miejmy więcej klientów”, a nie “zaróbmy milion dolarów w Q1”. Dobrze jest te pomiary z OKRów jakoś względnie bez zmian zamapować na “impact” naszych elementów w backlogu. 

W jaki sposób polecasz archiwizować/przechowywać wiedzę z przeprowadzonych testów (zakończonych sukcesem i porażką oczywiście też)?

Nie mam tu wiele do zaproponowania. U mnie backlog jest skonstruowany wokół JIRY (przy czym mam nieco zmienione ustawienia domyślne, ale to szczegół), a rozwinięcia elementów backlogu (dyskusje, pomiary, wnioski) są przeważnie trzymane jako strony na Confluence. Nigdy nie kasuję zadań w JIRZe (zamykam, ale nie kasuję) i nigdy nie kasuję stron w Confluence. Staram się narzucić sobie pewną dyscyplinę w strukturze tych danych, ale cała reszta to kwestia umiejętności skorzystania z wyszukiwarki.

Jakieś miejsca, książki lub ludzie, których polecisz naszym słuchaczom do poszerzenia swojej wiedzy na temat dostarczania produktów cyfrowych na rynek, releasów i ich rozwijania?

Ha! Dobre pytanie. Jest tu pewien paradoks, bo ja zasadniczo nie darzę wielkim zaufaniem komercyjnych produkcji w temacie product managementu (blogów, książek, szkoleń, itp.). Przyczyna jest prosta: te rzeczy są robione dla kasy. A sprzedaje się to co jest fajne, wesołe, nieco nieoczywiste, ale niekoniecznie prawdziwe. 

Miałem okazję odbyć wiele dyskusji / sprzeczek z ludźmi wychowanymi na blogach i książkach, którzy potrafili wpaść w poniedziałek do biura i od progu przyjmować postawę ewangelisty i proroka, przy czym przeważnie dość szybko udawało się dojść do tego co dany prorok przeczytał w weekend. Te dyskusje były równie zabawne co bezproduktywne. 

Moja rada: dzielmy się swoimi obserwacjami na takich spotkaniach jak to minione: nie robionych dla kasy tylko z potrzeby oddania czegoś czego się samemu nauczyło od swoich byłych mentorów, kolegów, koleżanek, często nieświadomie. I krytykujmy się nawzajem. I uczmy się od siebie. I pozwalajmy sobie na własne błędy. I zdobywajmy to doświadczenie po swojemu i dla siebie.

Nie ma reguł product managementu “one size fits all”. Ale są ludzie z bliznami (jak ja i ty) i ludzie ciekawi (jak ty i ja), którzy zawsze będą gotowi do rozmowy. Pozwólmy sobie na to, żeby w naszym własnym tempie stać się ekspertami w domenie product managementu. Kiedyś.

A zatem: do następnej dyskusji!

Pytania, które znalazły swoją odpowiedź podczas spotkania live (możesz je przesłuchać w nagraniu tego odcinka):

• Jak odsiać opinie ludzi, którzy płacą za produkt od tych, którzy go używają (w ramach tej samej organizacji)? Np. dla systemu księgowego opinia CEO vs. opinia księgowej?
• Jakie podejście sugerujesz do weryfikacji hipotez w produktach self-hosted ​gdzie feedback od użytkowników przyjdzie najwcześniej za 6 miesięcy?
• Jak przekazać plany na rozwój produkty wewnątrz firmy, aby skutecznie i efektywnie uzasadnić wybrane priorytety i rozwiać wątpliwości?