Czy brak jasności po cichu zabija Twój produkt?

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Wybaczcie wszelkie literówki, ponieważ bot nie zawsze działa w 100% poprawnie.

Hannah Clark: To praktycznie banał, ale zdarza się cały czas — mówisz coś trzem osobom, a każda z nich rozumie coś innego. I nie jest to takie złe, jeśli chodzi o coś w rodzaju: „Idę po kawę, ktoś chce coś dla siebie?”. Ale kiedy budujesz MVP przy stale skracającym się czasie działania firmy albo próbujesz dostarczyć coś w bardzo napiętym terminie, ten brak jasności może oznaczać śmierć startupu.

Naszym dzisiejszym gościem jest Bijan Shahrokhi — założyciel Product Management Exercises i Product Monkey AI. Bijan większą część swojej kariery poświęcił pomaganiu menedżerom produktu w zwiększaniu produktywności i lepszym zarządzaniu zespołami. Umiejętność zapewnienia zespołowi produktowemu jasności i zgodności jest podstawą tych kompetencji. Za kilka minut Bijan przedstawi łatwy do powielenia proces, który wymaga nieco czasu na początku, ale może uratować startup stojący na krawędzi przepaści. Zaczynajmy.

Witajcie ponownie, drodzy słuchacze. Dołącza dziś do mnie Bijan Shahrokhi. Jest założycielem ProductManagementExercises.com, a niedawno uruchomił narzędzie zwiększające produktywność, przeznaczone wyłącznie dla menedżerów produktu, o nazwie ProductMonkey.ai.

Bijan, bardzo dziękuję, że do nas dołączyłeś.

Bijan Shahrokhi: Bardzo dziękuję za zaproszenie.

Hannah Clark: Świetnie. Zawsze zaczynamy w ten sam sposób. Chciałabym, żebyś opowiedział nam trochę o swoim doświadczeniu i o tym, jak znalazłeś się w obecnym miejscu.

Bijan Shahrokhi: Jasne. Z zamiłowania jestem menedżerem produktu. Od ponad 10 lat pracuję jako menedżer produktu, całkowicie przypadkowo.

Nie wiedziałem nawet, czym jest zarządzanie produktem, dopóki nie miałem startupu, któremu nie wiodło się zbyt dobrze. Zapytałem znajomego, co jego zdaniem powinienem robić dalej, a on powiedział: „Powinieneś zostać menedżerem produktu”. Pomyślałem: chwila. To brzmi bardzo interesująco — produkt i zarządzanie produktem. Właśnie tym chcę się zajmować.

Od tego momentu zostałem menedżerem produktu. Przez ostatnie 10 lat zajmowałem się różnymi rzeczami. Przez pierwsze kilka lat pracowałem w większych organizacjach, na przykład w banku jako menedżer produktu, a później strateg produktu. Następnie dołączyłem do dwóch startupów. W obu przypadkach produkt został uruchomiony po moim dołączeniu do firmy, a jeden z nich został po półtora roku przejęty przez większego gracza w tym ekosystemie.

Drugi był faktycznie udanym projektem. W szczytowym momencie był wart wiele miliardów dolarów. Nadal działa i wciąż intensywnie się rozwija. Od tamtej pory przez kilka ostatnich lat skupiałem się głównie na Product Management Exercises. Niedawno uruchomiliśmy kolejny produkt dla społeczności zarządzania produktem o nazwie ProductMonkey.ai.

Hannah Clark: Niesamowite. Dziś będziemy rozmawiać o jasności w organizacjach, na której bardzo Ci zależy. Przez jasność rozumiem po prostu upewnienie się, że wszyscy interesariusze są zgodni i mają ten sam obraz tego, co się dzieje i co należy zbudować.

Jak wygląda dla Ciebie sytuacja, w której organizacji brakuje jasności?

Bijan Shahrokhi: Świetne pytanie. Myślę, że największym i najbardziej oczywistym sygnałem braku jasności w organizacji jest sytuacja, w której pytasz różne osoby w całej organizacji, jakie według nich są kryteria sukcesu dotyczące tego, co ma zostać dostarczone jako kolejny ważny kamień milowy, a następnie zaczynasz słyszeć różne historie.

Podam przykład. Załóżmy, że pracujesz nad bardzo technicznym produktem, którego działanie będzie oceniane na podstawie wielu wskaźników wydajności, takich jak opóźnienie, szybkość, liczba transakcji na sekundę czy liczba zadań, które można wykonać. Jeśli nie zostanie to jasno zdefiniowane przez osobę techniczną w organizacji, może ona próbować zbudować coś, co będzie w stanie obsłużyć niezwykle dużą liczbę transakcji.

Jeśli jednak zapytasz kogoś bardziej zorientowanego biznesowo i mającego kontakt z klientami, usłyszysz: musimy po prostu wypuścić coś na rynek, żeby zacząć zbierać opinie klientów. Wiesz, że brakuje jasności, gdy zaczynasz rozmawiać z ludźmi w całej organizacji i słyszysz różne liczby albo gdy mówią: „Och, nigdy o tym nie myśleliśmy” lub „Nigdy tego nie omawialiśmy”. To zwykle bardzo wyraźny sygnał dla menedżera produktu, że coś jest nie tak i brakuje tu jasności.

Hannah Clark: Brzmi, jakbyś miał kilka osobistych doświadczeń z taką sytuacją. Oczywiście bez podawania nazw — możesz przytoczyć jakąś anegdotę?

Bijan Shahrokhi: Jasne. Ostatni projekt, o którym mówiłem, ten, który osiągnął wycenę wielu miliardów dolarów, dotyczył firmy, której pozostało zaledwie kilka miesięcy do wyczerpania gotówki, a która nie uruchomiła jeszcze produktu.

Wydawało się, że firma jest tylko kilka miesięcy od uruchomienia produktu. Kiedy dołączyłem, początkowo powiedziano mi, że zostały trzy miesiące. Po dołączeniu zorientowałem się, że to, co niektórzy założyciele mieli w głowie, było prawdopodobnie oddalone od rzeczywistości o 5–10 lat.

Z kolei część inżynierów uważała, że dostarczy produkt również w ciągu kilku miesięcy. Między tymi wizjami istniała ogromna przepaść. W rezultacie firma przez ponad trzy lata tkwiła w cyklu tworzenia produktu, ponieważ zespół inżynieryjny wciąż przedstawiał coś jako gotowe, a część założycieli lub osób biznesowych patrzyła na to i mówiła: „Chwileczkę, nie jesteście gotowi”.

Produkt nie spełniał tego, co mieliśmy w głowie. Ponownie definiowali więc, co trzeba zbudować. Zespół wracał do pracy rozczarowany i z poczuciem, że nie wnosi do organizacji wystarczającej wartości. Wtedy, jako szef produktu, spędziłem pierwsze trzy miesiące na spotkaniach z wieloma interesariuszami, żeby naprawdę zrozumieć, które elementy wywołują bardzo różne opinie w organizacji.

Zauważyłem na przykład, że pewien element część osób uważała za niezbędny w pierwszej wersji produktu, a druga połowa nie. Zaczęliśmy więc prowadzić wiele rozmów na temat tych konkretnych elementów i uzyskaliśmy jasność co do tego, czy zostaną zbudowane. Była to decyzja zero-jedynkowa albo decyzja, że stworzymy ich bardzo ograniczoną wersję.

Ustaliliśmy dokładnie, co w jej ramach zrobimy. Dopiero potem zajęło nam około roku zbudowanie uproszczonej wersji tego, co początkowo miało zostać uruchomione w ciągu trzech miesięcy. Szczerze mówiąc, samo uzyskanie jasności co do tego, co zostanie zbudowane w ciągu roku, zajęło nam kilka miesięcy.

Mam nadzieję, że jest to przykład sytuacji, w której dzięki większej jasności można rzeczywiście wypuścić coś na rynek. Kiedy już to zrobisz, możesz wykorzystać opinie użytkowników, społeczności i całego ekosystemu, aby ustalić, które z elementów znajdujących się w planach należy potraktować priorytetowo w następnym kroku.

Hannah Clark: To ogromne osiągnięcie — zamknięcie takiej luki wydaje się niemal niemożliwe. To naprawdę potężne podejście. Jeśli spojrzymy szerzej, jakie są Twoim zdaniem najważniejsze konsekwencje sytuacji, w której organizacja nie wbudowała procesów zapewniających jasność w swoją kulturę, nie tylko w pracę zespołu produktowego?

Bijan Shahrokhi: Największy wpływ jest taki, że organizacje zwykle ostatecznie niczego nie dostarczają, a to bardzo poważny problem. Wiele świetnych projektów nigdy nie trafia do użytkowników, ponieważ firmom kończy się gotówka, zanim zdążą zacząć generować przychody. Niestety jest to jeszcze trudniejsza rzeczywistość w przypadku projektów opartych na badaniach i rozwoju. Projekty badawczo-rozwojowe, które są bardzo naukowe i mają dostarczyć przełomowego rozwiązania, są zwykle prowadzone przez założycieli z silnym zapleczem akademickim.

Nie mam nic przeciwko osobom z takim wykształceniem — sam mam mocne zaplecze techniczne i akademickie i uważam to za zaletę. Kiedy jednak organizacją kierują takie osoby, dążą one do perfekcji. W rezultacie ciągle budują, rozwijają i dodają kolejne elementy. Zawsze martwią się skrajnymi scenariuszami, które, szczerze mówiąc, nie oznaczają końca świata, jeśli wydarzą się na etapie inkubacji lub we wczesnej fazie projektu.

W rezultacie nigdy niczego nie dostarczają, a świat nie może zobaczyć ich wizji nowej technologii.

Hannah Clark: Tak, zmagamy się z tym odwiecznym problemem „gotowe kontra idealne” — perfekcjoniści ścierają się z ludźmi, którzy po prostu chcą coś dostarczyć. Jednym z obszarów, w których jasność jest niezwykle ważna, jest rozwijanie MVP. To obszar szczególnie podatny na błędy i nieporozumienia, które na koniec dnia mogą mieć katastrofalne skutki.

Jakie są typowe pułapki, o których powinny pamiętać zespoły budujące MVP, i jakie sposoby pozwalają ich uniknąć?

Bijan Shahrokhi: Myślę, że największym błędem startupów związanym z koncepcją MVP jest utożsamianie go z dostarczeniem zepsutego produktu, którego nie da się nawet używać.

Widziałem to bardzo wiele razy. Nie podając nazw, przytoczę przykład. Jestem inwestorem w pewien produkt przeznaczony dla przedsiębiorstw. Bardzo w niego wierzę i jestem nim podekscytowany, ponieważ od pierwszego dnia widziałem, że sam chciałbym z niego korzystać.

Widziałem też, że moja organizacja, Product Management Exercises, chciałaby używać go codziennie. Największą przeszkodą w jego wdrożeniu jest jednak to, że produkt jest tak pełen błędów, iż nie możemy z niego korzystać. Dla liderów produktu bardzo ważne jest więc zwracanie na to uwagi i upewnienie się, że gdy mówimy o MVP, nie mamy na myśli wadliwego produktu, który nie potrafi zaprezentować swojej wartości.

Trzeba dopilnować, aby podstawowe doświadczenie użytkownika i główna wartość produktu, którą chcesz dostarczyć, działały płynnie od początku do końca. Możesz ograniczyć zakres wielu zbędnych elementów, ale musisz zapewnić podstawowe doświadczenie produktowe.

To jeden z największych błędów firm: źle rozumieją znaczenie MVP i sądzą, że mogą wypuścić coś częściowo zepsutego.

Hannah Clark: Czyli istnieje obóz, który nie chce czekać z dostarczeniem produktu, aż wszystko będzie idealne, a po drugiej stronie jest skrajne podejście do wypuszczania niedopracowanych produktów. To ma sens.

Wspominałeś wcześniej, że masz dość intensywny proces uzyskiwania jasności w organizacjach. Gdyby słuchacze chcieli skopiować to podejście do własnego sposobu pracy, jakie kroki powinni podjąć, aby upewnić się, że cały zespół jest zgodny?

Bijan Shahrokhi: Dziękuję za to pytanie. To interesujące, ponieważ wiele osób w PM Exercises uważa ten proces za bardzo pomocny. Szczerze mówiąc, jest dość prosty i polega na wykonaniu trudnej pracy na początku, zanim rzeczywiście rozpocznie się projekt. Składa się z konkretnych kroków, więc szybko go omówię.

Najpierw poświęcasz dużo czasu na uzyskanie zgodności w całej organizacji za pomocą procesu krok po kroku. Dopiero gdy uznasz, że wszyscy są zgodni, zaczynasz pracę. Co ciekawe, takie podejście zostało przyjęte w wielu większych organizacjach, na przykład w instytucjach finansowych.

Kiedy jednak przeszliśmy z modelu kaskadowego na metodykę Agile i Scrum, uznaliśmy, że oznacza to brak potrzeby jasnego określenia kierunku i skupienie się wyłącznie na tym, co zrobimy przez najbliższe dwa tygodnie. Nie taka była intencja Agile. Chodziło o dostarczanie czegoś wartościowego co dwa tygodnie przy jednoczesnej jasnej wiedzy o tym, dokąd zmierzamy w perspektywie kilku miesięcy.

Jak to osiągnąć? Kiedy prowadzę projekt lub produkt i zauważam w nim dużo niejasności, zaczynam od ustalenia indywidualnych spotkań z interesariuszami produktu. Muszą to być spotkania jeden na jeden, a nie spotkanie grupowe, ponieważ w grupie ktoś może wyrazić opinię na wrażliwy temat, po czym ktoś inny się wtrąci i osoba odpowiedzialna za produkt nie będzie w stanie właściwie przyswoić całego kontekstu.

Musisz porozmawiać z każdą osobą i upewnić się, że naprawdę rozumiesz jej perspektywę. Załóżmy, że rozważasz kompromis: czy powinniśmy zbudować funkcję X? To decyzja binarna, ale ten model sprawdza się także w wielu innych sytuacjach.

Spotykasz się z daną osobą, poznajesz jej opinię na temat tego, dlaczego coś należy lub czegoś nie należy robić. Pytasz również, na co powinieneś zwrócić uwagę przy podejmowaniu decyzji. Prawdopodobnie wskaże cztery lub pięć rzeczy, które są dla niej bardzo ważne.

Jest to szczególnie istotne w obszarze badań i rozwoju. Im bardziej techniczny jest produkt lub im więcej ma zależności technicznych z innymi narzędziami w organizacji, tym ważniejszy staje się ten proces, ponieważ istnieją eksperci dziedzinowi. Spotykasz się z kolejną osobą, potem z następną i rozmawiasz indywidualnie ze wszystkimi.

Z czasem Twoja opinia na temat decyzji może się umocnić, możesz też wypracować nowe stanowisko albo zmienić ocenę kompromisów. Możesz zdać sobie sprawę, że pewne rzeczy są trudniejsze lub łatwiejsze, niż początkowo sądziłeś, i odpowiednio zmodyfikować swoje założenia.

W miarę zbierania informacji podczas spotkań indywidualnych wracasz do niektórych osób i mówisz: „Kiedy początkowo rozmawialiśmy, powiedziałeś, że największe obawy dotyczą punktów 1, 2 i 3. Na podstawie rozmów z innymi uważam, że nie powinny one być problemem. Oto moje argumenty. Powiedz, dlaczego się mylę, albo potwierdź, że mam rację”.

W toku tej czasochłonnej wymiany zdań okazuje się, że wiele wyzwań, z którymi mierzył się zespół, wynikało tak naprawdę z braku komunikacji. Nikt nie poświęcał czasu na jasne przedstawienie różnych kompromisów poszczególnym interesariuszom w organizacji, więc wiele kwestii zostaje rozwiązanych.

Z czasem uzyskujesz coraz większą jasność co do wszystkich kompromisów, na które musisz zwrócić uwagę. To podejście sprawdza się również przy ustalaniu priorytetów produktowych. W pewnym momencie możesz zauważyć, że kilka kwestii nadal wywołuje różne opinie. Na przykład połowa zespołu uważa bezpieczeństwo za bardzo ważny atrybut, a druga połowa twierdzi, że nie jest ono szczególnie istotne.

Każda strona ma własne powody. Wtedy organizujesz spotkanie grupowe i mówisz: „Aby podjąć decyzję, musimy omówić ten istotny dla nas atrybut. Istnieją dwie różne perspektywy. Chciałbym, żebyśmy o nich porozmawiali”. Dzięki takiej rozmowie na żywo zwykle udaje się podjąć decyzję.

Czasami pojawia się kilka zadań do wykonania, na przykład potrzeba dalszego zbadania tematu. Wtedy organizujesz kolejne spotkanie i wracasz z informacją: „To był nasz początkowy cel. Przeprowadziliśmy badanie i oto nowe ustalenia. Co robimy?”. Najważniejsze jest podjęcie decyzji.

Kiedy masz pełną jasność co do wszystkich kompromisów, łatwiej zdecydować, czy wybrać określoną ścieżkę, czy ustalić priorytety produktu. Możesz wtedy powiedzieć: „Ustaliliśmy, że to jest nasz priorytet i na nim się skupimy”.

Na bardzo wysokim poziomie wygląda to tak: krok pierwszy — rozpocznij od spotkań jeden na jeden, podczas których dokładnie poznasz perspektywę każdej osoby. Krok drugi — jeśli trzeba, wracaj do tych osób, aby upewnić się, że wszystkie kwestie, w których się różnią, zostały rozwiązane. Jeśli nie, przeznacz je do omówienia grupowego.

Krok trzeci — przeprowadź dyskusje grupowe. W rezultacie powstanie spójna strategia produktu, specyfikacja produktu albo zestaw priorytetów produktowych. W zależności od sytuacji może pojawić się dodatkowy krok. Przy ustalaniu priorytetów trzeba na przykład zastanowić się nad celem.

Być może na początku należy poświęcić trochę czasu na stwierdzenie: „Naszym celem jest szybkie dostarczenie czegoś na rynek i zdobycie wiedzy”. Następnie sprawdzasz, czy ktoś się z tym nie zgadza. Jeśli wszyscy są zgodni, możesz kontynuować proces.

Hannah Clark: Chciałabym porozmawiać jeszcze trochę o priorytetach produktowych. Nawet gdy jesteśmy stosunkowo blisko konsensusu albo wydaje nam się, że uzgodniliśmy cele i kryteria sukcesu, nadal trudno jest pogodzić konkurujące ze sobą priorytety.

Istnieją setki różnych modeli ustalania priorytetów funkcji produktu. Jakie metody stosowałeś i uważałeś za najbardziej skuteczne oraz uniwersalne w pracy z konkurującymi priorytetami?

Bijan Shahrokhi: Jednym z podejść jest ocenianie ich i patrzenie na nie z kilku perspektyw.

Pierwsza to wpływ, jaki dana funkcja lub produkt będzie moim zdaniem mieć na grupę docelową albo użytkowników docelowych. Druga to prawdopodobieństwo, że rzeczywiście uda nam się ten wpływ osiągnąć. W wielu przypadkach nie masz przecież pewności, czy nowy produkt faktycznie spotka się z zainteresowaniem odbiorców.

W takiej sytuacji prawdopodobieństwo jest niższe. Trzecim elementem jest łatwość wdrożenia. W głowie mam następujący wzór: „wpływ pomnożony przez prawdopodobieństwo wpływu plus łatwość wdrożenia”. Wpływ oceniamy w skali od 1 do 5, gdzie 5 oznacza największy wpływ, a 1 — najmniejszy.

W przypadku łatwości wdrożenia ocena 5 oznacza, że coś łatwo wdrożyć, a 1 — że wymaga to dużego wysiłku. Następnie otrzymujesz wynik. Podoba mi się to podejście, ponieważ jest obiektywne. W ramach opisanego wcześniej procesu możesz prowadzić podobne rozmowy.

Możesz wrócić do członka zespołu i powiedzieć: „Na podstawie rozmów ze wszystkimi przygotowałem tabelę najważniejszych projektów w organizacji. Oto moja ocena ich wpływu i nakładu pracy potrzebnego do wdrożenia. Na tej podstawie oto projekty, które powinny otrzymać najwyższą ocenę”.

Członek zespołu może odpowiedzieć, że pominąłeś trzy projekty, nad którymi również pracujecie, albo że jeden uwzględniony projekt powinien zostać podzielony na trzy, ponieważ jest większy, niż sądziłeś. Może też nie zgodzić się z oceną wpływu lub nakładu pracy. Teraz jednak rozmawiacie w sposób obiektywny, skupiając się na konkretnych elementach.

Interesujące w tym systemie oceniania jest to, że nie próbujesz dokładnie oszacować czasu potrzebnego na realizację wszystkiego. Patrzysz na projekty względnie, porównując je ze sobą. Dzięki temu łatwiej szybko osiągnąć konsensus dotyczący wartości, jaką coś dostarczy, i nakładu pracy, którego wymaga.

W rezultacie otrzymujesz jasno określone priorytety i możesz powiedzieć: „Na tych pięciu rzeczach skupimy się w kolejnym kwartale”. Kiedy pojawia się nowy element albo ktoś mówi: „Powinniśmy to zrobić”, patrzysz na tabelę priorytetów i odpowiadasz: „Przeanalizowaliśmy to i zdecydowaliśmy, że obecnie nie jest to priorytet z tego powodu. Kiedy skończymy te dwa lub trzy elementy, nadamy temu priorytet”.

Czasami okazuje się, że trzeba dodać coś jeszcze. Możemy również porozmawiać o tym, jak postępować w takich sytuacjach. Uważam jednak, że to podejście jest bardziej obiektywne i ułatwia ustalenie priorytetów.

Hannah Clark: Doceniam to. Rozmawialiśmy już w The Product Manager o odpersonalizowaniu informacji zwrotnych i rozmów o ustalaniu priorytetów, aby ludzie nie czuli, że istnieje osobisty powód, dla którego ich ulubiony projekt lub pomysł został zdegradowany albo umieszczony w innej kolejności, niż ich zdaniem powinien.

To bardzo konkretna metoda. Naprawdę ją doceniam. Przepraszam, do czego chciałeś wrócić? Wspomniałeś, że porozmawiamy o tym za chwilę.

Bijan Shahrokhi: Powiedziałem, że możemy porozmawiać o sytuacji, w której ktoś mówi: „To musi być priorytetem”, a Ty zdajesz sobie sprawę, że z jakiegoś powodu rzeczywiście powinno nim być.

Jak sobie z tym radzić? Czasami trzeba znaleźć sposób na realizację tego elementu, ale nie można po prostu dopisać go do listy priorytetów. Należy albo zrobić to tak, aby nie wpłynęło to na tempo dostarczania elementów już znajdujących się na liście, albo usunąć coś z listy i zdegradować istniejący priorytet.

Wtedy nowy element zastępuje go w systemie oceniania. Innym rozwiązaniem jest przeznaczenie dodatkowych zasobów na pracę nad nowym priorytetem. Zasada jest taka, że elementy z listy priorytetów nie mogą zwolnić tylko dlatego, że dodajesz do niej kolejną rzecz.

Moim zdaniem jest to zadanie menedżera produktu, choć w niektórych organizacjach tak nie jest. Właśnie wtedy pojawia się problem z niedostarczaniem rzeczy na czas.

Dobry menedżer produktu zwróci na to szczególną uwagę i upewni się, że jeśli nowe informacje uzasadniają nadanie czemuś wyższego priorytetu, zostanie to właściwie obsłużone. Albo usuwam coś z listy, albo zapewniam dodatkowe zasoby, które mogą pracować nad nowym elementem bez wpływu na tempo dostarczania pozostałych.

Hannah Clark: Fascynujące. Chciałam nieco zmienić temat, bo zbliżamy się do końca, i porozmawiać o produktywności. Wiem, że to kolejna rzecz, na której bardzo Ci zależy, i prawdopodobnie jeden z głównych powodów, dla których założyłeś productmonkey.ai.

Czy mógłbyś podzielić się ogólnymi wskazówkami dotyczącymi produktywności oraz informacjami o Product Monkey AI, które mogą zainteresować naszych słuchaczy? To bardzo ciekawe narzędzie.

Bijan Shahrokhi: Jasne. Product Monkey AI automatyzuje jedno zadanie, które jako menedżerowie produktu uważamy za bardzo potrzebne, ale którego nie lubimy wykonywać — poświęcanie dużej ilości czasu na pisanie szczegółowych wymagań i kryteriów akceptacji.

Product Monkey AI zbiera jak najwięcej informacji o projekcie, nad którym pracujesz, o Twojej organizacji i o konkretnym przepływie użytkownika. Dzięki odpowiednim wskazówkom od Ciebie i wykorzystaniu sztucznej inteligencji możemy przygotować szczegółowe wymagania produktowe, kryteria akceptacji, scenariusze testowe, a nawet zdarzenia i wskaźniki, na które należy zwrócić uwagę podczas budowania produktu.

Możesz od razu wykorzystać te materiały i rozpocząć pracę. Otrzymujesz szybki szkic obejmujący około 80% pracy potrzebnej do przygotowania zadań dla zespołu inżynieryjnego, dokumentów wymagań produktu i dokumentacji. Następnie poświęcasz czas na dopracowanie pozostałych 20%.

Jedną z korzyści, które możemy zapewniać jako menedżerowie produktu, jest — jak wspominałem — wprowadzanie jasności. Product Monkey AI może w tym pomóc, skracając czas potrzebny menedżerom produktu na zapewnienie zespołom inżynieryjnym jasnych informacji.

Hannah Clark: To wspaniałe. Jestem pewna, że wiele osób słuchających tego programu dostrzeże w tym narzędziu dużą wartość. Bijan, bardzo dziękuję za udział. Gdzie można znaleźć Cię w internecie, jeśli ktoś chce śledzić Twoją działalność?

Bijan Shahrokhi: Można znaleźć mnie na Twitterze, a właściwie na X, jak teraz nazywa się ten serwis. Mój nick na X to bijan_sha. Można też odwiedzić PM Exercises albo Product Management Exercises — wystarczy wyszukać jedną z tych nazw. Traficie na naszą stronę i będziecie mogli nawiązać ze mną kontakt.

Hannah Clark: Świetnie. Jeszcze raz dziękuję za poświęcony czas.

Bijan Shahrokhi: Bardzo dziękuję za zaproszenie.

Hannah Clark: Dziękujemy za wysłuchanie. Aby poznać więcej wartościowych spostrzeżeń, poradników i recenzji narzędzi, zapisz się do naszego newslettera pod adresem theproductmanager.com/subscribe. Więcej takich rozmów znajdziesz, subskrybując The CPO Club w dowolnej aplikacji, w której słuchasz podcastów.