Przychody, minuty słuchania i pytanie o Boga. Jakie metryki produktowe naprawdę pokazują, że produkt idzie w dobrą stronę

Zapytałam Senior Product Managerów w Pragmatic Coders:

„Jakie metryki warto mierzyć, żeby wiedzieć, że produkt idzie w dobrą stronę?”

W odpowiedziach pojawiły się: przychody, minuty słuchania, zarezerwowane noce, lagging indicators, jakość danych, dług techniczny i pytanie: „czy chcesz porozmawiać o Bogu?”.

Brzmi jak początek bardzo chaotycznej rozmowy? Być może. Ale im dłużej czytałam odpowiedzi, tym wyraźniej widziałam, że w tym szaleństwie jest metoda. Mierzenie produktu to nie tylko wrzucenie kilku efektownych metryk do dashboardu. To przede wszystkim zrozumienie, czym naprawdę jest wartość w danym produkcie, jak rozpoznać, że użytkownik ją otrzymał i jak szybko możemy się przekonać, czy to, co tworzymy, rzeczywiście działa.

Bo w jednym produkcie najważniejszym sygnałem będą przychody. W innym – minuty spędzone na słuchaniu muzyki. W kolejnym – liczba zarezerwowanych nocy, skrócony czas obsługi procesu, mniejsza liczba błędów albo spadek ręcznej pracy wykonywanej poza systemem.

Oto pięć różnych sposobów patrzenia na metryki produktowe — każda z nich ukazuje inny aspekt tego zagadnienia. Razem tworzą praktyczny framework, z którego korzystamy w Pragmatic Coders, gdy klient pyta nas, czy jego produkt zmierza w dobrą stronę.

Kluczowe wnioski

• Nie istnieje uniwersalny zestaw metryk produktowych. Wartość, którą trzeba zmierzyć, jest specyficzna dla produktu i etapu jego rozwoju.
• Większość metryk, po których poznaje się sukces (przychód, NPS, liczba leadów), to lagging indicators. Mówią o przeszłości. Do bieżącego sterowania potrzebujesz metryki proxy, silnie skorelowanej z celem biznesowym.
• Produkt warto mierzyć w siedmiu wymiarach równolegle: adopcja, skuteczność procesu, jakość i stabilność, jakość danych, delivery i przewidywalność, koszt i skalowalność, jakość decyzji produktowych.
• Dobra metryka to taka, po której zmianie zespół wie, co powinien zrobić inaczej. Pięć trafnych wskaźników bije na głowę dashboard z czterdziestoma.

Co właściwie chcemy zmierzyć? Najpierw zdefiniuj wartość

Pierwsza odpowiedź na moje pytanie padła krótka i właściwie ucięła całą dyskusję o „uniwersalnym zestawie metryk”.

„Myślę, że to mocno zależy, co to za produkt. To zależy, co jest dowodem na to, że użytkownik dostał wartość. Na przykład w Spotify to są minuty słuchane, w Airbnb – noce zarezerwowane.”

– Darek Tarasek, Senior Product Manager w Pragmatic Coders

Każdy z tych produktów ma własną North Star Metric – jedną liczbę, która najlepiej oddaje moment, w którym użytkownik faktycznie skorzystał z produktu. W Spotify nie jest to liczba kont premium ani nawet liczba zalogowań, tylko czas spędzony na słuchaniu, bo to słuchanie jest tym, po co użytkownik przyszedł. W Airbnb nie liczy się liczba odwiedzin strony, tylko liczba zarezerwowanych nocy, bo dopiero rezerwacja oznacza wymianę wartości między gospodarzem, gościem i platformą.

Wiktor domyka tę myśl od strony biznesu i robi to znacznie ostrzej.

„Przychody. Dopiero tak naprawdę to pokazuje, czy produkt ma sens.”

– Wiktor Żołnowski, CEO i co-founder Pragmatic Coders

To, co mówi Darek, i to, na czym zależy Wiktorowi, wcale się nie wyklucza – to po prostu dwa spojrzenia na ten sam temat. North Star Metric pozwala sprawdzić, czy użytkownik wraca po wartość. Przychód pokazuje, czy tę wartość faktycznie udaje się zamienić na stabilny biznes. Jeśli North Star idzie w górę, a przychód nie – prawdopodobnie masz problem z monetyzacją lub propozycją wartości. Jeśli przychód rośnie, ale North Star spada – chwilowo „kupujesz” wzrost, tracąc jednocześnie podstawę produktu, co szybko odbije się na retencji.

Zanim wybierzesz jakąkolwiek metrykę produktową, odpowiedz na dwa pytania:

1. Co w Twoim produkcie jest dowodem na to, że użytkownik dostał wartość?
2. W którym momencie ta wartość zamienia się w wynik biznesowy?

Jeżeli nie potrafisz odpowiedzieć w jednym zdaniu na każde z nich, żaden framework metryk Cię nie uratuje.

Większość kluczowych metryk to lagging indicators. Po co Ci metryka proxy

Tu pojawia się kolejny problem: metryki, które najlepiej obrazują sukces produktu, zazwyczaj nie nadają się do bieżącego zarządzania nim.

„W skrócie – najczęściej metryka, która pokazuje sukces produktu, jest metryką opóźnioną (lagging indicator). Więc mierzenie jej na bieżąco nic nie daje. Ona potwierdza, że się udało, ale wtedy to tak naprawdę już wiesz, że się udało. Bo produkt musi się spinać biznesowo – więc np. przychód albo ilość wygenerowanych leadów, albo NPS, to są metryki opóźnione. Nic się z nich nie dowiesz na bieżąco, ale jak są wysoko, znaczy że jest OK.”

– Bartek Czarnecki, Senior Product Manager w Pragmatic Coders

Lagging indicator – metryka opóźniona. Potwierdza wynik po fakcie. Przykłady: roczny przychód, NPS, retencja 12-miesięczna, liczba odnowień kontraktu.

Leading indicator / metryka proxy – metryka pośrednia, silnie skorelowana z lagging indicator, ale mierzalna na bieżąco. Pozwala reagować, zanim wynik się zmaterializuje. Przykłady: activation rate w pierwszych 7 dniach, częstotliwość kluczowej akcji w tygodniu, time-to-value.

Klasyczny przykład tego mechanizmu pochodzi z Facebooka.

„Najbardziej znana metryka proxy: Facebook’s famous early proxy was getting a user to connect with 10 friends in 7 days. Zdobycie 10 znajomych w 7 dni – to jest fajne do mierzenia, bo masz wyniki praktycznie codziennie. Każdy dzień to nowa kohorta. Możesz to monitorować i szybko reagować. A okazało się być bardzo silnie skorelowane z pozostaniem na platformie Facebooka i długofalowymi celami firmy.”

– Bartek Czarnecki, Senior Product Manager w Pragmatic Coders

Tę zasadę można zastosować praktycznie do każdego produktu. W przypadku SaaS B2B, jako metryka proxy najczęściej sprawdza się liczba zaproszonych do zespołu użytkowników w pierwszym tygodniu lub liczba najważniejszych akcji wykonanych przed końcem okresu próbnego. W marketplace’ach typową metryką będzie stosunek liczby zapytań po stronie popytu do liczby aktywnych dostawców w danym czasie. W produktach operacyjnych warto mierzyć odsetek procesów obsłużonych od początku do końca w nowym systemie, bez konieczności wracania do Excela.

Najlepiej to ująć tak: do każdej metryki opóźnionej (lagging metric), którą pokazujesz zarządowi, dobierz jedną metrykę pośrednią (proxy metric), którą zespół może śledzić na bieżąco, najlepiej codziennie. Jeśli przez dwie kolejne kohorty ta metryka proxy idzie w dobrą stronę, metryka opóźniona prawdopodobnie również pójdzie za nią.

Produkt to nie jedna liczba. 7 wymiarów, które warto mierzyć równolegle

Najbardziej rozbudowaną odpowiedź na moje pytanie dał Krzysztof Pykosz. Wychodzi on z mocnej tezy:

„Z mojej perspektywy najważniejsze jest to, żeby nie mierzyć produktu wyłącznie przez pryzmat »ile funkcji dowieźliśmy«. To jest częsty błąd. Produkt może mieć coraz więcej funkcjonalności, a jednocześnie coraz gorzej rozwiązywać realny problem użytkownika albo generować coraz większy koszt utrzymania.”

– Krzysztof Pykosz, Senior Product Manager w Pragmatic Coders

Dobre metryki produktowe odpowiadają na trzy pytania:

1. czy użytkownicy faktycznie używają produktu w kluczowych procesach,
2. czy produkt poprawia wynik biznesowy lub operacyjny,
3. czy jesteśmy w stanie rozwijać go stabilnie i bez rosnącego długu technicznego.

Z tych trzech pytań Krzysztof wyprowadza siedem wymiarów, które warto mierzyć równolegle.

1. Adopcja i realne użycie. Procent kluczowych procesów obsługiwanych w nowym systemie, liczba aktywnych użytkowników w podziale na role, udział użytkowników korzystających z nowych funkcji, liczba przypadków, w których ludzie nadal wracają do Excela, starego systemu albo ręcznej pracy. To ostatnie jest krytyczne. Jeżeli produkt formalnie istnieje, ale operacje muszą obchodzić go bokiem, adopcja jest pozorna, a metryka „funkcja wdrożona” niewiele mówi.

2. Skuteczność procesu. Skuteczność zakończenia procesu, liczba błędów operacyjnych, czas obsługi pojedynczego przypadku, liczba ręcznych korekt, liczba reklamacji, procent przypadków zamykanych bez interwencji supportu. To są metryki bliżej biznesu niż developmentu. Pokazują, czy system realnie poprawia jakość działania organizacji.

3. Jakość i stabilność. Liczba incydentów produkcyjnych, czas reakcji i czas rozwiązania incydentu, liczba hotfixów, liczba regresji po wdrożeniach. Najbrutalniej szczera bywa ostatnia metryka z tej kategorii: procent czasu zespołu zużywany na utrzymanie i gaszenie pożarów. Jeżeli coraz większa część sprintu idzie na naprawy, a nie na rozwój, produkt nie idzie w dobrą stronę, nawet jeśli roadmapa wygląda ambitnie.

4. Jakość danych. W wielu produktach dane są produktem. Warto mierzyć kompletność danych, liczbę błędnych rekordów, liczbę konfliktów między źródłami, opóźnienia synchronizacji, liczbę nieudanych importów, procent procesów wymagających ręcznej korekty danych. Brak jednego źródła prawdy bardzo szybko zwiększa koszt rozwoju, ryzyko błędów i liczbę problemów operacyjnych.

5. Delivery i przewidywalność zespołu. Lead time, cycle time, throughput, stosunek pracy rozwojowej do utrzymaniowej, WIP (ile pracy jest rozpoczęte równolegle), czas spędzony w poszczególnych statusach, przewidywalność realizacji sprintu. Te metryki pomagają wykryć problem wcześniej. Jeżeli zadania długo wiszą w jednym statusie, WIP rośnie, a throughput spada, to zwykle oznacza problem z procesem, zależnościami, jakością wymagań albo architekturą.

6. Koszt i skalowalność. Miesięczny koszt infrastruktury, koszt obsługi pojedynczej transakcji, latency, liczba timeoutów, stopień wykorzystania baz danych, relacja kosztów utrzymania do kosztów rozwoju. Produkt może zyskiwać nowe funkcje, ale równocześnie stawać się coraz droższy i trudniejszy do utrzymania. Te metryki pozwalają zauważyć ten problem, zanim wykażą go analizy finansowe.

7. Jakość decyzji produktowych. Często pomijana kategoria. Ile hipotez produktowych zostało zweryfikowanych, ile funkcji realnie poprawiło mierzalny wskaźnik, ile nie przyniosło oczekiwanego efektu, jak często decyzje są podejmowane na podstawie danych, a nie opinii, jak szybko po wdrożeniu umiemy ocenić efekt zmiany. Dobre zarządzanie produktem nie polega na tym, żeby zawsze mieć rację, ale na tym, żeby szybko sprawdzać założenia i umieć zmienić decyzję, gdy dane mówią co innego.

Etap produktu zmienia, co warto mierzyć

Te siedem wymiarów nie jest checklistą, którą trzeba odhaczyć od jutra. Wagi zmieniają się w zależności od etapu produktu.

• Nowy produkt, świeży market fit. Liczy się przede wszystkim adopcja, activation rate, retencja kohortowa i walidacja, czy w ogóle rozwiązujesz realny problem. Jakość danych oraz koszt jednostkowy obsługi pojedynczego użytkownika lub transakcji są drugorzędne, bo skala jest jeszcze zbyt mała, żeby coś z nich wynikało.
• Produkt operacyjny, wspierający codzienne procesy. Liczy się stabilność, skuteczność procesu i redukcja pracy manualnej. Tu największą wartością bywa to, czego nie ma na ekranie: brak incydentów, brak ręcznych korekt, brak obejść w Excelu.
• Produkt skalujący się. Liczy się wydajność, koszt jednostkowy obsługi transakcji i jakość architektury. Wzrost przychodu, który dwukrotnie podnosi koszt infrastruktury, jest pułapką, którą trzeba wyłapać metrykami kosztu, nie metrykami sprzedaży.
• Produkt po przejęciu albo po dużym długu technicznym. Liczy się liczba incydentów, liczba regresji, koszt utrzymania i przewidywalność delivery. Dopóki te metryki nie wrócą do normy, rozmowa o nowych funkcjach jest przedwczesna – choć w Pragmatic Coders od pierwszego dnia ratowania projektu z długiem technicznym staramy się dostarczać nową wartość biznesową, nie tylko naprawiać istniejący chaos.

W praktyce większość produktów jest w więcej niż jednej fazie naraz – na przykład część funkcjonalności jest dojrzała, a część dopiero szuka product-market fit. Wtedy mierzysz każdą część innym zestawem wskaźników i nie próbujesz na siłę uśrednić.

Dobra metryka to taka, po której wiesz, co zrobić inaczej

Pokusa po przeczytaniu poprzednich dwóch sekcji jest oczywista: zbudować dashboard z czterdziestoma metrykami i odhaczyć temat. To pułapka.

„Moja praktyczna rekomendacja: nie budować dashboardu z 40 metrykami. Lepiej wybrać kilka wskaźników, które realnie wpływają na decyzje. Dobra metryka to taka, po której zmianie zespół wie, co powinien zrobić inaczej.”

– Krzysztof Pykosz, Senior Product Manager w Pragmatic Coders

Uważamy, że minimalny zdrowy zestaw metryk produktowych obejmuje pięć kategorii, po jednej, maksymalnie dwóch metrykach w każdej:

• Biznes. Czy produkt dowozi wartość finansową (np. MRR, marża, koszt pozyskania klienta).
• Użycie. Czy ludzie faktycznie z niego korzystają (North Star Metric, retencja kohortowa, activation rate).
• Jakość. Czy działa stabilnie (liczba incydentów, czas rozwiązania, regresje).
• Delivery. Czy zespół dowozi przewidywalnie (cycle time, throughput, stosunek pracy rozwojowej do utrzymaniowej).
• Tech i koszt. Czy produkt da się rozwijać bez rosnącego długu (koszt jednostkowy operacji, latency, udział pracy utrzymaniowej w sprincie).

Lepiej mieć pięć najważniejszych wskaźników, do których regularnie wracasz, niż czterdzieści, na które nikt nie zwraca uwagi. Dashboard powinien wspierać podejmowanie decyzji, a nie dawać złudzenie kontroli.

Jeśli chcesz pójść głębiej, czyli pytanie o Boga

Tutaj wraca otwarcie tego artykułu. Na pytanie o metryki Michał Kania odpowiedział tak.

„Równie dobrze mogłabyś zacząć tę rozmowę… »Czy chcesz porozmawiać o Bogu?« To temat rzeka.”

– Michał Kania, Senior Product Manager w Pragmatic Coders

Pod żartem kryje się konkretna lista źródeł, z których warto czerpać, jeśli temat metryk produktowych chce się potraktować poważnie. Część z nich Michał wymienia jako te, które ukształtowały jego sposób myślenia, część jako narzędzia, których używa na co dzień:

• Lean Startup Analytics (Eric Ries oraz Alistair Croll i Ben Yoskovitz). Tu Michał wskazuje wprost, że to podejście ukształtowało jego myślenie o metrykach. Z tej tradycji pochodzi rozróżnienie na vanity metrics i actionable metrics oraz koncepcja One Metric That Matters dla danego etapu produktu.
• Obeya – koncepcja zarządzania wizualnego wywodząca się z Toyota Production System (jap. obeya dosł. „duży pokój”). To fizyczna lub cyfrowa przestrzeń, w której zespół ma stale na oczach cele, kluczowe metryki, hipotezy, blokery i decyzje. Wymusza wspólny obraz sytuacji zamiast pięciu różnych dashboardów dla pięciu różnych ról. Michał stosuje to podejście aktualnie u siebie.
• Impact Mapping Gojko Adzica. Łączy cele biznesowe z kluczowymi osobami lub grupami (klientami, użytkownikami, zespołem), ich zachowaniami i konkretnymi rezultatami w produkcie. To podejście pomaga jasno określić sens każdej mierzonej metryki i powiązać ją z realizacją celów – żeby metryka nie wisiała w próżni „bo wszyscy ją mierzą”.
• Outcome z User Story Mappingu (Jeff Patton, w praktyce też Josh Seiden, Outcomes Over Output). Outcome to mierzalna zmiana zachowania użytkownika, a nie dostarczona funkcja. Michał ujmuje to wprost: outcome = zmiana zachowań, na przykład „użytkownik może coś zrobić szybciej”. I właśnie to „szybciej” jest mierzalne – to jest dobra metryka produktowa.
• Systems Thinking (Donella Meadows, Russell Ackoff, Peter Senge). Pomaga nie wpaść w pułapkę optymalizacji jednej metryki kosztem całego systemu. Klasyczny przykład: średni czas obsługi w call center spada, bo agenci kończą rozmowę, zanim rozwiążą problem klienta. Metryka idzie do góry, biznes do dołu.
• „How to Measure Anything” Douglasa W. Hubbarda. Praktyczny argument za tym, że nawet rzeczy uznawane za niemierzalne (zadowolenie użytkownika, ryzyko, wartość strategiczna) da się zmierzyć z użytecznym poziomem precyzji, jeśli tylko jasno zdefiniujesz, co właściwie chcesz wiedzieć i jaką decyzję na podstawie tej wiedzy podejmiesz.

To są ramy, których w Pragmatic Coders używamy najczęściej, kiedy projektujemy z klientem zestaw metryk dla nowego produktu albo audytujemy istniejące dashboardy.

Co łączy te pięć perspektyw

Pięć osób, pięć różnych perspektyw – i pięć ważnych pytań, które realnie mogą pomóc poukładać myślenie o metrykach:

1. Czym dla naszego użytkownika jest wartość? (Darek)
2. Jak ta wartość zamienia się w wynik biznesowy? (Wiktor)
3. Po jakiej metryce proxy poznamy, że idziemy we właściwą stronę, zanim wynik biznesowy się zmaterializuje? (Bartek)

Kolejne kwestie pojawiają się już bardziej w komentarzach Krzysztofa i Michała – odnoszą się do praktycznych doświadczeń i ram, z których korzystają liderzy produktu:

• Na jakim etapie jest produkt i które z tych wymiarów są dziś priorytetem? (Krzysztof)
• Z jakich źródeł i frameworków warto czerpać inspirację, żeby nie wymyślać koła od zera? (Michał)

Odpowiadając na pierwsze trzy pytania względem swojego produktu, a następnie korzystając z gotowych ram i sprawdzonych perspektyw liderów, można przełożyć „chaos” z początku artykułu na konkretną mapę decyzji – i korzystać z niej na bieżąco, nie tylko od święta.

Od czego zacząć w swoim produkcie

Jeśli po lekturze tego artykułu chcesz sprawdzić, w których obszarach Twój produkt najbardziej potrzebuje poprawy, w Pragmatic Coders przygotowaliśmy trzy bezpłatne narzędzia do autodiagnozy – po jednym dla każdej z trzech warstw opisanych powyżej:

• Product Health Checklist (PHC 2.0) – warstwa produktowa. Audytuje strategię produktu, discovery, priorytetyzację oraz jakość decyzji produktowych. Najlepiej odpowiada na wymiary 1, 2 i 7 z framework’u Krzysztofa (adopcja, skuteczność procesu, jakość decyzji).
• Scrum Health Checklist (SHC) – warstwa delivery. Sprawdza, czy Scrum w Twoim zespole rzeczywiście dowozi Transparency, Inspection i Adaptation, czy tylko rytuały. Pokrywa wymiar 5 (delivery i przewidywalność zespołu).
• Technical Health Checklist (THC) – warstwa inżynieryjna. Audytuje architekturę, testy, CI/CD, observability, dane i bezpieczeństwo. Pokrywa wymiary 3, 4 i 6 (jakość i stabilność, jakość danych, koszt i skalowalność).

Każda z checklist zajmuje około 30 minut i wychodzi z niej priorytetyzowana lista konkretnych luk do zamknięcia.

Jeśli czujesz, że problem nie kończy się na metrykach i leży głębiej – dotyczy sposobu organizacji pracy po obu stronach projektu – zachęcamy do zapoznania się z naszym ebookiem „8 ways companies sabotage their own projects”. Publikacja powstała na bazie rozmów z naszymi Senior Product Managerami, CTO i Service Delivery Managerem i skupia się na typowych schematach działania, które po cichu osłabiają budżet i motywację zespołu – często w sposób trudny do wychwycenia samymi metrykami produktowymi.