Jak zmierzyć zdrowie produktu? Skuteczne spotkania z Zarządem. Zarządzanie produktami B2B vs B2C
Wydanie #24
Cześć 💙
Umiejętność zrobienia kroku wstecz, spojrzenia z perspektywy osoby trzeciej i wejścia w świat potrzeb użytkowników to proste praktyki stosowane przez zespoły produktowe na co dzień. Pomagają nam sprawniej działać. Identyfikujemy stan obecny oraz cel, który chcemy osiągnąć. Łączymy kropki, chwila na oddech i ruszamy.
Już niedługo kolejne kropki pojawią się na naszej mapie podróży. Tymczasem zapraszamy Cię do kolejnego wydania produktowego newslettera :)
Zaopatrz się w notatnik 📰 i swój ulubiony trunek 🍺🍸.
Życzymy dobrej lektury,
Grzegorz i Kamil
W dzisiejszym wydaniu między innymi:
✅ Produktowa prasówka
✅ Delivery: Czego nie robić podczas refinementu?
✅ Analityka: Jak zmierzyć zdrowie produktu?
✅ SaaS: Skuteczne spotkania z Zarządem
✅ Specjalizacja: B2B vs B2C Product Management
1️⃣ Produktowa prasówka
Wyselekcjonowane publikacje wokół produktu z ostatniego tygodnia:
2️⃣ Czego nie robić podczas Refinementu?
Mimo, iż Backlog Refinement nie należy do ceremonii Scrumowych to jest wg mnie najważniejszym spotkaniem podczas całego sprintu. Proces doskonalenia pozwala lepiej zrozumieć elementy, które znajdują się w Backlogu. Nie jest to najłatwiejsze spotkanie, dlatego tym bardziej warto pamiętać o kilku antywzorcach.
#1 Nie przychodź z rozwiązaniami
Przyjdź z kontekstem i problemami do rozwiązania. Z szansami do zbudowania przewagi konkurencyjnej. Jeszcze lepiej jeśli będą to cele do osiągnięcia, które jasno wpisują się w kontekst i strategie produktu oraz organizacji. Zacznij od “Dlaczego chcemy to zrobić?”, “Dlaczego to dla nas ważne?”
#2 Wykreśl ze słownika słowo “niemożliwe”
Przychodzimy z bardzo ambitnym tematem do zespołu i trafiamy na mur. Mamy wokół nas osoby, które potrafią i chcą rozwiązywać trudne zagadnienia, więc zacznijmy od prostego pytania “Jakie aspekty sprawiają, że jest to niemożliwe?”, “Jak inaczej możemy to rozwiązać?”
#3 Zrezygnuj z estymacji w godzinach (jeśli możesz)
Podczas refinementu chcemy ustalić złożoność zagadnienia. Aby zminimalizować ryzyko pomyłki oraz ustalić velocity zespołu warto estymować w Story Pointach. Po kilku sprintach zobaczymy średnią “prędkość” zespołu, co pozwoli nam w przyszłości lepiej planować ilość zadań do wielkości i umiejętności zespołu. Docelowo będziemy “dowozić” więcej wartości, a co za tym idzie - mniej historyjek będzie przechodzić na kolejne sprinty.
#4 Nie wpadnijcie w pętlę dyskusji wokół technologii
Zasada jest prosta - Określamy “Dlaczego to robimy?” oraz “Jakie rozwiązanie zastosujemy?”. Warto nakreślić także zarys “Jak to rozwiążemy?”, ale refinement nie jest momentem na szczegółową dyskusję na ten temat. Bardzo pomocne będą okazjonalne “Spikes”, gdzie niewiadome możecie w krótkim czasie zbadać i “na brudno” sprawdzić, czy zadziałają. Na spotkaniach zawsze ktoś powinien być moderatorem.
#5 Nie rozbijaj historyjek na obszary technologiczne
Każda historyjka użytkownika powinna wnieść nową wartość do produktu z perspektywy jej odbiorcy. Umiejętność podzielenia dużego zagadnienia na małe kawałki, przyniesie w dłuższym czasie więcej korzyści. Pamiętaj, że posiadając auto bez kół, nadal nie dotrzesz z punktu A do B.
#6 Nie wszystkie zagadnienia w Backlogu to User Stories
Backlog ma posiadać wszystkie elementy niezbędne do zbudowania wartościowego produktu. Nie wszystkie muszą być w formie historyjek użytkownika i to jest OK. Najważniejsze to, aby zespół rozumiał co ma zrobić, dlaczego i jak.
Keep reading with a 7-day free trial
Subscribe to 💜 PRODUCT ART 💜 to keep reading this post and get 7 days of free access to the full post archives.