Product Manager / Product Builder
Każdy z tych powodów jest niżej rozpisany na konkretnym przykładzie.
Pięć powodów
Rekrutacja jest do jednego obszaru. Sposób pracy działa w każdym.
Przez dziesięć lat odpowiadałem za rzeczy, które musiały wyjść na plus. W MILER Menswear zarządzałem całym e-commerce'em i zespołem: cudzy biznes, moja odpowiedzialność za wynik. Potem był Pomadziarz.pl: własny sklep internetowy, własny rachunek zysków i strat, własne ryzyko i własne pieniądze na stole. W nim i w TikTok Akademii sam ustalałem ceny produktów: to była moja decyzja i mój błąd, kiedy okazywała się zła.
Liczbą, wokół której kręciło się wszystko, był ROAS z płatnego ruchu: ile przychodu wraca ze złotówki włożonej w reklamę, przy jakiej cenie i przy jakiej marży to się jeszcze spina. Na reklamę wydawałem dwadzieścia pięć tysięcy złotych miesięcznie z własnej kieszeni. Nie było w tym subskrypcji, ale każda z tych złotówek musiała wrócić i to wystarczy, żeby nauczyć się dyscypliny.
Kiedy przychodzi zlecenie, nie zaczynam od „jak to zbudować”, tylko od „po co”. Bardzo często okazuje się, że to „po co” da się osiągnąć taniej i szybciej.
Pętla, w której podejmowałem decyzje
Kiedy drugi raz dostałem prośbę o ten sam raport, czyli o przekopiowanie danych z systemu do arkusza, przestałem myśleć o raporcie i zacząłem myśleć o tym, jak to zmienić. Pytania były dobre. Zła była droga, którą musiały pokonać.
Przejrzałem zgłoszenia do zespołu deweloperskiego i policzyłem, ile z nich to prośby o raporty: około dwudziestu na kwartał, z czego zrealizowane trzy. Reszta czekała, bo zawsze znalazło się coś pilniejszego. Wniosek był jeden: problemem nie jest brak raportów, tylko to, że osoba, która potrzebuje danych, nie może sięgnąć po nie sama.
Zależało mi na oddaniu tej sprawczości ludziom, którzy zgłaszają potrzeby raportowe. Powstała hurtownia danych z warstwą BI, a w Metabase i Claude Code samodzielne budowanie raportów stało się realne. Dziś korzysta z tego dziesięć osób, managerowie i liderzy, i nikt z nich nie stoi w kolejce.
Kiedy ktoś prosi mnie o raport, pytam, jak często będzie go potrzebował. Jeśli odpowiedź brzmi „co miesiąc”, to nie jest prośba o raport. To prośba o proces, którego nie ma.
Ta sama prośba, dwie odpowiedzi
Kiedy pojawia się sygnał, że trzeba coś zbudować, umawiam się z ludźmi, którzy wykonują tę pracę codziennie, nie z tymi, którzy ją zlecają. Pytam, jak wygląda ich dzień i co ich w nim boli.
Każdą taką rozmowę nagrywam i transkrybuję. Transkrypty kumulują się i stają się pamięcią decyzji: pół roku później, kiedy wraca dyskusja o pivocie albo o zmianie ustaleń, mamy zapisane, skąd wziął się dany pomysł i jaki problem miał rozwiązywać. To jedna z niewielu rzeczy, które realnie chronią zespół przed przepisywaniem tej samej decyzji trzy razy.
Poniedziałek
Spotkanie z grupą użytkowników. Pytam, jak wygląda ich dzień i co ich w nim boli. Nagrywam.
Poniedziałek i wtorek
Buduję coś, co można obejrzeć i skrytykować. Nie opis, nie makieta do wyobrażenia sobie.
Środa
Na pierwszym spotkaniu prawie nikt nie potrafi opisać swojej potrzeby w całości. Brakujący element widać dopiero przy czymś konkretnym.
Każda rozmowa nagrana i transkrybowana
Prawdziwy problem nie leży w narzędziach, tylko w tym, że obie strony mówią dwoma różnymi językami. Dlatego ta zmiana nie uda się, jeśli ruszy tylko jedna z nich.
Strona nietechniczna musi nauczyć się zasad panujących w dziale technologii: to tam ustala się standardy wytwarzania oprogramowania, a Product Builder ma się ich trzymać. Nie z grzeczności: praca włożona w prototyp, którego deweloperzy nie mogą przejąć, jest warta zero.
Strona deweloperska musi być otwarta na ludzi nietechnicznych, którzy wnoszą wiedzę biznesową i będą popełniać błędy w rzemiośle. Bez tego pierwszy nieudany prototyp zamyka temat na rok.
Zasady wytwarzania oprogramowania są po stronie działu technologii. Trzymam się ich, nie negocjuję ich od nowa pod siebie.
Nie w narzędziu, które jest wygodne dla mnie. Prototyp, którego zespół nie może przejąć, jest wart zero, niezależnie od tego, jak trafnie odpowiada na potrzebę.
To nie jest opinia o tym, jak mogłoby być. Przez ostatnie dziewięć miesięcy wypracowaliśmy standardy pracy w projekcie, w których to działa.
Jeśli każdy PR ode mnie musi przejść przez ręce seniora, zmiana paradygmatu kończy się przeniesieniem kolejki. Pipeline trzeba zaprojektować tak, żeby seniorzy decydowali, co w ogóle wymaga ich uwagi.
Ostatnie dziewięć miesięcy współtworzę taki proces z jednym założeniem: nie będę czytał kodu. I nie czytam, a wytworzyłem go już kilkaset tysięcy linii. Wysiłek wkładam w to, żeby środowisko pracy było na tyle poukładane, że zaglądanie do kodu przestaje być konieczne, a kolejne zadania można oddać mechanizmom. Do tego potrzebna jest standaryzacja pracy i to jest właściwa robota do wykonania.
Wymagania w ogłoszeniu otwierają się od zdania „odpowiadał_ś biznesowo za SaaS lub jego część”. Za SaaS nie odpowiadałem. Systemy, które budowałem w ostatnich latach, mają użytkowników, którzy za nie nie płacą i nie mogą od nich odejść, a to znosi połowę pytań, które w modelu subskrypcyjnym są najważniejsze.
Nie prowadziłem produktu subskrypcyjnego przez cykl życia: churn, retencja kohort, zachowanie przychodu powtarzalnego przy zmianie cennika.
Szukam dobrych wzorców niezależnie od branży i modeluję je do tej, którą się zajmuję. W e-commerce nie patrzyliśmy na konkurencję z branży, tylko na marki z zupełnie innych.
Automatyzację dokumentów zatrzymaliśmy na 88 procentach. Pozostałe dwanaście to klienci z indywidualnymi ustaleniami, a dociąganie ich w starym środowisku kosztowałoby więcej, niż jest warte. To nie było odpuszczenie, tylko decyzja: domknięcie jest zaplanowane po wdrożeniu nowego CRM.
Jeśli sprawdzone wzorce w SaaS istnieją, to się ich nauczę. To kwestia tygodni, nie lat. Sposobu myślenia nie da się nadrobić w tym samym trybie, a to on decyduje, czy ktoś zbuduje właściwą rzecz.
Kurs mam kupiony i startuję 26 października: mega.dev, o zarządzaniu pracą agentową, czyli dokładnie o tym, jak wygląda wytwarzanie oprogramowania po zmianie paradygmatu opisanej w ogłoszeniu.
Domena
Budżet, WPF i SWB robią jedno: biorą dane finansowe i generują z nich dokument zgodny z przepisami. Budżet składa projekt budżetu z danych historycznych, WPF prowadzi kreatorem przez prognozę, SWB wystawia sprawozdania.
Automatyzacja dokumentów, którą opisałem wyżej, ma dokładnie ten kształt: dane o kliencie na wejściu, gotowy dokument na wyjściu, osiemdziesiąt osiem procent obsłużone maszynowo i dwanaście procent, które ma wyjątki.
Pokrycie nie wzięło się od razu: rosło stopniowo, razem z tym, jak dział administracji opisywał kolejne przypadki, bo w punkcie wyjścia część z nich nie była jednoznacznie opisana.
I jedna rzecz, która przy dokumentach dla administracji będzie wracać częściej niż gdziekolwiek indziej: zawsze znajdzie się jednostka z wyjątkiem. Pytanie nie brzmi, czy obsłużyć sto procent przypadków. Brzmi: gdzie przebiega granica, za którą kolejny procent kosztuje więcej, niż jest wart, i co zrobić z resztą, żeby nie została sama.
Nie znam jeszcze tej domeny. Znam ten kształt problemu i wiem, gdzie w nim zwykle leżą miny.
Kształt, który znam
Kontakt
Jeśli to, co wyżej, brzmi jak ktoś, z kim warto spędzić godzinę, to umówmy się.
Pierwsze: że lubię wpływać na zmianę rzeczywistości i widzieć, że moje działania coś realnie przesuwają. Drugie: że frustruje mnie „bo zawsze tak było robione”. To drugie jest w ogłoszeniu jako test dopasowania do zespołu. Zdałem go, zanim zdążyłem przeczytać resztę. Nie szukam ucieczki od czegoś, tylko dokładnie tej roli: chcę być product builderem pracującym z LLM-ami i mieć na to czas.