Product Ops jako aktywator

Dec 06 2022

W ostatnich latach coraz większą uwagę zwraca się na rolę operacji produktowych, ale podobnie jak w przypadku wielu ról zmierzających do osiągnięcia dojrzałości, pojawia się wiele zamieszania i niepewności. Jedną z największych wątpliwości jest to, gdzie operacje produktowe są umiejscowione w organizacji, czym się kierują/posiadają i gdzie mogą wnieść wartość.

Jedną z największych wątpliwości jest to, gdzie operacje produktowe są umiejscowione w organizacji, czym się kierują/posiadają i gdzie mogą wnieść wartość. Szczególnie trudne przy wprowadzaniu Product Operations w organizacji, która nigdy nie pracowała z Product Operations.

Biorąc pod uwagę możliwość adaptacji roli i funkcji w zależności od organizacji, moglibyśmy potencjalnie argumentować, że wszystko jest grą i potencjalnie mieści się w naszym zakresie.

Moim zdaniem, jeśli zachowamy proste podstawowe zasady, rola będzie łatwa do dostosowania do każdej organizacji, a zakres łatwy do zdefiniowania.

Ale co to właściwie oznacza?

Słowo klucz to aktywator

Nawet eksperci mają różne opinie i punkty widzenia na ten temat, ale jedno słowo, które ciągle się pojawia, to bycie aktywatorem lub umożliwienie zespołowi.

Jak elokwentnie ujęła to Antonia Landi w niedawnej aktualizacji Linkedin :
„Nauczyłam się ostatnio czegoś ważnego: nie należy tłumaczyć Product Ops jako „ułatwiania ludziom życia”.

Jako osoba aktywizująca pracę łatwo jest chcieć być pomocnym za wszelką cenę i łatwo jest „sprzedać” tę historię nowym współpracownikom i zainteresowanym stronom. W końcu jestem tutaj, aby ułatwić ci życie, dlaczego nie chcesz mnie w pobliżu?

A potem ładnie podsumowuje swój ostateczny pogląd słowami: „Moim zadaniem jest umożliwienie ludziom w naszym dziale wykonywania świetnej pracy”.

Myślę, że ważnym wnioskiem jest to, że jasne określenie naszej roli jako aktywistów pomaga nam określić jaśniejszy cel i zakres.

Jako aktywiści będziemy Pomnażaczami Mocy , zgodnie z sugestią Marty'ego Cagana w jego artykule, a nie w roli wypełniacza.

Ale w praktyce, co to oznacza i jak zastosować tę logikę, myśląc o roli i zakresie?

Umożliwianie nie posiadania

Chociaż chcielibyśmy móc przedstawić standardową odpowiedź na temat zakresu i odpowiedzialności Product Operations, nie możemy, ponieważ będzie musiał się dostosować, w zależności od różnych czynników:

Specyficzne potrzeby organizacji
Gdzie operacje związane z produktem są umiejscowione w organizacji
Dojrzałość organizacji produktowej

Kiedy umożliwiamy, odblokowujemy możliwości. Pomagamy łączyć ludzi, aby budować właściwe relacje. Tworzymy infrastrukturę, aby wspierać zespół, a nie go zmuszać.

Spójrzmy na praktyczny przykład opinii klientów. Niezależnie od tego, czy firma prowadzi badania, sukcesy klientów, sprzedaż, operacje na klientach czy żadne z powyższych, rozumiemy, że opinie klientów są ważną częścią procesu rozwoju produktu.

Wyzwanie polega na tym, że opinie klientów pochodzą z różnych źródeł i każdy chce mieć pewność, że opinie klientów docierają do właściwych osób, aby podejmować właściwe decyzje.

W tym momencie działy produkcji mogą z łatwością uznać, że ich obowiązkiem jest naoliwienie maszyny i upewnienie się, że tak się dzieje.

Prawda jest taka, że istnieje wiele sposobów podejścia do sytuacji, w zależności od czynników wymienionych powyżej.

Jak sprawić, by to działało, nie depcząc nikomu po palcach?

Osobiście sugeruję następujące stopniowe podejście.

Krok 1: Zacznij od połączenia kropek

Pierwszym krokiem jest zidentyfikowanie kluczowych osób, działów i informacji do połączenia.

Kto jest właścicielem czego?
Kto pomoże nam popchnąć sprawy do przodu?
Kto musi konsumować informacje i jak?
Kto może udzielać informacji i w jaki sposób?

Czasami jesteśmy w stanie odkryć już istniejące rozwiązania i wydobyć je na światło dzienne. Jeśli te wspierające systemy i praktyki działają wystarczająco dobrze, być może będziemy w stanie cofnąć się bez większej interwencji.

W innych przypadkach możemy zdać sobie sprawę, że istnieje zbyt wiele brakujących ogniw między istniejącymi rozwiązaniami i będziemy musieli zapewnić większe wsparcie w łagodzeniu tych niedociągnięć.

Potencjalnie możemy dojść do wniosku, że nie ma prawdziwej infrastruktury i będziemy musieli być jeszcze bardziej aktywni niż poprzednie dwie wersje. Jednak, co jest ważne, nie oznacza to, że musimy przejąć rządy. Może to być wczesny wskaźnik, ale wciąż nie wyryty w kamieniu.

Krok 2: Wspieraj infrastrukturę

We wszystkich trzech przypadkach przedstawionych w poprzednim kroku będziemy musieli teraz zapewnić pewne wsparcie, ale będzie się to znacznie różnić dla każdego z nich.

W pierwszym przypadku chodzi o wspieranie tej łączności, dopóki nie będzie w stanie utrzymać się sama. Nie jako właściciele, ale jako pośrednicy lub łącznicy.

Drugi przypadek przedstawia nieco większą złożoność, gdzie musimy wspierać łączność, ale musimy również pomóc w zdefiniowaniu działających modeli brakujących elementów. W tym przypadku to, czy jesteśmy właścicielami dzieła, czy tylko wsparcia, będzie zależeć od tego, czy mamy obecnych właścicieli, którzy mają więcej sensu niż my.

W ostatnim przypadku musimy mieć bardziej aktywną rolę, a czasami musimy być kierowcami. Tutaj jesteśmy właścicielami przynajmniej podczas procesu tworzenia idei, definiowania i uruchamiania. Ale niekoniecznie właściciele na dłuższą metę.

Krok 3: Posiadanie tylko tego, co ma sens, kiedy ma to sens

W tym miejscu musimy być naprawdę surowi, jeśli chodzi o to, czy bierzemy coś na własność, czy też cofamy się i pozwalamy zespołom przejąć odpowiedzialność.

W pierwszym przypadku jest łatwiej, bo mają już istniejącą infrastrukturę do wszystkiego. Pomagamy odblokować efektywność w tych relacjach i modelach pracy. Otóż to.

W drugim przypadku musimy mieć pewność, kto powinien być właścicielem rozwiązania. Product Ops może go tymczasowo posiadać, dopóki nie będzie istniał potrzebny zespół lub infrastruktura. W przykładzie z opiniami klientów, jeśli istnieje zespół ds. sukcesu klienta lub operacje klienta, o wiele bardziej sensowne jest, aby byli jego właścicielami. Utrzymywanie go w Operacjach na dłuższą metę nie miałoby sensu, a „walka” o niego byłaby zmarnowanym wysiłkiem.

W ostatnim przypadku, podobnie jak w przypadku poprzedniej opcji, musimy mieć jasność, czy rozwiązanie mieści się w zakresie Product Ops na dłuższą metę. Jeśli ma to sens, to Ops powinien go posiadać i rozwijać.

Jeśli jednak nie mieści się w zakresie zdefiniowanym dla operacji produktowych, powinniśmy być przygotowani na to, że odpuścimy, gdy będzie gotowy.

Z przyjemnością przekażemy go właścicielom, którzy mają największy sens. Powinniśmy wspierać ich w przejmowaniu własności. Ich sukces jest częścią naszego sukcesu i nie odpuszczania naszego „dziecka”.

To ważna część bycia aktywistą. Chcemy wspierać zespoły w rozwiązywaniu złożonych wyzwań, a następnie pomagać im w przygotowaniu się do posiadania tych rozwiązań w przyszłości.

Końcowe przemyślenia

Prawdopodobnie jedną z najtrudniejszych rzeczy związanych z objęciem stanowiska Product Operations jest świadomość, że będziesz pracować nad wieloma rzeczami, których potencjalnie nie będziesz mieć w przyszłości.

Chodzi o inwestowanie naszego czasu i wysiłków w stworzenie naszej najlepszej pracy, a następnie czasami przekazanie jej innym.

Nagrodą jest obserwowanie, jak inni odnoszą korzyści z Twojej interwencji i jak sami dojrzewają i ewoluują dzięki Twojemu wsparciu i coachingowi.

Stosując stopniowe podejście, jesteśmy w stanie lepiej zrozumieć nasz poziom interwencji i uniknąć noszenia zbyt wielu kapeluszy lub przyjmowania na siebie więcej, niż jesteśmy w stanie przełknąć.

Ostatecznie chcemy odblokować supermoce organizacji produktu. Chcąc mieć wszystko na własność, moglibyśmy początkowo wykazać się dużym wpływem, ale na dłuższą metę stalibyśmy się blokerami innowacji i ewolucji organizacji.