TL;DR

Wybieraj narzędzia, które odpowiadają na realne potrzeby zespołu produktowego, a nie odwrotnie
Najważniejsze potrzeby produktowców to komunikacja planów (roadmapy) i dokumentacja produktowa
Zacznij od prostych narzędzi (Excel, Google Docs) i dopiero później przechodź do bardziej wyspecjalizowanych
Narzędzia do roadmap powinny oferować różne widoki dla różnych odbiorców (zespół, leadership, marketing)
OKR-y powinny być punktem wyjścia dla roadmapy, a inicjatywy na roadmapie powinny kontrybuować do OKR-ów
Standaryzacja procesów i templatki są ważniejsze niż samo narzędzie
Przy zbieraniu feedbacku najważniejsze jest wyciąganie insightów, które mogą przekładać się na roadmapę

Wprowadzenie

Wybór odpowiednich narzędzi to jedno z kluczowych wyzwań w pracy zespołów produktowych. W podcaście Product Vision, Beata Kupiec, Principal Product Manager w Atlassian, dzieli się swoimi doświadczeniami na temat narzędzi używanych przez produktowców. Podcast prowadzony przez Olgę Springer i Tomka Tomaszewskiego zagłębia się w praktyczny wymiar pracy z narzędziami, które wspierają komunikację, planowanie i podejmowanie decyzji w zespołach produktowych.

Podejście do wyboru narzędzi dla produktowców

Identyfikacja potrzeb przed wyborem narzędzi

W podcaście Beata Kupiec podkreśla, że kluczowe jest zrozumienie potrzeb produktowców przed wyborem narzędzi:

„Narzędzia potrzebne są takie, jakie są potrzebne product managerom, to znaczy sami product managerowie muszą dojść do tego jakie są im potrzebne narzędzia. Jest wiele aspektów, które decydują o tym, jakie to powinny być narzędzia: jak duża jest firma, jak duży jest zespół product managerów, ile jest obszarów produktowych.”

Kryteria wyboru efektywnych narzędzi

Według Beaty, dobre narzędzie dla zespołu produktowego powinno być:

Proste w użyciu
Wspomagające pracę, a nie będące barierą
Niewymagające nadmiernego czasu na utrzymanie
Dopasowane do potrzeb komunikacyjnych zespołu
Integrujące się z innymi narzędziami (np. z Jirą)

Narzędzia do roadmapowania i komunikacji

Popularne narzędzia do tworzenia roadmap

Z podcastu wynika, że na rynku jest kilka wiodących narzędzi do roadmapowania:

Product Board – wykorzystywany przez Beatę w Brainly, z funkcjami do zbierania feedbacku i zarządzania eksperymentami
AHA – używany przez Beatę w Relativity, z możliwościami komunikacji roadmapy do marketingu
Jira Product Discovery – obecnie używany przez Beatę w Atlassian
Trello – prostsze narzędzie, które również może służyć do roadmapowania

Doświadczenia Beaty z Product Boardem w Brainly:

Przeprowadzili staranny research przed wyborem narzędzia
Narzędzie pomogło rozwiązać problem z widocznością planów eksperymentów
Umożliwiło efektywne zarządzanie eksperymentami produktowymi
Pozwoliło stworzyć system templatów do opisywania inicjatyw i eksperymentów
Stało się jednym „single source of truth” dla całej organizacji produktowej

Korzyści z używania dedykowanych narzędzi

Beata i prowadzący podkreślają kilka istotnych korzyści płynących z używania dedykowanych narzędzi do roadmapowania:

Wspólna baza danych – jedno źródło prawdy dla całej organizacji
Elastyczne widoki – możliwość dostosowania roadmapy do różnych odbiorców:
- Dla zespołów deweloperskich – skupione na delivery
- Dla liderów produktowych – zorientowane na outcomes
- Dla marketingu – skoncentrowane na funkcjach komunikowanych klientom
- Dla inwestorów – pokazujące strategiczny kierunek rozwoju
Lepszy przegląd zależności między różnymi liniami produktowymi
Efektywniejsze zarządzanie eksperymentami i ich mierzenie
Łatwe linkowanie i udostępnianie konkretnych widoków

Beata dzieli się obserwacją na temat komunikacji z liderami:

„Z mojego doświadczenia wygląda to tak, że leadership na końcu i tak chce mieć slajdy, i tak chce mieć wykresy, i tak chce mieć cyferki na slajdach, nie do końca patrzy na road mapy.”

Alternatywy dla początkujących zespołów

Beata zaznacza, że na początek można używać prostszych narzędzi:

„Z perspektywy czasu uważam, że Excel na sam początek naprawdę robi robotę. Jeżeli to nie jest jakaś duża firma, jeżeli nie musicie wydawać pieniędzy, albo nie macie budżetu, to nie ma sensu tego robić.”

Zarówno Beata jak i Tomek zgadzają się, że warto zacząć od prostych, elastycznych narzędzi jak Google Sheets czy Excel, zanim przejdzie się do bardziej zaawansowanych rozwiązań.

Relacja między OKR-ami a roadmapami produktowymi

Jak tworzyć strukturę celów i inicjatyw

Z podcastu wynika, że istnieje określona relacja między OKR-ami a roadmapami:

OKR-y jako wsad do roadmapy:
- Najpierw ustalamy cele do osiągnięcia
- Następnie planujemy inicjatywy, które pomogą je osiągnąć
- Cele wynikają ze strategii firmy
Struktura planowania:
- Strategia firmy → OKR-y organizacyjne → OKR-y produktowe → Inicjatywy
- Każda inicjatywa powinna kontrybuować do konkretnego celu
- Metryki sukcesu inicjatyw powiązane z miarami OKR-ów
Backlog opportunities:
- Product Manager stale identyfikuje problemy i opportunities
- Część z nich będzie kontrybuować do bieżących celów
- Pozostałe czekają w backlogu na odpowiedni moment
Wizualizacja na roadmapie:
- OKR-y powinny być widoczne na roadmapie
- Inicjatywy przypisane do konkretnych OKR-ów
- Możliwość filtrowania roadmapy według celów

Beata mówi wprost:

„Dla mnie OKR-y zawsze są wsadem do roadmapy, więc ja zaczynam od tego, co chcę osiągnąć.”

Praktyczny workflow pracy z celami

Doświadczenia z narzędziami do zarządzania OKR-ami:

Optymalne narzędzia:
- Google Sheets/Excel – najprostsze i najbardziej elastyczne rozwiązanie
- Dedykowane dashboardy w Jirze – automatyzacja raportowania
- Product Board – częściowa integracja OKR-ów z inicjatywami
Częste wyzwania:
- Zbyt mocne skupienie na narzędziu kosztem zrozumienia istoty OKR-ów
- Brak mierzalności celów lub nieodpowiedni okres pomiarowy
- Zależności między inicjatywami a celami nie są jasno określone
Dobre praktyki:
- Regularne przeglądy postępów w realizacji celów
- Zespoły powinny regularnie sprawdzać, czy są na dobrej drodze
- Budowanie roadmapy w oparciu o OKR-y, a nie odwrotnie

Narzędzia do zbierania i zarządzania feedbackiem

Metody zbierania feedbacku od klientów B2B i B2C

Narzędzia i podejścia różnią się w zależności od typu biznesu:

Dla biznesów B2B:
- Salesforce jako baza klientów i ich feedbacku
- Kategoryzowanie feedbacku i łączenie go z roadmapą
- Bezpośredni kontakt z klientem jest łatwiejszy
- Możliwość powiązania feedbacku z konkretnymi klientami
Dla biznesów B2C:
- Product Board z portalem Insights do zbierania feedbacku
- Wyzwania przy dużej skali – miliony użytkowników
- Inne podejście do analizy dużych ilości feedbacku
- Trudności z reprezentatywnością próby
Inne narzędzia:
- Dovetail – używany przez researcherów
- Jira Service Management – formularze dla klientów
- Airtable – lepsza wizualizacja i automatyzacja
- Formularze Google i Jira Core – dla wewnętrznego feedbacku

Przekształcanie feedbacku w insighty produktowe

Strategiczne podejście do zarządzania feedbackiem:

Wyzwania z nadmiarem danych:
- Trudność w utrzymaniu i kategoryzowaniu wszystkich feedbacków
- Ryzyko utworzenia ogromnej, nieużytecznej bazy danych
- Problem z wyciąganiem wartościowych wniosków
Rodzaje feedbacku:
- Zamówiony (np. ankiety, badania)
- Niezamówiony (np. media społecznościowe, obsługa klienta)
- Potrzeba uwzględniania obu typów
Proces wyciągania insightów:
- Kategoryzowanie feedbacku
- Identyfikacja powtarzających się problemów
- Przekształcanie w opportunities i problemy na roadmapie
- Wykorzystanie jako argumentów za konkretnymi inicjatywami

Tomek zwraca uwagę na istotne pytanie:

„Ten feedback czasem zbieramy i on się trochę kumuluje… Czy przechowywanie całego tego feedbacku ma sens, a nie większy sens ma to, że wyciągamy z tego jakiś insight?”

Rola Product Operations:
- Wsparcie w analizie i kategoryzacji feedbacku
- Wyciąganie insightów
- Szczególnie istotne przy dużej skali biznesu

Efektywna komunikacja w zespole produktowym

Standardyzacja i templaty komunikacyjne

Korzyści z używania templatów komunikacyjnych według Beaty:

Oszczędność czasu dla produktowców:
- Nie trzeba zastanawiać się, co powinno znaleźć się w dokumencie
- Wystarczy wypełnić przygotowane sekcje
- Skraca czas tworzenia dokumentacji
Ułatwiona komunikacja do leadership:
- Liderzy otrzymują informacje w spójnym, znanym formacie
- Łatwiej przyswajają wiedzę, gdy nie muszą przyzwyczajać się do różnych form prezentacji
- Umożliwia porównywanie statusów i postępów między obszarami produktowymi
Zapewnienie kompletności informacji:
- Wszystkie kluczowe elementy (metryki, odbiorcy, cele) są zawsze uwzględnione
- Eliminuje ryzyko pominięcia istotnych informacji

Przykład z Atlassian – narzędzie Atlas:

Wymusza zwięzłość poprzez limit znaków
Produkt Manager lub Engineering Manager musi syntetycznie opisać status projektu
Pomaga w komunikowaniu interesariuszom aktualnego stanu prac i potencjalnych ryzyk

Praktyki tworzenia dokumentacji

Tomek podkreśla znaczenie „live dokumentów” – dokumentów, które są narzędziem do ciągłej współpracy, a nie statycznymi bytami:

„Ja mam wrażenie, że cały czas jeszcze ludzie nie rozumieją koncepcji live dokumentów, że to jest trochę takie narzędzie pracy, że to nie chodzi o to, żeby stworzyć dokument, który jest stworzony i zapomniany, tylko to jest coś, czego można użyć jako narzędzie do ciągłej współpracy.”

Praktyczne wskazówki:

Do każdego spotkania jedna, ciągła notatka:
- Zawiera historię wszystkich poprzednich spotkań
- Przed spotkaniem dopisuje się nowe punkty do omówienia
- Oznacza się cel punktu (informacja, decyzja, dyskusja)
Wykorzystanie funkcji współpracy:
- Tagowanie osób (@imię) do konkretnych zadań
- Przypisywanie zadań w Google Docs
- Dodawanie komentarzy do fragmentów dokumentów
Organizacja dokumentów:
- Tworzenie „master dokumentu” z linkami do powiązanych dokumentów
- Umieszczanie linków do kluczowych dokumentów w nagłówkach kanałów Slack
- Używanie nazewnictwa ułatwiającego wyszukiwanie
Asynchroniczna współpraca:
- Wiele prac nie musi odbywać się na spotkaniach
- Dokumenty pozwalają na pracę przed i po spotkaniach
- Decyzje mogą być podejmowane w komentarzach

Wyzwania i pułapki w korzystaniu z narzędzi produktowych

Minusy zaawansowanych narzędzi

Tomek identyfikuje kilka ograniczeń narzędzi typu Jira Product Discovery:

Brak wsparcia dla pracy wizualnej:
- Trudność w tworzeniu struktur drzewiastych
- Ograniczenia przy wizualizacji Opportunity Solution Tree
- Linearna struktura utrudnia pokazanie zależności między elementami
Bariera wejścia:
- Wymaga czasu na zrozumienie i konfigurację
- Konieczność nauczenia się nowego interfejsu i logiki
- Kształtuje określony workflow, do którego zespół musi się dostosować
Ograniczona elastyczność:
- Trudność w szybkim modelowaniu procesów, które się zmieniają
- Czas poświęcony na ustawienie narzędzia może być stracony, jeśli proces się zmieni
Dodatkowe obciążenie komunikacyjne:
- Wprowadzenie kolejnego narzędzia tworzy barierę komunikacyjną
- Konieczność logowania się do dodatkowego systemu
- Różny interfejs od narzędzi, których zespół już używa

Koszty i uzasadnienie inwestycji

Wyzwania finansowe związane z wdrażaniem narzędzi:

Koszty licencji:
- Niektóre narzędzia wymagają opłaty za każdego użytkownika
- Przy większej liczbie produktowców może to być znaczący koszt
Sposoby uzasadnienia kosztów:
- Szczegółowy research z kosztami i korzyściami
- Darmowy okres próbny dla ograniczonej liczby użytkowników
- Kalkulacja oszczędności czasu i efektywności
Podejście stopniowe:
- Rozpoczynanie z darmowymi alternatywami
- Przejście na płatne rozwiązania, gdy korzyści są potwierdzone
- Elastyczne zarządzanie licencjami

Standaryzacja i procesy ponad narzędzia

Uczestnicy podcastu podkreślają znaczenie procesów i rytuałów:

Wyzwania ze słowem „proces” w organizacjach Agile:
- Słowo „proces” często budzi negatywne skojarzenia
- Organizacje zwinne obawiają się nadmiernej biurokracji
- Alternatywne określenie: „rytuały produktowe”

Tomek zauważa:

„W PMA nazywamy to rytuałami, żeby było ładniej. Rytuały produktowe.”

Priorytetyzacja procesów przed narzędziami:
- Najpierw ustalić, jak organizacja ma funkcjonować
- Zdefiniować kluczowe „eventy” produktowe
- Ustalić system komunikacji i współpracy
Stopniowe wdrażanie:
- Rozpoczynanie od prostszych narzędzi
- Sprawdzenie, czy proces działa, zanim zainwestuje się w droższe narzędzia
- Upewnienie się, że wszyscy rozumieją sens procesu
Typowe elementy procesu produktowego:
- Cykliczne spotkania dotyczące roadmapy
- Regularne przeglądy celów biznesowych
- Miesięczne i kwartalne przeglądy
- Jasna komunikacja z liderami i interesariuszami

Podsumowanie praktycznych wskazówek

Zacznij od prostych narzędzi (Excel, Google Docs) i dopiero gdy rozumiesz swoje potrzeby, przechodź do bardziej wyspecjalizowanych
Najpierw ustal cele (OKR-y), a potem zastanów się nad inicjatywami, które pomogą je osiągnąć
Wybieraj narzędzia, które pozwalają na elastyczne tworzenie różnych widoków dla różnych odbiorców
Korzystaj z templatów i standardów, aby usprawnić komunikację
W przypadku feedbacku, koncentruj się na wyciąganiu insightów, a nie tylko na zbieraniu danych
Pamiętaj, że proces i zrozumienie roli product managera są ważniejsze niż samo narzędzie

Ten artykuł jest częścią serii notatek z wartościowych webinarów i podcastów na temat zarządzania produktem. Powstał na podstawie podcastu Product Vision z gościnnym udziałem Beaty Kupiec, Principal Product Manager w Atlassian.

Tag: Product Board

Narzędzia dla produktowców: Lekcje od Principal PM z Atlassian #EN57