Strategia, budowa i rozwój produktu IT okiem Product Managera

Budowanie produktów, czy rozwój tych istniejących to złożone wyzwanie. Pomysłów jest dużo, a zasoby zawsze ograniczone (chociażby te ludzkie). Nie da się zrobić wszystkiego naraz. Co więcej, błędem byłaby realizacja każdego wpadającego do głowy pomysłu. Jak podejmować decyzje, analizować szanse rynkowe oraz czym zająć się w pierwszej kolejności? Jak ocenić, czy pomysł jest dobry, czy warto go wdrożyć i jaka jest w tym rola product managera?

Przemek Szustak. Product Manager, Chatbots w Tidio. Product Manager z mocnym doświadczeniem biznesowym. Wprowadził na rynek kilka swoich produktów, aby następnie seryjnie tworzyć nowe projekty dla jednego z polskich venture builder’ów. Obecnie związany z Tidio, gdzie zajmuje się rozwojem chatbotów. W wolnych chwilach żongluje, żegluje i gra na saksofonie.

Product flow i powiązane strategie wynikają zazwyczaj bezpośrednio z kultury organizacji. Zdarza się również, że rola Product Managera w zarządzaniu produktem w firmie pozwala na pełną dowolność w ustalaniu flow bieżącej pracy –w tym przypadku często ma być po prostu dowieziony efekt. Bez względu na to, czy podejście jest owocem kultury organizacyjnej, czy pozostaje w zakresie PM’a, aby osiągać dobre wyniki, warto zbudować proces. Proces, który umożliwi w sposób ciągły i powtarzalny rozwój produktu oraz jego wzrost.

Budowa produktu lub rozwój funkcjonalności

Aby zwiększyć szanse na sukces produktu (czy poszczególnych funkcjonalności), powinieneś patrzeć na jego budowę jak na proces, układ następujących po sobie etapów, na które składają się konkretne elementy.

Eksperymentuj w sposób ciągły

W tym artykule przedstawię framework oparty o Hypothesis Driven Development z gotowymi szablonami, które pomagają skupić się na tym, co ważne. To podejście pozwala myśleć o rozwoju nowych pomysłów, produktów i funkcjonalności – jako o serii eksperymentów mających na celu określenie, czy oczekiwany rezultat (outcome) zostanie osiągnięty. Proces jest powtarzany do momentu uzyskania pożądanego wyniku lub stwierdzenia, że ​​pomysł nie jest “viable”.

Podejście to korzysta z tablicy Kanban, która ułatwia zwinne zarządzanie produktem, a w połączeniu z dodatkowymi materiałami wspiera opracowywanie pomysłów z naciskiem na projektowanie rezultatów. Idealnie pasuje jako narzędzie Product Ownera, którego celem jest, aby wartość z produktu była jak najwyższa. Zakłada ono etapowe podejście składające się z kilku kroków – od pomysłu, przez wdrożenie po podjęcie decyzji co dalej. W dalszej części artykułu poznasz szczegóły każdego z etapów, którymi są:

1. Idea Box
2. Faza Discovery
3. Zarządzanie Backlogiem Produktu & Development
4. Najważniejsze – co dalej?

Szablon Kanban znajdziesz tu.

Trzymaj się zasad

Wizja, strategia czy plan działania to bez wątpienia elementy niezbędne, aby produkt odniósł sukces. Powinieneś być skupiony zarówno na najbliższych tygodniach (w scrumie np. na najbliższym sprincie), jak i zaszczepić w sobie podejście wizjonera. Jeśli zależy Ci na wzroście produktu, musisz znaleźć prawidłowy balans pomiędzy “small”, a “big picture”. Te trzy zasady będą w tym pomocne:

1. Realizuj strategię

Większość zadań podejmowanych w ramach pracy zespołów powinna wynikać bezpośrednio lub pośrednio ze strategii firmy. Sprawdzoną metodą jej realizacji, jest stosowanie OKR’ów (Objectives Key Results) czy OIT’ów (Objectives, Indicators & Tasks – pochodna OKR’ów stosowana m.in. w ZnanymLekarzu i Tidio, zaproponowana przez Lucjana Samulowskiego). Dobrą praktyką jest wyznaczenie z góry, ile czasu poświęcisz na realizację zadań strategicznych (np. 70%), oraz ile zostawiasz sobie przestrzeni na bardziej ad hoc pomysły, refaktoring, czy naprawę bieżących błędów (np. 30%).

2. Co za długo, to niezdrowo

Warto pamiętać, że w dynamicznym środowisku i w warunkach niepewności (witamy w świecie startupów!) bardzo łatwo o dezaktualizację priorytetów. To, co jest dzisiaj ważne, za dwa miesiące może nie mieć już żadnego znaczenia. Każdy pomysł, powinien mieć zdefiniowany czas, po którego upływie nie będziemy brać go więcej pod uwagę. Jeśli coś długo leży w backlogu albo nie zostało dobrze przemyślane, to znaczy, że nie jest to ważne. Nie bój się odkładać na bok nawet tych świetnie opracowanych pomysłów. Zawsze możesz do nich wrócić, jeśli przyjdzie taka potrzeba. Teraz skup się na tym co ważne.

3. Czasem mniej = więcej

Coraz częściej spotykam się z opinią, że multitasking nie działa. Podobno im mamy więcej zadań, tym więcej czasu poświęcamy na przełączanie kontekstu niż efektywne ich wykonywanie. O ile czynność nie jest mechaniczna, to zasadniczo potrafimy skupić się tylko na jednym wyzwaniu. Szczególnie jeśli jest to wyzwanie intelektualne. A przecież wyłącznie z takimi mamy do czynienia budując produkty online. Właśnie dlatego warto otwarcie narzucić sobie limity zadań w toku (limit WIP), uznając prawa natury, które skutecznie dają do zrozumienia, że nie da się rozdwoić, a zdolność bilokacji objawia się tylko w bajkach.

Wprowadzenie produktu krok po kroku – cztery etapy rozwoju

1. Definiuj problemy (Idea Box)

W pierwszej kolejności musisz dobrze rozumieć użytkowników i ich realne problemy. Jest to ważne, ponieważ dopiero ich punkt widzenia nadaje się do zestawienia z celami biznesowymi i strategią. Dzięki temu będziesz w stanie zweryfikować ich satysfakcję, wykrywać i naprawiać błędy, rozwijać poszczególne funkcjonalności, pracować nad retencją oraz najważniejsze – podejmować lepsze decyzje produktowe i biznesowe. Jest wiele sposobów, aby zasilać Idea Box w sposób ciągły.

Na pewno warto zaprojektować proces na pozyskiwanie feedbacku od klientów. Warto skupić się m.in. na automatyzacji np. poprzez zadawanie pytań przy okazji mierzenia CES (Customer Effort Score), czy NPS (Net Promoter Score). Nie obejdzie się również bez bardziej jakościowych badań, które pozwalają lepiej poznać zdanie użytkowników i zrozumieć jak nasz produkt pomaga im w ich biznesie, czy z jakimi problemami się borykają.

Jak więc dobrze zdefiniować problem i podjąć decyzję czy warto się nim zająć? Dostępnych jest wiele podejść. Moim ulubionym jest podchodzenie do każdego zagadnienia rozpisując:

• Zagadnienie (Problem) – nazwanie rzeczy po imieniu, czyli przedstawienie stanu faktycznego,
• Zasięg (Reach) – określenie, jakiej populacji ono dotyka,
• Wpływ na użytkowników (Customer Impact) – jak rozwiązanie problemu przełoży się na klientów,
• Wpływ na biznes (Business Impact) – czy uda się poprawić metryki biznesowe,
• Dowody (Evidence) – szczegółowe dane dotyczące problemu.

Czasem warto zastanowić się jeszcze nad kosztem bezczynności (Cost of Inaction), czyli co się stanie, jeśli nie rozwiążemy danego problemu. Może się wówczas okazać, że coś, co prawda jest pożądane, ale wcale nie jest konieczne.

2. Analizuj pomysły (Faza Discovery)

Zanim podejmiesz decyzję czy warto zbudować dany produkt, czy wdrożyć daną funkcjonalność warto spojrzeć na zagadnienie z szerszej perspektywy. Jest to ważne nie tylko dla Product Managera, ale przede wszystkim pomaga to w lepszym zrozumieniu tematu przez zespół developerski. To w końcu on będzie zajmował się implementacją i dalszym rozwojem produktu. Fajnym narzędziem sprawdza się tutaj Lean UX Canvas, albo Validation Field zaproponowany przez Tim’a Herbig’a.

Pozwala on ustrukturyzować proces walidacji pomysłu uwzględniając określenie metryk sukcesu oraz jeszcze na tym etapie, podjęcia decyzji dotyczących następnych kroków. Warto zastanowić się również nad trzema scenariuszami – pozytywnym, neutralnym i negatywnym. Czyli co będzie świadczyło o tym, że eksperyment zakończył się w ten, a nie inny sposób i co z tym dalej zrobisz.

Wstępna analiza produktu i jego szans rynkowych wygląda następująco:

Szablon Validation Field znajdziesz tu.

3. Pokaż to światu! (Product Backlog, Development)

Tak naprawdę, wszystko co robimy w trakcie budowania czy rozwijania produktu to eksperymenty. Proof of Concept, MVP, wersja pierwsza, druga – możesz nazwać to jak chcesz. Bez względu na terminologię, to czym się zajmujesz, może przynieść efekt zgodny z założeniami, jak i odwrotny. Natomiast każdy wynik będzie dobry, o ile można się z niego czegoś nauczyć.

Żeby się nauczyć, trzeba zaszczepić w sobie eksperymentalne podejście, a projektując nowe produkty czy funkcjonalności, wiedzieć co chce się osiągnąć. Opracowane wcześniej zagadnienia bardzo łatwo przełożyć w gotowy do wdrożenia eksperyment. Wiesz już, co chcesz osiągnąć, jak to zrobić i co będzie świadczyło o tym, że Ci się udało. Pora więc przejść do działania.

W pojedynkę jednak nic nie zdziałasz. Warto angażować zespół w każdy etap procesu – co dwie (lub więcej) głowy to nie jedna! Wykorzystaj scrumowy Refinement, aby szczegółowo rozpisać zadania do wykonania (tutaj kilka podpowiedzi od Piotra Górajka, dlaczego warto wylać trochę potu na treningu, aby zaoszczędzić krwi na sprintowym ringu). Forma dowolna. Możesz wykorzystać te najbardziej popularne jak User Stories, czy Jobs To Be Done wsparte szczegółowymi kryteriami akceptacji, jak i te mniej znane, np. techniczno-poetycki język Gherkin służący do tworzenia przypadków testowych, który wywodzi się z podejścia BDD (Behaviour Driven Development).

Praktyka pokazuje, że najlepiej sprawdzają się formy łączone. Nie ograniczaj się do jednego podejścia. Mieszaj formy i znajdź tę, która najlepiej się sprawdza. Poniżej przykład jednej z funkcjonalności wdrażanej ostatnimi czasy w Tidio w ramach eksperymentu, który miał zwiększyć adopcje chatbotów (połączenie User Stories oraz Gherkin/BDD):

Zawsze staraj się trzymać dobrze opracowaną górę backlogu. Jeśli sam backlog jest dla Ciebie zbyt mało czytelny, nie bój się stworzyć czegoś na zasadzie szkicu następnego sprintu (np. Draft Sprint) i zadbaj o to, żeby nie pozostawiał zbyt wielu pytań. Na tym etapie wszystkie zadania do wykonania powinny być jasne i czytelne, a oczekiwane rezultaty znane. Takie podejście pomaga również w utrzymaniu transparentności tego, co powstanie w najbliższej przyszłości. Czym zatem zająć się w pierwszej kolejności? Co jest najważniejsze?

Jak to bywa w IT – to zależy. Jest przynajmniej kilka podejść, z których możesz skorzystać wyznaczając priorytety m.in. analiza MoSCoW, czy Kano Model. Sprawdź, który sprawdza się w Twoim przypadku najlepiej i skorzystaj z niego przy podejmowaniu decyzji co dalej. Poniżej przykład analizy MoSCoW zaproponowanej przez Piotra Latoszka uwzględniające zestawienie zmapowanej konkurencji, opinii zespołu oraz zgłoszeń użytkowników:

Szablon analizy MoSCoW (konkurencja, zespół & użytkownicy) znajdziesz tu.

Dalej to już stricte scrum’owy proces. To na co warto zwrócić uwagę, to kontrybujące bezpośrednio do strategii cele sprintu. Przyrost powinien odzwierciedlać zaplanowane w OKR’ach/OIT’ach zadania do wykonania. W końcu bez strategii nie ma rezultatów, prawda?

4. Mierz i ucz się (Done – co dalej?)

“Work is never done”. Szczególnie znajduje to swoje odzwierciedlenie w kontekście rozwijania produktów i zwiększania ich potencjału. O ile widzimy wzrost, najprawdopodobniej będziemy mieli, co robić (zakładając, że cele biznesowe są realizowane). Iteracyjne podejście nie kończy się na wypuszczeniu danej funkcjonalności czy po przeprowadzeniu danego eksperymentu. To dopiero początek.

Najważniejsze jest to, czy czegoś dzięki temu się nauczyłeś. Czy będziesz w stanie wykorzystać nowe informacje na swoją korzyść? Czy Twoje decyzje będą oparte nie tylko na intuicji, a również na danych? To w tym miejscu zataczamy krąg, jeśli chodzi o naszą pętlę sprzężenia zwrotnego (buduj – mierz – ucz się).

Jeśli zakończony eksperyment ma pozytywny wynik, możesz iterować go dalej. Nie osiadaj na laurach. Optymalizuj. W takim przypadku warto wyciągnąć wnioski, przegadać temat z zespołem i spróbować wycisnąć z niego jeszcze więcej.

Co jednak zrobić jeśli wynik jest negatywny? Wróć do podstaw. Zastanów się, czy dobrze zaadresowałeś problem. Czy postawiłeś słuszne hipotezy. Czy udało Ci się zebrać przydatne dane ilościowe i jakościowe. Wróć do Idea Box. Może dany problem da się rozwiązać w inny sposób? A może wystarczy kilka kosmetycznych zmian i wyniki będą zupełnie inne? Jeśli mimo to, nie udało Ci się zebrać żadnych konkretnych, realnych danych, które pomogą ulepszyć produkt – zmień swoje podejście. Nie da się robić w kółko tego samego i oczekiwać innych rezultatów. Eksperymentuj z innymi podejściami. Poproś o pomoc. Co dwie głowy to nie jedna.

Strategia produktu, usługi lub funkcjonalności IT – podsumowanie

Dobrze wdrożony proces powinien wspierać odkrywanie tego jak dowozić wartość dla użytkowników w taki sposób, abyśmy mogli realizować nasze cele biznesowe. I jak robić to w sposób ciągły.

Mam nadzieję, że chociaż część z wymienionych wskazówek w tym artykule pomoże Ci w lepszym generowaniu pomysłów na rozwój produktu i będą wsparciem w pozyskiwaniu insightów, które pozwolą Ci rosnąć. Nie staraj się jednak robić wszystkiego na raz. Wdrażanie procesów również wymaga podejścia iteracyjnego. Wybierz jedną rzecz i ją przetestuj. Zaproponowany framework sprawdza się najlepiej przy dużych wyzwaniach wymagających holistycznego podejścia.

Zarządzanie produktem to szereg procesów, narzędzi i potrzebnych umiejętności. Jeśli korzystasz z innych frameworków lub uważasz, że któryś z zaproponowanych elementów mógłby działać jeszcze lepiej – daj znać w komentarzu. Zapraszam do dyskusji.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z