- The Product Today -

Apple pokazało iPhone’a Duo, pierwszego składanego iPhone’a. I jak zwykle przy dużych premierach Apple, łatwo skupić się na samym urządzeniu: większym ekranie, zawiasie, cenie, specyfikacji, aparatach i tym, czy „to się przyjmie”. Ale z perspektywy Product Managementu i Product Designu ciekawsze pytanie brzmi inaczej: "Co taki format zmienia w sposobie projektowania produktów cyfrowych?" Bo iPhone Duo nie jest po prostu „większym iPhone’em”. To urządzenie, które może działać

To jeden z ciekawszych momentów w rozwoju produktu: wypuszczasz funkcję z jasnym założeniem, projektujesz konkretny flow, opisujesz główny scenariusz użycia… a potem użytkownicy robią coś zupełnie innego. Klikają inaczej. Omijają kroki. Używają funkcji do innego celu. Tworzą własne obejścia. Łączą produkt z narzędziami, których nie przewidziałeś. Ignorują część, która miała być „najważniejsza”. Pierwsza reakcja często brzmi: „Użytkownicy nie zrozumieli produktu.” Ale dużo cie

Pierwsze wrażenie w aplikacji powstaje bardzo szybko. Użytkownik wchodzi, rozgląda się przez kilka sekund i próbuje odpowiedzieć sobie na trzy pytania: Co to właściwie jest? Co mam tutaj zrobić? Czy warto poświęcić temu czas? Jeśli odpowiedzi nie są jasne, użytkownik nie będzie długo analizował produktu. Raczej zamknie aplikację, odłoży temat albo uzna, że „to chyba nie dla mnie”. Dobra wiadomość jest taka, że pierwsze wrażenie można poprawić bez wielkiego redesignu. Czasem w

Każdy zespół produktowy zna tę sytuację. Zaczynasz planować funkcję, projekt albo nowy etap produktu i bardzo szybko pojawia się lista: to musi być, to też musi być, bez tego nie wypuścimy, klient tego oczekuje, sprzedaż o to pyta, konkurencja to ma, zarząd chce to zobaczyć. I nagle z prostego pomysłu robi się projekt na miesiące. Problem z listami „must have” polega na tym, że większość rzeczy na tej liście wcale nie jest „must have”. Część jest ważna. Część jest przydatna.

W wielu zespołach produktowych pomysły poruszają się wolno. Najpierw trafiają do backlogu. Potem czekają na doprecyzowanie. Potem na design. Potem na development. Potem na review. Potem na release. A potem jeszcze trzeba sprawdzić, czy w ogóle zadziałały. I nagle pomysł, który wydawał się prosty, zaczyna żyć własnym życiem przez kilka tygodni albo miesięcy. Problem nie zawsze polega na tym, że zespół pracuje za wolno. Często problemem jest to, że między pomysłem a efektem jes

Backlog bardzo łatwo staje się miejscem, do którego trafia wszystko: prośby klientów, pomysły zespołu, bugi, rzeczy „na później”, tematy od sprzedaży, zaległe usprawnienia, funkcje, które „kiedyś mogą się przydać”. Na początku backlog ma pomagać. Ma porządkować pracę i dawać zespołowi jasność. Ale po czasie często zaczyna działać odwrotnie: robi się długi, nieczytelny i pełen tematów, których nikt już nie rozumie. Efekt? Zespół nie wie, co naprawdę jest ważne. Priorytety zmie

Feedback brzmi jak coś zawsze dobrego. W końcu użytkownicy mówią nam, czego potrzebują. Klienci pokazują, co ich boli. Sprzedaż przynosi sygnały z rynku. Support widzi problemy na pierwszej linii. I to wszystko jest prawda. Ale jest też druga strona: feedback potrafi szkodzić produktowi. Nie dlatego, że użytkownicy „nie wiedzą, czego chcą”. Bardziej dlatego, że feedback bardzo łatwo źle zinterpretować. Można pomylić głośną opinię z realnym problemem. Jednostkowy przypadek z t

W rozmowach z użytkownikami łatwo zatrzymać się na powierzchni. Użytkownik mówi: „Chcę prostszy panel.” „Potrzebuję eksportu.” „Przydałaby się automatyzacja.” „Chciałbym więcej opcji.” I bardzo często zespół zapisuje to jako insight. Problem w tym, że to jeszcze nie jest prawdziwa motywacja. To jest deklaracja, potrzeba na poziomie rozwiązania albo pierwsza warstwa problemu. Prawdziwa motywacja jest głębiej: użytkownik chce coś osiągnąć, czegoś uniknąć, poczuć większą kontrol

Rozmowy z użytkownikami potrafią być złotem. Ale potrafią też być frustrujące. Pytasz: „Czy ta funkcja byłaby dla Ciebie przydatna?” A użytkownik odpowiada: „To zależy.” Pytasz: „Czy korzystałbyś z takiego rozwiązania?” A on mówi: „Możliwe.” Pytasz: „Co byś zmienił?” A słyszysz: „Ciężko powiedzieć.” I po 30 minutach rozmowy masz notatki, które brzmią mądrze, ale nie pomagają podjąć decyzji. Problem zwykle nie jest w użytkowniku. Problem jest w pytaniach. Jeśli pytasz zbyt ogó

Koszyk pełny. Użytkownik przeszedł przez cały sklep, wybrał produkt, kliknął „Kup teraz”. Jest o krok od zapłacenia. I nagle znika. Zespół widzi to w danych i sięga po znane rozwiązania: „Wyślijmy mu maila z przypomnieniem.” „Dorzućmy 10% rabatu, to wróci.” Oba działania leczą objawy ale nie przyczynę. Bo ten użytkownik nie porzucił koszyka z braku chęci kupienia. Gdyby jej nie miał, nie dotarłby aż tutaj. Porzucił go, bo coś w ostatniej chwili zachwiało jego pewnością. To wa

Użytkownik otwiera ekran i się zatrzymuje. Nie dlatego, że jest mało rozgarnięty. Dlatego, że ekran nie mówi mu, co jest najważniejsze. Wszystko rzuca się w oczy: pięć przycisków tej samej wielkości, trzy linki w nagłówku, baner na górze, powiadomienie z boku. I wtedy w zespole pojawiają się dwie wygodne propozycje: „Dodajmy tooltip, który to wyjaśni.” „User się nauczy, jak trochę poużywa produktu.” Obie omijają problem. Bo dobry ekran nie potrzebuje instrukcji — on prowadzi

W większości produktów cyfrowych jest jedno miejsce, w którym tracisz najwięcej użytkowników. Nie jest to płatność. Nie jest to brak funkcji. To pierwsza minuta po rejestracji. Użytkownik wchodzi pierwszy raz i w głowie ma jedno, niewypowiedziane pytanie: „Czy to jest dla mnie i czy zaraz coś z tego będę miał?” Jeśli w ciągu około minuty nie dostanie odpowiedzi „tak”, to wychodzi. I najczęściej już nie wraca, bo drugiej pierwszej wizyty nie ma. A teraz nieprzyjemna prawda. Wi

Jedna z najdroższych pułapek w pracy nad produktem brzmi tak: „Zbudujmy to i zobaczymy.” Na pierwszy rzut oka brzmi rozsądnie. Przecież dopiero jak coś będzie działać, użytkownicy powiedzą, czy tego chcą. Problem w tym, że development jest drogi nie tylko finansowo, ale też organizacyjnie. Każdy pomysł, który wchodzi do budowy, zajmuje czas zespołu, odciąga uwagę od innych tematów i po wdrożeniu trzeba go utrzymywać. Dobra wiadomość jest taka, że wielu pomysłów nie trzeba od

Formularz to jedno z najbardziej niewdzięcznych miejsc w produkcie. To moment, w którym użytkownik już chce się zarejestrować, zamówić, zapisać, wysłać. Jest tuż przed metą. A i tak duża część ludzi odpada właśnie tutaj. I łatwo wtedy o dwie wygodne wymówki: „Widać nie byli wystarczająco zainteresowani.” „Trzeba dodać przypomnienie mailowe, to wrócą.” Obie omijają sedno. Bo formularz rzadko porzuca się z braku chęci. Porzuca się go, gdy w danym momencie wysiłek wydaje się wię

Od kiedy Figma wypuściła swojego agenta AI wprost na canvas, w zespołach produktowych słychać dwa skrajne zdania: „No to projektanci nie są już potrzebni.” „Spokojnie, to kolejny gadżet, który robi mockupy do wyrzucenia.” Oba są wygodne, bo zwalniają z myślenia. I oba są nieprawdziwe. Zanim przejdziemy do tego, co się zmienia, ustalmy w jednym akapicie, o czym właściwie mówimy. Bo o agencie zrobiło się głośno, a nie każdy zdążył sprawdzić, co konkretnie się pod tym kryje. Czy

„Zróbmy to prościej” to jedno z najczęściej wypowiadanych zdań w produktach cyfrowych. I jednocześnie jedno z najtrudniejszych do zrealizowania. Bo „prosty produkt” nie oznacza „mało rzeczy”. Oznacza, że użytkownik ma poczucie: wiem, co tu robić, wiem, co się stanie po kliknięciu, szybko osiągam cel, nie muszę myśleć o rzeczach, które mnie nie dotyczą. To jest prostota z perspektywy użytkownika a nie prostota techniczna czy organizacyjna. Co to znaczy „prosty produkt”? Prosty

Wypuszczanie nowych funkcji ma dwie pułapki: wypuszczasz za wcześnie i robisz pożar, wypuszczasz za późno, bo „jeszcze dopracujmy”. Perfekcjonizm w produkcie rzadko wynika z braku odwagi. Częściej wynika z realnego lęku: „a jak coś się zepsuje?” „a jak użytkownicy tego nie zrozumieją?” „a jak spadną metryki?” Da się to ogarnąć bez paraliżu. Kluczem jest zmiana pytania z: „Czy to jest idealne?” na: „Czy to jest wystarczająco bezpieczne i użyteczne, żeby dać wartość i zebrać fe

W większości produktów „coś jest nie tak” w wielu miejscach naraz: trochę tu, trochę tam, trochę w copy, trochę w flow, trochę w performance. I wtedy łatwo wpaść w tryb "poprawiamy wszystko po trochu". Efekt? Zespół pracuje, a użytkownik dalej czuje, że produkt „męczy”. Dużo lepsze podejście brzmi: znajdź jedną rzecz, która psuje doświadczenie najbardziej i napraw ją porządnie. Tylko jak ją znaleźć, skoro każdy ma inną opinię, a backlog jest pełen „ważnych tematów”? Poniżej z

To jeden z najbardziej klasycznych mechanizmów w produktach cyfrowych: ktoś przychodzi i mówi: „Konkurencja ma X. My też musimy.” I nagle temat ląduje wysoko w backlogu, bo: wygląda „oczywiście”, łatwo go uzasadnić, nikt nie chce zostać w tyle. Problem w tym, że „bo konkurencja ma” jest jednym z najdroższych sposobów budowania produktu. Bo często prowadzi do: kopiowania bez zrozumienia, rozjechania strategii, dokładania funkcji, które obciążają produkt, i inwestowania czasu w

To jeden z najbardziej „prawdziwych” konfliktów w pracy nad produktem. Na spotkaniu padają dwa zdania, które potrafią zablokować decyzję na tygodnie: „Dane pokazują, że to nie działa.” „No tak, ale ja czuję, że to jest dobre.” I nagle dyskusja schodzi na poziom: kto ma rację. A to jest zły poziom, bo w praktyce zarówno dane, jak i intuicja potrafią kłamać. Dane mogą być źle zebrane, źle interpretowane albo dotyczyć nie tego, co myślisz. Intuicja może być wynikiem doświadczeni