Product Requirements Document (PRD)
Szablon dokumentu wymagań produktowych. Wypełnij przed rozpoczęciem projektu — PRD to kontrakt między PM, designem i developmentem. Dobry PRD eliminuje nieporozumienia, przyspiesza development i zmniejsza liczbę zmian zakresu w trakcie projektu.
📖 Czym jest PRD? Product Requirements Document to dokument opisujący CO ma być zbudowane i DLACZEGO — nie JAK (to zadanie dla architektury technicznej). PRD powinien być żywym dokumentem: aktualizuj go gdy zmieniają się wymagania. Każda zmiana wymagań po starcie developmentu kosztuje 5–10x więcej niż zmiana w PRD.
| Autor | [Imię i nazwisko PM] |
|---|
| Data utworzenia | [DD.MM.RRRR] |
|---|
| Ostatnia aktualizacja | [DD.MM.RRRR] |
|---|
| Wersja | [v1.0] |
|---|
| Status | [Draft / In Review / Approved] |
|---|
| Stakeholderzy | [Lista osób które muszą zatwierdzić PRD] |
|---|
1. Przegląd produktu
Nazwa produktu / funkcji
[Wpisz nazwę produktu lub funkcji]
Problem (Problem Statement)
Jaki problem rozwiązuje ten produkt? Dla kogo? Jak duży jest ten problem? Skąd wiesz, że to prawdziwy problem?
[Np. "Freelancerzy tracą średnio 3h/tydzień na ręczne wystawianie faktur i śledzenie płatności. Rozmawialiśmy z 20 freelancerami — 18 z nich używa Excela lub papierowych notatek. Brak automatyzacji kosztuje ich ~600 PLN/mies. w straconej produktywności."]
Rozwiązanie (Solution)
Jak produkt rozwiązuje ten problem? Co jest unikalne w Twoim podejściu?
[Opisz rozwiązanie. Unikaj technicznego żargonu — skup się na wartości dla użytkownika.]
Cel biznesowy i metryki sukcesu (OKR)
Co chcemy osiągnąć? Jak zmierzymy sukces? Używaj formatu OKR: Objective + Key Results.
[Np. "Objective: Zostać wiodącym narzędziem do fakturowania dla freelancerów w Polsce. KR1: 1000 aktywnych użytkowników w 3 miesiące. KR2: 15% konwersja na płatny plan. KR3: NPS > 40."]
Zakres (In Scope / Out of Scope)
| W zakresie (In Scope) | Poza zakresem (Out of Scope) |
|---|
| [Co wchodzi w ten PRD] | [Co NIE wchodzi — równie ważne jak to co wchodzi] |
2. Użytkownicy i persony
💡 Persona vs ICP: ICP (Ideal Customer Profile) to opis firmy/segmentu. Persona to konkretna osoba w tej firmie. Dobra persona ma imię, zdjęcie, cytaty z prawdziwych rozmów z użytkownikami — nie jest wymyślona.
Persona główna
| Imię / Rola | [Np. "Marek, 32 lata, freelancer UX designer"] |
|---|
| Kontekst | [Gdzie pracuje, jak duża firma, jakie narzędzia używa] |
|---|
| Cele | [Co chce osiągnąć — zawodowo i w kontekście produktu] |
|---|
| Frustracje / Pain points | [Co go boli, co go spowalnia, co go irytuje] |
|---|
| Cytat (z badań) | ["Tracę tyle czasu na papierkową robotę, że wolałbym płacić komuś za to..."] |
|---|
| Jak mierzy sukces | [Co oznacza dla niego "produkt działa"?] |
|---|
Persona drugorzędna (jeśli dotyczy)
| Imię / Rola | |
|---|
| Kontekst | |
|---|
| Cele | |
|---|
| Frustracje | |
|---|
User Journey (ścieżka użytkownika)
Opisz krok po kroku jak użytkownik dochodzi do wartości produktu — od pierwszego kontaktu po stanie się lojalnym klientem.
| Etap | Akcja użytkownika | Myśl / Emocja | Punkt bólu |
|---|
| Awareness | | | |
| Consideration | | | |
| Onboarding | | | |
| Activation | | | |
| Retention | | | |
3. Funkcjonalności i wymagania
💡 Priorytety MoSCoW: Must-have (P0) — bez tego produkt nie działa. Should-have (P1) — ważne, ale można uruchomić bez. Could-have (P2) — nice-to-have, jeśli zostanie czas. Won't-have — świadomie wykluczone z tego zakresu.
| ID |
Funkcja |
Opis użytkownika (user story) |
Priorytet |
Acceptance Criteria |
Uwagi |
| F-01 |
[Rejestracja] |
[Jako nowy user chcę zarejestrować się przez Google aby nie tworzyć kolejnego hasła] |
[P0] |
[User może zalogować się przez Google OAuth w <30s] |
|
| F-02 |
|
|
|
|
|
| F-03 |
|
|
|
|
|
| F-04 |
|
|
|
|
|
| F-05 |
|
|
|
|
|
4. Wymagania niefunkcjonalne
Wymagania niefunkcjonalne opisują JAK system ma działać — nie co robi. Są równie ważne jak funkcjonalne.
| Kategoria | Wymaganie | Miara / Kryterium |
|---|
| Wydajność | Czas ładowania strony głównej | [Np. <2s na 3G, <1s na WiFi] |
| Skalowalność | Liczba jednoczesnych użytkowników | [Np. 1000 concurrent users bez degradacji] |
| Dostępność | Uptime SLA | [Np. 99.9% uptime = max 8.7h downtime/rok] |
| Bezpieczeństwo | Autentykacja i autoryzacja | [Np. OAuth 2.0, JWT, 2FA dla adminów] |
| Dostępność (a11y) | Standard dostępności | [Np. WCAG 2.1 AA] |
| Lokalizacja | Języki i regiony | [Np. PL i EN, strefa czasowa UTC+1] |
| Compliance | Regulacje prawne | [Np. RODO, PCI DSS jeśli płatności] |
5. Design & UX
Linki do designów
[Link do Figma / prototypu / wireframes]
Kluczowe ekrany i przepływy
| Ekran | Opis | Link do Figma |
|---|
| Landing page | | |
| Rejestracja / Login | | |
| Onboarding | | |
| Dashboard główny | | |
| Core feature | | |
| Ustawienia | | |
Design principles (zasady projektowania)
[Np. "Mobile-first. Minimalizm — każdy element musi mieć cel. Szybkość > bogactwo funkcji. Dostępność od dnia 1."]
6. Wymagania techniczne
Platformy docelowe
[Web (Chrome, Firefox, Safari, Edge) / iOS (min. iOS 15) / Android (min. Android 10) / Desktop]
Stack technologiczny (propozycja)
| Warstwa | Technologia | Uzasadnienie |
|---|
| Frontend | | |
| Backend | | |
| Baza danych | | |
| Auth | | |
| Hosting / Cloud | | |
| Płatności | | |
| Email | | |
| Analytics | | |
Integracje zewnętrzne
[Lista API i serwisów zewnętrznych: Stripe, Google OAuth, SendGrid, Twilio, OpenAI, etc. Dla każdego: cel integracji i czy jest krytyczna dla MVP.]
Wymagania wydajnościowe
[Np. API response <200ms p95, strona ładuje się <2s, obsługa 1000 concurrent users]
7. Analytics & Metryki
North Star Metric
[Jedna metryka najlepiej odzwierciedlająca wartość produktu. Np. "liczba faktur wystawionych miesięcznie"]
Kluczowe metryki (AARRR)
| Kategoria | Metryka | Cel (target) |
|---|
| Acquisition | [Np. nowe rejestracje/tydzień] | |
| Activation | [Np. % userów którzy wystawili pierwszą fakturę] | |
| Retention | [Np. D30 retention] | |
| Revenue | [Np. MRR, konwersja na płatny plan] | |
| Referral | [Np. NPS, liczba zaproszeń] | |
Eventy do śledzenia (tracking plan)
[Lista kluczowych eventów analytics: sign_up_completed, onboarding_step_X_completed, feature_used, payment_completed, etc.]
8. Timeline i fazy
| Faza | Zakres / Deliverables | Czas trwania | Deadline |
|---|
| Discovery | [User research, competitive analysis, problem definition] | [1 tydzień] | |
| Design Sprint | [Wireframes, prototyp Figma, user testing] | [2 tygodnie] | |
| Development Sprint 1 | [Core features P0] | [2 tygodnie] | |
| Development Sprint 2 | [Remaining P0 + P1] | [2 tygodnie] | |
| QA & Testing | [Testy funkcjonalne, bezpieczeństwo, wydajność] | [1 tydzień] | |
| Launch | [Deploy, monitoring, komunikacja] | [1 tydzień] | |
9. Ryzyka, założenia i zależności
Ryzyka
| Ryzyko | Prawdopodobieństwo | Wpływ | Mitygacja |
|---|
| [Np. Integracja z API X może być trudniejsza niż zakładamy] | [Wysokie] | [Średni] | [Spike techniczny w tygodniu 1] |
| | | |
| | | |
Założenia
[Co zakładamy że jest prawdą, ale nie zweryfikowaliśmy? Np. "Zakładamy że użytkownicy są gotowi płacić 49 PLN/mies." — to założenie wymaga walidacji.]
Zależności
[Co musi być gotowe zanim zaczniemy? Np. "Potrzebujemy dostępu do API X", "Design system musi być gotowy przed sprintem 1", "Prawnik musi zatwierdzić regulamin."]
10. Otwarte pytania (Open Questions)
💡 Tip: Otwarte pytania to jedna z najważniejszych sekcji PRD. Dokumentuj wszystko czego nie wiesz — to sygnał dla zespołu że potrzebna jest decyzja lub badanie.
| # | Pytanie | Kto odpowiada | Deadline | Status |
|---|
| 1 | [Np. Czy wspieramy import danych z Excela w MVP?] | [PM] | | [Open] |
| 2 | | | | |
| 3 | | | | |
