Kiedy i jak pozbywać się zbędnych funkcjonalności z produktu?

Jednym z głównych zadań Product Managera jest zwiększanie wartości produktów poprzez oferowanie funkcjonalności, które rozwiązują problemy klientów. Bardzo często wydaje nam się, że budując wartościowe produkty powinniśmy dodawać coraz więcej funkcjonalności, aby nie odstawać od konkurencji oraz cały czas  być atrakcyjnym dla użytkownika. Podczas intensywnej, codziennej pracy, często zapominamy, że zwiększanie wartości produktu nie oznacza tylko dodawanie funkcjonalności, ale też ich usuwanie.

Początek

Wdrażanie innowacyjnych usług czy produktów nie ogranicza się tylko do kwestii szczęścia, ciężkiej pracy czy znajomości dziedziny. Skupienie się tylko i wyłącznie na najbliższych tygodniach bez zdefiniowanej wizji i strategii działania, może doprowadzić do ślepego zaułka.  

To właśnie te etapy pomagają nam bardzo podczas podejmowania decyzji i klasycznym  “NIE” dla określonych funkcjonalności.

Podczas tworzenia produktów bardzo ważny jest pełny plan:  wizja, strategia, roadmapa oraz rejestr produktu.

• Wizja jest tak naprawdę opisem głównego powodu, dla którego postanowiliśmy stworzyć produkt. Powinna być „podparta” motywacją, a także pozytywną zmianą, którą ma spowodować rozwiązanie.
• Strategia jest planem wysokiego poziomu, który pomaga w realizacji wizji i osiągnięciu celu. Definiuje jak wizja będzie zrealizowana.
• Roadmapa jest opisem implementacji strategii. To tak, jakbyś zdefiniowaną strategię przelał na konkretne czyny i działania.
• Product backlog zawiera szczegóły potrzebne do zrealizowania roadmapy: historyjki użytkownika i epiki.

Planowanie funkcjonalności

Zanim zabierzemy się do wykonania pracy, bardzo ważne jest aby poznać ryzyka i wartości wprowadzenia danej funkcjonalności (rozmawiając z różnymi osobami o konsekwencjach) np. podczas planowania. Nie zawsze mamy możliwość ustrzec się przed błędami bo nawet najlepiej opracowany plan może nie zadziałać.

Co wtedy, gdy funkcjonalności, którymi wszyscy początkowo byli tak podekscytowani, nie powodują entuzjazmu, działają niezgodnie z oczekiwaniami i powodują masę problemów? Stają się po prostu bezużyteczne – tworzą martwe przestrzenie w naszych aplikacjach, które są dla nich szkodliwe. Nie powinniśmy pozwolić, aby produkt stał się “cmentarzykiem” nieudanych pomysłów.

Podejmowanie decyzji

Dochodzimy zatem do punktu w którym pojawiają się pytanie jakie funkcjonalności powinniśmy usunąć?

Jest wiele sposobów, które pozwalają nam podjąć odpowiednie kroki. Na początku warto wziąć pod uwagę dwie kwestie: częstotliwość korzystania z funkcjonalności przez użytkowników oraz jej znaczenie dla aplikacji.

Poprzez ocenianie rzeczy na podstawie dwóch osi  – częstotliwości i krytyczności – jesteśmy w stanie wnieść pewien obiektywizm do rozmowy z zespołem, o przyszłości danej funkcjonalności.

Jak mierzymy częstotliwość i krytyczność? Odpowiedź brzmi: to zależy.

Każdy produkt jest inny, a charakter zastosowania jest bardzo szeroki.

• Aby określić krytyczność, zadaj sobie pytanie: „Czy nasi użytkownicy mogą w pełni wykonać podstawowe zadanie w naszym produkcie bez tej funkcjonalności?” Jeśli odpowiedź brzmi „tak”, prawdopodobnie nie jest to funkcjonalność krytyczna. Może być ona interesująca i popularna, ale nie jest krytyczne.
• Częstotliwość natomiast wymaga pomiaru. Powinniśmy mierzyć interakcje związane z daną funkcjonalnością w oparciu o wcześniej ustalone KPI. Można podpiąć eventy w Google Analytics, które umożliwiają weryfikację, z których funkcjonalności czy też elementów interfejsu użytkownicy korzystają, a z których nie. Więcej można przeczytać tutaj.

Podział funkcjonalności

Często używane, krytyczne

Stanowią rdzeń produktu  – może to być możliwość zakupów i płatności w sklepie internetowym. Są to funkcjonalności, z których użytkownicy korzystają w aplikacji stale i bez nich produkt by nie zaistniał na rynku.

Często używane, niekrytyczne

Te funkcjonalności są często używane, ale jeśli znikną, klienci nadal będą mogli korzystać z produktu. Są one atrakcyjne dla użytkownika – mogą to być np. powiadomienia e-mail, sortowanie, wyszukiwanie i inne ulepszenia należące do tej kategorii.

Rzadko używane, krytyczne

Mają kluczowe znaczenie dla zapewnienia użytkownikom możliwości właściwego korzystania z produktu, ale nie są często używane. Powinny być stabilne, ale to nie jest miejsce na innowacje – mam tutaj na myśli np. opcję zapomniałem hasła do konta, itp.

Rzadko używane, niekrytyczne

To właśnie funkcjonalności do usunięcia – są obojętne użytkownikowi. Mogą za niedługo stać się bezużyteczne. Nie są ważne i nie są często używane.

Kiedy jeszcze pozbywać się funkcjonalności?

W trakcie cyklu życia produktu mamy bardzo dużo sytuacji podczas których musimy podejmować ważne decyzje dotyczące dodania lub usunięcia funkcjonalności produktu. Pamiętajmy, że brak reakcji w kluczowych momentach (teraz)  może kosztować nas (w przyszłości) przedwczesne zakończenie życia produktu, co w efekcie końcowym może nawet spowodować bankructwo firmy.

Poniżej kilka dodatkowych powodów dlaczego i kiedy warto pozbyć się lub zrezygnować z budowania nowej funkcjonalności w produkcie:

Powód 1. Funkcjonalność ciężka w implementacji i utrzymaniu

Jeśli zaplanowana funkcjonalność wymaga głębokich zmian w produkcie np. przebudowania bazy danych lub kluczowych elementów produktu powinieneś się zastanowić czy opłaca się tzw. “skórka za wyprawkę”. Pamiętaj, że im dalej w las tym więcej drzew, także może pojawić się więcej problemów. Przemyśl czy wprowadzona funkcjonalność jest tego warta.

Powód 2. Koszmarki podczas testowania

Nie wszystko działa w sposób zamierzony. Co wtedy gdy zapętlamy się i deweloper “gra w ping-ponga” z testerem? Znowu mamy do czynienia z decyzją opartą na ROI. Ile pracy trzeba poświęcić, aby to naprawić? Czy warto? Jak dana funkcjonalność wpłynie na inne?

Powód 3. Ofiara Pivota

Po zmianie modelu biznesowego, kilka funkcjonalności straciło całkowicie sens – stały się bezużyteczne i tylko powodują trudności podczas testowania i implementacji nowych. Ważne miejsca w aplikacji zajmowane są przez nieużywane opcje, które nie wnoszą wartości dla użytkownika (wcześniej były kluczowe). Chyba nie trzeba powtarzać, że taka sytuacja wymaga szybkiego usunięcia zbędnych funkcjonalności.

Powód 4. Złożoność

Bardzo często mamy do czynienia z sytuacją kiedy to klient nie zdaje sobie sprawy, że jego prośba o “małą”  funkcjonalność jest bardzo złożona np.: “proszę tylko dodać opcję rejestracji i logowania dla użytkowników”. Na etapie rozmów z zespołem deweloperskim możemy dowiedzieć się bardzo dużo o potencjalnych przeszkodach podczas tworzenia ficzera. Takie sytuacje trzeba wyłapywać w bardzo wczesnej fazie i oczywiście blokować. Jeśli funkcjonalność jest zbyt duża lub nie warta wysiłku pracy zespołu deweloperskiego powinniśmy powiedzieć “NIE”.

Powód 5. Tzw. “zabójca” roadmapy

Pamiętajmy, że roadmapa powinna być regularnie odświeżana, aby uniknąć wprowadzenia funkcjonalności, które były wcześniej zaplanowane, ale obecnie nie są nikomu potrzebne bo rynek uległ zmianie np. zmniejszył się popyt. Usunięcie funkcjonalności  z poziomu roadmapy produktu to odważny krok bo rozmawiamy tutaj o dość dużym obszarze produktowym. Jeśli mamy przesłanki, że dana funkcjonalność będzie zbyt trudna do realizacji z technicznego punktu widzenia, wymagała zbyt wielu zasobów lub po prostu nie jest warta inwestycji –  nie powinniśmy mieć skrupułów, aby usunąć ją z roadmapy. Taka decyzja pozwoli nam na podjęcie prac nad ficzerami, których jesteśmy w 100% pewni, bez zagrożenia, że nie będziemy w stanie dowieźć wydania na czas.

Powód 6. Kula u nogi w backlogu

Sytuacja ma miejsce kiedy wrzucamy każdą możliwą funkcjonalność do backlogu, uginając się pod presją interesariuszy. Wierzą , że ich  funkcjonalność zostanie w końcu wdrożona bo nikt jej wcześniej nie zablokował. Problem w tym, że w związku z natłokiem prac, nie zostają podjęte żadne działania bo każdy kolejny pomysł okazuje się bardziej wartościowy. Przeglądając backlog, cały czas widzimy zgłoszony pomysł – niestety zostaje on za każdym razem zepchnięty na spód backlogu, a życie toczy się dalej. Nie zmienia to faktu, że jest to “kula u nogi”, którą musimy rozpatrywać i marnować na nią czas. Jeśli znasz sytuacje z autopsji, lepiej szybko spotkaj się z zainteresowanymi stronami i uargumentuj usunięcie funkcjonalności z backlogu.

Powód 7. Użytkownicy nie używają wprowadzonego ficzera

Ten powód nie wymaga komentarza. Wprowadzona funkcjonalność nie jest używana przez klienta, co oznacza, że nie przynosi dodatkowej wartości dla produktu. Może w przyszłości powodować problemy podczas implementacji innych pomysłów w aplikacji. Należy ją jak najszybciej usunąć.

Powód 8. Drastyczny spadek użytkowników produktu

Klienci korzystają z danej funkcjonalności, ale jej nienawidzą. Być może nie spełnia wszystkich oczekiwań użytkownika albo powoduje wolne działanie produktu. Niezależnie od tego, czy jest to kiepski interfejs użytkownika czy jakiś techniczny problem – obserwujemy spadek użytkowników produktu.

Powinniśmy szybko wyrzucić niedziałającą (w odpowiedni sposób) funkcjonalność, aby zminimalizować negatywne odczucia i ograniczyć ekspansję użytkowników.

Powód 9. Kolizja z innymi funkcjonalnościami

Funkcjonalność blokuje atrakcyjność  innej co oznacza, że możesz nie być w stanie sprzedać pakietu premium, ponieważ coś, co oferujesz w darmowym pakiecie bardziej odpowiada użytkownikom lub może być prostsze niż posiadanie dwóch funkcjonalności rywalizujących o uwagę w tym samym czasie.

Powód 10. Spadająca gwiazda

Dawno temu Twoja funkcjonalność była bardzo popularna, ale z biegiem czasu jest używana przez coraz mniejszą ilość użytkowników, co może powodować utrudnienia w rozwoju produktu. Warto zastanowić się czy wierni fani tego ficzera są dla nas cennymi użytkownikami? Jeśli tak to trzeba być bardzo ostrożnym podczas podejmowaniu decyzji o usunięciu. Jeśli nie, należy znaleźć odpowiednie wytłumaczenie, dlaczego jesteśmy zmuszeni aby go usunąć – przy okazji nie zrażając użytkowników

Powód 11. Osłabiona propozycja wartości produktu

Produkt powinien rozwiązywać dość specyficzne,  wcześniej określone problemy. Nie musi robić wszystkiego innego w tym samym czasie bo może okazać się, że w dłuższej perspektywie nie pomaga użytkownikowi. Może to powodować utratę wartości dla użytkownika, który w najbliższym możliwym czasie, przesiądzie się na produkt, który bardziej odpowiada jego potrzebom. Warto przypomnieć sobie w tym momencie jaka była wizja i cel tworzenia produktu.

Jeżeli wskazaliśmy już najsłabsze punkty naszego produktu i wiemy kiedy będziemy chcieli je usunąć, możemy przejść do ostatniego kroku

Jak usunąć funkcjonalność z produktu?

Poniżej przedstawię kilka sposobów:

• Usunięcie funkcjonalności produktu bez informowania użytkowników.

Z narzędzi analitycznych wynika, że wykorzystuje ją jedynie mała część wszystkich użytkowników. Jeśli funkcjonalność nie jest naprawdę używana, można rozważyć wyłączenie jej całkowicie, bez koniecznej komunikacji. Przy małej ilości zainteresowanych ogromna większość nie zauważy zmiany.

• Odzwyczajanie użytkowników.

Częstym sposobem jest odzwyczajanie użytkowników poprzez częściowe usuwanie funkcjonalności w danej grupie. Proces należy wykonywać powoli aby mieć czas na ocenę ich reakcji. Jeśli nie widzimy żadnego zagrożenia możemy kontynuować usuwanie funkcjonalności (zwiększając jednocześnie ilość użytkowników).

• Usunięcie funkcjonalności produktu wraz z informacją dla użytkowników

Jeżeli duża ilość użytkowników korzysta z danej funkcjonalności należy poinformować ich o zmianach, które będą zachodziły w produkcie. Najczęściej taka sytuacja wymaga odpowiedniej argumentacji. Jeśli wraz ze zmianą użytkownik otrzyma większą wartość, powinien być zadowolony i zapewne ucieszy się z takiego zwrotu.

W obecnych czasach gdzie społeczeństwo wymienia się opiniami w internecie należy być przygotowanym na feedback ze strony użytkownika i konstruktywną krytykę – dlatego zanim wykonasz jakiś ruch – przemyśl dwa razy wszystkie możliwe konsekwencje!

Skontaktuj się ze wszystkimi działami w firmie (techniczny, obsługa klienta, handlowy i inne mające informację kontakt z produktem) aby upewnić się, że nikt nie będzie zaskoczony Twoją decyzją.

Poinformuj klientów jeśli chcesz usunąć lub zmodyfikować ważną funkcjonalność. Daj im wystarczająco dużo czasu na przygotowanie się do przejścia na nową funkcjonalność.

Wnioski

Prawdopodobnie już wiesz, co należy usunąć. Odetnij “martwe gałęzie” i utoruj drogę, aby umożliwić pojawienie się wzrostu, który naprawdę podnosi wartość twojego produktu. Pamiętaj, że nie jest to liczba jego funkcjonalności i nie chodzi o to, że jeden klient zagroził, że odejdzie, jeśli nie dodasz jego pomysłu. Wartość Twojego produktu zależy wyłącznie od tego, czy użytkownicy postrzegają go jako rozwiązanie swojego problemu.

Powodzenia!