produkt - Tebe.blog

Fikcja produktowa: strategia i wizja

Każdy produkt ma jakąś wizję i strategię. Sytuacje, w których jego właściciel nigdy nie pomyślał o tym co robi, dla kogo i jak, zdarzają się rzadko. Z drugiej strony spisywanie tych rzeczy nie jest popularne. Lepiej wychodzą, gdy komuś np. przy piwku, opisujemy czym się zajmujemy. Gdy start-upowiec po raz 5-ty usłyszy pytanie „dla kogo jest ten produkt” albo „jaki problem rozwiązuje”, to w końcu wpisze to do swojej prezentacji. Będzie ze swoim partnerem (czy jak się mówi w tej branży) działał posługując się tymi ustaleniami, czasem nawet nieświadomie. Co bardziej światły nazwie je po imieniu.

Gdy firma zatrudnia więcej niż kilkudziesięciu tzw. pracowników umysłowych i nie odrabia zadań domowych należycie, na korytarzu zaczynają się pojawiać pytania „jaka właściwie jest nasza strategia?”. To zdrowy objaw – ludzie interesują się kierunkiem, w którym zmierza budynek. Gdy jest odpowiedź moga ją krytykować, a podchodząc pozytywnie – lepiej działać. Strategia się więc przydaje. Poza nią wizja i jeszcze parę rzeczy powodujących, że przestają być tylko interesującą opowieścią.

Zacznijmy od wizji, bo to właściwa kolejność. Ona określa tożsamość i mówi, co robimy, co chcemy osiągnąć i gdzie chcemy być w ciągu 2-5 lat. CEO LinkedIn Jeff Weiner mówi: Na świecie jest 3,3 mld profecjonalistów i LinkedIn chce być zawodową tożsamością każdego z nich. Chce też by każda firma na świecie utrzymywała profil na LinkedIn i używała serwisu do zatrudniania. Niewiele więcej trzeba, ale ustalenie tych paru zdań nie jest łatwe.

Strategię określa się po ustaleniu wizji. Wizja mówi „wygramy wojnę”, strategia „wystrzelimy dużo rakiet”. Mniej więcej – tak to łatwiej zapamiętać. Nie udaję eksperta, ale wiem, że ze strategią jest jak z UX: większość osób, które posługują się tymi określeniami nie potrafi ich wytłumaczyć. Strategie piszą wszyscy bez względu na to co w jej ramach powstaje. Czasem jest to „roadmapa” czy inny pseudoplan, czasem opowieść o sytuacji rynkowej, najcześciej fantazyjny i mało treściwy powerpoint.

Strategią ludzie nazywają tyle różnych rzeczy, że powstał nawet blog skupiający się na cytowaniu różnych jej definicji. Niestety zgubiłem link. Zamiast niego polecam świetny tekst w nieocenionym HBR: „Don’t let strategy become planning”. Mówi, że strategia to zbiór wyborów dotyczących tego co chcemy osiągnąć, jak będziemy o to walczyć i czego do tego potrzebujemy. Na tym poziomie nie trzeba studiować tematu, żeby zacząć go realizować z sensem.

Więc wiemy gdzie chcemy być i jak tam dojdziemy. To dużo ale zanim cokolwiek zrobimy, jest to fikcja. I teraz zaczynają się schody.

Dokumentowanie, notowanie i biurokracja produktowa

Dobrze pamiętam, sensownie się umówiliśmy. Nic jednak się nie stało. Nikt też nie pamięta, co dokładnie się miało wydarzyć. A wystarczyło spisać. Ciągle jeszcze mi się zdarza doświadczyć sensowności prostej zasady: nie ufaj swojej pamięci. Zapisuj. Twórz notatki, zwłaszcza jeśli pracujesz z dużą liczbą osób.

Dokumentowanie kojarzy nam się z biurokracją i odrabianiem zadań domowych. Bardzo tego nie lubimy. Na dodatek wiemy z opowieści, że produkty cyfrowe mogą się bez tego obejść. Wszystko da się zrobić w kodzie, bazując na szkicach. Wystarczy zgrany zespół i rozproszona w mailach i zapisach z komunikatorów korespondencja. Tak może zaczynać dowolny startup, ale wzrost wymusi na nim zmianę.

Nie lubimy dokumentów, założeń i notatek, bo często stają się czymś koszmarnym. W korporacjach standardowe kwity, zwłaszcza dotyczące tzw. projektów informatycznych zwykle są fatalnie sformatowane i wypełnione pustymi formularzami, które bardzo rzadko mają zastosowanie (są w każdym kwicie, bo format jest uniwersalny). Na 5 stronach mamy kilka zdań treści, a reszta to elementy dokumentu, których używa się raz na jakiś czas. Na dodatek nazwy pól są bardziej czytelne niż treść. Dlaczego się tak dzieje? Bo rzadko kto zawraca sobie głowę dbaniem o przejrzystość tych rzeczy. Kolejne generacje pracowników używają tego, bo muszą. Na dodatek uczą się, że tak ma być i.. przenoszą czasem wzory w nowe miejsca.

Po co spisuje się rzeczy? Przede wszystkim – by wyręczyć pamięć i nie tracić czasu na dyskusje o tym, co raz się ustaliło. Gdy coś jest spisane może krążyć i wywoływać dyskusję. Tylko ludzie, którzy „wiedzą lepiej” jej nie potrzebują. Pisanie wspomaga też myślenie. Zwłaszcza u wzrokowców – osób, które najlepiej odbierają informacje, gdy je czytają. Taki przekaz zaoszczędza też czas na osobiste tłumaczenie. W końcu kwity są potrzebne, by uchwycić moment podjęcia decyzji. Potem można do tego wracać. Spisane ustalenia pozwalają na weryfikację dokonań.

W każdej organizacji, w której niewielu decyduje o pracy większości, pewne rzeczy trzeba ustalać zanim zacznie się coś realizować. Nawet jeśli mamy całkowicie samodzielne zespoły, coś musi wyznaczyć ramy ich działania. Gdy wszystkie ustalenia są w mailach, to czasem ten stan wymaga tylko drobnej ewolucji. Wystarczy wyjść z poziomu dyskusji do spisanych ustaleń, a efekt przerzucić do notatki z nazwą, datą i autorami. Stworzyć minimalną liczbę wymaganych dokumentów i napisać, czego nie może w nich zabraknąć. Minimum jakie ma się w nich znaleźć wymaga dyscypliny. Lepiej przy tym unikać długich kwitów. Czasem to nie wychodzi, wtedy można wymuszać pisanie w punktach.

Poza tym warto jeszcze zadbać o sensowne nazwy tych kwitów (naprawdę macie 50 plików o nazwie zalozenia.rtf?). Formatowaniem nie trzeba się zajmować, jeśli nikt nie formatuje. Gdy ludzie zaczynają korzystać z wymyślnych możliwości oprogramowania, lepiej narzucić prosty standard. Żeby nie tracili czasu na wybór kształtu bulletpointa a skupili się na treści.

Warto pamiętać, że – to wychodzi zwłaszcza w rozwoju produktów – tekst pisany każdy rozumie po swojemu. Jednoznaczne jest dopiero to co powstało, coś czego można użyć. Dobre, proste kwity są jak terminy. Same nie mają mocy sprawczej, ale pozwalają się nam znaleźć na „tej samej kartce”. Nie są celem samym w sobie, dlatego warto dobrze się umówić jakie powinny być, a jakich tworzyć nie trzeba.

Warto spisywać kluczowe ustalenia dotyczące zmian w produktach, lub tworzonych funkcjonalności. Po każdym projekcie dobrze jest stworzyć podsumowanie. Powody nieźle opisuje UxBooth, choć trochę przesadza z ilością dokumentów. Ważniejsze niż spisywanie tego jest sprawienie, by rzeczywiście ktoś do tych zapisów wracał i ich użył. Na wyższym poziomie warto mieć spisaną strategię, wizję i jakąś roadmapę / backlog z postulowanzmi zmianami (pamiętając, że wielomiesięczna roadmapa zawsze jest fikcją). Ten ostatni to na szczęście nie literatura – raczej sztuka dzielenia, nazywania i priorytetyzowania rzeczy.

Mity na temat rozwoju produktów

Nieporozumienia i błędy związane z rozwojem produktów są dość uniwersalne – problemy znane z branży cyfrowej występują również w inżynierii kosmicznej i branży farmaceutycznej. Świetnie omawiają to autorzy artykułu „Six Myths Of Product Development” opublikowanego w Harvard Business Review. Jakie są ich wnioski?

Prace rozwojowe warto dzielić na małe części, realizowane w krótkich cyklach. Dzięki temu łatwiej weryfikować tezy projektowe i reagować w razie niepowodzenia. Po latach porażek z wielkimi projektami wydaje się dziwne jak rzadko się tak robi.
Zmiana planu to rzecz nieunikniona i dobra. A nawet: w rozwoju nie da się nic dokładnie zaplanować i wszystkiego przewidzieć. Wybór rozwiązania ustala się dzięki testom i na początku procesu nie można określić, które powinno być wdrożone i ile to zajmie. Autorzy piszą, że w całej swojej historii nie spotkali produktu, co do którego wymagania nie zmieniły się w procesie projektowania.
Dlatego planowanie to zgadywanie (jeden z podrozdziałów „Rework” ma taki tytuł). Plany warto mieć, ale ze świadomością, że oparte są na fałszywych przesłankach i trzymanie się ich może być przepisem na porażkę.
To, że projekt zaczynamy wcześniej, nie oznacza, że wcześniej go skończymy. To ma bezpośredni związek z dostępnością zasobów. Rzecz dotyczy raczej większych organizacji – takich, w których ludzie nie pracują stale nad jednym produktem, tylko realizują różne projekty. Jedna z zasad kanbana mówi, że należy kontrolować ilość prac w toku. Ważna reguła w prowadzeniu projektów natomiast „nie zaczynaj, dopóki nie masz wszystkich zasobów”. Zamiast dbać o to, by projekty ruszały „tak szybko jak się da”, lepiej troszczyć się o to, by całkowity czas trwania – od pierwszego spotkania zespołu do zakończenia poprawek – się skracał.
Liczba funkcji nie przekłada się na jakość produktu. Dla zainteresowanych projektowaniem to nic nowego. Dobre produkty robią kluczowe rzeczy bardzo dobrze. Jeden z głównych powodów: mniejsza liczba funkcji pozwala skupić się zespołom na najważniejszych.
Sukces rzadko oznacza powodzenie przy pierwszej próbie. Lepiej się pomylić i szybko wyciągnąć wnioski. Przeważnie paraliżuje nas lęk przed porażką. Sięgamy po bezpieczne rozwiązania, które niczego nie zmieniają i nie tworzą wartości.

Polecam lekturę. Artykuł można znaleźć nie tylko na stronach HBR.

Generalizując wnioski: budując organizację, która zajmuje się rozwojem lepiej skupić się na tworzeniu zespołów, które sprawnie eksperymentują i zdolne są do zwrotów, szybkiego wyciągania wniosków i porzucania błędnych tropów. Ważniejsza jest gospodarka odpadami niż tworzenie ambitnych, fikcyjnych planów. Ważniejsza jest realizacja niż pomysły z powerpointa.

Najciekawszy wątek artykułu to jednak teza, że w takiej organizacji dążenie do pełnego wykorzystania zasobów jest błędem. O tym jednak w następnym wpisie.

Nowy zawód: właściciel produktu

Oto nowy zawód: właściciel produktu cyfrowego. Coraz częściej w firmach potrzebne są osoby, które rozumiejąc rynek i użytkowników sprawnie poruszają się na styku biznesu i technologii. Ich głównym zadaniem jest podejmowanie decyzji związanych z rozwojem.

Właściciel musi wiedzieć co najbardziej dolega produktowi i czego brakuje jego użytkownikom. Powinien ich i produkt znać na wylot. Rozumieć każdy aspekt jego działania, rozumieć jak funkcjonuje obsługująca go technologia, ale też jakie procesy są z nim związane – co i jak robią pracujący przy nim ludzie. Musi też wiedzieć z czym produkt najmocniej odstaje od konkurencji (co nie znaczy, że tę konkurencję ma gonić).

W branży cyfrowej nie ma produktów skończonych. Zawsze są jakieś rzeczy do poprawienia lub zbudowania. Dynamicznie zmienia się oferta konkurencji i technologia. Inspiracji do rozwoju nie brakuje. Niestety realizacja większości dostępnych pomysłów nic zmienia, a za każdym razem zajmuje czas i kosztuje. Rozwój wymaga wyborów: nawet jeśli idzie szybko, to cokolwiek robimy, nie robimy w tym czasie czegoś innego. By osiągać efekt można robić dużo, licząc, że czasem się trafi, albo niewiele, starając się dobrze wybierać.

Praca właściciela produktu to ciągłe podejmowanie decyzji o rozwoju i współpraca z ludźmi w projektach, w których te decyzje są realizowane. To komplikuje się wraz z wielkością organizacji. Złożone, popularne produkty obsługuje często kilka grup osób. Może to być nawet kilkudziesięciu ludzi z kilkoma szefami w strukturze. Zajmują się jego sprzedażą, tworzą zapełniające go treści, komunikują się z użytkownikami. Z drugiej strony, do każdego projektu rozwojowego trzeba zwykle zaangażowac kilku ludzi: programistów, webmastera, projektanta i grafika. Gdyby zebrać wszystkich szefów i ludzi niezbędnych w realizacji, czasem trudno znaleźć dla nich salę. Poza kłopotami logistycznymi, udział tych wszystkich ludzi może powodować paraliż decyzyjny.

Jak z tego wybrnąć? Rozwiązanie to właśnie „product owner” reprezentujący wszystkich zajmujących się produktem. Musi on ich dobrze znać, słuchać i rozumieć. Pracuje z nimi nad wizją i strategią rozwoju. Jej świadomośc pozwala mu ocenić, co jest ważne, które zmiany ją wspierają, a które nie. Jako jedyny przedstawiciel biznesu jest kluczowym członkiem zespołu projektowego.

Idealnie gdy właścicielem jest to sam szef biznesu związanego z produktem. Gdy jednak biznes jest duży – ktoś bezpośrednio raportujący do niego. Produkt owner musi być stale dostępny dla zespołu projektowego. Musi mieć przy tym wiedzę niezbędną do pracy z technologią nad produktami dla ludzi. Musi rozumieć jak użytkownicy korzystają oni z cyfrowej komunikacji (z internetu, komputerów, smartfonów itp.). Nie może nie potrafić dogadać się z programistami. To kluczowa rzecz – dogadać to znaczy umieć zyskać szacunek, potrafić uzyskać kluczowe informacje i wspólnie znaleźć optymalne drogi realizacji celów. Umieć zadawać dobre pytania i prowadzić dialog. Nie korpo-dialog oparty na władzy i hierarchii, ale normalną otwartą rozmowę.