Budujesz swój biznes? Zobacz konferencję Founders Mind na PGE Narodowy [20 października]

Sprawdź agendę i dołącz

Czołem Przemku, powiedź jak się zaczęła Twoja przygoda z zarządzaniem produktem, co robisz dziś i jak oceniasz swoją ewolucję na przestrzeni lat?

Moja ewolucja na przestrzeni lat to istny rollercoaster. Jeszcze na początku studiów kręciłem się wokół kilku startupów (głównie pozycje entry level) gdzie miałem szansę współpracować z naprawdę wyjątkowymi ludźmi. Mam wrażenie, że to właśnie możliwość nauki i obserwacji tych wszystkich ambitnych ludzi, zaszczepił we mnie duch przedsiębiorcy i produktowca. Dzięki temu, odważyłem się na testowanie swoich własnych sił i odpalanie inicjatyw na własny rachunek. Zawsze wiązało się to z budowaniem produktów (w końcu początkujący founder to człowiek od wszystkiego). Mam wrażenie, że to właśnie dzięki temu, decydując się na współpracę z innymi firmami jako Product Owner czy Product Manager miałem (i mam) ogromny szacunek do wysiłku włożonego w rozkręcenie biznesu (rozumiem też jak ważni są klienci). Nie bez znaczenia jest również fakt, że obie moje inicjatywy okazały się de facto “biznesową porażką” (wolę nazywać to lekcją). Empirycznie doświadczyłem czego nie warto robić, a na czym jednak warto się skupić. Obecnie jestem w stanie wykorzystywać to w Tidio, gdzie jestem odpowiedzialny za rozwój chatbotów, z których korzystają dziesiątki tysięcy klientów na całym świecie.

Posiadanie product ownera to luksus w przypadku startupów, nie każdą firmę na niego stać. Powiedź mi jak według Ciebie powinien podejść founder do roli rozwoju produktu, jeżeli mówimy, że nie może wyznaczyć w zespole dedykowanego zasobu do tej roli?

Jeśli nie ma środków na zatrudnienie doświadczonego PO’sa/PM’a, nic nie stoi na przeszkodzie, żeby taki kapelusz przyjął sam Founder (co jest zresztą częstym przypadkiem). Warto jednak delegować część innych obowiązków, ponieważ nie ma nic bardziej niekomfortowego niż niedostępny dla zespołu Product Owner. Warto też pamiętać, że Product Owner to tylko rola w SCRUMie. Metodologie powinny pomagać firmom budować dobre produkty, nie mogą one jednak przyćmić tego co najważniejsze – zaspokajania potrzeb klientów. Warto więc podchodzić do tego z głową. Naturalnie, na początku drogi startupu nie zawsze jest przestrzeń i możliwość zbierania z rynku najlepszych graczy. I nie ma w tym nic złego. Warto jednak wyznaczyć sobie granice oraz ustalić, że w pewnym momencie i tę część obowiązków będzie trzeba delegować. W pojedynkę daleko się nie zajdzie.

Dołącz do ponad 500 polskich przedsiębiorców na www.founders.pl

Jaka jest według Ciebie różnica między budowaniem produktów cyfrowych, a budowaniem produktów fizycznych?

Myślę, że więcej różnic da się zauważyć w podejściu do marketingu i sprzedaży niż w samym procesie powstawania produktów (albo nawet szerzej – w dystrybucji). W końcu ukochany przez rynek IT – Lean, pochodzi właśnie od sposobu zarządzania linii produkcyjnej Toyoty. Ten sam zestaw umiejętności potrzebny jest, aby zbudować produkt fizyczny, jak i cyfrowy. Wydaje mi się, że najważniejsze da się zebrać w tych kilku punktach 👇

• Stawianie użytkowników na pierwszym miejscu
• Identyfikowanie problemów
• Budowanie zespołów
• Prototypowanie
• Testowanie
• Dostarczanie produktu i ciągłe iterowanie

Jakie badania, formy walidacji konceptu poleciłbyś wykonać początkującym founderom, aby nie musieli budować drogiego software-u?

Internet jest pełen świetnych przykładów różnych form walidacji pomysłu – od zwykłych wywiadów z potencjalnymi użytkownikami, przez “fake door” pozwalające sprzedać coś czego nie ma, aż po usługę typu “concierge” która zaklada manualne wykonywanie czynności przez ludzi, które w docelowym rozwiązaniu będą zautomatyzowane. Myślę, że nie ma jednego sposobu, zawsze to zależy od tego co trzeba walidować. Inny zestaw narzędzi użyty zostanie do zbadania problemu/potrzeby, a zupełnie inny do weryfikacji technologii (feasibility – czy jesteśmy w stanie to dowieźć). Jeśli chodzi o walidację konceptu samego produktu, to oprócz tych wymienionych wyżej, skutecznymi formami są również klikalne prototypy, tzw. Czarnoksiężnik z krainy Oz, crowdfunding/pre-order, czy test dymny. Świetnie sprawdzają się również narzędzia w stylu szablonów Business Model Canvas – podobno jeśli pomysłu nie da się zmieścić na jednej kartce, to jest on kiepski 🙂

Jak pracować z Eearly adoptersami, aby nasz produkt był szyty pod klientow, a nie nasze „widzimisię”

ROZMAWIAĆ Z NIMI. Tylko tyle. I aż tyle! Naprawdę nie ma innego sposobu niż poświęcenie sporej ilości czasu na regularne spotkania z klientami (lub potencjalnymi klientami). W końcu produkt budowany jest dla nich. Jeśli ten najważniejszy element zostanie pominięty, najprawdopodobniej zostanie zbudowany świetny produkt, którego nikt nie chce używać (been there, done that – nic fajnego 😛). Trafiłem niedawno na cytat, który do mnie bardzo przemówił:

“There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else.”

Skoro klient jest tym jedynym szefem, to czy możemy pozwolić sobie na to, aby dostarczać produkty niedopasowane do jego oczekiwań?

Jakie dostrzegasz najczęstsze błędy przy budowaniu produktów, popełniane przez osoby nimi zarządzające?

Mikrozarządzanie. Zamknięcie się na feedback. Kiepska komunikacja. Brak empatii. Brak asertywności. Niechęć do zmian. Empirycznie doświadczyłem każdego z tych błędów. Jak nietrudno zauważyć, zaczynam od kompetencji miękkich. Nie bez kozery. Uważam, że technicznych aspektów pracy nad produktem idzie się dość szybko i łatwo nauczyć. To co jest największym wyzwaniem, to utrzymanie zaangażowania zespołu na najwyższym poziomie i przekazania im WHY! Dlaczego coś robimy. Później wystarczy dać im tylko przestrzeń na kreatywność i tematy mogą iść do przodu jak burza. A wszyscy będą z utęsknieniem czekać na poniedziałek 🙂

Jak może rozwijać się osoba, odpowiedzialna za budowę produktu?

Przede wszystkim – w praktyce. Naturalnie warto się szkolić, uczestniczyć w kursach, jak ktoś czuje potrzebę to nawet zdobywać certyfikaty (np. PSPO), ale uważam, że nie ma nic lepszego niż wskoczenie na głęboką wodę. Sucha teoria nie wystarczy. Po 20 godzinach nauki przepisów drogowych na kursie prawa jazdy, pewnie większości ludziom auto gaśnie na pierwszej próbie podjazdu pod górkę. Całkowicie naturalna sprawa. Popełniamy błędy, wyciągamy z nich wnioski, a druga i kolejna górka najprawdopodobniej zostanie pokonana bez przeszkód. Tak samo jest z nauką budowy produktu. Dużo teorii i jeszcze więcej praktyki. 

Klienci zgłaszają pomysły na zmiany/feature-y – jak podejść do lejka produkcji gdy z jednej strony robimy to dla nich, ale z drugiej jeżeli będziemy wdrażali każdą zmianę, zaprojektujemy kombajn-kreaturę

“Wartość, a nie funkcja. Efekt, a nie wynik!”

Przede wszystkim nie powinno się budować featurów, tylko adresować problemy / potrzeby użytkowników. Wydaje mi się, że to jest jedyny sposób, aby nie zrobić z firmy “feature factory” i nie wpaść w pułapkę budowania. Uważam, że nieprawdą jest, że klienci wiedzą czego chcą. Często idą na skróty swoim procesem myślowym i proszą o rozwiązania w zakresie tego co znają. A w takim przypadku ciężko o innowacje. Powinno się dogłębnie analizować potrzeby klientów a następnie projektować rozwiązania, które wychodzą ponad ich oczekiwania. Oczywiście czasem ich propozycje da się zaimplementować 1:1, ale nie radzę spełniać ich każdej zachcianki, ponieważ zasoby są zawsze ograniczone. Czasem może to być też sprzeczne z wizją firmy/produkty, o której ci sami klienci mogą po prostu nie wiedzieć.

Czy pracując w międzynarodowym produkcie, inaczej pracujecie nad funkcjonalnościami dedykowanym poszczególnym regionom, czy jednak nie ma takiej regionalizacji w budowie software-u?

Globalnie, jeśli chodzi o software, to są branże, które ze względu na lokalną specyfikę wymagają innego podejścia – chociażby fintech. Co region to inne regulacje prawne, więc zazwyczaj nie da się zbudować uniwersalnego rozwiązania dostępnego dla wszystkich. W takich przypadkach, zazwyczaj ogranicza się konkretne funkcjonalności w zależności od kraju użytkownika. Z kolei w Tidio, bardziej niż na lokalizację patrzymy na dostarczenie jak największej wartości wewnątrz konkretnej platformy. Mamy różny zestaw funkcjonalności dla klientów korzystających z naszych usług na Shopify, a inny dla użytkowników z WordPressa lub WIX’a. Wynika to głównie z tego, że każda platforma oferuje różne możliwości wykorzystywania ich API.

Jakie jest Twoje największe wyzwanie na najbliższe miesiące w Tidio

Utrzymanie zaangażowania zespołu na najwyższym poziomie. Zależy mi na tym, żeby wszyscy rozumieli dlaczego robimy to, nad czym właśnie pracujemy. Żeby wiedzieli gdzie zmierzamy i co będzie świadczyło o tym, że idziemy w dobrą stronę. W końcu, żeby stworzyć im przestrzeń do kreatywnej pracy, dzięki której staniemy się #1 narzędziem do zarządzania obsługą klienta w ecommerce. Największym wyzwaniem będzie sprawienie, żeby wszyscy czuli, że to co robimy, ma sens. Za każdym produktem stoją ludzie. I te dobre relacje międzyludzkie to zdecydowanie najciekawsze wyzwanie.