Product Developer – czym różni się od zwykłego Developera?

Product Developer pracuje w środowisku, w którym ma odpowiednią wiedzę, narzędzia i swobodę, by wdrażać rozwiązania produktowe, które użytkownicy pokochają. Moim głównym zadaniem jako Product Managera jest właśnie stworzenie takiego środowiska.

Jak może to działać w praktyce? Poznajcie team Challenger w Displate: Maję i Bartka (Backend), Olę i Marcina (Frontend), Pawła (QA), Konrada (Engineering Manager), Elenę (UX Designer) oraz mnie (Product Manager). Nasza zespołowa misja to: We constantly surprise our customers with new inspirations and products, so they return to Displate.com and make their collections (and walls) shine!

Misja zapewnia nam to, że każdy z członków zespołu wie (przynajmniej mam taką nadzieję :)), za jaki etap ścieżki użytkownika odpowiada i jakie mamy cele. Dzięki tej wiedzy każdy w zespole może dopytać lub zakwestionować omawianą ideę. Każdy może również zgłosić swój pomysł i jest on omawiany równie szczegółowo, jak ten dodany przez UX Designera lub Product Managera. 

Najlepiej wypracować wspólną misję, wizję i cele razem z zespołem, np. w formie warsztatów. Nawet jeśli ten cel nam jest “dany z góry”, to warto poświęcić tyle czasu, ile jest potrzebne, by z zespołem omówić wszystkie wątpliwości. To jednak tylko początek drogi. 

Myślenie produktowe każdego dnia

Równie ważne (a nawet ważniejsze) jest to, by żyć tą wizją i celami na co dzień. Kilka pomysłów, jak to wygląda w praktyce:

• Skupiamy się przede wszystkim na problemie, a nie samym rozwiązaniu. Zwykle rozmawiamy o tym na refinementach (my akurat pracujemy w Scrumie). W naszym zespole refinementy trwają długo, poświęcamy na nie nawet 4 godziny w tygodniu. Chcemy jednak mieć pewność, że problem jest odpowiednio dobrze zrozumiany, a planowana zmiana optymalnie dobrane do jego rozwiązania. 
• Jako Product Manager nie jestem tylko “gościem”, który pojawia się raz na 2 tygodnie na planowaniu i demo. Jestem blisko zespołu. Poza wspomnianymi refinementami, jestem na prawie każdym daily. Zwykle tylko słucham, bo zespół deweloperski świetnie sobie radzi i podejmuje niezbędne decyzje w swoim zakresie. Czasem pomogę rozwiać jakąś wątpliwość i podjąć decyzję. Dla mnie daily to również fajna okazja, by pogadać z teamem, sprawdzić, co słychać… i podzielić się insightem czy metrykami. 
• Spamowanie Dzielenie się statystykami. Staram się, by zespół był na bieżąco i widział, jak wyglądają nasze najważniejsze metryki produktowe. Raz w tygodniu publikuję update na Slackowym kanale, a co dwa tygodnie prezentujemy update dotyczących naszych celów podczas demo. Dodatkowo  spontanicznie wrzucam jakieś nietypowe wyniki wynikające z naszych AB testów lub wprowadzanych zmian.
• Uczestnictwo w badaniach z użytkownikami. Zachęcamy (ale nie zmuszamy 🙂 ) deweloperów by brali udział w wywiadach lub usability testach, które prowadzimy regularnie. Po przeprowadzonym researchu dzielimy się wnioskami i nagraniami. Dodatkowo podrzucam smaczki z naszych kanałów w mediach społecznościowych (Reddit i Discord). Czasem jednak developerzy wyłapują je nawet przede mną. 
• W związku z sugestią zespołu do naszego kalendarza dodaliśmy (tak wiem, brzmi jak sadomasochizm) jedno spotkanie produktowe raz miesiącu. To tak zwany Product refinement, gdzie rozmawiamy o planach wykraczających poza kwartał. Zespół zwrócił  uwagę, że pomoże to lepiej planować obecnie budowane funkcjonalności. Z mojego punktu widzenia takie podejście pomaga też w utrzymaniu poczuciu, że rozwijamy produkt w dłuższej perspektywie (a nie tylko od ficzera do ficzera). Wszyscy zdajemy sobie sprawę, że takie długoterminowe plany najpewniej ulegną zmianie. Nie mniej jednak dobrze jest znać kierunek, a o wszystkich zmianach informujemy się na bieżąco. 

Autonomiczny nie oznacza odizolowany 

Jeszcze słowo o komunikacji z innymi zespołami projektowymi i resztą firmy. Dużo napisałem o naszym zespole, ale są jeszcze inne zespoły produktowe: Houston, Enterprise, Voyager, Atlantis i Discovery. W dodatku w naszej galaktyce orbitują m.in. marketing, finanse, produkcja, logistyka (przypominam, że Displate to przede wszystkim genialny produkt fizyczny). Robimy wszystko byśmy byli dobrze zsynchronizowani. Wspomniane demo są otwarte i każdy może na nie wpaść. Jeśli nie ma czasu, to publikujemy później nagrania oraz podsumowanie. Ponadto mamy dobrze zorganizowane otwarte kanały na Slacku, gdzie łatwo można zadać odpowiednie pytania i trzymać rękę na pulsie. 

Oprócz tego, że każdy zespół ma swój cel i misję, to pracujemy w ramach jednej strategii produktowej i mamy jedną misję jako firma. Pracujemy z OKR-ami. To kolejne narzędzie, które pomaga nam lepiej rozumieć priorytety firmy, innych działów. Na tej podstawie możemy tak skomponować nasz OKR, by pomógł nie tylko naszej domenie, ale też Displate’owi jako całości. 

Dodatkowo organizujemy nasze  #AMA na których nasi CTO i CPO odpowiadają na pytania i uwagi zgłoszone wcześniej przez zespół engineering. Mamy za sobą dwie edycje tego eventu i zostały bardzo fajnie odebrane. Pojawiające się tam pytania świadczą o tym, że mamy wysoką świadomość produktową wśród naszych developerów. 

Oferty pracy z

Nie samym produktem człowiek żyje 

Piątek to dzień “święty”, kiedy deweloperzy mogą odpocząć od bieżącej pracy nad sprintowymi taskami. Te 20 proc. czasu poświęcają na pracę w ramach gildii, czyli pochłaniają ich wyzwania związane z rozwojem technologii i spłacaniem długu technologicznego.

Pracujemy głównie w trybie zdalnym, ale staramy trzymać się blisko. Spotykamy się na spontanicznych “kawkach online” i od czasu do czasu stacjonarnie na piwku lub genialnych Displate’owych integracjach. Dla mnie to ważne, byśmy byli czymś więcej niż pracującą ze sobą grupą ludzi. Raczej paczką znajomych, która sobie ufa i potrafi wspierać w trudnych sytuacjach – zarówno zawodowych, jak i prywatnych. 

Na koniec chciałbym uspokoić wszystkich, którzy kochają Displate’y i chcieliby z nami pracować. Wciąż podstawowym zadaniem naszych deweloperów jest kodowanie, nauka i wdrażanie nowych technologii. Zależy nam natomiast na tym, by to wszystko działo się w jak najlepszym zrozumieniu naszych użytkowników i naszego biznesu. Dzięki temu każdy deweloper może podejmować lepsze decyzje w trakcie implementacji i po prostu realnie współtworzyć Displate.com. 

Najlepiej podsumował to Marcin z naszego zespołu, którego poprosiłem o przeczytanie draftu mojego artykułu: “Można by też dodać coś o sprawczości, jaką każdy ma w Displate – nie ma tu jakichś korpo barier, gdzie każdy tylko pilnuje własnego nosa i nie ma wstępu na terytorium innych. Jak masz jakiś pomysł, to możesz go drive’ować dalej o ile jest on dobry.” To fakt, wtykanie nosa w nie swoje sprawy, to u nas zaleta 😉