20 promptów dla product managerów, które pokazują kompromisy

01. Napisz PRD z chaotycznego briefu i wypisz otwarte pytania

Masz wątek ze Slacka, notatkę z rozmowy i termin, ale nie masz specyfikacji.

Zamień ten chaotyczny brief w dokument wymagań produktowych (PRD).

[wklej brief, wątek, notatki z rozmów lub co tam masz]

Sekcje, w tej kolejności: problem i kto go ma, dowody, które mamy na jego istnienie, cel z mierzalnym wynikiem, co jest w zakresie, co jest poza zakresem, przepływ użytkownika w ponumerowanych krokach, wymagania oznaczone MUST lub SHOULD oraz zależności od innych zespołów.

Korzystaj wyłącznie z tego, co jest w briefie. Tam, gdzie brief milczy, wpisz [OPEN: pytanie] zamiast uzupełniać to od siebie.

Na końcu wypisz wszystkie otwarte pytania, pogrupowane według tego, kto może na nie odpowiedzieć (ja, design, development, dział prawny, klient), a trzy pytania blokujące budowę umieść na początku.

02. Podziel funkcję na user stories z kryteriami akceptacji

Refinement jest jutro, a funkcja wciąż jest jednym wielkim ticketem.

Podziel tę funkcję na user stories, które zespół może zbudować i wypuścić pojedynczo.

Funkcja: [co robi]
Użytkownicy: [kto z niej korzysta i co chce osiągnąć]
Ograniczenia: [platformy, terminy, rzeczy już zbudowane]

Dla każdej historii:
1. Jako [użytkownik] chcę [działanie], aby [rezultat].
2. Kryteria akceptacji w formie Given / When / Then, od trzech do sześciu na historię, każde możliwe do przetestowania przez osobę, która ich nie pisała.
3. Szacunek wielkości S, M lub L i jedna rzecz, która sprawia, że jest niepewny.

Ułóż historie tak, aby pierwsza dostarczała coś, z czego prawdziwy użytkownik może skorzystać, nawet jeśli to niewiele. Oznacz każdą historię, która tak naprawdę jest dwiema historiami, oraz każdą, która ma sens dopiero po wypuszczeniu innej.

03. Znajdź przypadki brzegowe, które pominęło Twoje PRD

Specyfikacja wygląda na gotową, a development zaczyna w przyszłym tygodniu.

Przeczytaj to PRD jako inżynier, który po premierze dostanie zgłoszenia błędów.

[wklej PRD lub specyfikację]

Wypisz przypadki brzegowe, których dokument nie obejmuje, pogrupowane w kategorie: stany puste i pierwsze użycie, błędy i przekroczenia czasu, uprawnienia i role, limity (bardzo długie, bardzo liczne, zero, duplikaty), współbieżność (dwie osoby edytują, podwójne kliknięcia, ponowienia), dane sprzed powstania tej funkcji oraz dostępność.

Dla każdego przypadku podaj: scenariusz w jednej linijce, co według obecnej specyfikacji by się stało oraz pytanie, na które muszę odpowiedzieć. Uszereguj pięć najważniejszych według tego, jak prawdopodobne, że prawdziwy użytkownik trafi na nie w pierwszym miesiącu. Nie wymyślaj wymagań, tylko pytaj.

Odblokuj pozostałe 17 promptów za darmo, zapisując się na newsletter

Zapisz się na newsletter Whizi, aby przeczytać resztę tego pakietu.

4. Oceń backlog metodą RICE i pokaż rachunki
5. Zamień notatki z wywiadów w zadania, bolączki i cytaty
6. Napisz scenariusz wywiadu discovery o tym, co ludzie zrobili, a nie czego chcą
7. Pogrupuj tickety supportu w problemy produktowe warte naprawy
8. Napisz jednostronicową specyfikację, z której inżynierowie mogą budować
9. Wybierz metrykę sukcesu i metrykę przeciwwagi, która pilnuje uczciwości
10. Zaprojektuj eksperyment i najpierw odpowiedz na pytania o wielkość próby
11. Zbuduj checklistę premiery z właścicielem dla każdego zespołu
12. Napisz release notes, które użytkownicy naprawdę czytają
13. Napisz aktualizację dla interesariuszy, która zaczyna się od tego, co się zmieniło
14. Napisz narrację roadmapy, która mówi, czego nie robisz
15. Odmów realizacji prośby o funkcję, podając powód i kolejny krok
16. Przeprowadź pre-mortem, zanim premiera wyjdzie
17. Rozbierz stronę produktu konkurenta twierdzenie po twierdzeniu
18. Napisz jeden cel sprintu z długiej listy ticketów
19. Zamień zamówione rozwiązanie w problem, który za nim stoi
20. Poproś drugi model o recenzję PRD napisanego przez pierwszy