PRD ne işe yarar?
Bir ürün ekibinde en pahalı hata, yanlış şeyi doğru yapmaktır. Tasarım, yazılım ve test aylarca çalışır; ürün çıkar; sonra kimsenin o problemi o şekilde yaşamadığı anlaşılır. PRD bu hatayı kod yazılmadan önce yakalamak için vardır.
PRD üç soruyu yazılı ve ortak hale getirir:
- Neden? Hangi kişinin, hangi anda yaşadığı hangi problem? Bunun kanıtı ne?
- Ne? Bu sürümde neyi yapıyoruz, neyi bilinçli olarak yapmıyoruz?
- Nasıl anlayacağız? Başardığımızı hangi davranış değişikliğinden, hangi eşikten anlayacağız?
Bu üç soru cevapsız kaldığında ekip özellikleri tartışır; cevaplandığında problemi tartışır. İkincisi çok daha verimlidir.
İyi bir PRD’nin yedi bölümü
| Bölüm | Cevapladığı soru | Sık yapılan hata |
|---|---|---|
| 1. Problem | Kimin, hangi anda, hangi ihtiyacı var? Kanıt düzeyi ne? | Problem yerine çözüm yazmak: “Kullanıcı X butonu istiyor.” |
| 2. Hedef ve başarı ölçütü | Kullanıcının davranışında ne değişecek? Eşik ne? | Çıktıyı ölçmek (“özellik yayında”), sonucu ölçmemek |
| 3. Kapsam (MVP) | Neler giriyor, neler girmiyor, neyi asla yapmayacağız? | “Yapmayacaklarımız” bölümünü boş bırakmak |
| 4. Kullanıcı akışı | Ana senaryo adım adım nasıl ilerliyor? Uç ve boş durumlar ne? | Yalnızca mutlu senaryoyu yazmak |
| 5. Yapay zekâ bileşeni (varsa) | Model ne yapıyor, ne yapmıyor? Değerlendirme seti, sınırlar, insan onayı | Yapay zekâyı sıradan bir özellik gibi yazmak |
| 6. Varsayımlar ve riskler | En hassas varsayım hangisi, nasıl doğrulanacak? | Varsayımı gerçek gibi yazmak |
| 7. Açık sorular ve kararlar | Neyi henüz bilmiyoruz, kim karar verecek? | Kararların tarihini ve sahibini kaydetmemek |
Problem cümlesi için kullanışlı bir kalıp: [Persona], [temas anı] sırasında [ihtiyaç] ihtiyacı duyuyor; çünkü [içgörü]. Bu kalıp sizi çözümden önce kişiye, ana ve nedene bakmaya zorlar. Persona ve temas anı çıkmadan PRD yazmaya başlamak, temelsiz bina kurmaktır; önce Ürün Yönetimi Nasıl Yapılır? rehberindeki ilk adımlara bakın.
PRD, MRD, kullanıcı hikâyesi ve yol haritası
| Doküman | Ne anlatır? | Kim için? |
|---|---|---|
| MRD (pazar gereksinim dokümanı) | Pazar, segment, rakipler, fırsat: neden bu alana girmeliyiz? | Yönetim, pazarlama, ürün |
| PRD (ürün gereksinim dokümanı) | Bu fırsata ürün nasıl cevap verecek: problem, kapsam, ölçüt, sınır | Ürün, tasarım, mühendislik |
| Kullanıcı hikâyesi | Tek bir işlevin kullanıcı gözünden tarifi ve kabul kriterleri | Geliştirme ekibi |
| Yol haritası | Hangi problemleri hangi sırayla çözeceğiz? | Bütün paydaşlar |
PRD, MRD’nin “neden”i ile kullanıcı hikâyelerinin “nasıl”ı arasındaki köprüdür. Her kullanıcı hikâyesi bir PRD’deki probleme bağlanabilmelidir; bağlanamıyorsa o hikâyenin neden yazıldığı sorulmalıdır.
Kısa bir örnek (varsayımsal)
Aşağıdaki örnek tamamen varsayımsaldır; yalnızca bölümlerin nasıl doldurulduğunu göstermek içindir.
- Problem: Küçük işletme sahibi, ay sonunda faturalarını öderken hangisinin ne zaman son gününün dolduğunu takip edemiyor; çünkü faturalar farklı kanallardan, farklı tarihlerde geliyor.
- Başarı ölçütü: Gecikme cezası ödeyen kullanıcı oranının düşmesi; eşik ve ölçüm dönemi ekipçe belirlenir.
- MVP’ye girenler: Son ödeme tarihine üç gün kala tek bildirim; bildirimden tek dokunuşla ödeme.
- İlk sürümde olmayanlar: Fatura tarama, harcama analizi.
- Yapmayacaklarımız: Kullanıcı onayı olmadan otomatik ödeme.
- En hassas varsayım: Kullanıcılar bildirime gün içinde tepki veriyor. Doğrulama: prototiple küçük bir grupta deneme.
Dikkat edin: örnekte hiçbir teknik ayrıntı yok. PRD neyi ve neden yaptığımızı sabitler; nasıl yapacağımızı ekip birlikte bulur.
İyi bir PRD’nin altı işareti
- Problemle başlar, çözümle değil. İlk paragrafta bir özellik adı geçiyorsa yeniden yazın.
- Kanıt düzeyini açıkça söyler. Varsayım, sinyal ya da kanıt; üçü aynı ağırlıkta değildir.
- Sonucu ölçer. “Özellik yayına alındı” bir başarı ölçütü değildir; kullanıcının davranışındaki değişim ölçüttür.
- Sınır çizer. “Yapmayacaklarımız” bölümü dolu bir PRD, kapsam kaymasına karşı en iyi sigortadır.
- Kısadır. Tek sayfada anlatılamayan bir özellik muhtemelen birden fazla problemi çözmeye çalışıyordur; bölün.
- Yaşar. Öğrendikçe güncellenir; her kararın tarihi ve sahibi kayıtlıdır.
Şablonla başlayın
Tek sayfalık PRD şablonu, yukarıdaki yedi bölümü hazır başlıklarla verir; kopyalayıp kendi ürününüze uyarlayabilirsiniz: PRD şablonu. Problem bölümünü doldurmadan önce Problem ve Temas Anları aracıyla problemi netleştirin; kapsamı önceliklendirmek için Fayda/Zorluk Matrisi, en hassas varsayımı denemek için Prototip ve Test Planı işinize yarar.