Mniej niż 1% kart płatniczych dodanych do aplikacji dużej sieci convenience trafiło tam przez funkcję, która miała być jej największym wyróżnikiem. Rozwiązanie działało technicznie, przeszło testy na klikalnych makietach i uzyskało bardzo dobre wyniki badań. Użytkownicy wybrali jednak trzy inne, prostsze metody.
Krzysztof Heyda odpowiadał za rozwój tej aplikacji jako product owner. Podczas Mobile Trends for Experts 2026 zestawił własne doświadczenie z trzema głośnymi przypadkami z rynku: aplikacją e-TOLL, inwentaryzacją opartą na AI w amerykańskich kawiarniach Starbucks i procesem rezygnacji z Amazon Prime.Każdy z nich pokazuje inny powód, dla którego produkt cyfrowy może zawieść, mimo że zespół miał budżet, kompetencje i dobre intencje.
Wspólnym mianownikiem tych porażek nie jest słaba technologia. Heyda przypisuje je do czterech ryzyk produktowych opisanych przez Marty’ego Cagana: wartości, użyteczności, wykonalności i opłacalności. Ta rama dobrze tłumaczy, gdzie w procesie tworzenia aplikacji zapadają decyzje, które później kosztują najwięcej.
Rynek aplikacji mobilnych nie daje drugiej szansy
Zanim przeszedł do porażek, Heyda przypomniał, w jakich warunkach działają twórcy produktów cyfrowych. Przytoczone przez niego dane pochodzą z różnych rynków i segmentów, więc sam zaznaczał, że trzeba traktować je z ostrożnością. Kierunek jest jednak czytelny: w niektórych aplikacjach nawet 80% funkcji pozostaje w praktyce nieużywanych, a 46% aplikacji znika z telefonów w ciągu 30 dni od instalacji.
Do tego dochodzi zjawisko mniej widoczne w statystykach odinstalowań. Systemy operacyjne same usypiają aplikacje, z których nikt nie korzysta, więc część z nich formalnie zostaje na urządzeniu, ale przestaje istnieć w codziennym użyciu. Dla zespołu produktowego oznacza to, że liczba instalacji coraz słabiej opisuje rzeczywistą obecność aplikacji w życiu użytkownika.
Najbardziej wymowna jest struktura czasu spędzanego na smartfonie. Użytkownik korzysta średnio z około 18 aplikacji dziennie, ale połowę tego czasu pochłania sześć z nich, najczęściej należących do największych graczy, takich jak Facebook, Chrome czy TikTok. Pozostałe aplikacje dzielą między siebie resztę uwagi. W takim otoczeniu każda funkcja, która nie odpowiada na realną potrzebę, oraz każdy proces, który zniechęca w pierwszych dniach, ma bezpośredni wpływ na retencję.
Ryzyko wartości: badanie, które odpowiedziało na złe pytanie
Zespół aplikacji sieci convenience przygotowywał płatności w sklepie: klient skanuje aplikację przy kasie, potwierdza transakcję w telefonie i zakupy są opłacone. Już w MVP przewidziano trzy sposoby dodania karty do portfela w aplikacji: ręczne wpisanie danych, odczyt przez NFC po przyłożeniu karty do telefonu oraz zdjęcie karty rozpoznawane przez OCR.
Czwarta metoda miała być wyróżnikiem. Obietnica brzmiała: „nie rób nic, karta doda się sama przy kasie”. Klient skanuje kartę lojalnościową w aplikacji, płaci zwykłą kartą przy terminalu, a ta po chwili pojawia się w portfelu. Problem polegał na tym, że prostota istniała tylko w opisie koncepcji.
Kolejne wymagania stopniowo rozbudowywały proces. Dział prawny wskazał, że użytkownik musi wcześniej wyrazić zgodę na dodanie karty, więc aplikacja pytała o nią w przypadkowym momencie, zanim klient poszedł do sklepu. Przy kasie trzeba było zapytać ponownie, czy chodzi właśnie o kartę użytą do tej płatności, bo wiele osób ma ich kilka. Analiza ryzyka nadużyć pokazała, że kasjer mógłby podstawić własną aplikację i przejąć kartę klienta, dlatego doszły kod CVC, weryfikacja 3D Secure i PIN. Funkcja, która miała wymagać zera wysiłku, rozciągnęła się na kilka dni, kilka ekranów i kilka interakcji. Każda z trzech pozostałych metod była prostsza.
Zespół widział narastające przeszkody, ale, jak przyznał Heyda, bardzo chciał tę funkcję wydać. Rozwiązanie przetestowano więc z użytkownikami na klikalnych makietach, w profesjonalnie przeprowadzonym badaniu. Pytania dotyczyły jednak tego, czy badani rozumieją proces i wiedzą, co mają zrobić. Nikt nie zapytał, czy zamierzają z niego korzystać. Wyniki były bardzo dobre, a w praktyce metodą tą dodano mniej niż 1% wszystkich kart.
To przykład ryzyka wartości w czystej postaci. Funkcja działała technicznie i była zrozumiała, ale nie rozwiązywała problemu, którego użytkownik nie potrafiłby rozwiązać szybciej w inny sposób. Badanie użyteczności nie zastąpi weryfikacji wartości, a dobrze wypadający test łatwo staje się potwierdzeniem decyzji, którą zespół podjął już wcześniej.
Ryzyko użyteczności: e-TOLL, czyli wymagania przepisane na ekran
Aplikacja e-TOLL, uruchomiona w 2021 roku, służy do opłacania przejazdów po części płatnych dróg w Polsce na podstawie lokalizacji GPS. Sam pomysł jest sensowny, a dla wielu kierowców, zwłaszcza zawodowych, korzystanie z systemu było obowiązkiem. Aplikacja nie musiała więc walczyć o użytkowników z konkurencją, co tym wyraźniej pokazuje, jak duże znaczenie ma sama możliwość przejścia przez proces.
Heyda zastrzegł, że nie zna projektu od środka, ale jego zdaniem wszystko wskazuje na to, że wymagania prawne i szeroko zakrojone wymagania funkcjonalne zostały przeniesione wprost do formularza. Użytkownik musi podać m.in. numer VIN, wybrać dopuszczalną masę całkowitą, określić normę emisji spalin z dodatkowymi dokumentami, a gdy system CEPiK nie odpowiada, dołączyć dowód rejestracyjny jako zdjęcie lub plik PDF. Dla kogoś, kto chce po prostu zapłacić za przejazd autostradą, to zestaw danych trudny do zrozumienia i jeszcze trudniejszy do zgromadzenia.
Skutki widać w ocenach. Według danych pokazanych podczas prelekcji aplikacja miała ocenę 1,6 w fazie testów, 1,3 przed objęciem systemem samochodów osobowych, a po pięciu latach i około 12 tysiącach ocen jej średnia wynosi 1,8. W najnowszych komentarzach użytkownicy wciąż piszą, że nie mogą dodać pojazdu, czyli wykonać podstawowej czynności, do której aplikacja służy.
Ten przypadek dotyczy ryzyka użyteczności. Wymagania mogły być kompletne i zgodne z przepisami, ale nikt nie sprawdził, czy przeciętny użytkownik jest w stanie przez nie przejść. Projektowanie zaczyna się tam, gdzie kończy się lista wymagań: trzeba zdecydować, które dane system może pozyskać samodzielnie, które da się uprościć, a które rzeczywiście muszą trafić na ekran.
Ryzyko wykonalności: AI, która działała tylko w laboratorium
Starbucks w Stanach Zjednoczonych miał realny problem operacyjny. Ponad 11 tysięcy kawiarni regularnie liczy zapasy: kawę, kilka rodzajów mleka, syropy, sezonowe kubki. Inwentaryzacja zabierała pracownikom czas, który mogliby poświęcić klientom. Firma wspólnie z partnerem technologicznym przygotowała aplikację mobilną, która na podstawie zdjęcia półki miała rozpoznawać produkty i ich liczbę. Zapowiadano skuteczność na poziomie 99% i ośmiokrotnie szybsze liczenie niż ręcznie. Narzędzie wdrożono od razu we wszystkich kawiarniach.
W codziennej pracy ujawniły się problemy, których testy nie wychwyciły. Produkty trzeba było ustawiać w równych rzędach, żeby system w ogóle działał, a część kawiarni musiała kupić nowe iPady Pro, bo model działał lokalnie na urządzeniu. Zdjęcie robione przez szybę lodówki dublowało odbicia produktów, więc mleko liczono podwójnie. System mylił mielony karmel z cynamonem, nie odróżniał mleka pełnego od 2% i odtłuszczonego, gubił się przy miękkich, nieregularnych opakowaniach kawy. Przy słabym Wi-Fi aplikacja potrafiła się zawiesić w trakcie liczenia i stracić zebrane dane.
Najbardziej kosztowny okazał się przypadek, gdy producent mleka zmienił opakowanie. Douczenie modelu, tak by rozpoznawał nowy wygląd produktu, zajęło sześć tygodni. W sieci o dużej rotacji asortymentu i silnej sezonowości oznacza to, że system stale nie nadąża za półką. Według Heydy po około dziewięciu miesiącach Starbucks wycofał narzędzie ze wszystkich lokali, a bariści wrócili do liczenia ręcznego.
W klasycznym ujęciu ryzyko wykonalności dotyczy pytania, czy da się coś zbudować. Ten przypadek pokazuje szerszą definicję: rozwiązanie zbudowano i działało w kontrolowanych warunkach, ale nie w środowisku, dla którego powstało. Dla zespołów wdrażających AI to szczególnie ważna lekcja. Skuteczność modelu w testach mówi niewiele o tym, jak poradzi sobie z odbiciami w szybie, zmianą opakowania czy niestabilnym połączeniem. Wdrożenie od razu w całej sieci, bez etapu pilotażu w realnych warunkach, sprawiło, że wszystkie te problemy wystąpiły jednocześnie w 11 tysiącach lokalizacji.
Ryzyko opłacalności: gdy metryka świeci na zielono
Amazon Prime to w Stanach Zjednoczonych usługa powszechnie używana i relatywnie tania: darmowe dostawy, wideo, muzyka w jednym abonamencie. Zapisanie się wymaga w praktyce jednego kliknięcia, a zachęty do skorzystania z darmowego okresu próbnego pojawiają się w wielu miejscach serwisu. Rezygnacja wyglądała zupełnie inaczej.
Proces anulowania subskrypcji funkcjonował podobno wewnętrznie pod nazwą Iliad Flow, w nawiązaniu do Iliady i dziesięcioletniej wojny. Sam dostęp do niego nie był oczywisty, a później użytkownik przechodził przez kolejne ekrany, na których musiał potwierdzać, że chce kontynuować. Po drodze widział przyciski „przypomnij mi później” i „zachowaj subskrypcję”, oferty z niższą ceną oraz podsumowanie korzystania z usługi, nawet jeśli wynosiło ono zero.
Z perspektywy dashboardu proces działał bez zarzutu, bo churn pozostawał niski. Sytuacja zmieniła się, gdy sprawą zajęła się amerykańska Federalna Komisja Handlu (FTC). We wrześniu 2025 roku Amazon zawarł z nią ugodę na 2,5 mld dolarów, z czego 1,5 mld przeznaczono na zwroty dla klientów. Heyda zwrócił uwagę na szczegół z dokumentów postępowania: według zeznań projektanci UX zgłaszali zastrzeżenia do procesu, a firma w pewnym momencie go uprościła. Gdy jednak metryki wyraźnie spadły, wrócono do poprzedniej wersji.
Ryzyko opłacalności zwykle sprowadza się do pytania, czy funkcja się zwróci. Przypadek Amazona pokazuje jego mniej oczywisty wymiar. Proces realizował cel biznesowy mierzony jednym wskaźnikiem, ale pełny rachunek obejmował karę, zwroty, straty wizerunkowe i pracę wielu zespołów zaangażowanych w obsługę postępowania. Metryka, która nie uwzględnia zaufania klientów i ryzyka regulacyjnego, może przez lata pokazywać sukces produktu, który w rzeczywistości generuje rosnący koszt.
Product Trio: trzy role, cztery ryzyka
Odpowiedzią na te ryzyka nie jest dodatkowy etap akceptacji ani kolejny raport. Heyda wskazuje na model Product Trio, popularyzowany m.in. przez Marty’ego Cagana: zespół produktowy, w którym trzy role od początku wspólnie odpowiadają za to, co powstaje. Model dotyczy zarówno produktów dla klientów zewnętrznych, jak i narzędzi wewnętrznych, takich jak aplikacja inwentaryzacyjna Starbucksa.
Każda z ról przejmuje inne ryzyko. Product Manager odpowiada za wartość i opłacalność: pilnuje, by rozwiązanie miało sens dla użytkowników i spinało się biznesowo w pełnym rachunku, a nie tylko w jednym wskaźniku. Właśnie tego zabrakło przy automatycznym dodawaniu karty i w procesie rezygnacji z Amazon Prime. Product Designer odpowiada za użyteczność, czyli za to, by użytkownik rozumiał, co ma zrobić, i mógł to zrobić z wykorzystaniem znanych mu wzorców, czego zabrakło w e-TOLL. Tech Lead odpowiada za wykonalność: dba o to, by rozwiązanie dało się zbudować, utrzymać, skalować i rozwijać bez długu technologicznego od pierwszego dnia, a także by działało w warunkach, w których będzie używane, jak w kawiarniach Starbucksa.
Przypisanie ról do ryzyk określa, kto ma decydujący głos w danym obszarze, ale nie dzieli pracy na niezależne odcinki. Według Heydy kluczowe jest to, że cała trójka pracuje razem od etapu discovery. Wtedy projektant może zakwestionować formularz, zanim trafi on do developmentu, inżynier może wskazać, że warunki w kawiarni różnią się od laboratoryjnych, a product manager może zapytać, czy czwarta metoda dodawania karty jest komukolwiek potrzebna. Każde z tych pytań kosztuje najmniej na początku projektu.
Problem leżał w pytaniach, nie w budowaniu
Żaden z opisanych zespołów nie zignorował weryfikacji. Zespół aplikacji convenience przeprowadził badania, twórcy e-TOLL odwzorowali wymagania prawne, Starbucks przetestował model, a Amazon mierzył skuteczność procesu. Heyda podkreśla, że wszyscy zadawali pytania, tylko nie te, które były najważniejsze. Badano zrozumienie zamiast chęci użycia, zgodność z przepisami zamiast możliwości przejścia procesu, skuteczność w testach zamiast działania w kawiarni, churn zamiast pełnego kosztu dla firmy.
Dla zespołów tworzących aplikacje mobilne i inne produkty cyfrowe to praktyczna wskazówka. Przed decyzją o wdrożeniu warto sprawdzić, czy każde z czterech ryzyk zostało zweryfikowane osobno i czy dowody, na których opiera się decyzja, rzeczywiście odpowiadają na właściwe pytanie. Dobry wynik testu, wysoka skuteczność modelu czy zielony wskaźnik na dashboardzie są cenne tylko wtedy, gdy mierzą to, od czego naprawdę zależy sukces produktu.
Artykuł powstał na podstawie prelekcji Krzysztofa Heydy wygłoszonej podczas Mobile Trends for Experts 2026. A o bieżącej edycji Mobile Trends Conference przeczytasz tutaj.
