Poznaj Swoje Prawa, czyli jak nie wpaść w pułapki czyhające na Product Managera

4
2

Kiedy wyruszamy w podróż często jesteśmy tak podekscytowani, że nie myślimy o tym, jakie prawa nam przysługują w przypadku problemów z lotem lub bagażem. Denerwujemy się, kiedy nasz lot jest opóźniony, ale rzadko który pasażer wie, że może mu wtedy przysługiwać rekompensata. Podobnie jest z pracą właściciela produktu. Zaangażowanie w pracę przy produkcie oraz napięte terminy potrafią przysłonić główne zadanie, zarządzanie produktem. Po przeczytaniu tego artykułu dowiecie się, jak nie stracić kontroli nad produktem oraz jak przejść przez wszystkie etapy jego tworzenia bez wpadek i frustracji.

Właściciel vs Kierownik Produktu

Jakie cechy odróżniają Właściciela Produktu od Kierownika Produktu? Poza wizją, wiedzą i organizacją pracy, niezbędna jest asertywność i pewność siebie. Nie chodzi tu o zwyczajne mówienie „nie”, ale o myślenie strategiczne i szukanie realnej, długoterminowej wartości dla stakeholderów (interesariuszy) i użytkowników. Jeśli jesteś w stanie przewidzieć czego Twój interesariusz będzie potrzebował za 12 miesięcy i potrafisz go przekonać do zainwestowania w skalowalne rozwiązanie; jesteś na dobrej drodze do tworzenia produktów, z których będziesz w przyszłości dumny. Wydawałoby się to oczywiste, ale w dobie ciągłych zmian na rynku bardzo trudno jest uniknąć tzw. „łatania dziur”. A to jak wiadomo „pali” Story Pointy i nie pozwala skupić się na skalowalnym rozwiązaniu. Kolejnym krokiem jest zbudowanie zaufania do decyzji, które podejmujesz. Feedback jest ważny, ale to Ty jako właściciel produktu podejmujesz finalne decyzje. (You’ve got the power!) Przystępując do pracy nad nowym produktem warto zapamiętać te podstawowe prawa, które przysługują właścicielowi produktu i starać nie uginać się pod naciskami.

Ustalenie celów

Pierwszym etapem tworzenia nowego produktu jest ustalenie jego celów i KPI (Key Performance Indicator) oraz upewnienie się, że wszyscy interesariusze się z nimi zgadzają. Cele danego produktu powinny pomagać osiągnąć długoterminowe KPI produktu. W przypadku serwisu gromadzącego prawa pasażerów Know Your Rights (Poznaj Swoje Prawa) celem jest edukacja pasażerów lotniczych oraz umożliwienie w łatwy i szybki sposób znalezienia najważniejszych informacji na temat tego, co zrobić w przypadku opóźnionych lub odwołanych lotów lub problemów z bagażem. Dlaczego? Ponieważ badania z użytkownikami wykazały, że pasażerowie nie mają takiej wiedzy, a linie lotnicze i lotniska nie udzielają takich informacji w przystępny sposób. Kolejnym KPI dla „Poznaj Swoje Prawa” to optymalizacja pod kątem SEO, a więc metryką mierzącą sukces produktu będzie zwiększenie konwersji z ruchu organicznego. Po dokładnej analizie SEO wybrane zostały grupy słów kluczowych, na których opiera się serwis.

Kick off meeting

Na kick off meeting zapraszamy najważniejszych interesariuszy, którzy będą mieli wpływ na kształt produktu. W przypadku serwisu „Poznaj Swoje Prawa” głównym interesariuszem jest marketing ze względu na cel – SEO. Na kick offie warto ustalić kto będzie brał udział w cyklicznych spotkaniach. Pozostali interesariusze mogą otrzymywać podsumowania spotkań drogą mailową. W ten sposób wszyscy są na bieżąco z postępami w projekcie, a my unikamy rozproszenia informacji i zbyt wielu uczestników na spotkaniach. Kluczowym elementem spotkania rozpoczynającego projekt jest agenda. W agendzie powinny się znaleźć opis projektu, dane na temat produktu, podsumowanie konkurencji oraz plan działań. Przed spotkaniem warto dobrze przygotować się na ewentualne pytania.

Wireframing

Kiedy omawiamy rozwiązania dotyczące danego produktu dobrze jest przedstawiać je na wireframe’ach. Warto przygotować kilka propozycji, aby interesariusze wyrazili swoje stanowisko. Krótkie omówienie każdego z pomysłów pozwoli uniknąć dodatkowych pytań i usprawni spotkanie. Dla każdego z rozwiązań warto przygotować „za” i „przeciw”, które pokazują proces myślowy i skracają proces decyzyjny. Niezależnie od programu, którego używacie do prototypowania ważne jest, aby wireframe był przekazany w formacie, do którego każdy z interesariuszy ma dostęp. Ja najczęściej zapisuję i przesyłam swoje wireframe’y w PDF. Jeżeli produkt jest skomplikowany i wymaga wielu wireframe’ów polecam korzystanie z prostych narzędzi takich jak Balsamiq, który pozwala w szybki sposób naszkicować rozwiązanie. Na dalszym etapie warto przygotować klikalne prototypy.

Praca ze stakeholderami – ustalenie założeń

W pracy Product Managera bardzo ważna jest umiejętność słuchania i wyciągania wniosków. Każdy z uczestników spotkania powinien mieć szansę wypowiedzi. Dlatego też w cyklicznych spotkaniach powinny brać udział osoby o różnych specjalizacjach. W ten sposób mamy holistyczny obraz produktu i jesteśmy w stanie uniknąć potencjalnych zagrożeń. Przy każdym projekcie pojawiają się różne opinie na temat designu i rozwiązania problemów użytkowników. Czasami dochodzi do różnicy zdań lub pomysłów, które się wykluczają.

Właściciel produktu powinien wyczuć moment, w którym należy się zatrzymać, podsumować dotychczasowe ustalenia, przypomnieć główne cele projektu i zaproponować rozwiązanie. W ten sposób projekt posuwa się do przodu, a my nie tracimy czasu na zbyt długie dyskusje. Sprzyja to też atmosferze spotkań.

Copywriting

Serwis „Poznaj Swoje Prawa” to kopalnia wiedzy na temat praw pasażerów lotniczych. Ponad 14 000 słów dla 15 konkretnych przypadków. Przed rozpoczęciem pisania niezbędna jest analiza SEO, czyli jakie frazy użytkownicy wpisują w okno wyszukiwarki oraz współpraca z innymi działami np. Działem Obsługi Klienta, który posiada kopalnię wiedzy na temat najczęstszych zapytań klientów. W firmie AirHelp pracuje wielu prawników, ale spisanie takiej ilości wiedzy i przedstawienie jej w przystępny sposób to nie lada wyzwanie. Nad treściami stron „Poznaj Swoje Prawa” pracowały dwie copywriterki oraz reprezentantka działu prawnego. W celu stworzenia treści, które będą pasować do projektu, copywriter powinien uczestniczyć w spotkaniach dotyczących layoutu oraz designu strony. Dzięki temu pisanie treści może dziać się równolegle z projektowaniem strony.

Przykładowo, serwis „Poznaj Swoje Prawa” zawiera przydatne porady na temat czterech głównych problemów pasażerów lotniczych: opóźniony lot, odwołany lot, odmowa przyjęcia na pokład, problemy z bagażem. Porady są zwięzłe, aby użytkownik mógł od razu dowiedzieć się najważniejszych informacji bez konieczności wczytywania się w szczegóły. Kiedy copywriterka zaczęła pisać podpunkty okazało się, że każdy z nich ma kilka zdań. Zdecydowaliśmy się na rozwijane podpunkty, co oznaczało, że treść musiała być przygotowana następująco: jedno zdanie podsumowujące cały podpunkt (poradę) oraz bardziej szczegółowy opis po rozwinięciu podpunktu. Gdyby copywriterka nie brała udziału w spotkaniach projektowych, treść nie zostałaby przygotowana w odpowiedni sposób. To jeden z wielu przykładów na to, jak ważna jest synchronizacja procesu tworzenia treści z layoutem strony.

Logika

Jednym z najważniejszych elementów stron „Poznaj Swoje Prawa” jest logika wyświetlania treści. Założeniem strony jest serwowanie treści dopasowanej do sytuacji pasażera.

Po wielu godzinach spędzonych na projektowaniu UX dla wyświetlania tych informacji, zdecydowaliśmy się na dwustopniowy formularz.

Krok 1

Pierwsza część formularza: Kategoria problemu

Krok 2

druga część formularza
Druga część formularza: Podanie szczegółów lotu

Pierwszą informacją, którą podaje użytkownik jest sytuacja, w której się znalazł. Na następnym kroku użytkownik jest proszony o podanie bardziej szczegółowych informacji na temat trasy lotu oraz linii lotniczej. Dzięki temu jesteśmy w stanie skierować pasażera do konkretnej sekcji na jednej z podstron „Poznaj Swoje Prawa”, która zawiera praktyczne porady oraz opis praw dopasowanych do konkretnej sytuacji. Badania z użytkownikami pokazały, że niektórzy użytkownicy nie lubią wypełniać formularzy i od razu scrollują w dół strony. Dlatego poniżej formularza znajdują się boxy z ogólną informacją o czterech najbardziej popularnych sytuacjach. Po wyborze sytuacji użytkownik przechodzi do podstrony ogólnej np. o opóźnionych lotach. Na tej stronie znajdzie porady oraz informacje o prawach przysługujących w przypadku każdej trasy lotu np. loty w Unii Europejskiej, loty w Stanach Zjednoczonych lub loty międzynarodowe. Ostatnim poziomem podstron są strony na temat poszczególnych praw; prawa w Unii Europejskiej, prawa w Stanach Zjednoczonych i prawa międzynarodowe, które opisuje Konwencja Montrealska. Te podstrony zawierają najwięcej treści, dlatego postanowiliśmy je ułożyć w przystępnej formie pytań i odpowiedzi. Odpowiedzi są widoczne po kliknięciu w pytanie, dzięki czemu czytelnik może przeskanować wszystkie zagadnienia bez konieczności scrollowania całej strony.

Design

Kiedy wszystkie decyzje UX są już podjęte a treści częściowo przygotowane, zaczynamy proces projektowania strony. Design tego typu serwisu powinien pomagać w odbiorze treści, dlatego designerzy chcieli zachować jak największą prostotę i czystość stron. Ikony sprzyjają w odbiorze dużej ilości treści, dlatego zastosowaliśmy je na stronie głównej. Porady zostały wypunktowane, aby zaznaczyć ich kolejność. W celu zwiększenia zasięgu strony zastosowaliśmy również obrazki do share’owania na Facebooku i Twitterze, które zawierają ciekawe informacje na temat praw pasażerów. Jeśli chcesz, aby Twój produkt miał dobry design i jednocześnie ufasz swojemu designerowi to nie pozwól, aby Twoje zaangażowanie ograniczało jego wolność.

Zachęcenie do share’owania

Testowanie z użytkownikami

Po zaprojektowaniu strony przeprowadziliśmy testy z potencjalnymi odbiorcami na klikalnych prototypach. Pasażerowie lotniczy dostarczyli nam cennej wiedzy na temat swoich doświadczeń na lotniskach i jeszcze cenniejszy feedback na temat zaprojektowanych przez nas prototypów. W celu uzyskania najważniejszych informacji w szybkim czasie zastosowaliśmy zasadę testów z pięcioma użytkownikami

Po wprowadzeniu feedbacku od pasażerów i akceptacji stakeholderów strona jest gotowa do developmentu.

Development

Zanim karty dotyczące tak dużego projektu trafią do Sprintu, zespół developerów powinien poznać projekty. W przypadku stron „Poznaj Swoje Prawa” komunikacja z programistami rozpoczęła się na wczesnym etapie wireframe’ów, co pozwoliło sprawnie rozpisać projekt w Jirze. Kiedy powstał pierwszy prototyp, developerzy zostali zaproszeni na demo, na którym  właściciel produktu zaprezentował projekt a oni zadawali pytania i proponowali rozwiązania. W projektach z dużą ilością treści ważne jest, aby zarówno treści jak i design były finalne w momencie kiedy developer zaczyna pracować nad projektem. Drobne zmiany (najczęściej przed samą publikacją serwisu) są nieuniknione chociażby ze względu na ciągłą ewolucję produktu, ale powinno być ich jak najmniej. Jednym z najbardziej skomplikowanych elementów stron „Poznaj Swoje Prawa” pod kątem developmentu jest logika formularza w Jumbotronie. Ze względu na dużą ilość treści bardzo ważna okazała się również decyzja o narzędziu do zarządzania treścią. Aby podjąć taką decyzję należy odpowiedzieć sobie na pytania: kto będzie edytował treści, w ilu językach będzie funkcjonowała strona oraz jak wiele elementów będzie znajdowało się w blokach tekstowych.

Wdrożenie

Wdrożenie strony na produkcję powinno być już formalnością. Jeśli zaangażowanie stakeholderów w projekt jest duże, warto wysłać wersję testową i dać kilka dni na przesłanie uwag. Po wprowadzeniu uwag oraz naprawie drobnych bugów (przy takiej ilości treści ciężko ich uniknąć), zespół może wcisnąć „zielony guzik” i pokazać swoje dzieło światu.

Marketing

Promocja jest bardzo ważna przy tego produktach, których odbiorcą jest osoba zewnętrzna. Strategia marketingowa powinna być planowana już na etapie tworzenia produktu. Przy współpracy z marketingiem bardzo pomaga stworzenie „briefu produktowego” z informacjami na temat celów, zasięgu, grupy docelowej, struktury produktu. Taki dokument tworzy Product Owner, którego uczestnictwo w pierwszych spotkaniach dotyczących strategii marketingowej jest mile widziane.

Co dalej?

Wypuszczenie produktu i sprawdzanie wyników w Google Analytics to za mało. Teraz zaczyna się prawdziwa zabawa, czyli optymalizacja. Odpowiednie trackowanie produktu pozwala sprawdzać zachowania użytkowników, a tym samym optymalizować produkt. Pamiętaj o stworzeniu eventów dla elementów, które chcesz mierzyć oraz heatmap, które pokażą Ci jak zachowują się użytkownicy.

Proces tworzenia produktu można porównać do biegu z przeszkodami. Poza doświadczeniem i zbadaniem potrzeb użytkowników, ogromnie ważna jest intuicja oraz wytrzymałość. Czasami szybka decyzja o zmianie kierunku myślenia potrafi obrócić produkt o 180 stopni. I najważniejsze… Product Owner nie musi wiedzieć wszystkiego. Czasami warto przyznać się do niewiedzy i cofnąć się krok w tył niż ślepo podążać nadanym na początku kierunkiem. Zaufaj swojemu instynktowi i twórz produkty, z których będziesz dumny.

 

 

4 KOMENTARZE

  1. Ze smutkiem zauważam brak testów po/w trakcie developmentu. Jest to tym bardziej zastanawiające, że projekt był duży,a logika formularza skomplikowana.

    • Racja! Informacja o Quality Assurance nie została zawarta w tym artykule, ponieważ przedstawiłam proces z perspektywy Product Managera i nie chciałam się wdawać w szczegóły pracy developerów. Oczywiście testy były prowadzone w trakcie developmentu przed wypuszczeniem każdej karty (Jira). Testy prowadzimy również po tym jak strona ujrzała światło dzienne.

  2. Mam jedną drobną sugestię, wynikającą z doświadczenia. Definiowanie KPI na początku projektu często wywołuje efekt: nie widzę lasu bo mi drzewa zasłaniają. Dlaczego? Dobrze zdefiniowany KPI odpowiada na to: co? dlaczego? i jak? chcemy mierzyć, aby wiedzieć, że „model biznesowy produktu” działa. Uczestnicy, a najczęściej główni interesariusze projektu, koncentrują się na KPI, tracąc szansę na zrobienie „czegoś więcej”. Dlatego na początku projektu KPI zastępuję CSF (critical success factors), jako element diagnozy oczekiwań i ich zrozumienia potrzeb, a KPI definiuję dopiero na etapie przygotowania do wdrożenia z wykorzystaniem blueprintu. Oczywiście zawsze wracam z info do wszystkich na jakie CSF jesteśmy w stanie odpowiedzieć, a na jakie nie, i dlaczego. Później są one częścią testów. KPI odpowiadają nam później, że wszystko, co stworzyliśmy działa lub co powinniśmy poprawić/ zmienić.

ZOSTAW ODPOWIEDŹ

Proszę wpisać swój komentarz!
Proszę podać swoje imię tutaj

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.