Co właściwie w tym produkcie nie działa?
Czyli kilka grzechów głównych
W zeszłym tygodniu dotknęliśmy product managementu. Mówiliśmy o tym, że nie zawsze wygląda tak, jakbyśmy sobie tego wszyscy życzyli. Teraz pora to uszczegółowić. Co właściwie może pójść nie tak? Nie narzekamy przecież na brak ładnej roadmapy czy super skonfigurowanej Jiry...
Widzimy głębszy problem: w wielu firmach obszar produktu istnieje tylko z nazwy. Mamy „product managera”, ale bez strategii, bez discovery, bez realnego wpływu. Mamy zespół tech, który koduje, ale nikt nie wyjaśnił mu, po co. Te grzechy konkurują o podium:
1. Produkt nie zaczyna się od użytkownika
Produkt ma sens tylko wtedy, gdy rozwiązuje realne problemy użytkowników. Dlatego proces produktowy powinien opierać się na ich zrozumieniu – na badaniach, testach, analizie zachowań. Nie zaczynamy pracy, póki nie mamy choć silnej hipotezy: jaki i czyj problem rozwiązujemy. Potrzebujemy więc rozmawiać z użytkownikami, testować różne opcje, patrzeć na dane i dopiero w konsekwencji podejmować decyzje. Bo to użytkownik powinien być punktem odniesienia dla wszystkich działań produktowych.
A w wielu firmach tak po prostu nie jest. Decyzje podejmują prezesi, zarządy, szefowie marketingu. PM dostaje gotowe pomysły do wdrożenia, zamiast weryfikować, czego faktycznie potrzebuje użytkownik. Albo słyszymy, że trzeba zrobić DOKŁADNIE TO i mamy jako PM wymyślić, jak to zrobić, żeby zadziałało dla użytkownika.
Co możesz zrobić? Konfrontuj wizję zarządu z rzeczywistością użytkownika. Pokazuj wywiady, analizy, testy, mierz wpływ dotychczasowych zmian i udowadniaj, że produkt nie jest robiony dla CEO, tylko dla ludzi, którzy z niego korzystają. A jeśli jako pojedynczy PM nie masz visibility na CEO i zarząd, wyposaż swojego szefa w karty (dane), które pozwolą mu dobrze grać. Nasze ulubione pytanie: a skąd wiemy (Panie Prezesie), że x to jest realny problem użytkownika?
2. Strategia? A komu to potrzebne?
Bez przemyślanej wizji - dryfujemy. Zamiast priorytetów mamy koncert życzeń. A proces produktowy musi mieć kierunek. Musi być jasne, dokąd z produktem idziecie. Bez strategii backlog staje się listą przypadkowych pomysłów, a decyzje są podejmowane chaotycznie. PM powinien mieć jasno określoną strategię – wiedzieć, w jakim kierunku rozwijać produkt i jakie decyzje mają sens w dłuższej perspektywie. Discovery powinno być stałym elementem procesu, a backlog powinien odzwierciedlać priorytety biznesowe i potrzeby użytkowników. Bo żeby utrzymać motywację i atmosferę do kombinowania w zespole - ten zespół musi wiedzieć, w którą stronę idzie.
Często tak... nie jest :) Widzimy brak strategii, backlog jako śmietnik, roadmapę jako zbiór „wrzutek” od różnych interesariuszy. W wielu przypadkach PM nie ma narzędzi, by powiedzieć „nie” albo „nie teraz”, więc backlog puchnie, a zespół działa chaotycznie.
Co z tym robić? Regularnie prowadzić discovery, ustalić jasne zasady priorytetyzacji i zakomunikować je organizacji. Pokazywać, które funkcje są kluczowe i dlaczego, oraz decydować na podstawie danych, a nie siły przebicia interesariuszy.
3. Dostarczamy, ale się nie uczymy
Wdrażamy funkcjonalności, ale ich nie sprawdzamy. Brakuje testowania, rozmów z użytkownikami, refleksji. A przecież każda iteracja to szansa na weryfikację hipotezy, którą mieliśmy. Jeśli nie mierzymy efektu, to na podstawie czego określamy wartość naszego delivery?
A to ważne, bo produkt to nie jednorazowy projekt – to ciągły proces. Iteracyjność pozwala szybko reagować na błędy i uczyć się na podstawie realnych danych. Nowe funkcjonalności powinny być wdrażane w małych porcjach, sprawdzane w warunkach produkcyjnych, a ich wpływ analizowany. Więc nie, wdrożenie to nie koniec pracy. Wprowadzaj A/B testy, analizuj dane, rozmawiaj z użytkownikami. Miej odwagę przyznać, że coś nie działa i poprawić to, lub usunąć.
4. PM jako lider? Czy stenotypista?
Product Manager to nie task master. To lider, który w zamyśle rozumie dane, użytkownika i kontekst. Który wyznacza kierunek i bierze za to odpowiedzialność. Który dba o to, żeby praca zespołu nie szła w piach. Zespół potrzebuje kompasu – nie kogoś, kto tylko przepisuje pomysły do Jiry.
PM nie powinien być osobą realizującą cudze pomysły, ale liderem, który kształtuje kierunek rozwoju produktu. Który podejmuje decyzje, zarządza priorytetami i dba o to, by produkt faktycznie odpowiadał na potrzeby użytkowników. Nie zawsze mamy na to wpływ, ale walczmy dzielnie, by nie zostać managerem backlogu. Budujmy autorytet, podejmujmy decyzje i brońmy naszych racji przed tymi, którzy mają odmienne zdanie.
5. Product Manager nie ma swojego miejsca
W idealnym świecie PM działa strategicznie, bada użytkowników, priorytetyzuje zadania i iteracyjnie rozwija produkt. W rzeczywistości często musi walczyć z chaosem, presją stakeholderów i brakiem danych. Dobry PM koryguje te odstępstwa i wprowadza zmiany, które pozwalają budować lepsze produkty.
To taki nasz manifest trochę ;) Chcemy produktowców osadzonych w organizacjach. Z wpływem, słyszanych, a nie tylko odbijanych między działami. Dlatego właśnie piszemy ten newsletter – żeby mówić o realnych problemach i wspierać tych, którzy próbują z nimi coś zrobić.
Dlatego zostań z nami, jeśli chcesz robić produkt świadomie, skutecznie i z sensem :)
Agnieszka i Marcin


