Jak sztuczna inteligencja wykracza poza tradycyjną rolę menedżerów produktu

Droga do zarządzania produktem

Od ponad 15 lat jestem menedżerem produktu. Wcześniej w swojej karierze zajmowałem się wszystkim innym, czym tylko mogłem, w tym projektowaniem, sprzedażą, doradztwem, marketingiem, a nawet programowaniem w czasach PHP — fuj.

Zająłem się zarządzaniem produktem, ponieważ bardzo podobało mi się przechodzenie między różnymi tematami i współpraca z użytkownikami, deweloperami, kadrą kierowniczą itd. Miałem także dobre wyczucie projektowania i produktu. Po przeprowadzeniu wielu badań odkryłem, że istnieje rola, która bardzo dobrze do tego pasuje — zarządzanie produktem. Zatem aplikowałem na swoje pierwsze stanowisko PM i tak się tutaj znalazłem.

Pracowałem w najróżniejszych branżach: B2B, B2B2C, handlu detalicznym i oprogramowaniu konsumenckim. Ponad dekadę temu zacząłem uczyć zarządzania produktem w General Assembly, a później niezależnie uruchomiłem własne kursy online na Udemy, a następnie na LinkedIn Learning. Obecnie mam łącznie ponad 1,6 miliona studentów na obu platformach. Występowałem także na wielu konferencjach dotyczących zarządzania produktem i projektami, w tym współpracowałem z Google przy prowadzeniu kursu o produkcie w Kijowie na Ukrainie.

Obecnie współpracuję z Probably.dev, aplikacją będącą deterministycznym agentem danych, finansowaną przez a16z. Jesteśmy małym zespołem, więc nie jestem tylko PM-em, ale także inżynierem, przedstawicielem handlowym, projektantem itd.

Nasza aplikacja jest natywną aplikacją desktopową, która wykonuje deterministyczną analizę danych na poziomie doktorskim, wraz z wizualizacjami, aby bezpośrednio odpowiadać na dowolne zapytania w języku naturalnym, bez opuszczania komputera przez wrażliwe dane. Można myśleć o niej jak o „drugim pilocie danych”. Działa bezpośrednio na schematach hurtowni danych (np. BigQuery, Snowflake, Clickhouse itd.), a także na plikach lokalnych, takich jak CSV, JSON i Parquet. Wszystkie odpowiedzi dostarczane przez naszego agenta można prześledzić i odtworzyć przez człowieka, więc typowe halucynacje LLM nie stanowią problemu. To nie jest kolejny agent generujący SQL — potrafimy obsługiwać miliardy wierszy i kolumn oraz złożone schematy zawierające dziesiątki tysięcy tabel.

You should also read

• Menedżer projektów i edukator wspomagany przez AI przedstawia prosty przepływ pracy AI, który zasadniczo zmienia sposób realizacji projektów

• Rzeczywiste przepływy pracy z AI stosowane przez szefa realizacji w agencji wdrażającej Asanę

Jak AI pomaga zespołom osiągać więcej dzięki każdej osobie

AI wywarła duży wpływ na moją pracę. Kiedyś byłem „tylko PM-em”. Brzmi to głupio, ponieważ PM-owie robią bardzo wiele, ale teraz mogę wnosić wkład także w inne obszary, takie jak inżynieria i sprzedaż. A to pomaga przyspieszyć pracę zespołu. Wraz z transformacją zarządzania projektami przez AI tradycyjne granice ról stają się coraz bardziej płynne.

Zadania wymagające dużych nakładów czasu, takie jak badania i analiza, wykonuje się znacznie szybciej, a zaoszczędzony czas pozwala na znacznie częstszy bezpośredni kontakt i komunikację z interesariuszami. Umożliwia to także szybsze podejmowanie decyzji.

Duża część pracy PM-a polega na zapewnieniu wszystkim innym możliwości skutecznego wykonywania swoich zadań, więc skoro sam mogę zrobić jeszcze więcej, jesteśmy w stanie osiągnąć znacznie więcej dzięki każdej osobie. To hybrydowe podejście człowiek–AI staje się niezbędne dla nowoczesnych zespołów odpowiedzialnych za dostarczanie.

Dlaczego dogłębne zrozumienie AI pozwala menedżerom produktu robić niemal wszystko

Im bardziej się w to zagłębiam, tym wyraźniej uświadamiam sobie, jak stroma jest krzywa uczenia się w zakresie skutecznego i wydajnego korzystania z AI/LLM, a także umiejętności dopasowania jej do preferowanych przez ludzi wokół nas lub członków naszych zespołów sposobów pracy. Umacnia to moje przekonanie, że każda osoba w firmie musi doskonale znać nie tylko LLM-y ogólnie i dostępne modele, lecz także liczne narzędzia ekosystemu wokół nich, takie jak MCP, tryby pracy, jak CLI i GUI, a przede wszystkim architekturę transformatorową. Osobom, które chcą pogłębić swoją wiedzę, lektura książek o zarządzaniu projektami z wykorzystaniem AI może dostarczyć cennych informacji na temat skutecznego wdrażania tych technologii.

Sprawne korzystanie z AI w obecnym morzu treści i narzędzi tworzonych przez AI, niezależnie od tego, czy chodzi o treści, czy narzędzia, to umiejętność, którą trzeba doskonalić, a można to zrobić wyłącznie poprzez doświadczenie. Trzeba rozumieć, jak działają LLM-y oraz co potrafią, a czego nie potrafią robić dobrze, aby uzyskać z nich jak najwięcej i osiągać optymalne rezultaty.

Wiele dostępnych na rynku „przełomowych” produktów i narzędzi SaaS wydaje się oferować dobre rozwiązania — na przykład tworzenie PRD — ale odkryłem, że 99% wszystkiego, co trzeba zrobić, można wykonać samodzielnie: taniej, szybciej, w bardziej spersonalizowany sposób i znacznie lepiej. Oczywiście pod warunkiem, że rozumie się powyższe koncepcje i ma umiejętności skutecznego korzystania z LLM-ów.

To jak w tych reklamach telewizyjnych, w których ktoś wykonuje prostą czynność, a następnie pokazują, jaka jest ona „trudna”, po czym próbują sprzedać ci całe urządzenie, które ma rozwiązać ten drobny problem? Zamiast pokroić banana na kawałki nożem jak normalny człowiek, chcą sprzedać ci krajalnicę w kształcie banana, która kroi wszystkie kawałki jednym ruchem…

Nóż to LLM, a krajalnica do bananów to tandetna aplikacja niszowa. Naucz się używać cholernego noża. Kup porządny, dobrej jakości, używaj go, poznaj go i przestań kupować głupoty tylko dlatego, że technologiczny Twitter mówi ci, że jakaś przypadkowa aplikacja SaaS właśnie „sprawiła, że projektanci stali się zbędni” albo „zabiła programowanie”.

Zasadniczo nie ma niczego, czego nie można zrobić za pomocą LLM w interfejsie wiersza poleceń, przeglądarce internetowej oraz od czasu do czasu przy użyciu otwartego, niezależnego od konkretnego zadania narzędzia automatyzacji, takiego jak n8n.

Oszczędzaj pieniądze i naucz się tworzyć rzeczy, które odzwierciedlają mądrość wynikającą z twoich zdobytych doświadczeń, zamiast akceptować wynik działania uruchomionej przez noc wyskakującej aplikacji SaaS.

Jedyny przypadek, w którym to nie miałoby zastosowania, dotyczy narzędzi przeznaczonych do jednego celu, które koncentrują się konkretnie na rozwiązywaniu problemów, do których architektura transformatorowa LLM w podstawowych modelach wiodących (tj. niedostrojonych) jest z natury nieodpowiednia. Przykładem może być analiza danych na dużą skalę lub matematyka.

Jak rozpocząć naukę AI jako menedżer produktu

Najlepsze w LLM jest to, że możesz zapytać je, jak się ich nauczyć. Jeśli jesteś wzrokowcem, tak jak ja, YouTube jest wisienką na torcie — znajdziesz tam mnóstwo dobrych materiałów o AI i LLM.

Gdybym zaczynał od nowa, podszedłbym do nauki w następujący sposób: powiedz LLM, że chcesz dowiedzieć się wszystkiego o obszarze AI/LLM, dostosowując wyjaśnienia do swojego poziomu wiedzy technicznej. Możesz nawet polecić mu zadawanie coraz bardziej technicznych pytań, aby rozpoznał twój obecny poziom biegłości w dowolnym obszarze AI/LLM, zaczynając od podstaw. A gdy dojdziesz do punktu, w którym wykraczasz poza swoją wiedzę, możesz poprosić je o polecenie tematów do nauki — od podstaw architektury transformatorowej aż po sposób działania aplikacji takiej jak ChatGPT.

Chodzi o uzyskanie listy tematów do nauki, a następnie wyszukanie każdego z nich na YouTube, aby znaleźć film pomagający zrozumieć dany temat.

Oto przykładowe polecenie:

Zachowuj się jak osoba oceniająca mój „punkt wyjścia” w zakresie AI/LLM.

Zadaj mi maksymalnie 12 pytań (połącz łatwe i techniczne), aby ocenić:

• mój ogólny poziom swobody w kwestiach technicznych (programowanie, dane, API)
• moje rozumienie działania LLM (tryby pracy modelu, takie jak CLI i GUI, a także tokeny, kontekst, halucynacje itp.)
• moją znajomość współczesnych wzorców aplikacji opartych na LLM (RAG/embeddingi, agenci/wykorzystywanie narzędzi)
• moją umiejętność oceny jakości (ewaluacje, weryfikacja)
• moją świadomość zagrożeń (prywatność, wstrzykiwanie promptów itp.)
• moją świadomość ograniczeń AI (dobre i złe przypadki użycia LLM, dokładność, niekontrolowany charakter wyników LLM itp.)

Gdy odpowiem, wyświetl WYŁĄCZNIE:

• 5–10 tematów na YouTube o największym znaczeniu, których powinienem nauczyć się w następnej kolejności, uporządkowanych według priorytetu. Każdy punkt musi zawierać frazę do wyszukania na YouTube (nie zdanie) oraz 5–10 słów wyjaśniających, „dlaczego ma to znaczenie”.

Zacznij teraz zadawać pytania.

Jakich umiejętności związanych z AI menedżerowie produktu powinni nauczyć się w pierwszej kolejności

Moim zdaniem ważne jest zrozumienie, gdzie i jak można używać LLM. Mam na myśli zrozumienie, że mogą działać w aplikacji, w terminalu komputera albo w kodzie obsługującym automatyzację za pośrednictwem MCP lub API.

W drugiej kolejności musisz zrozumieć, że są one:

1. Niedeterministyczne, niekontrolowalne i podatne na błędy
2. Nigdy nie należy polegać na nich w kwestii dokładnych informacji, szczególnie przy podejmowaniu krytycznych decyzji
3. Można je kreatywnie automatyzować, aby ograniczyć skutki dwóch poprzednich punktów, zależnie od przypadku użycia

Klasyczny przykład, który podaję, to nigdy nie używać LLM do napisania za ciebie całego eseju, ale jak najbardziej można poprosić je o wymienienie kilku pomysłów na kierunki, w których można pójść, jeśli utkniesz i nie wiesz, co napisać dalej. Innymi słowy, LLM świetnie uzupełniają ludzki umysł, ale wejście na drogę, na której próbujesz powierzyć im całe myślenie zamiast ludzkiemu umysłowi, prowadzi w mroczne miejsce.

Ostatnia rzecz, o której wspomnę, jest taka, że podczas nauki powyższych koncepcji musisz samodzielnie je wypróbowywać. Jeśli na przykład uczysz się, jak działa projektowanie promptów, powinieneś zadać LLM to samo pytanie sformułowane na dwa różne sposoby, aby zobaczyć różnicę w wynikach. Nigdy nie ucz się bez jednoczesnego praktykowania tego, czego się uczysz.

Dlaczego nie należy automatyzować za pomocą AI interakcji z klientami o dużej wartości

Gdy nauczysz się tego, co musisz wiedzieć, możesz zrobić praktycznie wszystko. Ale to nie oznacza, że powinieneś.

W przypadku firmy na wczesnym etapie rozwoju, oferującej produkt premium, interakcje z klientami i sprzedaż „wydają się” najbardziej podatne na wykorzystanie AI i automatyzacji. W praktyce przekonałem się jednak, że kontakt z człowiekiem jest absolutnie niezbędny. Osobiście uważam, że interakcja z użytkownikami lub potencjalnymi klientami stanowi dużą wartość dodaną dla obu stron i nawet nie chcę próbować jej automatyzować.

Jako PM wyrządzałbyś sobie krzywdę, całkowicie dystansując się od rozmów z użytkownikami. Im częściej osobiście rozmawiasz z nimi własnym głosem, tym więcej informacji zdobywasz i tym większe zaufanie budujesz.

Dlaczego menedżerom produktu trudno jest — choć jest to możliwe — wnosić wkład w kod

Dlatego ostrożnie podchodzę do tego, do czego wykorzystuję AI, ale korzystam z niego bardzo często.

Na przykład tuż przed wdrożeniem na produkcję zawsze wybucha gorączka poprawiania błędów. Zazwyczaj w większej firmie tymi końcowymi pracami zajmowaliby się inżynierowie i zespół QA. Oczywiście starszy rangą product manager byłby na bieżąco, ale jednocześnie planowałby kolejne kroki i strategie monitorowania wdrożenia, zbierał opinie użytkowników, przygotowywał kilka cykli naprzód albo gromadził metryki po uruchomieniu funkcji lub produktu.

Ponieważ obecnie pracuję w mniejszej firmie, przełomową zmianą okazała się dla mnie możliwość wspólnego z inżynierami usuwania błędów, a udało mi się to osiągnąć wyłącznie dzięki wykorzystaniu AI/LLM.

W swojej karierze zawsze angażowałem się w QA produktów i funkcji, ale rzadko miałem możliwość wejścia w sam środek problemu i naprawienia błędu wymagającego zmian w kodzie w całym stosie technologicznym.

Doświadczeni specjaliści techniczni wiedzą, że inżynierowie są bardzo przywiązani do swoich baz kodu i standardów kodowania. Dlatego nawet jeśli technicznie wiesz, jak naprawić konkretny błąd, musisz też znać kontekst standardów kodowania i osobowości w zespole inżynierskim, a także rozumieć inżynierów, którzy pracowali nad poszczególnymi fragmentami kodu. W rezultacie naprawienie niektórych błędów jest dalekie od łatwego, nawet jeśli wiesz, jak to zrobić, a większość inżynierów zlekceważyłaby twoją prośbę o scalenie poprawki.

Dzięki AI udało mi się jednak nie tylko wnosić wkład w kod poprzez bezpośrednie wypychanie zmian do gałęzi main, ale także zaradzić dodatkowym czynnikom kulturowym, które się z tym wiążą.

Jak zbudować agenta AI, który może bezpiecznie wnosić wkład w bazę kodu

Moje początkowe podejście polegało na stworzeniu dokumentu Markdown ze standardami kodowania. W tym celu rój agentów w Claude Code analizował całe repozytorium z poprzednich sześciu miesięcy i przyswajał styl kodowania, plik Claude.md repozytorium, a przede wszystkim wszystkie komentarze na temat różnic w GitHubie, rozwiązywania konfliktów, commitów i zmian wprowadzonych w pull requestach.

W ten sposób uzyskałem dość solidny dokument ze standardami kodowania, który następnie rozszerzyłem, przekształcając go w zestaw umiejętności i poleceń w Claude Code. Miały one sprawdzać dowolny kod wygenerowany przeze mnie w ramach poprawki błędu i dostosowywać go do standardów kodowania, które zespół wdrożył już w bazie kodu. Następnie utworzyłem kolejnego subagenta, który za pomocą hooków połączonych z GitHubem mógł być również uruchamiany przeze mnie ręcznie w celu przeanalizowania napisanego przeze mnie kodu, a także komentarzy lub poprawek, a następnie włączenia wszystkich tych informacji do uzupełnienia dokumentu ze standardami kodowania.

Ostatecznie, już po zaledwie kilku pull requestach, kod, który generowałem dla danej poprawki, można było bardzo łatwo przekształcić w taki rodzaj kodu, jaki chcemy widzieć w bazie kodu, za pomocą prostego dokumentu Markdown, który był w istocie stale udoskonalanym i samouczącym się przewodnikiem po stylu kodowania, uruchamianym przez wiele zadań cron i automatyzacji z Claude Code.

Agent jest teraz tak dobry, że mogę scalać zmiany bezpośrednio do gałęzi main.

Jak małe zespoły produktowe mogą zwiększyć elastyczność

To dobry przykład tego, jak wychodzę poza tradycyjną rolę PM-a. Wykraczanie poza tradycyjne role wymaga jednak dobrych procesów.

Mamy dobrze uporządkowany i otagowany backlog w Linear, a w poniedziałki, środy i piątki rano odbywamy obowiązkowe spotkania. W dni bez spotkania synchronizacyjnego jesteśmy na bieżąco dzięki odprawie na Slacku. Cała pozostała priorytetyzacja i dyskusja odbywa się w czasie rzeczywistym na Slacku.

To może nie być najlepsze rozwiązanie dla większych firm, ale zdziwiłbyś się, jak dobrze sprawdza się w tym przypadku i jak dużą elastyczność nam zapewnia. Kiedyś korzystałem z Google Drive, arkuszy kalkulacyjnych, dokumentów, prezentacji i miliona innych aplikacji. Teraz, jako mały zespół, możemy działać przy użyciu GSuite, Slacka, Linear i GitHuba.

Lekkie metody zarządzania produktem są ważne w tej nieustannie ewoluującej przestrzeni AI/LLM. Każdego dnia tygodnia może pojawić się coś nowego w opiniach użytkowników lub wydaniach potencjalnych konkurentów, za czym będziemy musieli szybko nadążyć i wokół czego będziemy musieli ustalać priorytety.

Jak AI zmusza zespoły produktowe do ponownego przemyślenia rytuałów

Jeśli chodzi o rytuały, największa zmiana polega na tym, że stały się one naprawdę cyklicznym, niekończącym się procesem, a nie czymś opartym na zastałych dokumentach, które trzeba nieustannie tworzyć i przeglądać.

Zakres zaczyna się jako konkretne zgłoszenie w Linear, zawierające różny poziom szczegółowości. Następnie wykorzystuję AI do sprawdzenia go pod kątem niejednoznaczności, przypadków brzegowych i możliwości ustalenia kolejności działań, a potem dopracowuję go, aż będzie można wdrożyć go w najmniejszym możliwym wycinku.

W naszym małym, zdalnym zespole uzgadnianie odbywa się głównie asynchronicznie — za pomocą krótkiego wątku na Slacku, który kończy się jasną decyzją i listą kolejnych działań, a lekkie codzienne odprawy obsługuje Geekbot. Mimo to trzy lub cztery spotkania zespołu w tygodniu nadal mają ogromną wartość, ponieważ pozwalają nam wspólnie wymieniać pomysły i budować morale.

Walidacja stała się dla mnie bardziej rygorystyczna, a nie luźniejsza. LLM-y zazwyczaj generują przekonujące bzdury, jeśli nie wiesz, jak prawidłowo z nich korzystać, dlatego każda zmiana funkcji lub aplikacji otrzymuje niewielki zestaw testów ewaluacyjnych — realistyczne dane wejściowe, oczekiwane wyniki i przypadki adwersarialne — który AI może pomóc przygotować, ale który samodzielnie opracowuję i testuję.

Wykonanie sprowadza się następnie po prostu do Linear + Claude Code + samodzielnie hostowanej analityki Posthog. Wdrażamy, obserwujemy, dostosowujemy i utrzymujemy szybki cykl działania, ponieważ rynek technologiczny zmienia się obecnie w tempie, które wydaje się niemal godzinowe.

Dlaczego minimalistyczny zestaw narzędzi oparty przede wszystkim na AI jest najlepszy

Oto mój podstawowy zestaw narzędzi PM:

• GSuite
• Slack
• Bot Slacka Geekbot (do codziennych spotkań)
• Linear
• VSCode
• LLM oparty na wierszu poleceń (w naszym przypadku Claude Code)

Dlaczego Linear? Zawiera absolutne minimum. Jest wystarczająco funkcjonalny, aby sprostać niemal wszystkim wymaganiom zespołu projektowego, ale jednocześnie na tyle prosty, że każdy może z niego korzystać. To przeciwieństwo JIRA. Co najważniejsze, łatwo integruje się z GitHubem i Slackiem, czyli miejscami, w których inżynierowie pracują od początku. Jest prosty, lekki i powoduje minimalne dodatkowe tarcia, gdy inżynierowie mają na bieżąco realizować zadania lub je aktualizować. Jest także niezwykle elastyczny, dzięki czemu można robić ciekawe rzeczy, takie jak automatyczne poproszenie LLM działającego w wierszu poleceń o próbę naprawienia błędu po zgłoszeniu go w roboczym PR — zanim człowiek w ogóle zacznie się mu przyglądać.

Nic więcej nie jest potrzebne. Wszystkie inne prace można wykonywać za pomocą narzędzi o otwartym kodzie źródłowym w terminalu.

Ulubione narzędzie AI Cole’a do osobistej produktywności

Na osobistym, niezwiązanym z zespołem poziomie absolutnie uwielbiam Raycast za zwiększanie produktywności. To najlepsza aplikacja zapewniająca szybki dostęp, w pełni konfigurowalna i niezwykle lekka, która zastępuje okropną aplikację „Spotlight” na Macu lub klawisz „Windows” w systemie Windows. W przypadku większości czynności ograniczysz korzystanie z myszy o 75%. Możesz zintegrować niemal każdą aplikację za pomocą istniejących integracji lub z łatwością stworzyć własne — wystarczy poprosić Claude Code o przygotowanie rozszerzenia!

Jeśli chcę skopiować do schowka tekst z obrazu, który widzę, naciskam skrót klawiszowy Raycast, wpisuję „OCR” i naciskam Enter. Uruchamia to narzędzie do wykonywania zrzutów ekranu i rozpoznawania tekstu cleanshotX, dzięki czemu mam tekst z dowolnego obrazu w mniej niż pięć sekund. Podobnie mogę użyć skrótu, wpisać „Ask Spotify”, a następnie wprowadzić zdanie w języku naturalnym, takie jak „daj mi dobrą, energetyczną muzykę do programowania”, a narzędzie zinterpretuje moje zdanie za pomocą LLM, wyszuka tagi i właściwości muzyki w API Spotify, a następnie natychmiast uruchomi w Spotify playlistę z muzyką, o którą poprosiłem.

Możliwości zastosowań są nieograniczone. Wystarczy pobrać aplikację, aktywować AI za pomocą własnych kluczy API lub ich subskrypcji, a następnie przejrzeć najpopularniejsze rozszerzenia na ich stronie internetowej i znaleźć rzeczy, które mogą być dla Ciebie przydatne. To całkowicie zmienia zasady gry.

Dlaczego zarządzanie produktem i inżynieria zaczynają się przenikać

Wkrótce większość inżynierów zajmujących się funkcjami będzie zmuszona zacząć myśleć i podejmować decyzje jak menedżerowie produktu, a menedżerowie produktu będą musieli nauczyć się wystarczająco dużo o uczeniu maszynowym, sieciach neuronowych, LLM-ach i różnych architekturach, aby dzięki korzystaniu z LLM-ów zbliżyć się do poziomu inżyniera, nie stając się nim w rzeczywistości. Ta transformacja odzwierciedla odważne podejście do integracji AI, które przekształca tradycyjne role.

Oczywiście istnieje wiele wyjątków i obszarów, w których nie będzie to miało zastosowania, ale ogólnie rzecz biorąc, diagram Venna wszystkich wcześniejszych ról w firmie — od sprzedaży, przez marketing i produkt, po inżynierię — będzie nieuchronnie zbliżał się do jednego wspólnego obszaru, a bardzo niewiele umiejętności pozostanie przypisanych wyłącznie do jednej konkretnej roli.

Jak uniknąć nieuniknionego kryzysu egzystencjalnego, gdy AI zmienia pracę nad produktem

Oto moja rada: spróbuj uniknąć nieuniknionego kryzysu egzystencjalnego, do którego możesz być skłonny w miarę dalszego rozwoju tej ery technologii.

Zamiast tego skup się na umiejętnościach, które posiadasz i które rozwinąłeś dzięki doświadczeniu. LLM-y potrafią generować treści, ale naprawdę kiepsko radzą sobie z dobrym wyczuciem.

Odpowiedzi są teraz powszechne, więc umiejętność zadawania AI wyjątkowych pytań opartych na konkretnym doświadczeniu jest dziś bardzo cenna. Co więcej, odkrycie we własnym umyśle właściwego pytania, które należy zadać, jest prawdziwą pracą intelektualną.

Śledź jego działania

Możesz śledzić Cole’a na X oraz na jego osobistej stronie internetowej, gdzie nadal podważa granice tego, co jest możliwe dla menedżerów produktu. Zajrzyj także na stronę Probably.dev!

Już wkrótce kolejne wywiady z ekspertami na stronie The Digital Project Manager!