Poniższy tekst zawiera notatki z podcastu, w którym Teresa Torres, autorka „Continuous Discovery Habits” i ekspertka współpracująca z ponad 17 000 menedżerów produktu z całego świata, dzieli się swoimi obserwacjami na temat evolucji product discovery w kontekście sztucznej inteligencji. Wszystkie przedstawione przemyślenia, metody i wnioski pochodzą od rozmówców podcastu.

TL;DR

Discovery staje się ważniejsze, nie mniej ważne – kiedy tworzenie prototypów jest „za darmo”, potrzebujemy lepszej selekcji pomysłów
Wywiadowanie oparte na historiach – zbieraj konkretne historie z przeszłości zamiast hipotetycznych opinii
AI prototyping należy używać do testowania założeń – nie do testowania całych pomysłów na raz
Produkty AI wymagają 5 nowych umiejętności: inżynieria kontekstu, orkiestracja, obserwacja, ocena jakości, utrzymanie
Analiza błędów staje się nową formą discovery – analizowanie śladów i tworzenie ewaluacji to sposób uczenia się o użytkownikach
Fake discovery ma jasne symptomy – nic się nie zmienia w backlogu, zespoły nie zabijają pomysłów
Continuous discovery to żywy dokument – opportunity solution tree wymaga regularnych aktualizacji co 3–4 wywiady

Dlaczego discovery w erze AI jest kluczowe

Teresa Torres prezentuje jasne stanowisko w tej sprawie. Według niej, kiedy delivery jest za darmo, discovery staje się bardziej ważne. Łatwość tworzenia prototypów AI nie eliminuje potrzeby badania potrzeb użytkowników, lecz wręcz przeciwnie – zwiększa jej znaczenie.

Torres argumentuje, że zespoły budujące wszystko bez selekcji doprowadzą użytkowników do frustracji. W rezultacie pojawi się chaos w produkcie, zmęczenie ciągłymi zmianami oraz przeładowanie funkcjonalnościami.

Ekspertka ilustruje to analogią z serialu Simpsonowie. Homer projektował własne auto, dodając wszystkie elementy, które wydawały mu się atrakcyjne – wielki fotel jak recliner, liczne uchwyty na piwo czy miejsca na pączki. Jednak finalne auto wyglądało absurdalnie i prawdopodobnie nie spełniało podstawowej funkcji transportu.

Torres redefiniuje cel discovery, podkreślając kluczową różnicę. Discovery nie służy przede wszystkim oszczędzaniu czasu inżynierów, lecz chronieniu klientów przed błędnymi funkcjami i ciągłymi zmianami produktu.

Problem z tradycyjnymi customer interviews

Torres identyfikuje kilka głównych przyczyn, dla których zespoły prowadzące customer interviews wciąż tworzą produkty nietrafione.

Słabości w prowadzeniu wywiadów

Większość zespołów wchodzi na wywiad z zamiarem eksplorowania swoich rozwiązań, co jednak nie stanowi najlepszego sposobu na uzyskanie wartościowych informacji zwrotnych. Prawdziwym celem customer interview powinno być poznanie klientów.

Torres wskazuje najczęstsze błędy w zadawanych pytaniach:

„Co lubisz i nie lubisz w różnych rzeczach?”
„Opowiedz o swoim doświadczeniu z produktem”
„Czy używałbyś tego produktu?”
Zadawanie hipotez zamiast głębszego dociekania

Różnica między hipotezami a rzeczywistością

Ekspertka przedstawia wyraźną różnicę między pytaniami hipotetycznymi a podejściem opartym na historiach.

Złe podejście charakteryzuje się pytaniami typu „Czy używałbyś tego produktu?”. Ludzie nie potrafią przewidzieć przyszłego zachowania, dlatego często mówią „tak” z grzeczności lub nadmiernego optymizmu co do przyszłego czasu.

Z kolei lepsze podejście polega na pytaniach w stylu „Opowiedz o ostatnim razie, gdy używałeś produktu”. Takie pytania pozwalają poznać rzeczywiste zachowania, a nie wyobrażenia czy aspiracje użytkowników.

Wywiadowanie oparte na historiach – praktyczne podejście

Torres wprowadza koncepcję „wykopywania historii”, porównując ją do pracy archeologów, którzy używają małych narzędzi i delikatnie wydobywają artefakty.

Przełamanie normy 50/50

W normalnej rozmowie osoby mówią na zmianę. Jednak w wywiadzie uczestnik powinien wypowiadać się przez większość czasu. Konieczne jest wyraźne komunikowanie, że szczegóły są naprawdę potrzebne.

Praktyczny przykład głębokiego wywiadu

Zamiast zadowalać się krótkimi odpowiedziami jak „oglądałem film wczoraj po kolacji”, Torres sugeruje dalsze drążenie:

„Przeniesiemy się do tego momentu po kolacji”
„Opowiedz o decyzji dotyczącej oglądania czegoś”
„Przejdź mnie przez całą narrację – jak szedłeś z jadalni do salonu”
„Jakiego urządzenia użyłeś?”

Główny błąd zespołów

Zespoły często zaczynają od pytania opartego na historii, ale nie potrafią skutecznie jej „wykopać”. Zamiast tego zgadują, co się wydarzyło, zadając pytania w stylu „Czy coś poszło nie tak podczas oglądania?” czy „Czy sprawdzałeś rekomendacje?”.

Torres zaleca używanie podpowiedzi czasowych: „Co robiłeś najpierw?” oraz „Co było potem?”.

Szablon syntezy pojedynczego wywiadu

Ekspertka opracowała konkretny szablon dla każdego wywiadu:

Mapa doświadczenia – kluczowe momenty w historii (najważniejszy element)
Lista możliwości – niezaspokojone potrzeby, bolączki, pragnienia
Szybkie fakty – dane segmentacyjne (zaangażowany klient? nowy? enterprise?)
Zdjęcie i cytat – pomoce pamięciowe
Spostrzeżenia – inne notatki o niejasnym jeszcze miejscu

Synteza między wywiadami

Po przeprowadzeniu 3–4 wywiadów Torres tworzy „super mapę doświadczenia” obejmującą wszystkie historie. Momenty z tej mapy stają się możliwościami najwyższego poziomu w opportunity solution tree.

Opportunity solution tree funkcjonuje jako żywy dokument wymagający aktualizacji po każdych 3–4 wywiadach. W przypadku prowadzenia jednego wywiadu tygodniowo oznacza to rewizję co 3–4 tygodnie.

AI jako partner w discovery

Torres używa AI jako partnera do dyskusji o rezultatach – pomocy w lepszym formułowaniu czy mierzeniu. Nie polega jednak na AI w kwestii określania, jaki powinien być rezultat, ponieważ wymaga to kontekstu biznesowego.

Obawy dotyczące AI w wywiadach z klientami

Niektóre zespoły eksperymentują z AI prowadzącym customer interviews. Torres wyraża jednak mieszane uczucia, martwiąc się o przekaz dla klientów – czy naprawdę chcemy się o nich uczyć, skoro nie poświęcamy własnego czasu na rozmowy.

Dodatkowo bezpośrednia rozmowa z klientem buduje empatię, której nie zapewni czytanie transkryptu. Dlatego Torres nadal zaleca bezpośrednie rozmowy między ludźmi.

Konkretne liczby dotyczące AI synthesis

Torres przeprowadziła intensywne eksperymenty porównujące AI synthesis z własną pracą. Jej wnioski pokazują, że rozwiązania AI są dobre w 60-80%, jednak martwi ją utrata pozostałych 20-40%.

Jej podejście hybrydowe zakłada:

Do zadań codziennych i mniej istotnych – używaj AI do szybkiej analizy
Dla kluczowych wyróżników produktu – przeprowadzaj analizę samodzielnie, aby dogłębnie zrozumieć dane i zbudować przewagę konkurencyjną

Torres podkreśla, że ludzkie mózgi zmieniają się podczas spędzania czasu z danymi, co stanowi wartość trudną do zastąpienia.

AI prototyping we właściwym kontekście

Torres wyraża zachwyt nad AI prototyping, opisując je jako „naprawdę magiczne doświadczenie”. Jednak ostrzega przed niewłaściwym zastosowaniem.

Właściwy moment na AI prototyping

Ekspertka nie zaleca rozpoczynania od AI prototyping. Zamiast tego proponuje konkretną kolejność:

Posiadanie jasnego rezultatu
Przeprowadzenie 3–4 wywiadów
Stworzenie szkicu przestrzeni możliwości
Wybór docelowej możliwości
Wymyślenie kilku rozwiązań do porównania
Dopiero wtedy użycie AI prototyping do testowania założeń

Testowanie założeń kontra testowanie całego pomysłu

Zamiast testować kompletne pomysły, Torres dzieli je na leżące u podstaw założenia. Przykład z jej trenera wywiadów ilustruje wyzwania techniczne:

Czy studenci pozostają w głównym pokoju wystarczająco długo, by otrzymać pozwolenie na nagrywanie?
Czy pamiętają o nagrywaniu w breakout room?
Czy odnajdą nagranie na komputerze?
Czy prześlą je do odpowiedniego narzędzia?

Torres testuje każde założenie osobno, dzięki czemu dokładnie wie, gdzie proces się psuje. Testowanie całego przepływu nie pozwoliłoby zidentyfikować konkretnego problematycznego kroku.

Typowe błędy w AI prototyping

Torres identyfikuje „syndrom błyszczącego obiektu” – sytuację, gdy ludzie zaczynają od pomysłów na rozwiązania, nie znając problemu klienta, który rozwiązują.

Według ekspertki praca PM polega na rozwiązywaniu potrzeb klientów w kontekście konkretnego problemu, bolączki czy pragnienia. AI prototyping ułatwia przekształcenie półupieczonego pomysłu w realny produkt, co wymaga dyscypliny w zatrzymaniu się i zapytaniu: „Po co to robimy?”.

Discovery dla produktów AI – nowe wyzwania

Torres buduje swój pierwszy produkt AI – trenera wywiadów przekazującego informacje zwrotne studentom na podstawie transkryptów. Doświadczenie to ujawniło jej istotne różnice w podejściu.

Kontekst historyczny continuous discovery

Torres przypomina, że jej framework powstał dla nowo upoważnionych zespołów produktowych. Historycznie zespoły otrzymywały funkcje z określonymi datami dostarczenia (roadmaps), a zadaniem PM było delivery zgodnie z wytycznymi interesariuszy.

Następnie firmy przeszły z focus na wyniki na focus na rezultaty. Obecnie mówią: „nie wiemy, co budować, ale musisz zmniejszyć odejścia lub zwiększyć retencję”. Zespoły odpowiadają: „zawsze mówiliście mi, co budować, nie wiem, jak to robić”.

Continuous discovery habits powstały właśnie dla takich zespołów – jako sposób odpowiadania na wiecznie aktualne, szeroko otwarte wyzwania związane z zaangażowaniem i retencją.

Pięć komponentów rozwoju produktu AI

Inżynieria kontekstu (prompt engineering)

Torres preferuje termin „inżynieria kontekstu” od „prompt engineering”. Problem polega na tym, że w czacie z AI możemy poprawić nieudane polecenie, natomiast w produkcie jest ono „jednorazowe” (one shot) i musi działać niezawodnie tysiące razy. Brak drugiej szansy oznacza konieczność precyzyjnego dostarczenia kontekstu.

Kluczowe spostrzeżenie Torres dotyczy podobieństwa inżynierii kontekstu w produktach LLM do nauczania ludzi umiejętności. Chodzi o to, jak i kiedy dostarczyć właściwy kontekst, nie tylko o pisanie promptów. Torres wyraża zainteresowanie angażowaniem naturalnych nauczycieli w budowanie produktów AI.

Orkiestracja

Trener Torres zaczął jako jeden prompt, obecnie składa się z siedmiu promptów i szybko rośnie. Kluczowym pytaniem jest sposób podziału zadań, aby LLM były w nich skuteczne.

Przykład: LLM myliły się między różnymi wymiarami oceny, gdy jeden wymiar pobierał instrukcje z innego. Torres podzieliła system na 7 osobnych wywołań, co wymaga orkiestracji odpowiedzi.

Torres wspomina narzędzia do orkiestracji w prostym języku:

Serwery MCP – agent może żądać informacji z innych narzędzi
RAG – funkcjonuje jak wyszukiwanie w bazie dokumentów, wyciągając właściwy kontekst dla zapytania
Narzędzia – sposób przekazania agentowi dostępu do zewnętrznych funkcji

Obserwacja

Większość produktów AI loguje ślady (prompt + odpowiedź). Torres podkreśla etyczny aspekt – użytkownicy powinni o tym wiedzieć, a informacja nie powinna być ukrywana w regulaminie.

Ocena jakości (ewaluacje)

Torres przeprowadza analizę błędów w partiach po 50 transkryptów. Porównuje odpowiedź trenera z tym, co zrobiłaby jako instruktor. Po zidentyfikowaniu błędów pisze ewaluacje – kod automatycznie wykrywający te błędy.

Utrzymanie

Bieżące utrzymanie różni się znacząco od funkcji deterministycznych.

Analiza błędów jako nowa forma discovery

Torres poświęca znaczny czas analizowaniu śladów, co staje się pętlą informacji zwrotnej do inżynierii kontekstu i orkiestracji.

Proces analizy błędów obejmuje:

Przegląd śladów (50 na raz)
Notowanie błędów z porównaniem do eksperckiego podejścia
Szukanie powtarzających się wzorców
Pisanie ewaluacji dla uporczywych błędów (automatyczne wykrywanie)
Testowanie A/B zmian (stare vs nowe podejście)

Torres używa Claude Code od tygodnia i już wydała większą aktualizację. Nie napisała ani jednej linii kodu, pełniąc rolę recenzenta i architekta.

Inne eksperymenty w branży

Torres wspomina eksperymenty Davida Blanda z AI w identyfikacji założeń, a nawet testów założeń, co pokazuje szybki rozwój dziedziny.

Rozpoznawanie fake discovery

Torres przedstawia jasne kryteria fake discovery poprzez czerwone flagi:

Brak zmian w backlogu
Nieuśmiecanie żadnych pomysłów
Zawsze kończenie budowaniem tego, od czego się zaczęło
Nierozważanie wielu rozwiązań
Brak wpływu wywiadów na decyzje produktowe

Według Torres istnieje dużo „teatru discovery”, jednak nie uważa, żeby zespoły celowo udawały. Problem tkwi bardziej w braku odpowiedniej wiedzy.

Toksyczne przekazy w branży PM

Torres krytykuje obecny trend w przemyśle, wskazując na toksyczne przekazy sugerujące, że jeśli nie robisz wszystkich „właściwych” rzeczy, nie jesteś prawdziwym menedżerem produktu.

O LinkedIn mówi jako o „toksycznym śmietniku, gdzie wszyscy mówią, że robisz swoją pracę źle”. Torres chce odejść od tego przekazu.

Jej stanowisko jest jasne: jeśli robisz to, czego oczekuje twoja firma, jesteś menedżerem produktu. To fundamentalna podstawa. Można robić więcej, jednak bazą pozostaje dostarczanie zgodnie z oczekiwaniami organizacji.

Osobista praca wymagana w discovery

Discovery wymaga pracy nad sobą – odłożenia ego na bok oraz oderwania się od ulubionego pomysłu. Konieczne jest zachowanie ciekawości w siódmym wywiadzie na ten sam temat oraz aktywne szukanie tego, co unikalne u każdego klienta.

Torres identyfikuje problem organizacyjny: firmy nadal nagradzają za bycie w porządku i posiadanie silnych opinii, nie nagradzając ciekawości ani porażek wskazujących na naukę.

Wiele kontekstów organizacyjnych nie wspiera tego sposobu pracy. Jednak Torres uważa, że jednostki mają więcej sprawczości, niż myślą, nawet bez wsparcia organizacyjnego.

Przyszłość discovery w erze AI

Ostateczny wniosek z analizy Torres jest jasny: przyszłość należy do zespołów, które potrafią mądrze połączyć siłę AI z ludzką empatią. Sztuczna inteligencja nie zastąpi potrzeby rozmowy z klientem, ciekawości ani krytycznego myślenia.

Prawdziwą siłą AI jest wzmacnianie ludzkiej pracy, a nie jej zastępowanie. Co więcej, rozwój produktów AI prowadzi do coraz większego zacierania się ról w zespole produktowym, wymagając od menedżerów produktu, projektantów i inżynierów jeszcze ściślejszej współpracy.

Praktyczne wnioski

Dla regularnego discovery

Używanie pytań opartych na historiach: „Opowiedz o ostatnim razie, gdy…” zamiast hipotetycznych
Wykopywanie historii: podpowiedzi czasowe, szczegóły, unikanie zgadywania
Aktualizowanie opportunity solution tree co 3–4 wywiady
Prowadzenie testowania założeń przed całymi prototypami

Dla produktów AI

Inżynieria kontekstu wymaga wiedzy o kliencie – nie można nauczyć LLM pomagać klientom bez rozumienia ich potrzeb
Rozpoczynanie od prostoty z dodawaniem złożoności na podstawie analizy błędów
Etyczne logowanie śladów z transparentnym informowaniem użytkowników
Analiza błędów jako discovery – wzorce w błędach pokazują potrzeby klientów

Uniwersalne zasady

Discovery staje się ważniejsze, gdy dostarczanie jest łatwe
Unikanie syndromu błyszczącego obiektu – zawsze w kontekście problemu klienta
Podejmowanie decyzji porównawczych – wiele rozwiązań dla tej samej możliwości
Tygodniowe wywiady budują empatię i kontekst

Kluczowe listy kontrolne

Wywiadowanie oparte na historiach

Przed wywiadem:

Przygotuj rezultat, nad którym pracujesz
Zaplanuj zbieranie konkretnych historii z przeszłości
Unikaj pytań o przyszłe zachowania

Podczas wywiadu:

Zacznij od: „Opowiedz o ostatnim razie, gdy…”
Używaj podpowiedzi czasowych: „Co robiłeś najpierw?”, „Co było potem?”
Wykopuj szczegóły – sytuuj uczestnika w konkretnym momencie
Dąż do proporcji 80/20 – uczestnik mówi większość czasu

Po wywiadzie:

Stwórz mapę doświadczenia – kluczowe momenty historii
Wylistuj możliwości – bolączki, potrzeby, pragnienia
Zapisz znaczący cytat – pomoc pamięciową

Rozpoznawanie fake discovery

Czerwone flagi:

Brak zmian w backlogu przez tygodnie
Zespół nie zabija żadnych pomysłów
Zawsze budują to, od czego zaczęli
Brak testowania założeń – od razu testowanie całego pomysłu

Zdrowe discovery:

Backlog ewoluuje na podstawie nauki
Pomysły są odrzucane na podstawie dowodów
Wiele rozwiązań jest rozważanych
Regularne aktualizacje opportunity solution tree

Rozwój produktu AI

Inżynieria kontekstu:

Zrozum potrzeby klientów przed pisaniem promptów
Testuj prompty na realistycznych ilościach danych
Projektuj na sukces za pierwszym razem (bez ludzkiego udoskonalania)

Jakość i obserwacja:

Ustaw logowanie śladów (etycznie – informuj użytkowników)
Ustanów proces analizy błędów (przegląd partii 50 śladów)
Pisz ewaluacje dla uporczywych błędów
Testuj A/B ulepszenia

Praktyczne prompty inspirowane podejściem Teresa Torres

Na podstawie opisów Torres z podcastu – sposoby wykorzystania AI w discovery i development

AI jako partner do myślenia dla rezultatów

Kiedy stosować: Gdy masz rezultat zdefiniowany przez zespół kierowniczy, ale chcesz go lepiej sformułować lub zmierzyć

Mam rezultat zdefiniowany przez przywództwo: [wstaw swój rezultat]


Pomóż mi lepiej go sformułować i zaproponuj sposoby mierzenia. Weź pod uwagę:
- Czy jest wystarczająco konkretny?
- Jakie metryki najlepiej go odzwierciedlają?
- Jak mogę go komunikować zespołowi?
- Czy jest osiągalny w kontekście naszego produktu?

Inżynieria kontekstu – nauczanie AI jak ekspert

Kiedy stosować: Budując funkcję produktu AI, przekazując wiedzę domenową

Chcę nauczyć Cię oceniać [konkretną aktywność] tak jak robiłby to ekspert.


Oto moja rubrika/framework: [wstaw swoją wiedzę ekspercką]

Przykłady dobrej vs złej [aktywności]: [konkretne przykłady]

Teraz przeanalizuj ten przykład i oceń go zgodnie z rubryką, wyjaśniając swoje rozumowanie krok po kroku.

Claude Code – rozwiązywanie problemów

Kiedy stosować: Gdy masz zidentyfikowany problem w produkcie AI i potrzebujesz pomocy z implementacją

Zidentyfikowałem problem w moim produkcie AI: [opis problemu]


Możesz zobaczyć cały kod. Pierwszym krokiem jest wykrycie tego problemu.

Pomóż mi zaprojektować ewaluację, która wykryje ten wzorzec. Zacznijmy od prostego rozwiązania.

Analiza błędów – przegląd partii

Kiedy stosować: Analizując jakość wyników AI, szukając wzorców w błędach

Przeanalizowałem 50 wyników mojego systemu AI i znalazłem te wzorce błędów:

[lista błędów z przykładami]

Dla każdego błędu:
1. Jak często występuje (%)
2. Czy to błąd inżynierii kontekstu czy orkiestracji?
3. Jakie może być rozwiązanie?
4. Jak napisać ewaluację do automatycznego wykrywania?

Uproszczenie gdy AI proponuje zbyt złożone rozwiązania

Kiedy stosować: Gdy AI proponuje zbyt skomplikowane rozwiązanie

Twoje rozwiązanie jest zbyt złożone. Zaproponowałem prostsze podejście: [twój prosty pomysł]

Czy możesz pomóc mi zaimplementować tę prostszą wersję? 
Priorytetem jest działające rozwiązanie, nie elegancja.

Synteza AI z ludzkim nadzorem

Kiedy stosować: Gdy masz dużo danych z wywiadów do syntezy, ale chcesz zachować ludzkie spostrzeżenia

Oto transkrypty z [liczba] wywiadów klientów na temat [topic]:

[załącz transkrypty]

Przeanalizuj i wyciągnij:
1. Możliwości (niezaspokojone potrzeby, bolączki, pragnienia)
2. Kluczowe momenty w podróży użytkownika
3. Wzorce w wywiadach
4. Unikalne spostrzeżenia od każdego klienta

Pamiętaj: szukam konkretnych, wykonalnych spostrzeżeń, nie ogólników.

Kluczowe wglądy

Paradoks darmowego dostarczania

Standardowo myślimy: Skoro AI robi prototypowanie szybkie i tanie, discovery staje się mniej ważne. Po co badać, skoro można szybko zbudować i przetestować?

W praktyce okazuje się, że: Jak mówi Torres – im łatwiej coś zbudować, tym bardziej potrzebujemy filtrów decyzyjnych. Kiedy delivery jest za darmo, discovery staje się bardziej ważne.

Dlaczego to jest istotne: Bez discovery zespoły wpadną w pułapkę Homera Simpsona – dodadzą wszystko, co im się spodoba, wyczerpią użytkowników zmianami i stworzą chaotyczny produkt. Łatwość budowania wymaga lepszej selekcji, nie gorszej.

Test na jutro: Następnym razem, gdy ktoś powie „szybko zrobimy prototyp i zobaczymy”, zamiast od razu prototypować spróbuj zadać pytanie „jaki problem klienta rozwiązujemy?” i sprawdź, czy zmieni to dyskusję o priorytecie.

Błędy sztucznej inteligencji to Twoje odkrycia

Standardowo myślimy: Odkrywanie produktu robimy przed wdrożeniem, aby uniknąć błędów i porażek.

W praktyce okazuje się, że: W produktach AI najcenniejsze odkrycia pochodzą po wdrożeniu, z systematycznej analizy błędów popełnianych przez model. Każdy błąd to dane o potrzebie użytkownika lub niedoskonałości systemu.

Dlaczego to jest istotne: Zmienia to postrzeganie błędów – z porażek, których należy unikać, stają się one najważniejszym źródłem informacji zwrotnej do dalszej pracy. Zespoły, które najszybciej uczą się na błędach, wygrywają.

Test na jutro: Następnym razem gdy będziesz pracować nad funkcją opartą na AI, zamiast skupiać się wyłącznie na unikaniu błędów przed wdrożeniem, zaplanuj od razu system zapisywania odpowiedzi. Poświęć godzinę w tygodniu na przejrzenie 50 losowych wyników i znajdź wzorce w błędach – to będzie Twój materiał na następną iterację.

Ten wpis stanowi część kolekcji notatek z wartościowych podcastów, webinarów i innych treści edukacyjnych. Oryginalne źródło: The #1 Skill PMs Need in 2025: AI Product Discovery Masterclass by World’s Leading Authority

Tag: Context Engineering

Claude Code Deep Dive – kompletny przewodnik po AI w terminalu #EN259

Product discovery w erze AI – kluczowe umiejętności PM według Teresa Torres #EN247