Jak skorygować kurs, gdy mapa drogowa chronicznie schodzi z toru

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: Mapy drogowe produktu, podobnie jak prawdziwe mapy drogowe, nieuchronnie napotykają opóźnienia. Niektóre można przewidzieć i odpowiednio zaplanować, a inne pojawiają się zupełnie niespodziewanie, ale przez większość czasu można wyznaczyć objazd i wrócić na właściwy tor. Co jednak, jeśli zauważysz niepokojący wzorzec: cele nie są realizowane, terminy chronicznie się wydłużają, a cała mapa drogowa wydaje się nieustannie schodzić z toru?

W dzisiejszym odcinku usłyszycie Michaela Pierce’a, dyrektora ds. zarządzania produktem w Public Consulting Group, który twierdzi, że chroniczne opóźnienia w realizacji mapy drogowej mogą być objawem braku dopasowania między strukturą firmy a strukturą zespołu produktowego. Jeśli więc trudno wam zrozumieć, dlaczego wasze cele i inicjatywy nigdy nie są realizowane zgodnie z prognozami, być może właśnie tego rodzaju korekty kursu potrzebujecie. Zaczynajmy.

Witajcie, słuchacze. Witajcie ponownie w podcaście dla menedżerów produktu. Jest dziś ze mną Michael Pierce. Michael jest dyrektorem ds. zarządzania produktem w Public Consulting Group. Michaelu, bardzo dziękuję, że do nas dołączyłeś.

Michael Pierce: Tak, dziękuję, Hannah. Cieszę się, że tu jestem.

Hannah Clark: Michaelu, czy możesz zacząć od opowiedzenia trochę o swoim doświadczeniu i o tym, jak znalazłeś się w obecnym miejscu?

Michael Pierce: Oczywiście. Zacząłem od studiów ekonomicznych, podobnie jak wiele osób zajmujących się produktem. Ludzie produktowi mają przecież bardzo różne doświadczenia. Pracowałem w firmie brokerskiej ubezpieczeniowej i wtedy znajomy dał mi egzemplarz książki „The Lean Startup”. Zacząłem ją czytać i zastanawiać się nad różnymi nieefektywnymi procesami w pracy, mając jeszcze dość niedojrzałe podejście do produktu.

W końcu stworzyłem dość zaawansowany program VBA, sam nauczyłem się kodu w Visual Basicu i zacząłem automatyzować różne zadania. To był początek mojego zainteresowania zarządzaniem produktem, choć w tamtym czasie nie było ono jeszcze tak spopularyzowane jak dziś.

Chodziło o rozmowy z użytkownikami, ustalanie, czego potrzebują, próby zbudowania rozwiązania i sprawdzanie z nimi postępów w całym procesie. Niedługo później stworzyłem swój pierwszy start-up. Działał w branży związanej z basenami. Współpracowaliśmy z wieloma basenami, a miasto Denver, gdzie mieszkam, w Denver w Kolorado, było jednym z naszych klientów. To było dla nas bardzo ekscytujące, ale właśnie wtedy rozpoczęła się moja przygoda z produktem.

Rozmawialiśmy z użytkownikami i stworzyliśmy coś w rodzaju mapy drogowej, niemal w stylu „teraz, następnie, później”, ponieważ byłem wtedy dopiero na początku swojej drogi produktowej. Było to jednak świetne wprowadzenie do tej dziedziny. Kilka lat później doszło do przejęcia firmy wraz z zatrudnieniem zespołu, po czym przeniosłem się do pracy w przedsiębiorstwie w Bostonie. To było wspaniałe doświadczenie. Niedługo potem trafiłem do obecnej firmy, Public Consulting Group, jako dyrektor ds. zarządzania produktem.

Hannah Clark: Wspaniale. W trakcie swojej kariery pracowałeś z kilkoma zespołami — czasami jako ich członek, ale często także jako lider. Jakie wyzwania uznałbyś za charakterystyczne dla zespołów produktowych jako takich?

Michael Pierce: Myślę, że dużym wyzwaniem, którego wiele osób zajmujących się produktem nie zawsze jest świadomych, jest konieczność przyjrzenia się firmie, w której obecnie pracujesz, i określenia dwóch głównych kwestii. Po pierwsze: czy firma jest kierowana przez sprzedaż, finanse albo marketing? Wszyscy znamy dobre przykłady takich organizacji.

Jeśli spojrzysz na HubSpot, zobaczysz firmę zdecydowanie kierowaną przez marketing. Z kolei Zoom czy Slack to klasyczne przykłady bardzo silnego wzrostu napędzanego produktem i przywództwa skoncentrowanego na produkcie. Dlatego zespoły produktowe powinny zastanowić się, czy dyrektor generalny często spotyka się z działem sprzedaży i czy łączy ich bardzo bliska relacja.

Warto też sprawdzić, czy członkowie kierownictwa wywodzą się z operacji, sprzedaży lub innej funkcji. Może to być wskazówką, jak działa firma. Drugą ważną kwestią dotyczącą kultury organizacyjnej jest sposób podejmowania dużych decyzji.

Czy decyzje są podejmowane całkowicie odgórnie? Czy najwyższe kierownictwo omawia je z innymi menedżerami i członkami kadry zarządzającej? A może proces jest bardzo demokratyczny? Zrozumienie struktury podejmowania kluczowych decyzji jest niezwykle istotne. Jeśli wiesz, czy firma jest kierowana przez sprzedaż lub finanse oraz jak wygląda struktura decyzyjna, możesz lepiej zrozumieć, jak dział produktu wpisuje się w całość i jak poruszać się w tych uwarunkowaniach.

Jeśli zignorujesz te informacje i po prostu będziesz wykonywać codzienną pracę jako dział produktu, możesz napotkać wiele blokad i wyzwań, ponieważ nie ustawisz się właściwie, aby wpływać na innych ludzi w organizacji.

Hannah Clark: Spróbujmy ująć to za pomocą przykładu. W jaki sposób brak dopasowania między tym, jak zespół produktowy postrzega swoją rolę, a tym, jak faktycznie działa firma, może później powodować problemy?

Michael Pierce: Myślę, że jednym z przykładów jest obecne zainteresowanie wzrostem napędzanym produktem. Osobiście bardzo lubię ten model, choć jestem trochę stronniczy. Jeśli jednak dział produktu działa w sposób silnie skoncentrowany na wzroście napędzanym produktem, podczas gdy firma w rzeczywistości rozwija się głównie dzięki sprzedaży, doprowadzi to do dużego braku zgodności w zakresie finansowania inicjatyw i uzyskiwania poparcia różnych działów.

Dlatego bardzo ważne jest rozpoznanie swojej pozycji jako działu i funkcji w odniesieniu do wszystkich pozostałych funkcji. To pozwala zespołowi odpowiednio planować kolejne ruchy.

Hannah Clark: Porozmawiajmy trochę o ustalaniu priorytetów i związanych z nim wyzwaniach. Myślę, że w pewnym stopniu zmaga się z tym każdy zespół produktowy, niezależnie od modelu wzrostu. Jakie wyzwania związane z priorytetyzacją zauważyłeś w firmach, dla których pracowałeś?

Michael Pierce: Przychodzą mi na myśl dwie kwestie. Pierwsza to często występująca luka między stanem idealnym, czyli myśleniem w kategoriach listy życzeń, a rzeczywistością tego, co faktycznie budujemy.

Jednym z wyzwań związanych z priorytetyzacją jest presja ze strony zarządów, spółek publicznych i inwestorów. Pracowałem też dla firm należących do funduszy private equity. Taka presja może prowadzić do tworzenia ogromnej mapy drogowej pełnej atrakcyjnych i efektownych elementów.

Wyzwaniem jest sprowadzenie wszystkich z powrotem na ziemię, ale w taki sposób, aby nadal czuli się dobrze z podjętymi decyzjami. Priorytetyzacja wymaga więc uzgodnienia najważniejszych elementów. Najpierw trzeba wiedzieć: oto nasza wizja, oto nasza gwiazda polarna.

Należy określić te nadrzędne elementy, aby skutecznie ustalać priorytety. Drugą pułapką jest brak porozumienia interesariuszy i kadry zarządzającej wokół wizji, sposobu mierzenia sukcesu, gwiazdy polarnej, kluczowych wskaźników efektywności i celów oraz kluczowych rezultatów.

Kiedy te kwestie są uzgodnione, łatwiej prowadzić zdrowy proces ustalania priorytetów i odejść od rozdętej listy życzeń na rzecz czegoś znacznie bardziej precyzyjnego. Elementów może być wiele, ale powinny być dobrze zdefiniowane. Organizacja powinna wiedzieć, że na przykład cztery główne epiki lub inicjatywy są ściśle powiązane z dwoma celami i kluczowymi rezultatami, na których naprawdę zależy dyrektorowi generalnemu oraz całej organizacji. Tak właśnie postrzegam problem ustalania priorytetów.

Hannah Clark: W poprzedniej rozmowie opowiedziałeś mi historię o analizie pewnej firmy. Nie wymienimy jej nazwy, ale występowały w niej problemy z nietrafionymi celami i poproszono cię o znalezienie ich przyczyn. Czy możesz trochę o tym opowiedzieć?

Michael Pierce: Oczywiście. Firma nie realizowała dużej części elementów mapy drogowej i chciała wiedzieć dlaczego. To było całkowicie uzasadnione pytanie. Jako osoba zajmująca się produktem postrzegam mapę drogową jako rezultat wielu innych procesów. Praca wykonywana w praktyce jest wynikiem złożonych interakcji i danych wejściowych.

Jedną z pierwszych rzeczy, które zrobiłem, było przeanalizowanie przyczyn. Jeśli nie realizujemy 50% elementów mapy drogowej, jakie są tego źródłowe powody? Jedną z możliwości było to, że po prostu mieliśmy zbyt wiele elementów. Jeśli mapa drogowa wymaga na przykład 2000 godzin, a dysponujesz tylko 1000 godzin pracy programistów, oczywiście nie zrealizujesz połowy zadań. Jednak z tego, co widziałem, liczba inżynierów, osób zajmujących się zapewnianiem jakości i pozostałych pracowników pomocniczych powinna wystarczyć do wykonania tej mapy drogowej.

Zacząłem więc szukać głębiej, aby zrozumieć, dlaczego firma nadal nie realizuje wielu elementów. Odkryłem kilka rzeczy. Jedną z nich było zorganizowanie zespołów programistycznych w taki sposób, że były współdzielone przez wiele produktów. Dla osoby odpowiedzialnej za produkt wyzwaniem przy tworzeniu dobrej mapy drogowej jest uzyskanie pewności, że ma się pięć stałych zasobów.

Pięciu inżynierów pracuje nad tym produktem przez 40 godzin tygodniowo. Być może efektywnie dysponują 30 godzinami, ponieważ rozpraszają ich wiadomości na Slacku, e-maile i inne sprawy. Można jednak oszacować ten czas i prognozować przyszłość, określając prawdopodobieństwo realizacji mapy drogowej na poziomie 80 czy 90%.

Dużym problemem przy współdzielonym rozwoju jest to, że pożar w innym produkcie albo ogromny kontrakt zdobyty dla jednego z produktów może poważnie wykoleić mapę drogową całej firmy oraz danego produktu. To była jedna z przyczyn: współdzielenie zespołów programistycznych.

Drugą ważną przyczyną była duża liczba nieplanowanych prac i błędów. Mapa drogowa była tworzona z wysokim poziomem pewności, że można ją zrealizować. Jednak gdy zespoły napotykały problemy — na przykład konieczność zaktualizowania dużej zależności, zdobycie dużego kontraktu wymagającego przesunięcia zasobów albo błąd wykryty po wdrożeniu kodu na produkcję — wszystkie te rzeczy mogły uniemożliwić ukończenie mapy drogowej.

Jako osoby zajmujące się produktem wiemy, że istnieje bardzo wiele zmiennych. Zawsze staramy się ustalić, które z nich są stałe, a które dynamiczne, a następnie na tej podstawie planować produkcję. Jednak im więcej jest różnych zmiennych, tym mniejsze prawdopodobieństwo pomyślnego ukończenia kwartału lub roku finansowego.

Hannah Clark: A to dotyczy tylko tego, co znajduje się na mapie drogowej. Nie mówimy nawet o problemach, jakie może to powodować w zakresie innowacji ani o tym, co ma nadejść później.

Michael Pierce: Zgadza się.

Hannah Clark: Jak możemy chronić mapę drogową? Załóżmy, że uwzględniliśmy cały czas potrzebny do jej realizacji, ale wiemy też, że w przyszłości będziemy potrzebować czasu na innowacje, tworzenie nowych funkcji i reagowanie na funkcje, których dział sprzedaży potrzebuje dla określonego klienta. Jak możemy chronić mapę drogową i ten czas?

Michael Pierce: Pierwszym krokiem, który sugerowałbym osobie zajmującej się produktem, jest analiza historycznych kwartałów i ustalenie dobrej wartości bazowej — zgodnie z klasycznym określeniem „wczorajsza pogoda”. Jeśli w poprzednim kwartale 20% pracy stanowiły błędy, 20% nowe funkcje sprzedażowe, a 10% eksperymentalne inicjatywy innowacyjne, możesz wykorzystać ich sumę do prognozowania przyszłych map drogowych.

Dobrym sposobem na uzgodnienie mapy drogowej w całej organizacji jest przedstawienie jej jako dobrze zbilansowanej diety. Możesz przeznaczyć 40% na nowe funkcje, 10 lub 15% na błędy, a około 20% na duże żądania sprzedażowe, które mogą się pojawić.

W ten sposób można ustalić właściwe proporcje zadań, nad którymi powinno się pracować, podobnie jak w diecie. Pierwszym krokiem jest zapewnienie odpowiednich proporcji i zakomunikowanie ich interesariuszom.

Nie będą wtedy zaskoczeni, jeśli 10% czasu inżynierów zostanie przeznaczone na interesujący eksperyment lub bardziej przyszłościową funkcję, ponieważ wcześniej zostało to uzgodnione. Zespoły zyskują też większą możliwość odmowy w odpowiedni sposób. Mogą powiedzieć: chcielibyśmy wprowadzić jeszcze jedną zmianę w tej funkcji, ale w tym kwartale przeznaczamy 10% naszych mocy na zbadanie nowej funkcji, która może bardzo pomóc sprzedaży w przyszłym roku. Wszystko sprowadza się do zarządzania oczekiwaniami — zarówno zespołów produktowych, jak i kadry kierowniczej oraz innych interesariuszy.

Hannah Clark: Skoro mówimy o zespołach, jaki jest związek między sposobem ich projektowania a wpływem na to, co zostaje wybrane jako priorytet i dostarczone?

Michael Pierce: Wraca to do naszej początkowej rozmowy o tym, czy firma jest kierowana przez produkt czy sprzedaż. Sposób projektowania zespołów często odzwierciedla kulturę organizacji.

Jeśli organizacja ma bardzo agresywną kulturę sprzedaży — w pozytywnym znaczeniu, ponieważ próbuje zdobywać wiele nowych kontraktów — wpłynie to również na sposób projektowania zespołów. Możliwe, że będzie potrzebnych więcej prac związanych z tworzeniem funkcji, a także dedykowane zespoły zajmujące się dostosowaniami dla klientów.

Struktura zespołów w dużej mierze wynika z tego, co ceni organizacja: sprzedaż, finanse czy przede wszystkim produkt. Znaczenie ma też podejście do zupełnie nowych prac i funkcjonalności tworzonych od podstaw.

Warto również zastanowić się, jaka struktura służy realizacji pracy. Wszyscy słyszymy o metodyce zwinnej. W przeszłości istniało więcej firm pracujących kaskadowo, a przedsiębiorstwa organizują się także na wiele innych sposobów.

To kolejny ważny element projektowania zespołów: zrozumienie, czy kultura firmy jest przede wszystkim zwinna, czy raczej kaskadowa. Wszystko to wpływa na skład zespołu. Kiedy jednak rozumiesz ten kontekst, możesz jako osoba zajmująca się produktem wskazywać luki.

Możesz powiedzieć: rozumiem, że dotychczas działaliśmy głównie kaskadowo, ale wprowadzamy nowy produkt i zamierzamy go zaoferować na rynku. Spróbujmy zastosować tutaj proces zwinny albo przejść od współdzielonego zespołu inżynieryjnego do zespołu dedykowanego. Taka wiedza kontekstowa bardzo wzmacnia zespoły produktowe.

Hannah Clark: Czy miałeś wcześniej doświadczenie, w którym trzeba było przeorganizować zespół, aby dopasować go do sposobu funkcjonowania firmy?

Michael Pierce: Oczywiście. Ostatnia firma, w której pracowałem, była przedsiębiorstwem private equity z Bostonu. Zatrudniono mnie, abym od podstaw zbudował dział produktu.

W ramach tego zadania przeanalizowałem, jak wszystkie zespoły wykonują pracę i jak są zorganizowane. Firma miała kilka różnych produktów, a jej sposób działania był częściowo kaskadowy i nieco chaotyczny. Po dokładnej analizie i rozmowach z właścicielami oraz dyrektorem generalnym powiedziałem, że widzę możliwość przeorganizowania sposobu działania zespołów i pogrupowania ich w mniejsze jednostki pracujące na rzecz całego portfela produktów.

Było to wspaniałe doświadczenie. Mieliśmy możliwość wdrożenia metodyki zwinnej we wszystkich zespołach, połączenia różnych grup w zespoły platformowe i zespoły pracujące bezpośrednio nad produktami. Niektórym osobom umożliwiliśmy działanie bardziej w roli technicznych menedżerów produktu zamiast klasycznych menedżerów produktu w standardowej ofercie oprogramowania jako usługi.

To była świetna okazja, aby jako osoba zajmująca się produktem spojrzeć całościowo na strukturę organizacji, zaproponować najlepszy sposób ułożenia zespołów i zmierzyć sytuację przed zmianą oraz po niej. Widziałem większą efektywność dzięki codziennym spotkaniom, prezentacjom wyników sprintów i wszystkim tym elementom. Miały one bardzo pozytywny i znaczący wpływ na organizację. To najlepsze, o co możemy prosić jako osoby zajmujące się produktem: możliwość wywierania wpływu i mierzenia jego rezultatów.

Hannah Clark: Mając takie doświadczenie, czy możesz wskazać czerwone flagi, na które szczególnie liderzy produktu powinni zwracać uwagę i które mogą sugerować, że warto rozpocząć reorganizację zespołu?

Michael Pierce: Jedną z czerwonych flag jest konieczność zebrania danych dotyczących tych kwestii. Warto przyjrzeć się całkowitemu czasowi od pomysłu do wdrożenia na produkcję. Jeśli jest on znacznie dłuższy od normy, może to być sygnał ostrzegawczy. To trudne, ponieważ nie ma wielu opublikowanych standardów.

Załóżmy jednak, że stworzenie niewielkiej nowej funkcji i wdrożenie jej na produkcję zajmuje dwa tygodnie. To dobry wynik, ponieważ typowy cykl sprintu trwa dwa lub trzy tygodnie. Nie uznałbym tego za czerwoną flagę.

Jeśli jednak mały fragment funkcjonalności wymaga 40 godzin pracy programistów, a mimo to od rozpoczęcia do wdrożenia mija pięć, sześć, siedem lub osiem tygodni, byłby to dla mnie sygnał ostrzegawczy. Być może występuje wąskie gardło w zapewnianiu jakości albo problem z uzyskaniem opinii właściwych interesariuszy na temat epiki lub dokumentu wymagań funkcjonalnych.

Wskaźnikiem jest sytuacja, w której — patrząc na cały system jak na pudełko z danymi wejściowymi i wyjściowymi — rezultaty nie odpowiadają oczekiwanej wartości bazowej.

Hannah Clark: Jak mierzyć sukces reorganizacji zespołów?

Michael Pierce: Można zrobić to na wiele sposobów. Klasycznym sposobem jest analiza wyników zespołu. Czy w krótszym czasie dostarcza on klientom końcowym więcej przyrostów wartości? Innym sposobem jest sprawdzenie, czy skraca się czas od pomysłu do wdrożenia.

Czy szybciej i bardziej zwinnie — wybaczcie grę słów — przenosimy pracę z punktu A do punktu B? Często pomijaną metodą jest połączenie rozmów indywidualnych, sprawdzania sytuacji członków zespołu i przekazywania ustaleń kadrze zarządzającej z klasyczną ankietą porównującą sytuację przed reorganizacją i po niej.

Jak czuli się członkowie zespołu? Czy mieli poczucie, że są mniej rozciągani w różnych kierunkach i rzadziej muszą przełączać kontekst? Czy czuli się bardziej uprawnieni do podejmowania decyzji wraz z właściwymi osobami i doprowadzania pracy do końca? To wszystko są dobre wskaźniki skuteczności reorganizacji i jej pozytywnych rezultatów.

Hannah Clark: Świetnie. Podsumowując, jakie były rezultaty reorganizacji zespołu?

Michael Pierce: Od samego początku było jasne, że znacznie zmniejszyła się luka we wspólnym rozumieniu pytań i niejednoznaczności związanych z pracą zespołu. Przed moim przyjściem do firmy zespół spotykał się raz w tygodniu.

Po reorganizacji zaczęliśmy organizować codzienne spotkania. Zespół mógł więc każdego ranka uzyskać odpowiedzi na pytania od właściwych osób. Zwiększyło to ilość wykonanej pracy, a także zmniejszyło niepokój programistów, którzy wcześniej czekali z pytaniami przez cały tydzień.

Jeśli czegoś nie byli pewni, następnego dnia mogli uzyskać odpowiedź. Nie zawsze, ale w większości przypadków tak było. Dzięki temu zespół czuł się znacznie lepiej wspierany w całej organizacji.

Hannah Clark: Na zakończenie porozmawiajmy o uzyskiwaniu poparcia ważniejszych interesariuszy. Jak skutecznie udowodnić albo przynajmniej wskazać, że reorganizacja będzie warta początkowego okresu inwestycji?

Michael Pierce: Duża część reorganizacji polega na przeanalizowaniu wszystkich złożoności związanych z przejściem od punktu A do punktu B podczas tworzenia oprogramowania. Oprogramowanie jest przecież skomplikowane, pełne zakrętów i nieprzewidzianych sytuacji.

Dlatego podczas rozmów o reorganizacji z członkami kadry zarządzającej i wyższymi interesariuszami trzeba zapytać: jaki jest rzeczywisty rezultat? Jakie są cele i kluczowe rezultaty? Jakie kluczowe rezultaty chcecie osiągnąć dla organizacji?

Następnie można wykorzystać je jako punkt odniesienia lub wartość bazową do oceny skuteczności organizacji pracy. To samo dotyczy pomiaru pracy jako takiej. Najważniejsze jest ustalenie wartości bazowych i mierzenie wyników względem nich, aby sprawdzić, jak blisko udało się osiągnąć cel.

Hannah Clark: Świetnie. Michaelu, bardzo dziękuję, że do nas dołączyłeś. Wiem, że jesteś współtwórcą treści w The CPO Club. Twoje teksty można przeczytać na stronie TheProductManager.com. W jaki jeszcze sposób można znaleźć cię w internecie?

Michael Pierce: Najlepiej znaleźć mnie na LinkedInie. Jestem cyfrowym minimalistą, więc korzystam tylko z LinkedIna. Jeśli jednak napiszecie do mnie wiadomość, z przyjemnością porozmawiam wirtualnie ze słuchaczami podcastu.

Hannah Clark: Świetnie. Dziękuję za poświęcony czas i bardzo doceniam twoje spostrzeżenia.

Michael Pierce: Dziękuję, Hannah.

Hannah Clark: Dziękujemy za wysłuchanie. Więcej ciekawych spostrzeżeń, poradników i recenzji narzędzi znajdziecie w naszym biuletynie pod adresem theproductmanager.com/subscribe. Więcej takich rozmów usłyszycie, subskrybując The CPO Club w dowolnej aplikacji, w której słuchacie podcastów.