Metryki produktowe - brakujące narzędzie inżyniera produktu
Czyli w jaki sposób budować most pomiędzy rozwiązaniami, a przychodami firmy.
Jako inżynierowie często frustrujemy się brakiem wpływu na biznes. Dostarczamy funkcję za funkcją, ale nie potrafimy przełożyć naszej pracy na wyniki organizacji. Między kodem a przychodami jest przepaść - nie wiemy jak ją wypełnić.
Jak zwykle działają zespoły
Skupienie na wdrożonych rozwiązaniach to norma w większości zespołów. “Zrobiliśmy 10 feature’ów w tym sprincie”, “Wdrożyliśmy nowy system płatności”, “Ukończyliśmy migrację do nowej architektury”. Te metryki dominują w naszych rozmowach. Mierzymy ile dostarczamy, nie czy to coś zmienia.
Czasami ktoś zapyta o wyniki biznesowe - czy wzrosły przychody, czy spadły koszty operacyjne. Problem w tym, że między wdrożonymi rozwiązaniami a przychodami firmy jest przepaść. Nie wiemy co się dzieje pomiędzy. Nie wiemy co powinniśmy mierzyć.
Nikt systematycznie nie monitoruje czy użytkownicy faktycznie korzystają z tego, co zbudowaliśmy:
Wdrożyliśmy nowy system rekomendacji produktów, ale czy ktokolwiek z niego korzysta?
Zoptymalizowaliśmy proces zakupowy, ale czy faktycznie coś to dało?
Zrefaktorowaliśmy moduł płatności, ale czy to przyspieszyło rozwój?
W rezultacie próbujemy bezpośrednio powiązać wdrożone rozwiązania z wynikami finansowymi. To się nie może udać - zbyt duży przeskok.
Powstaje jednak pytanie...
Dlaczego to jest ważne dla inżynierów
Bo możemy się tym nie przejmować. Ale ostatecznie “mimo wszystko” warto 🙃
Zbyt wolna pętla zwrotna
To pierwszy problem, który uderza w naszą pracę. Piszemy kod, deployujemy, i... cisza. Feedback przychodzi po miesiącach.
Bez szybkiej informacji zwrotnej nie możemy ocenić czy nasze decyzje były słuszne. Czy ten refactoring coś dał? Czy optymalizacja faktycznie pomogła? Czy nowa funkcja w ogóle jest używana?
Pracujemy w ciemno. Każda kolejna zmiana to strzał w nieznane. Nie wiemy co działa, a co leży odłogiem. Bez tego kontekstu nie potrafimy się uczyć ani poprawiać.
Narracje bez danych
Ten problem pojawia się gdy wyniki biznesowe spadają. Przychody nie rosną jak planowano. Retencja maleje. Ale dlaczego? Nikt nie wie. Nie ma nici łączących nasze wdrożone rozwiązania z wynikami biznesowymi.
W rezultacie szukamy winnych, a nie przyczyn:
“To wina tego feature’a, który zespół X wdrożył”
“Gdyby Y nie nalegał na tę zmianę, byłoby OK”
“Ten refactoring zepsuł wszystko”
Obrzucamy się winą zamiast analizować fakty. Tworzymy narracje oparte na domysłach. Polityka zastępuje dane.
Brak odpowiedzialności zespołu
Skoro nie wiemy jak nasza praca wpływa na użytkowników, to dlaczego mielibyśmy się przejmować? “Zrobiliśmy zgodnie ze specyfikacją” - staje się naszą tarczą.
Tracimy ownership. Stajemy się wykonawcami, nie współtwórcami produktu. Nikt nie czuje się odpowiedzialny za efekt końcowy.
Brak uzasadnienia dla usprawnień
To codzienność każdego lidera technicznego. “Musimy zrefaktorować ten moduł” - mówisz na planowaniu. “A ile to przyniesie pieniędzy?” - słyszysz w odpowiedzi.
Trudno bezpośrednio znaleźć przełożenie zmian technicznych na wyniki biznesowe. Brakuje pośrodka, który połączyłby refactoring z zyskami firmy. Między naszym kodem a przychodami jest przepaść - ta sama, o której mówiliśmy na początku.
Output-Outcome-Impact
Podział Output-Outcome-Impact to sposób myślenia, który pozwala zrozumieć jak praca inżynierska przekształca się w wartość biznesową.
Poniżej znajduje się grafika, która bazuje na tej z artykułu Output vs Outcome vs Impact Christophe’a Achouiantza.
Output to nasza codzienna praca. Namacalna i mierzalna w ticketach i feature’ach.
Outcome to efekt naszej pracy widziany oczami użytkownika. Zmiana ich zachowań i sposób korzystania z produktu.
Impact to wymierny efekt biznesowy dla organizacji. Liczby, którymi żyje C-level.
Metryki produktowe znajdują się między tym, co robimy, a efektem biznesowym. Pokazują jak użytkownicy faktycznie korzystają z naszych rozwiązań.
Kluczowe jest zrozumienie, że te elementy są ze sobą połączone. Nasz Output generuje Outcome (zmianę zachowań użytkowników). Ten z kolei generuje Impact (wyniki biznesowe).
Korzyści z metryk produktowych
Zbudowanie mostu pomiędzy rozwiązaniami, a wpływem biznesowym ma kilka zalet:
Szybsza pętla zwrotna - Dni czy tygodnie zamiast miesięcy. Wiemy czy nasze decyzje były słuszne, zanim projekt się zakończy.
Możliwość korygowania kursu - Zmiany można wprowadzać zanim dotrą do Impact. Nie czekamy aż metryki biznesowe pokażą problem.
Wspólny język z biznesem - Zamiast “Zrobiliśmy nowy onboarding” mówimy “60% użytkowników ukończyło onboarding (vs 30%)”. Liczby zastępują domysły.
Uzasadnianie usprawnień technicznych - “Refactoring przyspieszy wdrażanie zmian w X, co poprawi metric Y”. Znajdujemy brakujący pośrednik między kodem a zyskami.
Usprawnienia techniczne przestają być “zachciankami” inżynierów. Stają się inwestycjami w lepsze wyniki biznesowe.
Od czego zacząć
Krok 1: Wybierz jedną funkcję do obserwacji
Weź na tapet feature czy epic, nad którym obecnie pracujesz. Wybierz coś istotnego, ale nie krytycznego - potraktuj to jako eksperyment.
Krok 2: Określ co będziesz obserwować
Zadaj sobie pytanie: jak zaobserwujesz zmianę zachowania klienta?
Jakie akcje użytkownik wykona inaczej niż dotychczas?
Które ekrany/funkcje zacznie częściej odwiedzać?
Co przestanie robić, bo nowe rozwiązanie jest lepsze?
Jak zmieni się jego ścieżka w produkcie?
Krok 3: Zbuduj minimalną obserwowalność
Potrzebujesz narzędzia do obserwowania zachowań użytkowników. To może być Posthog, Amplitude, a nawet prosty dashboard w Kibanie.
Nie musisz od razu kupować drogich rozwiązań. Zacznij od tego, co masz pod ręką.
Krok 4: Poczekaj aż zmiana się wygrzejeje
Daj zmianie czas na wygrzanie się. Tydzień, dwa, może miesiąc - w zależności od częstotliwości użytkowania produktu.
Dopiero wtedy oceń wyniki. Zbyt wczesna ocena pokaże tylko szum, nie prawdziwy trend.
Krok 5: Wprowadź rytm przeglądu
Wprowadź regułę: wszystkie kolejne funkcje muszą być obserwowane produktowo. Ustal stały punkt w kalendarzu na przegląd obserwacji:
Sprint review z danymi o zachowaniach użytkowników.
Retrospektywy oparte o fakty, nie domysły.
Decyzje produktowe wsparte obserwacjami.
Krok 6: Argumentuj usprawnienia danymi
Naucz się łączyć usprawnienia techniczne z obserwacjami użytkowników:
“Ten refactoring przyspieszy wdrażanie zmian w X, dzięki czemu więcej użytkowników zrobi Y”
“Spłata długu technicznego zmniejszy liczbę bugów, co zwiększy liczbę powracających użytkowników”
Metryki produktowe to brakujące ogniwo między kodem a wpływem na biznes. Zacznij od jednej funkcji, a zobaczysz jak zmienia się sposób pracy całego zespołu.