Niedawna deklaracja Head of Product od Gemini (Google) wywołała spore poruszenie w środowisku produktowym: „Przechodzimy od kultury writing-first do building-first.”
Brzmi przełomowo? To podejście oznacza właściwie koniec PRD (Product Requirements Document). A to przecież dobrze napisane PRD przez lata był świętym gralem zarządzania produktem. A teraz… mamy porzucić PRD?
Co o tym myślisz? Poniżej moje podejście do PRD w erze AI ⤵️
1. Co się dzieje? Kultura„Building-first” vs „Writing-first”
Ja sam mam dosyć mocne znadanie o tym co się dzieje. Wkrótce napiszę o tym więcej, ale bardzo mocno wierzę, że budowanie produktów przechodzi właśnie FUNDAMENTALNA zmianę.
Widzę jak najlepsi liderzy produktowi już dziś wychodzą poza swoją tradycyjną rolę, by dzięki AI działać szybciej i podejmować trafniejsze decyzje. Najlepsze zespoły pracują przysłowiowe 10x szybciej, mądrzej i z większym impaktem. To nowa rzeczywistość.
To, co ogłosił Google, to nie jest tylko proste przejście z „pisania” na „budowanie”. To właśnie sygnał tej fundamentlanej zmiany w podejściu.
Przez lata zasoby deweloperskie były „drogie” i ograniczone. Dlatego w wielu firmach, zanim zaangażowałeś zespół inżynierów, musiałeś wszystko dokładnie przemyśleć rozwiązanie i opisać w opasłym dokumencie PRD.
Dziś, w erze AI, sytuacja się odwróciła. Narzędzia takie jak Lovable, Bolt.new czy nawet sam ChatGPT/Claude/Gemini pozwalają stworzyć interaktywny prototyp w czasie zbliżonym do napisania dokumentu. PM-owie mogą wreszcie pokazywać, a nie tylko opowiadać.
2. Koniec PRD? Koniec pisania? Mam mieszane uczucia.
1️⃣ Robiłem to zanim stało się modne
Z jednej strony, wenętrznie uśmiechnałem się jak zobaczyłem ten post. Od dawna w podobny sposób pracuję - moje PRD to zawsze były krótkie LIVE dokumentu zawierające głownie najważniejsze założenia.
No i zawsze byłem fanem szybkiego prototypowania. Zamiast opisywać rozwiązania w dokumentach i dyskutować o nich godzinami, wolałem szkicować makietę, kodować prosty prototyp w HTML, a teraz "vibe-kodować" z pomocą AI. A to przecież daje:
Szybkość: błyskawicznie przechodzisz od idei do czegoś namacalnego.
Lepsze zobrazowanie: prototyp często mówi więcej niż tysiąc słów (i sto stron dokumentacji).
Szybszy feedback: możesz od razu zebrać reakcje od userów i stakeholderów.
Przez takie podejście często męczyłem się w korporacjach, gdzie wciąż słyszałem: "a gdzie jest do tego porządna dokumentacja? Przecież to trzeba porzadnie opisać!".
2️⃣ Znowu zakochujemy się w rozwiązaniach, zamiast w problemie użytkownika?
Z drugiej strony pisanie tych moich MINI PRD na start (“writing first”) i potem ich rozwijanie - to była dla mnie idealny sposób na stały proces produktowej pracy. Bo przecież:
🔍 Prototyp bez hipotezy to tylko kolejne ROZWIĄZANIE
❌ Budowanie bez refleksji prowadzi do jeszcze większego zakochania się w rozwiązaniu, a nie w realnym zrozumieniu i rozwiązywaniu problemu uzytkownika. Zamist pracy na OUTCOMACH, wracamy do OUTPUTÓW.
🧠 Vibe-coding nie zastępuje pracy produktowej - nie abdykujmy ze swojej produktowej roli!
Dlatego stawiam mocną tezę: AI daje nam supermoce, ale supermoc w rękach kogoś, kto nie wie, co robi, prowadzi do super-katastrofy.
Masz już prototyp? Fajnie. A potrafisz w 30 sekund odpowiedzieć: Jaka jest JEDNA, kluczowa hipoteza, którą on weryfikuje? Kto jest Twoim userem? Jaki problem dla niego rozwiązujesz? To są fundamentalne pytania.
Fun fact: 8 na 10 osób, które czytają ten post, nie są jeszcze subskrybentami ProductCraft. Nie przegap kolejnego materiału o budowaniu produktów 10x szybciej, mądrzej i z większym impaktem - zasubskrybuj teraz ⤵️
3. Moje podejście do PRD w erze AI
Nienawidzę biurokracji, ale pomylenie rezygnacji z opasłych specyfikacji z rezygnacją z myślenia to największy błąd, jaki możesz popełnić. Przeskakiwanie od razu do prototypu nie uczyni nikogo zwinnym, tylko niecierpliwym.
3.1. PRD → Produktowa Klarowność
Ostatecznie w naszej pracy chodzi o klarowność, a nie o dokumenty:
po co to robimy?
co chcemy osiągnąć?
czyj problem chcemy rozwiązać?
jakie to problem?
jaką zmianę zachowań chcemy osiągnąć?
jak to wygląda ilościowo?
po czym poznamy, że osiągnęliśmy sukces?
jakie mamy pomysły na rozwiązania i co wychodzi z ich walidacji?
No i najażniejsze: Jak tego wszystkie się DOWIEDZIEĆ i jak to PRZETESTOWAĆ?!
O osiąganiu tej produktowej klarowności - trudno mi mówić bez jej mininalnego nawet rozpisania i pilnowania w trakcie pracy produktowej. Czy to w dokumencie, czy na Miro, czy opisie epika w Jira.
Dlatego ja z PRD na razie nie rezygnuję. Dalej będę używał swoich MINI PRD.
Dla mnie kluczowy jest wciąż żywy dokument, który służy mi do myślenia. To moje centrum dowodzenia, gdzie planuję i realizują swoją produktową pracę, myślę co i jak testować. To tam definiuję grupę docelową, problem do rozwiązania i model biznesowy.
3.2. mini PRD <3 AI
Co więcej, mój dotychczasowy workflow świetnie się spisuje się w połączeniu z AI. Takie mini PRD doskonale pozwala zasilić i wykorzystywać AI w produktowej pracy:
Głęboka rozkmina z AI Co-pilotem - wrzucam takie PRD do AI (używam ChatGpt, Claude i Gemini), razem z innymi “dokumentami” staje się moim doskonały co-pilotem. Prowadzę z nim dialog: proszę o podważenie moich założeń, szukanie luk w logice, pomoc w priorytetyzacji. Traktuję AI jak super-inteligentnego partnera do sparingu myślowego, który pomaga mi wyostrzyć mój plan.
Budowa prototypu na sterydach - to też doskonały wsad do tego, do vibe-codowania prototypów (np. Lovable). Wklejam go i w kilka minut mam interaktywny prototyp, gotowy do walidacji z userami.
4. Co na ten temat myślą inni produktowi liderzy?
Zebrałem kilka opinii od mądrych i doświadczonych liderów produktów - co oni o tym wszystkim sądzą. Oto najciekawsze z nich:
Ludmiła Kostyleva (Head of Platform @ Tutlo.com):
„Rozpoczęcie pracy nad projektem od prototypowania sprawdzało mi się w ekstremalnych sytuacjach, kiedy mieliśmy ograniczony czas, ale jednocześnie kilku doświadczonych głów na pokładzie, którzy poświęcali 90% swojej uwagi i czasu zagadnieniu.
Dzięki temu większość projektu było przemyślane "w głowie w loce". Podobny tryb pracy wymagał również wprowadzenia sporej liczby zmian na bieżąco. Do końcowego użytkownika produkt wychodził szybciej, ale kosztem tego że zostały zaniedbane inne projekty, lub rozwiązanie zawierało istotne luki.
Dla mnie "papier" - sposób na poukładanie i strukturyzację wiedzy. Wizualizacja również pozwala na spojrzenie z innej perspektywy niż miało się w głowie;
PRD nie musi być duże, tylko wystarczające;
PRD nie musi być tekstem, tylko może zawierać szkic (czytaj - wysokopoziomowy prototyp) oraz diagram;
Kwestia dobrania odpowiedniej formy do zagadnienia.
Pamiętajmy też, że prototyp to tylko jeden ze sposobów na przetestowanie hipotezy oraz potencjalnego rozwiązania. Ale aby testować, musimy wiedzieć CO testujemy, jaki mamy cel itd.
Samo przygotowanie PRD również ma swoje pułapki, ale to inna historia na dużą dyskusje :)”
Więcej znajdziesz ich w tym wątku na Linkedin.
Co myślisz o całym tym przejściu Google na kulturę “Building first”? Daj znac w komentarzu lub odpowiedz na maila