Z tego podcastu dowiesz się:
- Czym jest priorytetyzacja backlogu
- Dlaczego istnieje wiele sposobów ustalania priorytetów dla produktu
- Kto ustala priorytety
- Od czego warto zacząć definiowanie priorytetów
- Co zrobić jeszcze zanim wybierzesz jedną z technik priorytetyzacji
- Co charakteryzuje podstawowe techniki: Value vs Effort, MoSCoW oraz KANO
- Jakie są plusy i minusy każdej z technik
- Czy bez znajomości tych metod można zostać product managerem
- Które przydatne triki możesz wykorzystać w pracy nad priorytetami
- Jak rozumieć pojęcia performance features oraz delighters
- Według jakich kryteriów dobierać technikę priorytetyzacji do produktu
Podcast wysłuchasz także na:
Materiały dodatkowe
Technika Value vs Effort
To jedna z trzech technik, które naświetlam w dzisiejszym podcaście. W nagraniu wspominam m. in. o tym, że technika Value vs Effort oparta jest na bardzo prostej macierzy Eisenhowera. Poniżej zamieszczam przykład tego jak „na papierze” wygląda wspomniana technika. Pamiętaj, że 'wysiłek’ możesz definiować dowolnie, również jako koszty lub np. poziom skomplikowania technicznego danych usprawnień.
Technika MoSCoW
Podobnie jak wyżej, tutaj również zamieszczam przykład tego jak może wyglądać schemat techniki spod szyldu MoSCoW. Jak widzisz, nie ma to nic wspólnego z Rosją 😉
Technika KANO
Te technikę można, ale niekoniecznie trzeba wizualizować w jakiś wykręcony sposób. Niemniej jednak zachęcam, żeby w ramach ćwiczenia wspólnie z zespołem 'osadzić’ funkcjonalności według pionowej oraz poziomej osi KANO:
Product Discovery
Ten popularny framework do odkrywania i definiowania potrzeb użytkowników będzie tematem osobnego podcastu. Jeśli jednak już teraz chcesz dowiedzieć się więcej w tej materii, to polecam obejrzeć poniższy film. Zobaczysz w nim Teresę Torres, którą kojarzy chyba każdy doświadczony produktowiec na świecie. To bowiem Teresa uchodzi za najważniejszą popularyzatorkę product discovery. Film tylko w języku angielskim.
Jeśli mój podcast wydał Ci się interesujący, ale szukasz dodatkowego wsparcia w rozwoju zawodowym, to zapraszam na moje konsultacje managerskie.
Transkrypcja
„ Być jak Manager – Podcast Epizod 12”
Dzień dobry. Dzisiaj temat ważny, istotny, którego nie można pominąć, w sumie, to wszystkie tematy staram się dobierać do podcastu tak, żeby były ważne i istotne w pewien sposób dla ciebie, drogi słuchaczu. Natomiast istotny z punktu widzenia product managerskiego, więc będzie to podcast mocno produktowy, ale wydaje mi się, że przyszli product ownerowie, także mogliby sporo fajnej, ciekawej, przyzwoitej wiedzy z dzisiejszego podcastu dla siebie wyciągnąć. Ja ci dziękuję drogi słuchaczu, że już odpaliłeś ten podcast. Jeżeli nie jest to pierwszy podcast ode mnie, którego słuchasz, to tym bardziej kłaniam się podwójnie nisko. Ja tylko przypomnę już zwyczajowo, że ten podcast „Być jak manager” jest dla przyszłych, ale też początkujących managerów branży IT, managerów projektu, produktu, scrum masterów, a także product ownerów.
Dziś temat produktowy, ponieważ wydaje mi się, że nie mógłbym go pominąć w swoich treściach. Mianowicie porozmawiamy o ustalaniu priorytetów. Ustalaniem priorytetów dla produktu, bo o takich priorytetach, o takim obszarze będziemy tak naprawdę dzisiaj mówić. To jest jedna z głównych, jeśli nie najważniejsza kompetencja produktowca. To jest absolutny must have, zaraz obok tworzenia roadmapy, definiowania metryk czy tworzenia wymagań biznesowych. Myślę, że bez znajomości tych technik priorytetyzowania, o których będziemy dziś rozmawiać, product manager byłby trochę takim żołnierzem bez znajomości obsługi karabinu. Można na takim produktowym polu bitewnym szybko się przekręcić. Technik, co zaznaczę od razu na wejściu, takiej priorytetyzacji jest wiele. Sam znam kilkanaście z nich, aczkolwiek nie chcę przytłaczać ciebie, drogi słuchaczu, ich liczbą, ani opowiadać o nich także pobieżnie, dlatego do dzisiejszego podcastu wybrałem tak na rozkrętkę 3 techniki, których znajomość – i ja ci to gwarantuję, bo bazuję tutaj nie tylko na swoim doświadczeniu, ale i na doświadczeniu moich kolegów po fachu – te 3 podstawowe techniki, ich znajomość, załatwi naprawdę większość tematów, związanych z priorytetyzacją funkcjonalności z jakimi przyjdzie ci się zmierzyć. Oczywiście nie ograniczaj zdobywania swojej wiedzy tylko do tych 3 technik. Ja w przyszłym podcaście, o tym też jeszcze będę mówił. Będę brał na warsztat kolejne techniki, już mam naszykowany skrypt do kolejnego podcastu. Natomiast nie wszystkie techniki priorytetyzacji backlogu, są potrzebne w każdej organizacji. To jest taki troszkę banalny, ale oczywisty fakt. Po prostu fakt. Powiedziałem „oczywisty”, ale nie powinno się tak mówić. Po prostu fakt. Ja korzystałem z kilku swoich ulubionych technik dotychczas, które tak naprawdę dobierałem różnie, w zależności od potrzeb, od specyfiki produktu, od specyfiki organizacji lub przyzwyczajeń klienta, z którym współpracowałem, więc dużo zależy od kontekstu, a żeby prawidłowo dobierać technikę do kontekstu, no to przede wszystkim trzeba znać te techniki.
W podcaście dzisiejszym opowiem o 3. Ja nazywam te techniki podstawowymi technikami priorytetyzji backlogu. Te techniki pomogą ci ustalać priorytety dla produktu. Wyjaśnię również jakie podjąć kroki najpierw, zanim jeszcze sięgniesz po którąś w ogóle z metod priorytetyzacji, jak się przygotować do tego. Myślę, że po przyswojeniu wiedzy z dzisiejszego podcastu, będziesz mieć już takie solidne podstawy do tego, żeby ustalać priorytety dla produktu i poniekąd także dla całego zespołu deweloperskiego, więc dziś nie owijamy w bawełnę. Stokrotne dzięki, już kończąc te przydługawy wstęp, za każdy komentarz, który zostawisz pod dzisiejszym podcastem na mojej stronie: bycjakmenager.pl albo na mediach społecznościowych, ja przy okazji zachęcam do zapisania się na mój newsletter, jeśli chcesz być na bieżąco z tym co u mnie słychać i co słychać w świecie zarządzania IT. Nigdy nie spamuję, nie odsprzedaję niczyich danych osobowych firmom trzecim. Temat technik priorytetyzacji rozwinąłem, tak jak wspomniałem w kolejnym podcaście, także bądźmy na łączach. Myślę, że warto się zapisać na ten newsletter. A dla bardziej ambitnych, to jest wydaje mi się nowość, nie wspominam o tym wcześniej, uruchomiłem również specjalny moduł konsultacji na stronie i dzięki temu modułowi, jeżeli oczywiście czujesz taką potrzebę to możesz zarezerwować dla siebie konsultacji jeden na jeden ze mną albo zlecić mi po prostu przeanalizowanie twojego obecnego CV pod kątem tego jak bardzo skuteczny jest to CV. Szczegóły w zakładce konsultacje na blogu, kończę zanudzać przejdźmy do mięsa.
Pierwsza faza, w ogóle podejście do tego zanim zaczniemy sięgać po którąś z technik priorytetyzacji. Otóż, zanim wybierzesz jakąś konkretną metodę przygotuj sobie grunt. To, co ja rekomenduję to przede wszystkim wziąć wszystkie funkcjonalności jakie masz, jakąś taką listę funkcjonalności, które albo dostałeś od kogoś, albo przyszły, albo wy pracowaliście wspólnie z zespołem, z różnymi zespołami w czasie burzy mózgów. Bierzesz wszystkie te funkcjonalności, załóżmy, że jesteś kilkanaście może nawet kilkadziesiąt, no i teraz może się pojawić tak zwany paraliż decyzyjny. Taki paraliż decyzyjny, jak ja to nazywam on się pojawia za każdym razem, kiedy należy wybrać w funkcjonalności, nad którymi będzie pracował zespół i warto pogrupować sobie właśnie te wszystkie funkcjonalności według pewnej tematów, pewnych obszarów, żeby tego paraliżu decyzyjnego uniknąć.
O co chodzi? Otóż generalnie chodzi o to, żeby grupy funkcjonalności, które stworzysz wspinały się przede wszystkim z celem firmy, z wizją produktową organizację, w której jesteś, albo w ogóle z ogólną strategię organizacji. Ja to czasem nazywam także koszyczkami z funkcjonalnościami. Takie koszyczki pomogą ci, zaraz powiem o jakich koszyczkach mówimy, ale te koszyczki jak sobie stworzyć, takie grupy, tematy nazywaj to jak chcesz one pomogą ci upewnić się, się, że wasz zespół pracuję nad właściwym typem funkcjonalności, które są najważniejsze w projekcie. Pamiętaj, że nawet jeżeli zdarzy ci się i będziesz musiał powiedzieć „nie” dla wybranego projektu albo feature, to nie oznacza, że go porzucasz na zawsze, ale że w tej chwili wybierasz powzięcie tego wysiłku deweloperskiego i wdrożeniowego w innym miejscu. Zawsze komunikat zespołowi, że wrócicie do tych funkcjonalności, ale najpierw muszę iść te z wyższym priorytetem.
No i teraz jak pogrupować te wiele różnych funkcjonalności na te wybrane tematy, jak ja to nazywam na potrzeby dzisiejszego podcastu. 3 triki czy teraz sprzedam, któryś z nich myślę na pewno ci przypasuje, bo to w zależności od tego w jakim produkcie i w jakim klimacie będziesz się obracał.
Trik pierwszy, to pogrupować funkcjonalności według tematów, które znajdują się na road mapie. Jeśli zdarzy ci się, że masz już gotową road mapę albo przejąłeś schedę po innym produktowcu i ta road mapa gdzieś była. Załóżmy, że jakaś roadmapa jest, albo ty otrzymujesz od jeszcze wyższego managementu road mapę produktu, to prawdopodobnie widnieją tam różne sekcje, jeżeli możemy tak powiedzieć, które dotyczą konkretnych miejsc lub akcji w systemie. Załóżmy że takimi miejscami na tej road mapie są na przykład szeroko pojęte raporty, albo integracje jeżeli integrowanie się z jakimiś zewnętrznymi plagi nami widzisz tytułami jest sporym obszarem produktu na którym pracujesz, komunikacja być może, być może panel administratora jest takim szerokim obszarem, być może obszar płatności jeżeli coś takiego już jest takie obszary, albo roadmapa, na której widoczne są pewne takie obszary, no to przyszłe funkcjonalności które będzie trzeba z priorytetyzować, powkładaj sobie, mówiąc brutalnie, do takich właśnie koszyczków wziętych z mapy. Oczywiście, żebyśmy się dobrze zrozumieli, nie dodawaj nowych ficzerów od razu do roadmapy. Nie o to chodzi. Tylko posegreguj je roboczo, bazując na znanych tobie, ale także znanych pozostałym osobom z zespołu obszarach tych obszarach w produkcie związane z płatnościami do grupy o nazwie płatności ćwiczenie z generowaniem i pobieraniem raportów do sekcji raportu raporty i tak dalej, i tak dalej. To jest pierwszy trik, który możesz wykorzystać, żeby nieco okiełznać bałagan wstępny.
Trik numer 2, jeżeli pierwszy nie bardzo ci podchodzi, no to jest pogrupowanie funkcjonalności według trzech bloków. Pierwszy blok, to funkcjonalności, o które na przykład prosili, i wciąż proszę sami użytkownicy, blok numer drugi, to funkcjonalności, które mają za zadanie bezpośrednio wpłynąć na nasze najważniejsze metryki biznesowe oraz trzeci blok, w którym przykładowo umieszczamy wszystkie funkcjonalności, jakie potencjalnie mogą zachwycić naszych użytkowników, ale o które sami użytkownicy jakoś nie prosili. Z badań wiemy, że takie coś takie coś zrobiłoby efekt wow.
Także stworzenie takich trzech micro obszarów przed zgryzaniem się w priorytety, również może pomóc Trik numer 3 jeżeli 1, 2 nie zagra w twoim w twoim projekcie. Trik numer 3 polega na tym, żeby przypasować jakby skategoryzować pogrupować funkcjonalności, przypisując każdą z nich to konkretnej metryki, na którą potencjalnie może dobrze wpłynąć, ale ten trik numer 3 za bandla tylko w organizacji, gdzie jest naprawdę super jasność co do tego, jakie metryki powinny zostać poprawione, weź mi jakiś przykład. Załóżmy, że masz tysiące zadowolonych użytkowników, którzy korzystają z produktu nad którym pracujesz, ale wasz biznes szeroko pojęty, tudzież zarząd chciałby, żeby użytkownicy ci spędzali nieco więcej czasu w serwisie. No i wtedy możesz stworzyć taki koszyczek pod tytułem “czas spędzony w aplikacji” i wrzucić do tego koszyczka właśnie wszystkie funkcjonalności na wejściu, które mogą potencjalnie ten czas spędzony na aplikacji wydłużyć, a obok możesz stworzyć temat dla funkcjonalności. Wokół na przykład metryki NPS net promoter score, czyli mówiącej o zadowolenie użytkowników. Ja nagrałam osobny podcast o podstawowych i tych popularnych metrykach, więc jeżeli pominąłeś z jakiś powodów, aby nie wiem, czy okazji wysłać tamtego podcastu, to serdecznie zapraszam. Na pewno znajdziesz go na blogu i to był tryb numer 3 czyli po grupowanie fitcherów zanim zaczniemy je priorytetyzować, według pewnych metryk i te 3 triki, no to był tak naprawdę dopiero pierwszy stopień do produktowego piekiełka.
Spokojnie, słuchaj, rozkręcamy się. Słuchaj, jest jeszcze druga rzecz, którą naprawdę rekomendował bym by zrobić, jeszcze zanim weźmiemy którąś z technik i to jest bardzo fajne ćwiczenie. Mnie niejednokrotnie pomogło. Chodzi o to, że mamy już te pogrupowane według któregoś z tych trików. Pogrupowane funkcjonalności i teraz warto przelecieć jeszcze przez te future jeden po drugim. Warto by je właśnie otagować. Może to jest właściwe słowo, otagować trzema różnymi kategoriami. Kategorią wykonalności, atrakcyjności oraz zdolności utrzymania się tych funkcjonalności na rynku. Nie jest to oczywiście must have, ale uwierz mi, że ustawienie takich kategorii niezwykle pomaga, żeby zawsze patrzeć na funkcjonalność w nieco szerszym kontekście pokrótce wyjaśnię wykonalność.
O co chodzi? O to, żeby zastanowić się jak bardzo możliwe pod kątem technicznym jest zbudowanie takiego ficzera. Porozmawiaj z backendem, z front-end developera mi również porozmawiać też również z designerami, aby zrozumieć, co może zostać zrobione w kontrze do tego, co jest technicznie niemożliwe lub bardzo trudne. Nie układaj na tym etapie że żadnych priorytetów, to jeszcze nie jest ten etap to zrobisz później. Oflaguj jedynie te funkcjonalności które mogą być technicznie trudne w implementacji. Atrakcyjność drugi taki tag, taka lejbelka. Musimy się zastanowić, czy twoi klienci aby użytkownicy rzeczywiście tego chcą, rzeczywiście czekają na ten feature. Wykorzystaj wszystkie dostępne narzędzia jakie masz żeby zrozumieć czy to jest coś, na co czekają użytkownicy. Przeanalizuj na przykład feedback, jeśli zbierać jego wśród userów, porozmawiaj z researcherami, CXam to są customer experience specjaliści nie wiem jak to przetłumaczyć na język polski z obsługą klienta. Możesz też sięgnąć po sprawdzone framework do odnajdywania i definiowania realnych potrzeb użytkowników, jakim jest product discovery.
O product discovery będzie osobny pod podcast, ale już teraz zachęcam żebyś zajrzał na wpis na moim blogu pod tym podcastem. Podlinkowałem tam film, w którym – w dużym uproszczeniu – wyjaśniono czym jest product discovery i trzecia ta cecha którą warto przypisać poszczególnym funkcjonalnością, aby otagować nią ficzery, no to jest viability, ciężko przetłumaczyć to słowo na język polski, ale tak jak wspomniałem wcześniej, to jest pewna zdolność utrzymania się czegoś na rynku. O co chodzi? No chodzi o to, aby odpowiedzieć sobie na pytanie czy dany feature odpowiada na konkretne potrzeby rynkowe, czy jest na rynku zapotrzebowanie na takie feature? Porozmawiaj z wyższym management albo z researcherami, jak dana funkcjonalność działa albo będzie działać w większym ekosystemie, a może już jest na rynku podobna funkcjonalność. Jeśli trzeba to zachęcam też, żeby zrobić samemu dodatkową analizę rynku i oflagować na tym etapie właśnie te funkcjonalności, które realnie zaspokajają potrzeby rynkową, albo po prostu wypełniają pewną większą lukę na rynku. No i dobra doszliśmy do momentu gdzie mamy, według jednego z trzech trików pogrupowane funkcjonalności dodatkowo sobie je otagowaliliśmy, według wykonalności, atrakcyjności oraz tego, czy się utrzymają w na rynku. No i kiedy już to wszystko mamy, to tym samym ogarnęliśmy pierwszy krok do tego żeby zacząć ustalać priorytety.
To, o czym mówiliśmy dotychczas, to mówiąc językiem skoków narciarskich dopiero wyjście z progu cała zabawa zaczyna się teraz. Opowiem ci teraz o trzech technikach priorytetyzacji, tych technik jest oczywiście więcej. Zapewniam cię, że te 3 na razie w zupełności wystarczą żeby w miarę efektywnie chociaż nie na najwyższym poziomie ale w miarę efektywnie w wielu firmach technologicznych na świecie, te priorytety ustalać, jakoś nimi zarządzać i kierować. Oczywiście warto znać więcej niż tylko 2, 3 techniki ponieważ nigdy nie wiesz która z nich najbardziej ci się przyda.
Zresztą jak głoszą stare prawdy, no lepiej mieć więcej truskawek w koszyku niż mniej albo lepsze uzębienie, to te bogatsze w zęby niż ich brak. No to taka jakby logiczny argument który ciężko podważyć. Lepszy product manager to ten, bogatszy w wiedzę niż jej brak. Otrzymają ostatnio od jednego ze słuchaczy kilka bardzo konstruktywnych uwag podawać więcej przykładów i sytuacji z życia, gdzie mogą mieć zastosowanie te rzeczy o których mówią. Spróbuję tam gdzie mogę, łapać się jakiegoś konkretnego przykładu nawet wymyślonego, żeby bazować na fajnych konkretnych przypadkach użycia. Pierwsza technika priorytetyzacji value versus effort, wartość kontra wysiłek. To jest bardzo zwinna priorytetyzacja, niektórzy o tym mówią lean prioritisation i ta technika jest chyba najprostszą z technik priorytetyzacji, ponieważ ona bazuje na tak zwanej macierzy Eisenhowera. Najszybszy i najłatwiejszy sposób żeby zrozumieć te technikę, wartość kontra wysiłek, to jest zwizualizować się osobie na bardzo prostej właśnie macierzy Eisenhowera, macierzy 2 x 2. Ja wiem że mój opis słowny może nie być za wszystkich wystarczający dla zrozumienia tej techniki, dlatego zachęcam ciebie do wejścia na stronę byćjakmanager.pl, gdzie pod tym postem o technikach dodałem też przykładowe obrazki właśnie tych metody priorytetyzacji i teraz że byśmy pracowali na jakimś namacalnym przykładzie, to wyobraź sobie że jesteś PMem od aplikacji do zamawiania jedzenia na dowóz. Aplikacja działa na rynku od kilku lat, ma się dobrze zarabia na siebie i o dziwo, co się rzadko zdarza w świecie IT, nie ma też jakiegoś większego długu technicznego. Poza tym notuje bardzo dobre opinie od użytkowników, ogólnie jest w porząsiu i twój zespół oraz obsługa klienta regularnie zbiera też feedback od użytkowników, przekazuje ten feedback między innymi tobie, jako PMowi, na różnych dedykowanych do tego spotkaniach, ale od pewnego czasu użytkownicy dość intensywnie proszą o to, żeby wprowadzić nowe funkcjonalności, a dokładniej 4 potencjalne usprawnienia aplikacji których ich zdaniem rzekomo brakuje.
Funkcjonalność numer 1, to ma być taka możliwość zamawiania posiłków z wyprzedzeniem, na określoną godzinę. Na przykład, chcę zamówić dwa posiłki na wieczór, na ustaloną wcześniej porę. Pierwsza funkcjonalnością, o którą proszę użytkownicy. Druga funkcjonalność o której czytasz w feedback od użytkowników, to możliwość zostawiania napiwków dostawcom. Na przykład, jeśli jedzonko przyjdzie super szybko i jeszcze jest bardzo ciepłe, wręcz gorące, no to ja jako użytkownik chciałbym zostawić takiemu dostawcy TIP. STIPować go, czyli zostawić mu napiwek. To jest druga funkcjonalność. Trzecia funkcjonalność, to możliwość logowania się do systemu za pomocą face ID. Użytkownicy iPhonów dobrze wiedzą o czym mówię. Face ID, czyli super wygodny sposób logowania się do jakiejś aplikacji albo potwierdzenia akcji w systemie, za pomocą swojej twarzy. Po prostu kamerka patrzy na nas, smartfona nas patrzy, rozpoznaje że my to my i potwierdza akcje w systemie. To jest trzecia funkcjonalność, właśnie logowanie za pomocą face ID i do systemu, czyli odchodzi nam to wielokrotne wpisywanie za każdym razem pinu, żeby się zalogować i funkcjonalność numer 4, o którą zaledwie kilku restauratorów, ale jednak są to duzi restauratorzy. Już nie użytkownicy końcowi, ale restauratorzy, czyli te taka strona biznesowa twojej aplikacji i oni wnioskowali, ci restauratorzy, którzy są jednymi z naszych pierwszych i jest to prawda kilku, ale bardzo ich szanujemy.
Cenimy, bo to są nasi tacy fajni partnerzy, właśnie wśród restauratorów. To jest możliwość stworzenia oferty abonamentu dla klientów. Właściciele tych kilku restauracji, chcieliby sprzedawać swoje posiłki w abonamencie. W taki sam subskrypcji, że na przykład jeśli klient wykupił abonament miesięczny na obiady, od poniedziałku do piątku, no to restauracja może mu codziennie przygotowywać i wysyłać posiłek o tej samej porze, którą dla siebie wybrał. Niestety, obecnie w aplikacji nad którą pracujesz, nie ma takiej możliwości, nie można oferować klientom sprzedaży w subskrypcji posiłków i co my mamy? Mamy 4 funkcjonalności którym należy nadać priorytet. Załóżmy przy tym, że każdy z tych feature request, jak to się nazywa czyli zgłoszonych zapotrzebowań na jakość funkcjonalność. Załóżmy, że został już zwalidowany, przemyślany i masz naprawdę potwierdzenie w danych oraz analizie że te usprawnienia rzeczywiście mają sens. Przyjmiemy taki kontekst, ale trzeba to ułożyć w jakąś sensowną kolejność. No i co za tym zrobić? Jeśli musisz w miarę szybko, ale także niewielkim nakładem pracy nadać priorytety tym funkcjonalnością, zanim je umieścić na roadmapie produktu, no to tutaj wracamy do naszej techniki value vs effort, wartość kontra wysiłek.
Tak jak wspomniałem technika opiera się na prostej macierzy eisenhowera, 2 na 2. Bierzemy więc kartkę i długopis albo korzystamy z fizyczne i czytam wirtualnej tablicy, rysujemy dwie osie poziomą i pionowa. Pozioma oś czasu określa nam tak zwany effort, czyli wysiłek potrzebny do wdrożenia danej funkcjonalności. Im dalej na osi poziomej w prawo, tym oczywiście większy wysiłek zespołu jest potrzebny do wdrożenia feature. Oś pionowa z kolei określa tak zwane vallue, czyli potencjalną wartość jaką niesie ze sobą dany feature i im wyżej na osi pionowej, tym większą wartość dla produktu oraz użytkowników wniesie dany feature i całość, te osie kończymy sobie na te osie, które narysowaliśmy. Całość kartki dzielimy na macierze 2 na 2, czyli cztery kwadraty. Jeden po lewej stronie wykresu u dołu. Drugi zaraz nad nim. Trzeci po prawej u dołu, a czwarty po prawej u góry. Mamy macierze i dwie osie przecinającą ją wzdłuż i wszerz, to tak bym powiedział. Wiem, że może być trudno sobie to wyobrazić dlatego jeżeli słuchasz mnie na przykład na siłownię albo w samochodzie albo w innym miejscu, gdzie zwyczajnie możesz nie możesz otworzyć przeglądarki, żeby oglądać się ilustracje pomocnicze, to spróbuję to zobrazować słowami najlepiej jak potrafię. Skoro mamy dwie osie, poziomą która idzie w prawą stronę i określa wysiłek zespołu potrzebne do wyrażenia feature oraz pionową, która idzie w górę i określa wartość takiej funkcjonalności, no to nie pozostaje nic innego jak przypiąć te nasze 4 funkcjonalności w odpowiednich miejscach, na naszym matrixie a dlaczego podzieliliśmy całość 4 kwadratami na 4 strefy? A to ponieważ, gdyż, funkcjonalność, która będzie kosztowała zespół mało wysiłku, ale też będzie miała małą wartość, spozycjonujemy na pewno w lewej, dolnej części naszej macierzy, ponieważ niską wartość niską wartość określa początek osi pionowej, a niewielki wysiłek początek osi poziomej. No, nic prostszego, w tej sposób, jakby analogicznie powinieneś wspólnie z zespołem, lub po rozmowach z zespołem umiejscowić na tej twojej macierzy, wszystkie funkcjonalności.
Wróćmy do naszych featurerów, po rozmowach z zespołem, które odbyłeś zrobieniem dodatkowego reaserchu, zrobieniem dodatkowej analityki, wiesz już, że pierwsza funkcjonalność, czyli ta możliwość zamawiania posiłków z wyprzedzeniem, na określoną godzinę, będzie kosztować zespół niewielki wysiłek, ale też nie będzie to wielka wartość dla produktu i użytkowników, to wiesz już na pewno. No to umieszczamy to więc, w lewej, dolnej części naszej macierzy, jako niski effort, ale też małą wartość. Funkcjonalność 2, czyli ta możliwość zostawiania napiwków dostawcom. No tutaj zespół developerski, z pewnością powiedział, że to będzie nieco większy wysiłek, związany z implementacją takiego rozwiązania, ale też dużo większa wartość dla użytkowników. Bardzo wielu o nią prosiło, dlatego ten feature wyląduje w prawy, górnym rogu jako wartościowy, ale jednak skomplikowany pod kątem technicznym. Trzecia funkcjonalność, możliwość logowania się do systemu, za pomocą twarzy, czyli face ID. Głównie dla użytkowników iPhonów. Po konsultacjach z zespołem projektowym i analizie feedbacku od użytkowników wyciągasz prosty wniosek.
To usprawnienie jest super pożądane przez userów, a przy tym, co wiesz od zespołu technicznego, nie będzie wymagało wielu prac po stronie developmentów, oraz innych zespołów, żeby to wdrożyć, czyli koniec końców, logowanie za pomocą face ID trafia więc, w lewy, górny róg naszego matrixa, jako niski wysiłek, a potencjalnie duża wartość. 4 funkcjonalność, o którą wnioskowało kilku restauratorów, pamiętamy ją, czyli ta możliwość stworzenia oferty abonamentu dla klientów, żeby sprzedawać obiady w formie na przykład miesięcznej subskrypcji. Tutaj jest dość spory potencjał takiej funkcjonalności, ponieważ za pomocą subskrypcji można by jeszcze lepiej monetyzować każdego użytkownika, a nawet zmniejszyć tak zwany churn, czyli opływ użytkowników. Jak wezmą subskrypcję, to wiadomo co z miesiąca na miesiąca, są z nami związani. Niestety, wiemy już, że zaledwie kilka restauracji wyraziło chęć korzystania z takiej funkcjonalności, ponieważ większość restauracji po prostu nie ma abonamentów w swojej ofercie, w swoim modelu biznesowym, wiemy też, że od strony regulaminowej, nasza aplikacja, ale również technicznej, implementacja będzie po prostu, to jest skomplikowana i trudna, bo tam chodzi o recurring payments, czyli te płatności autoodnawialne, gdzie automatycznie schodzą ci pieniądze z konta i tak dalej, no i łączysz te dwa fakty, jako product manager i okazuje się, że mało jest zapotrzebowania na ten feature, a przy okazji spory wysiłek potrzebny do wdrożenia tego pomysłu. No to w naszym matrixie, ta funkcjonalność znalazłoby się gdzieś w prawym, dolnym rogu, jako wysoki fort, a mała wartość i teraz gdy zrobiliśmy sobie takie ćwiczenie, to niemal ze 100% pewnością, aczkolwiek nigdy nie można być czegokolwiek 100% pewnym, w żadnej branży chyba, ale z dużą dozą pewności, możemy wskazać, która z tych funkcjonalności powinna pójść na pierwszy ogień. Otóż, usprawnienia i featury, których będziesz szukać, jako product manager i które osobiście sprawiają, nie ukrywam najwięcej frajdy biznesowej, to są takie, do których wysiłek potrzebny do ich wdrożenia jest relatywnie mały, ale on sam wnoszą potencjalnie wielką wartość i na naszym przykładzie jasno widać, że taką pożądaną funkcjonalnością byłoby logowanie do systemu z użyciem face ID. Dlaczego? Ponieważ z naszego ćwiczenia, z technikum value kontra afford, wyciągnęliśmy wniosek, że to udoskonalenie będzie nas kosztować bardzo mało. Mały efford deweloperski, ale wpłynie niezwykle pozytywnie na ogromną liczbę użytkowników, czekających na te featury. Z kolei całkowicie po drugiej stronie medalu, znalazł się pomysł, żeby wdrożyć ten model sunskrypcyjny, w związku z tym, że korzystanie z niego zadeklarowało tylko mały odsetek restauracji, a koszty potrzebne do wdrożenia ponieślibyśmy duże.
To nie ma żadnego, logicznego argumentu na teraz. Argumentu za tym, żeby w ogóle to robić. Być może w przyszłości będzie miało to sens, gdy więcej restauratorów zgłosi chęć oferowania użytkowników abonamentu, ale na teraz możemy spokojnie ten pomysł zamrozić. Masz ku temu, jako PM wszystkie argumenty. Plusy techniki value versus afford, już kończąc, przechodząc do kolejnej, plusy tej techniki, no to jest bardzo elastyczna. Afford dla różnych organizacji może czasem oznaczać wysiłek deweloperski, dla innych może to być koszt implementacji i taka elastyczność powodu, że możemy potem afford przepisać różne rzeczy, a oznacza to, że framework, z jakiego korzystamy, ta technika może być wykorzystywana praktycznie w każdej firmie, niezależnie od przemysłu lub typu produktu i tak dalej, innym plusem jest to, że w organizacjach, gdzie zasoby są bardzo ograniczone, na przykład budżet, taka prosta analiza wartości w stosunku do wysiłku, może nam szybko pomóc kupić tylko na tych rzeczach, które realnie wpływają na największą liczbę użytkowników, a samo reorganizacja nie poniesienie przez to ogromnych kosztów, w czasie wdrażania i trzeci plus, jaki wydaje mi się, można przypisać tej technice to, to, że jest ona naprawdę bardzo prosta. Nie wykorzystuje żadnych skomplikowanych modeli obliczeń czy formułowaniu w excelu. Ja też nie jestem specem ani ekspertem od excelozy i też nie jestem fanem excelozy. Dzięki tej prostocie, łatwo w te technikę wdrożyć z tych folderów i osoby trzecie i jest też bardzo łatwa i przyjemna, w komunikacji z biznesem lub inżynierami. Jakie są minusy? No kilka wydaje mi się mógłbym wskazać. Pierwszy minus, to, to, że w sumie we wszystkich ćwiczeniach dotyczących priorytetyzacji, to jest trochę gra w stymulacji, w zgadywanie. Nie operujemy na wysokim poziomie ogółu, to zostaje przez to sporo przestrzeni do tego, żeby niedoestymować, albo przeestymować, to w chmurce, na osi. Ostateczna wycena może być, na przykład niewystarczająca, przy tej technice. Wiecie, tam gdzie jest prosta, łatwo i szybko, pojawia się pole do nadużyć. Czasem wycenianie natomiast, bardziej co mniej skomplikowane technicznie, może skraść więcej czasu niż nam się to wydaje. Zwłaszcza czas tu na dysku, między inżynierami. To też musimy brać pod uwagę i w końcu ta technika może być trudna do wykorzystania, jeśli w grę wchodzi przykładowo kilka dużych zespołów projektowych, które mają na sobie typy produktów, różne typy komponentów, a te komponenty i produkty zespołów, w ogóle na siebie bezpośrednio jeszcze wpływają i są między nimi różne relacje. Na przykład, na takim poziomie skomplikowania organizacyjno-produktowym, taka prosta technika priorytetyzacji, nie zawsze może wystarczyć.
Technika priorytetyzacji numer 2, z tych podstawowych, które dziś dla ciebie przygotowałem. MoSCoW. Tak jak z języka angielskiego Moscow, M, O, S, C, O, W. Po angielsku powiedzielibyśmy Moskwa, ale uwierz mi, to od razu dodam, nie ma to nic wspólnego z miastem Moskwa, absolutnie nic. To wynika ze skrótu. Sama nazwa właśnie tej techniki (wyjaśniam, ponieważ jak rozwiniemy ten tajemniczy skrót, no to od razu dowiemy się na jakie 4 konkretne obszary, będziemy rozdzielać funkcjonalności) jako że MoSCoW, pisane jest wielkimi i małymi literami, a wielkie są tylko cztery: M, S, C, W i to są bezpośrednio skróty od: M jako must have, tutaj mamy obszar must have. Załóżmy, że tworzymy taki koszyczek, taki bucket i do tego must have, wrzucamy funkcjonalności, które muszą znaleźć się na road mapie, dlatego muszą? Ponieważ wiemy, że bez nich produkt nie zadziała, bo nie będzie funkcjonalny i to są funkcjonalności niezbędne, czyli takie, dla których być albo nie być się nie negocjuje, a przynajmniej w teorii tylko takie powinny trafić do tej grupy. Jeśli któraś z tych funkcjonalności nie zostanie wdrożona, to produkt, lub jego nowa, nadchodząca wersja, nie może zostać wydana na rynek. To są rzeczy, które definiują funkcjonalności, jakie mają trafić do must have. Absolutnie niezbędne. Na przykład użytkownicy muszą, ale nie mogą czy chcieliby. Użytkownicy muszą zalogować się na swoje konta. Załóżmy, że jest jakaś aplikacja bankowa, no to żeby z niej korzystać, użytkownicy muszą zalogować się na swoje konta, wiec funkcjonalność, która odpowiada, funkcjonalność która mówi: „ja, jako użytkownik, chcę się zalogować na swoje konto”, albo użytkownik po prostu na tyle jest nazwana po imieniu „logowanie do systemu”, musi się pojawić na road mapie, bo bez nich produkt po prostu nie zadziała. I drugim koszyczkiem, jako, że to jest MoSCoW, to kolejna litera wielka to jest S, to jest schould have, czyli powinni. Do schould have, troszkę spolszczam, ale to jest zawsze taki obszar triki, powiedziałbym zdradliwy, jeśli opowiada się w języku polskim o różnych definicjach frameworkach angielskich, bo nie wszystko jest łatwo przetłumaczalne. Natomiast do schould have, do tej grupy, powinny trafić wymagania biznesowe i featury, które są super ważne dla organizacji albo produktu, ale na które nie ma narzuconego ograniczenia czasowego i które nie są niezbędne, tak bym powiedział. Oznacza to takie funkcjonalności, które w produkcie musza się znaleźć prędzej czy później, ale niekoniecznie muszą się znaleźć od samego początku, mogą być na przykład przeparkowane do dowiezienia w kolejnej wersji oprogramowania i przykład, użytkownicy powinni mieć możliwość resetowania swoich haseł. Resetowaliśmy chyba wszyscy kiedyś, co najmniej raz w życiu jakieś hasło do aplikacji, tudzież strony. Bez resetowania tego hasła, też byśmy przeżyli i produkt też by działał, ale jednak jest to coś, co powinno się znaleźć w wielu aplikacjach.
Kolejną, trzecią grupą, to są tak zwane could have, funkcjonalności, które nie są ani niezbędne ani nawet wystarczająco ważne, żeby dowieźć jest w odpowiednim czasie. Wiemy, że na pewno z większą satysfakcją użytkowników, że wpłyną mega pozytywnie na jakość produktu, to wiemy na pewno, ale wiemy również, że jeśli nie wdrożymy ich teraz ani nawet troszeczkę później, to tak naprawdę świat się nie zawali. Jaki przykład moglibyśmy tutaj podać? Niech będzie następujący, użytkownicy mogliby zapisać postępy swojej pracy, bezpośrednio w chmurze, z poziomu swojej aplikacji. Zakładamy, że dotychczas użytkownicy zapisywali swoje postępy w aplikacji, a tutaj, mogliby w chmurze zapisywać i niezależnie z jakiego urządzenia by się logowali, mieli postępy swojej pracy zapisane, mogliby sobie je pobrać z chmury. Funkcjonalność niekoniecznie do dowiezienia na szybko, niekoniecznie niezbędna, bez niej produkt przeżyje, ale taki could have i 4, ostatnia grupa, w tej technice priorytetyzacji, to są want have i tutaj lądują te najmniej krytyczne wymagania i taski. Zwłaszcza takie, które mogą być najwyżej takimi nice to have. Ja często te ostatnią grupę właśnie tak nazywam: nice to have i to są przede wszystkim albo fajne, mile, dodatkowe usprawnienia, które mogą, ale nie muszą się pojawić, ale również takie funkcjonalności, dla których wdrożenia nie mamy wystarczających zasobów, przykładowo nie ma ludzi albo odpowiednich kompetencji w projekcie albo nie jesteśmy technologicznie gotowi, żeby je wdrożyć, no to want have, my ich po prostu nie zrobimy ale want have nie oznacza, że w ogóle nie będziemy tego robić. To oznacza jedynie, że nie będziemy tego robić teraz. Te funkcjonalności w przyszłości spokojnie, mogą znaleźć się na kolejnej road mapie, jeśli okoliczności na to pozwolą. Może być tak, że dzisiejsze want have, w przyszłości staną się must hevami. Jakie są plusy metodologii priorytetyzacji czy tam techniki priorytetyzacji MoSCoW, otóż to dobry sposób na zaangażowanie stakeholder, bez wiedzy technicznej zwłaszcza, do procesu priorytetyzacji, bo ta technika jest dość łatwa w zrozumieniu. To jest dość szybki i intuicyjny sposób w jaki możemy komunikować priorytety dla zespołu i użytkowników.
Ja bardzo często korzystam z MoSCoW, bo jest mi łatwiej pokazać zespołowi, co jest super ważne, co jest mniej ważne, a co najmniej ważne, a co w ogóle nie będzie na naszej tapecie w najbliższym czasie i ta technika pozwala też pomyśleć zawczasu o ewentualnym alokowaniu, różnych zasobów i szukaniu specjalistów do projektu, kiedy już sklasyfikujemy featuery do każdej z tych grup, ale są 2 takie minusy tej techniki priorytetyzacji i pierwszym z nich będzie na pewno, zawsze jest to kuszące, żeby przesadzać z liczbą funkcjonalności must have, więc nie zdziw się jak dostajesz 30 funkcjonalności, z czego 15, czy tam 20 będą samym must have, dlatego ja tutaj rekomenduje, żeby jasno i bardzo asertywnie edukować ludzi z biznesu, że must have musi spełnić pewne warunki i że przede wszystkim oznacza to absolutnie niezbędne funkcjonalności, dla poprawnego działania produktu, w ogóle dla działania produktu i drugim minusem, który bym tutaj wypunktował, to raczej jest ćwiczenie, które pomaga zdefiniować kryteria przyszłych realisów, aniżeli taka super metoda priorytetyzacji. Co mam na myśli? Ja bym sugerował stosować MoSCoW jako pewną uzupełniającą technikę, a nie główną metodę układania priorytetów, chociaż nie zawsze. Chyba, że sam produkt jest na tyle nieskomplikowany to myślę, że MoSCoW może wtedy naprawdę dobrze siadać. Natomiast im bardziej skomplikowany produkt albo projekt, tym MoSCoW może być na zbyt dużym poziomie ogółu operować nam, żeby nam tu wnieść wartość do naszych priorytetów. Tyle, jeśli chodzi o MoSCoW i przechodzimy płynnie do ostatniej techniki, którą chciałbym dziś tobie przedstawić. Mianowicie, niektórzy mówią KANO, bardzo prosty termin.
W największym skrócie KANO, to jest taki trochę model scoringowy, który pomaga priorytetyzować funkcjonalności opierając się na tym jak bardzo mogą usatysfakcjonować naszych użytkowników, ale też zderzając ten zachwyt z wysiłkiem albo kosztami jakich będzie wymagać od nas, czy od zespołu projektowego, wdrożenie tych funkcjonalności i żeby poprawnie wykorzystać tą technikę, należy zrobić poprawnie następujące ćwiczenie. Przede wszystkim porozmawiać z wieloma potencjalnymi użytkownikami lub dokładnie przeanalizować feedback od nich. Jeśli takowy jest zbierany na bieżąco, w twojej organizacji i co dalej z tym feedbackiem? Należy sobie stworzyć roboczo, 3 koszyczki, to jest grupa, segment, do których będziesz wrzucał funkcjonalności. Zaparkujmy tutaj jakiś taki namacalny przykład, na którym omówimy sobie te technikę. Wyobraź sobie, że wspólnie z zespołem inżynierów, chcecie stworzyć szczoteczkę do zębów, wszyscy wiemy jak wygląda szczoteczka do zębów, mam nadzieję. I po wielu produktywnych burzach mózgów, macie już te listę featerów, które ty, jako product manager chcesz trochę ogarnąć pod kątem priorytetów. Sięgasz więc po model KANO, który usłyszałeś na podcaście Mariusza Najwera, taka autopromocja. No i tworzysz, co tworzysz? Koszyczki tworzysz, no przecież to nie będziemy uciekać od tego słowa. Koszyczek numer 1, czy tam koszyk, nazywamy go „podstawowe funkcjonalnośći”, basic. I tutaj, do tego koszyka, z tych wszystkich funkcjonalności dotyczących szczoteczki do zębów, na pewno wrzucasz te, których oczekują użytkownicy. Takie usprawnienia powinny tutaj trafić do tego koszyczka, z podstawowymi funkcjonalnościami, bez których użytkownicy na pewno, co wiesz, poczują się zawiedzeni, bo nie pomożesz im rozwiązać podstawowego problemu. Jak by się to miało zadziać, w przypadku naszej szczoteczki? Dwa takie proste featury. Mam mieć trzonek, czy tam jakąś rączkę i ma mieć jakieś włosie, do szczotkowania zębów, no bo co potrzebne użytkownikom, żeby w podstawowy problem został rozwiązany, żeby umyć zęby po jedzeniu. Trzonek z jakimś włosiem, tyle, koniec, basic, podstawowe funkcjonalności. Koszyk numer 2, to po angielsku nazywa jest performance features i tutaj trafiają funkcjonalności, które na pewno usatysfakcjonują użytkowników, ale nie są dla nich super istotne w pierwszej kolejności. Również takie byśmy tutaj wrzucili featury, który wiesz, że im więcej zainwestujesz w to czasu, analiz, pieniędzy i tak dalej, tym bardziej zadowolony będzie użytkownik, kiedy dostarczysz mu jeszcze bardziej wykręcone, takie performance features. No i jak w przypadku naszej szczoteczki by to wyglądało? Załóżmy, że podstawowe funkcjonalności zostały już dowiezione, czyli mamy trzonek, mamy włosie, co dalej? Tym razem włosie ma być wyprofilowane specjalnie tak, żeby było dopasowane do kształtu zębów. To włosie, musi mieć też różne poziomy twardości, na przykład miękkie dla wrażliwego podniebienia, średnia twardość i duża twardość, dla największych kozaków. Z kolei trzonek i tutaj trzecia funkcjonalność. Trzonek, czyli ta rączka szczoteczki powinna być troszkę wyprofilowana, nie taka prosta, żeby lepiej leżała w dłoni. No i widzisz, mamy te trzy funkcjonalności, bez nich, gdyby ich nie było, użytkownik też umyje zęby, problem będzie rozwiązany, ale jednak performance feature, z tego drugiego koszyczka sprawi, że użytkownik będzie jeszcze bardziej usatysfakcjonowany tym produktem, czyli nie must have, ale bez nich, nie byłoby jakoś super rewelacyjnie i koszyk numer 3, domyślasz się pewnie co może być w koszyku numer 3. Zagranicznie koledzy po fachu nazywają ten koszyk deilghters, ja po polsku nazwałbym to: zachwycacze. Nie ma takiego słowa, ale tutaj oczekuje się, że tutaj znajdą się featury, na które użytkownicy nawet nie czekają, nawet nie domyślają się, że można coś takiego zrobić, ale ty zrobiłeś badania i testy i wiesz, że jeśli dostarczysz im te funkcjonalności, to userzy będą cholernie zachwyceni. Oni będą cię całować po rękach, że dałeś im to, czego nie oczekiwali, ale jednak wiesz, dodałeś im takiego zachwycacza. Oczywiście te featury będą wymagać o wiele większego wysiłku, po stronie całego twojego zespołu, wysiłku po stronie analityki. A jakby się to miało po stronie naszej szczoteczki? Wyobraź sobie, że ta twoja szczoteczka będzie odliczała czas, który będzie ci mówił, ile zostało ci minut do końca mycia zębów, żeby użytkownik był pewien, że na myciu zębów spędza te 2 minuty. Ale nie wszystko.
Nie wiem czy pamiętasz, była szczoteczki marki Jordan, ale jak ja już myłem około 2 minut zęby, to ta szczoteczka zmieniała kolor i to było takie wow. Ja podejrzewam, że wtedy ktoś w firmie Jordan zrobił dobrą priorytetyzację. Nie spodziewałbym się jako użytkownik, że szczoteczka może zmieniać kolor. A może ma śpiewać piosenki, a może ma sama przypominać o swoim istnieniu. I takie właśnie 3 koszyczki to jest podstawa techniki priorytetyzacji KANO, ale zapytasz mnie, ale skąd ja mam wiedzieć, na które funkcjonalności czekają użytkownicy? No i tu dlatego wspomniałem, że bardzo ważna jest rozmowa z użytkownikami, ankietowanie. Możesz ich pytać wprost czego im brakuje. Sposobów na feedback jest mnóstwo, ale to już temat na inny podcast. I model KANO można tez pokazać obrazowo, także wykorzystując dwie osie, poziomą i pionową. Na osi poziomej, funkcjonalności według wysiłku, czyli czasu i kosztów im dalej w prawo, tym więcej wysiłku zespół musi włożyć w implementację i badania, a na osi pionowej układasz według satysfakcji użytkowników. Im więcej frajdy, to wybrana funkcjonalność jest windowana wyżej. Jaki są plusy, tego modelu? Samo ćwiczenie tej techniki może nauczyć zespoły, żeby nie przesadzać z szacowaniem tych ekscytujących featerów ale bardziej precyzyjnie estymować funkcjonalności. To jest troszkę dokładniejszy model jednak i wymagający bardziej zaawansowanej estymacji. Dobra metoda priorytetyzacji, jeśli mamy ograniczone zasoby. Na przykład mamy mało osób, mało czasu, mały budżet, ta technika może się okazać pomocna i ta technika może pomóc w podejmowaniu lepszych decyzji produktowych oraz lepszym progrozowaniu potrzeb rynkowych, bo bazujemy, tu jest duży nacisk na to, żeby bazować właśnie na oczekiwaniach użytkowników. Ja bym widział dwa minusy tej techniki, jak już mówimy o minusach, ta technika potrafi być czasochłonna, ponieważ żeby naprawdę poznać oczekiwaniu userów, to musimy spędzić trochę czasu nad tym, przeprowadzić odpowiednią ilość ankiet, żeby uzyskać nie odpowiedzi od wszystkich, ale chociaż od reprezentatywnej grupy osób, które dadzą nam, reprezentatywną próbę tych sugestii i drugi minus, istnieje pewne ryzyko, że userzy nie zawsze mogą dobrze zrozumieć funkcjonalności, o które ich pytasz w ankietach.
Ja zalecałbym skorzystanie z pomocy CXa, to są specjaliści lub skorzystanie z pomocy doświadczonego product designera, żeby pomógł ułożyć bardzo precyzyjne pytania, dla użytkowników, źle zadane pytanie, może ci dostarczyć złych odpowiedzi. Podsumowując nasze dzisiejsze spotkanie. Priorytetyzowanie backlogu produkt, czyli funkcjonalności, które się w nim znalazły, to jedna z podstawowych kompetencji product managera. Zanim sięgniemy po którąś z metod priorytetyzacji, warto pogrupować sobie funkcjonalności od tematów albo kategorii, żeby uniknąć późniejszego bałaganu. Można je także podzielić na 3 klocki. Featury, o które sami proszą użytkownicy, na featury które wpłyną bezpośrednio na nasze metryki lub na featury, które mogą zachwycić użytkowników, ale o które sami nie prosili. Z tak przygotowanym backlogiem, na pewno będzie ci łatwiej przeprowadzić któreś z ćwiczeń, na przygotowanie priorytetów. Wkrótce kolejna część podcastu, którym opowiem tobie kolejne 4 sposoby. Dziękuję pięknie raz jeszcze za każdy komentarz.
KONIEC
Źródła
https://roadmunk.com/guides/product-prioritization-techniques-product-managers/
https://slab.com/blog/eisenhower-matrix/
https://www.career.pm/briefings/product-prioritization-techniques
https://www.productplan.com/learn/strategies-prioritize-product-features/
https://www.aha.io/roadmapping/guide/release-management/prioritization-framework
https://plan.io/blog/feature-prioritization/
https://agilehunters.com/3-najlepsze-metody-priorytetyzacji-product-backlogu/
