Rano otworzyłeś stronę w Notion zatytułowaną "PRD: [nazwa funkcji]". Trzy godziny później nadal widnieje na niej "PRD: [nazwa funkcji]".
Znasz problem. Znasz rozwiązanie. Wczoraj dwa razy przeprowadziłeś przez nie swojego tech leada. Ale w momencie, gdy siadasz, żeby to spisać, utykasz.
To nie problem z myśleniem. To problem z pisaniem na klawiaturze.
PM-om nie płaci się za stukanie w klawiaturę. Płaci się ci za decyzje o tym, co budować i dlaczego. PRD to tylko artefakt, który tę decyzję utrwala, żeby zespoły inżynierskie, designerskie i kierownictwo mogły działać. Gdzieś między „wiem, co napisać” a „skończony dokument” znikają godziny.
Jest szybsza droga. PRD to jeden z dokumentów, które najlepiej leżą głosowi spośród wszystkich, jakie pisze PM. To w zasadzie to, co powiedziałbyś, stojąc przy whiteboardzie i tłumacząc funkcję. Kiedy przestajesz wpisywać PRD-y i zaczynasz je dyktować, czas potrzebny na draft spada.
Podatek od pisania, o którym nikt PM-om nie mówi
Każdy PRD, który piszesz, konkuruje ze spotkaniem, przeglądem roadmapy i wątkiem ze stakeholderem na Slacku. Samo pisanie odbywa się w wykradzionych półgodzinnych oknach albo po kolacji.
Matematyka jest bezlitosna. Przeciętna osoba pisze na klawiaturze około 40 słów na minutę. Przeciętna osoba mówi około 150. To z grubsza 3,5x różnicy, zanim doliczysz całe tarcie, które utrudnia pisanie: cofanie, przeformułowywanie, trzykrotne przemyśliwanie tego samego zdania, zanim ruszysz dalej.
PRD o długości 1500 słów, którego napisanie zajmuje 90 minut, można wypowiedzieć w jakieś 25 minut. Myślenie jest takie samo. Efekt jest taki sam. Zmienia się tylko mechanizm.
Dlaczego PRD-y są idealnie skrojone pod głos
Większość dokumentów źle znosi dyktowanie, bo wymaga precyzji: kod, tabele, modele finansowe. PRD-y są ich przeciwieństwem. To dokumenty narracyjne.
Pomyśl o ostatnim PRD, jaki napisałeś. Sekcja „Problem” to dwa akapity tłumaczące, dlaczego coś ma znaczenie. „Rozwiązanie” to opis tego, jak ta rzecz działa. „User stories” to zdania w formacie „Jako X, chcę Y, żeby Z”. Sekcja „Edge cases” to lista scenariuszy „co się stanie, gdy…”.
Nic z tego nie wymaga precyzji na klawiaturze. Wszystko to jest dokładnie tym, co powiedziałbyś na spotkaniu. Sam format pasuje do tego, jak PM-owie naprawdę komunikują pracę.
Workflow draftu PRD w 30 minut
Oto schemat, który działa: 1. Otwórz pusty dokument z gotowymi nagłówkami sekcji: problem, rozwiązanie, user stories, kryteria akceptacji, edge cases, poza zakresem, otwarte pytania. 2. Przechodź sekcja po sekcji. Dyktuj każdą tak, jakbyś tłumaczył ją nowemu inżynierowi dołączającemu do zespołu. 3. Nie edytuj w trakcie mówienia. Przeskoki między rolą „mówcy” i „redaktora” spowalniają cię najbardziej. 4. Po podyktowaniu wszystkich sekcji przeczytaj cały draft raz, od góry do dołu. Dociśnij język. Popraw to, co naprawdę nie gra. 5. Wyślij do recenzji.
Cała dyscyplina mieści się w kroku trzecim. Jeśli co chwilę przerywasz, żeby poprawić zdania, nie wyciągasz z tego żadnej prędkości. Wracasz do prędkości pisania na klawiaturze, tylko w innym przebraniu.
Sekcja po sekcji: jak dyktować każdą część PRD
Niektóre sekcje dyktuje się łatwiej niż inne. Oto jak podejść do każdej z nich.
Opis problemu
To najłatwiejsza sekcja do podyktowania. Czysta narracja. Tłumaczysz, co jest zepsute, dla kogo i dlaczego ma to znaczenie teraz.
Wypowiedz to tak, jakbyś brief'ował nowego członka zespołu na stand-upie. Wspomnij segment użytkowników, na jakie tarcie trafiają i jaką metrykę to dotyka. Nie martw się elegancją prozy. Od tego jest edycja.
Zarys rozwiązania
Przejdź przez proponowane rozwiązanie tak, jakbyś rysował je na whiteboardzie. „Użytkownik klika tutaj, widzi to, a potem…”. Głos radzi sobie z tym płynnie, bo odpowiada temu, jak i tak byś to tłumaczył na głos.
User stories
User stories brzmią mechanicznie z powodu wzorca „Jako X, chcę Y, żeby Z”, ale dyktują się dobrze, jeśli zobowiążesz się do trzymania formatu. Wypowiedz każdą historyjkę jako jedno zdanie i przechodź dalej.
Jeśli masz dziesięć historyjek, podyktuj wszystkie dziesięć w jednym przebiegu. Nie numeruj ich w trakcie. Niech formatowanie ogarnie edytor dokumentu albo twój przebieg czyszczenia przez AI.
Kryteria akceptacji
Listy to najtrudniejsza część dyktowania, ale da się je ogarnąć. Dwa podejścia:
Pierwsze to podyktować kryteria jako pełne zdania i pozwolić AI zamienić je na listę. Powiedz na przykład: „Użytkownik powinien móc filtrować wyniki po dacie, po użytkowniku i po statusie. Stan filtra powinien przetrwać między sesjami. Pusty stan powinien pokazywać podpowiedź”.
Drugie to wprost wymawiać strukturę punktów: „Punkt pierwszy, filtrowanie po dacie. Punkt drugi, filtrowanie po użytkowniku. Punkt trzeci, trwałość między sesjami”. Wybierz to, co mniej grzęźnie ci w ustach.
Przypadki brzegowe
To miejsce, w którym głos naprawdę błyszczy. Edge case'y to dokładnie ten typ myślenia na głos, który wychodzi czysto, gdy mówisz, a niezgrabnie, gdy piszesz. Pytania typu „co się stanie, jeśli użytkownik jest offline” albo „a co z sytuacjami, w których dane są nieaktualne” płyną w mowie bardziej naturalnie niż na piśmie.
Podyktuj każdy edge case, jaki przychodzi ci do głowy, nawet te, które wydają się oczywiste. Przyciąć możesz przy edycji.
Poza zakresem
Trzy zdania. Może cztery. Głos załatwia to w niecałą minutę.
Otwarte pytania
Ta sekcja jest niedoceniana. Większość PM-ów ją pomija, bo nie chce wyjść na niepewnych. Nie rób tego. Sekcja otwartych pytań to miejsce, w którym inżynieria, design i twój skip-level wyłapują rzeczy, których jeszcze do końca nie przemyślałeś.
Głos jest do tego idealnym narzędziem. Otwarte pytania to dokładnie te niedoformowane myśli, które wychodzą w porządku, gdy mówisz, a wydają się dziwnie ciężkie, gdy próbujesz je wpisać. Wypowiedz każdą wątpliwość na głos, nawet te, które wydają ci się mieć oczywistą odpowiedź. Połowa z nich rozwiąże się na następnym stand-upie. Druga połowa uratuje wam launch.
Dopasowanie tonu do sekcji
PRD nie jest pisany jednym głosem. Streszczenie dla kierownictwa na samej górze powinno być zwięzłe i strategiczne. Specyfikacja techniczna powinna być precyzyjna. Sekcja „otwartych pytań” może być bardziej luźna.
Gdy dyktujesz, naturalnie zmieniasz rejestry. Twój głos staje się oficjalny, gdy mówisz o strategii, i luźniejszy, gdy przechodzisz przez edge case'y. Problem w tym, że większość narzędzi do dyktowania wypluwa tę samą płaską transkrypcję niezależnie od kontekstu.
I dokładnie tu wchodzą Smart Rules w Voicr. Możesz ustawić styl „czysta profesjonalna spec” dla edytora dokumentów, styl „luźny burzy mózgów” dla wątków na Slack i styl „techniczna precyzja” dla wiki inżynierskiej. Voicr wykrywa aktywną aplikację i automatycznie stosuje właściwy styl, więc ta sama wypowiedziana myśl ląduje inaczej w zależności od tego, gdzie trafia.
Konkretnie pod PRD-y skonfiguruj regułę, która zamawia czystą profesjonalną prozę, usuwa wypełniacze i robi listy punktowane tam, gdzie je sygnalizujesz. Mówisz raz. Dokument czyta się tak, jakbyś pisał go z namysłem.
Tam, gdzie głos nie pomaga
Szczera uwaga: nie każda część PRD zyskuje na głosie.
Tabele i macierze szybciej się wpisuje. Jeśli twój PRD zawiera siatkę porównawczą funkcji, macierz uprawnień albo tabelę oszacowań, wpisz to z palca.
Dokładne ciągi techniczne też szybciej się wpisuje. Nazwy endpointów API, nazwy kolumn w bazie, numery wersji — możesz dyktować dookoła nich („endpoint to ukośnik users ukośnik ID”), ale to niezręczne. Wpisz to z palca.
Diagramów z oczywistych powodów nie da się podyktować. Naszkicuj je w swoim ulubionym narzędziu i osadź.
Cała reszta — narracja, user stories, edge case'y, decyzje, uzasadnienia — głosem wygrywa na prędkości i na tym, że nie zacinasz się w połowie zdania, próbując sformułować coś idealnie.
Zmiana nastawienia: myśl na głos, edytuj później
Największy zysk z dyktowania PRD-ów to nie matematyka słów na minutę. To fakt, że przestajesz dopracowywać w trakcie pisania.
Kiedy piszesz na klawiaturze, używasz backspace. Dwa razy przepisujesz to samo zdanie. Wpatrujesz się w akapit, który jest „prawie dobry”, przez dziesięć minut. To właśnie tu PRD-y idą umrzeć: w lukę między pisaniem a edycją, w której tak naprawdę nie dzieje się ani jedno, ani drugie.
Kiedy dyktujesz, zatwierdzasz. Wypowiadasz zdanie, ląduje ono na stronie i przechodzisz dalej. Pierwszy przebieg jest mniej dopracowany niż to, co byś wpisał. Ale kończysz draft. A skończony, niedopracowany draft jest dramatycznie bardziej użyteczny niż dopracowany, ale nieskończony.
Kiedy draft już istnieje, edycja to zupełnie inna, znacznie szybsza czynność. Często spędzisz więcej czasu na cyzelowaniu niż na dyktowaniu — i to jest w porządku. Cyzelowanie gotowego dokumentu to znana robota. Wpatrywanie się w pusty — nie.
Spróbuj przy następnym PRD
Wybierz PRD, którego unikałeś. Otwórz dokument, wstaw nagłówki sekcji i podyktuj wszystko od góry do dołu, bez edytowania. Ustaw stoper na 25 minut. Zobacz, co z tego wyjdzie.
Za pierwszym razem będzie to dziwne uczucie. Będziesz się martwił, że efekt nie jest wystarczająco dobry. Powstrzymaj odruch poprawiania w locie. Po prostu skończ.
Jeśli chcesz, żeby dyktowanie wychodziło na tyle czysto, że ledwo trzeba je edytować, Voicr sam zadba o doszlifowanie. Przytrzymaj FN z dowolnego miejsca na swoim Macu, opowiedz sekcję, puść i wklej oczyszczony tekst do dokumentu. Voicr usuwa wypełniacze, poprawia gramatykę i porządkuje twoje myśli, zanim trafią do schowka. Draft PRD, który kiedyś zajmował całe popołudnie, mieści się na jedno posiedzenie.
Twoje PRD-y same się nie napiszą. Ale nie muszą też być wystukiwane na klawiaturze.