Bülten #21: Ürün Gereksinimleri Dökümanı (Product Requirements Document, PRD)

Bültene hoş geldin 👋

Bu sayıda ürün geliştiren herkesin hayatında az çok bir yeri olan ve bir taraftan da herkesin ayrı bir yoğurt yiyişinin olduğu bir kavramı, Ürün Gereksinimleri Dökümanı’nı ele aldık. Ne olduğundan, faydaları ve zorluklarından bahsedip, topluluk üyelerimizin verdiği örnekleri paylaştık ve faydalı kaynakları da eklemeyi unutmadık. Topluluk görüşlerini dahil edebildiğimiz sayıları çok beğenerek yazıyorum, umarım siz de okurken keyif alırsınız ve yeni fikirler edinirsiniz.

İyi internetler,
Burcu

Hatırlatma: Üretim Bandı Slack! 🎉

Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Üyelere özel webinarlara da başladık! Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:

Slack Grubumuza Katıl

Ürün Gereksinimleri Dökümanı (Product Requirements Document, PRD)

1. Nedir?

2. Faydaları ve zorlukları

3. Topluluktan örnekler

4. Yararlı kaynaklar

1. Nedir?

Ürün gereksinimleri dökümanı (Product requirements document, PRD), ürün geliştirme süreçlerinin standart bir parçası haline gelmiş, özünde geliştirilecek ürünün/özelliğin detaylarını belirlemeye ve ekipler arasında standart bir biçimde aktarmaya yarayan bir dökümantasyon sistemi. Bu döküman hem Agile methodolojilerle, hem farklı farklı pratiklerle uzun bir süredir var ve zaman içinde amacı değişmese de içeriği ve fonksiyonları değişmiş ve farklı farklı varyasyonları oluşmuş. Güncel durumda tek bir tipi yok, organizasyonlar kendi ihtiyaçları özelinde bu dökümanı özelleştiriyor ve ürün geliştirme süreçlerini optimize etmeye gayret ediyorlar.

SVPG Managing Director’ı Martin Cagan’a göre “klasik anlamda” PRD’ler 2007 ve sonrası itibariyle ürün yöneticileri için bir örnek uygulama değiller, çünkü bu dökümanı hazırlamaya ayrılan vakit ve emek gerçek anlamda yapılması gereken ürün yönetimi işlerinden yiyor. Cagan PRD’lere ayrılan bu kaynağı keşif süreçlerine tahsis etmeyi ve bu süreçlerden öğrenilenleri PRD dökümanlarındaki bilgiler yerine değerlendirmeyi öneriyor. Geçmiş zamanlardan bu yana internette dolaşan farklı örneklerini incelediğimizde de görüyoruz ki PRD’ler zaman içinde evrimleşerek olabilecek tüm bilgileri içermekten ve yapılacak işi en ince teknik detayına kadar anlatmaktan çıkıp (bu tip dökümanlar daha çok “yazılım gereksinimleri dökümanı” olarak anlandırılıyor), problem ve çözüm alanlarının da irdelendiği, farklı rollerden herkesin az çok fikir edinebildiği referans noktaları olmuş. “Modern” PRD’lere örnek olarak Amazon’un “Working Backwards” basın bültenleri ve Product Hunt’ın ilk çıktığında çokça popüler olan PRD şablonu ilk aklıma gelenler oldu. Confluence’ın kullanıcılarına sağladığı “Product requirements” şablonu da yaygın kullanılanlar arasında.

Bahsettiğimiz gibi PRD’ler için takip edilen şablon ihtiyaca göre, yani organizasyon büyüklüğüne, sektöre, ekip yapısına ve hatta kültüre göre değişkenlik gösteriyor. Yine de tüm ekibin fikir edinebileceği bir döküman doğal olarak her rolün sorumluluklarına ilişkin bir kısım bilgiler içermek durumunda. Küçük bir araştırma yapıp bahsedilen şablonlara göz attığımızda, genel olarak şu başlıkların ortak olduğunu gördük:

• Amaç: Yapılan yeniliğin yapılma sebebi ya da problemin özeti, hangi kullanıcılara yönelik olduğu ve bu yenilikle birlikte nelerin mümkün olabileceğinin anlatıldığı kısım bu kısım oluyor ve genelde ilk sırada yer alıyor.

• Gereksinimler/Özellikler: Bu kısımda geliştirilecek yeniliğin fonksiyonalitesi detaylandırılıyor: Tanımlamalar, düşünce akışları ve notlar, yazı, görsel ve/veya prototip formatında kullanıcı akışları ve kullanıcı hikayeleri (user stories), modellemeye ilişkin teknik notlar ve benzeri temel bilgilerin hepsi bu kısımda tutuluyor.

• Performans/Başarı kriterleri: Bu kısımda yapılan yeniliğin başarısını ve performansını ölçmek üzere belirlenen kriterler yer alıyor. Bu yeniliğin ürün stratejisine olan katkısını ve kullanıcılar tarafından benimsenme oranını anlayabilmek için “Tüm kullanıcı havuzunun toplam %X’i tarafından kullanılması”, “X segmentindeki kullanıcıların elde tutma (retention) oranınının %Y kadar artması”, “NPS’in Z seviyesine çıkması” gibi kriterler ekipçe belirleniyor ve bu yeniliğin işe yarayıp yaramadığına dair herkesin hemfikir olduğu bir standardizasyon oturtulmuş oluyor.

• Ekip: Yapılan yenilik üzerine çalışan ekip listesine bu dökümanda yer vermek, ihtiyaç halinde kime danışılacağını anlamaya ya da geçmişe dönük kayıt tutmaya yardımcı oluyor.

• Zamanlama: Bu yeniliğin planlanan canlıya alınma tarihi ve bu zamana kadar takip edilecek önemli tarihler bu kısımda yer alıyor.

Şu başlıklar ise üsttekiler kadar yaygın değil, ancak fikir vermesi açısından bahsedelim istedik:

• Varsayımlar, kısıtlar ve bağımlılıklar: Kullanıcılar adına yapılan varsayımlar, geliştirme süreçlerinde karşılaşılacağı bilinen kısıtlar ve bu yeniliğin hayata geçirilebilmesi için tamamlanması gereken diğer başka adımlar burada bahsediliyor.

• Gelecek geliştirmeler/iyileştirmeler: Üzerine düşünülen ancak bu yeniliğin kapsamına dahil edilmeyen çözümler, dahil edilmeme sebepleri, belirlenen başarı kriterlerine ulaşılması ya da ulaşılamaması halinde yapılacaklar bu kısımda oluyor.

• Canlıya alma kriterleri: Yapılan yeniliğin canlıya almadan önce geçmesi gereken eşikleri listeleyen kısım bu oluyor; kullanılabilirlik, performans, stres ve hız testleri, destek fonksiyonlarının çalışma hızı gibi süreçlere dair beklentiler bu kısımda netleştiriliyor.

• Sistem ve ortam gereksinimleri: Bu yeniliğin desteklendiği ortamın yani tarayıcı, işletim sistemi, işlem gücü gibi gerekliliklerin detaylandırılması bu kısımda oluyor.

• Rakipler ve ilham kaynakları: Benzer fonksiyonları olan ürünler ve bu ürünlerin söz konusu problemi nasıl çözdüğüne dair ilham verecek notlar bu kısımda tutuluyor.

• Pazarlama planı: Go-to-market (GTM) ve canlıya alma sonrası yapılacak pazarlama aktivitelerinin yer aldığı kısım bu oluyor.

2. Faydaları ve zorlukları

PRD hazırlamanın, güncel tutmanın ve genel olarak bu süreçlerin faydaları ve zorlukları kısaca şöyle:

Faydaları

• Ürün geliştirme süreçleri içinde olan ya da olmayan herkesin yapılacakları anlaması ve aynı noktada olması en büyük faydası.

  • Satış ya da müşteri ilişkileri ekipleri yapılan yeniliğin hangi ihtiyaca yönelik olduğunu ve nasıl çözümler ürettiğini yolun başında anlayıp görüştüğü kullanıcıları bilgilendirebiliyor ve hatta erken geri bildirimleri toplayabiliyor. Pazarlama ekipleriyse iletişimde verecekleri mesaj ve bu yeni özelliğin konumlandırmasına erkenden çalışmaya başlayabiliyor. Ürünü geliştiren ekip içinse yanlış anlaşılmalar en aza indiğinden riskler de azalmış oluyor.

• Yapılacak yeniliğin geliştirme süreçlerinde feragat edilecek noktalar (tradeofflar) üzerine kafa yorarken bu dökümanlar en önemli referans noktaları oluyor: Yeniliğin yapılma amacından ya da çözmeye çalıştığı problemlerden sapmadan karar alabilmeye yaraması yine en büyük faydalarından.

Zorlukları

• Geliştirme süreçlerinde yolda alınan küçüklü büyüklü kararları PRD’ye de yansıtmak ve dökümanı güncel tutmak gerekli. Bu da ürün yönetimi rolündeki kişilerin zamanlarının bir kısmını bu “düzeni koruma” işlerine ayırmasını gerektiriyor, ki günlük koşturma içinde bunun zorluğunu hepimiz az çok biliyoruz.

• Geliştirilecek bu yeni özelliği uzun uzun, paragraflarca anlatmak kısmen kolay, ancak bu durumda diğer ekip üyelerinin sıkılmadan bu dökümanı okumaları, hatta bu dökümanı okumaları dahi zorlaşıyor. Kısa ve basit cümlelerle, okunaklı bir biçimde PRD’ler hazırlamaksa emek ve biraz da tecrübe istiyor.

• Yeni özelliğin problem/ihtiyaç özelinde oraya koyacağı çözüm yolu ve şeklini spesifik bir biçimde ortaya koymak, problemi çözecek ekip için yaratıcı olmanın önüne geçebiliyor.

  • Bu durumu engellemenin en iyi yolu problemi çözecek ekibi keşif süreçlerine de dahil edip, problemi detayıyla anlamalarını sağlamak ve PRD’de bahsi geçen çözüm yolunu beraber inşa etmek oluyor.

3. Topluluktan örnekler

Bu yazının ilham kaynağı daha önce pek çok sefer olduğu gibi topluluk üyelerimizin Slack üzerinden bu konuda sohbet edip, fikirlerini paylaşması oldu. Paylaşılanlardan bazı başlıkları şöyle derledik (ve bu paylaşımlara bu sayıda yer vermemize sıcak baktıkları için kendilerine buradan da teşekkür ediyoruz):

Çağatay Tanyıldız: Aslında çoğunlukla bir geliştirici olarak benim requirement almam gerekmiyor. Ancak bazen bu işi benim yapmam gerekiyor. Ve kapsamı daraltmak için söylememde fayda var, firma içi araçlar geliştiren bir ekibin parçası olarak ağ mühendisleri ile beraber çalışıyorum. Benim müşterim de çoğu zaman onlar. Özellikle şunlara dikkat ediyorum:

• İstenen özelliğe hangi sıklıkta ihtiyaç duyuyorlar? Bu bir özelleştirme mi, yoksa daha genel senaryoları da kapsıyor mu?

• Bu özellik kaç farklı versiyonu ve rolü etkiliyor?

  • Buradaki rolden kastım ağ cihazının topolojideki yeri, versiyon da üzerinde çalışan yazılımın versiyonu.

• İstenen özelliğin parametreleri neler? Özellikle versiyonlar arası farklılıklar neler?

• Tüm bunların dışında bu özellikle neyi hedefliyorlar? Bazen ağ cihazının yeni versiyonda duyurduğu/duyuracağı bir özelliği araçta istedikleri oluyor. Zaten built-in gelecek bir özellikle vakit kaybetmemek için bu adımı önemsiyorum. 

• Bazen de öneriyi getiren taraf cihazda istediği özelliğin aktif edildiği durumda istediği başka bir özelliğin etkilediğinin farkında olmuyor, bunu da teyit etmek bize kalabiliyor.

İrem Çilingir: Biz Segmentify’da hem use caseler için hem de problemin doğru bir şekilde analiz edilebilmesi için bir checklist / cevaplanması gereken sorular listesi çıkarmıştık. Paylaşayım:

• Problem

  • What is the customer’s Minimum Valuable Problem?

  • Does the problem have different flavors/manifestations in different customers?

  • How many customers did the problem come from? 

  • How many customers’ problems will it solve?

  • Do we have quantitative data? Can we prove the problem with data?

  • Did we talk to the customer and listen to the problem from the customer?

  • Is there a known best-practice to already solve the problem (so that we don’t re-invent the wheel)? If so what is it and can we use the same method totally/partially in our solution as well?

• Solution

  • How do we plan to solve it?

  • Did we talk to the customer and explain the solution to the customer?

  • What is the goal (metric) of using the feature for…

    • the Product Team?

    • an eCommerce website?

    • the shoppers?

    • the internal stakeholders?

  • What is the impact if the goal IS met?

• Design & Use Cases

  • How does the feature affect other existing features of the platform?

  • What prior knowledge/information are we assuming that the user would have? Are those being communicated well?

  • Do we need an empty state for first-time users? How will it look? What CTAs(Call to action) will it have?

  • What if the user tries to enter a huge number, or a numeric instead of text? What should happen?

  • İrem sağolsun, bu kısım için çokça ve detaylı maddeler var, tamamını merak edenleri Slack’teki konuşmaya alalım.

Mustafa Büyükkara: Bizim 1 sayfalık bir şablonumuz var. Elimizdeki sorunun büyüklüğüne göre bu çerçevede gereksinimleri çıkarmaya çalışıyoruz. Çok kapsamlı bir şablon değil, mümkün mertebe “minimum viable PRD’ler” oluşturarak çevikliğimizi kaybetmemeye çalışıyoruz: https://docs.google.com/document/d/1IWpSaYcMVxunfrWrOAccZINGwdNgKovtvDNbFWvzPNw/edit?usp=sharing

Burak Alparslan: Biz backlog item’larını geliştirme ekibine iletmeden önce aşağıdaki şablonu kullanıyoruz:

4. Yararlı kaynaklar

• Killing the Requirements Document – Link – “The Product Charter” başlığında yer alan şablonu özellikle tüm rollerin birlikte ürün keşif süreçlerini yürüttüğü yapılar için oldukça faydalı buldum.

• Lenny’s Newsletter: My favorite product management templates – Issue 37 – Link – Sıkı takipçisi olduğumuz Lenny’den Square, Asana, Figma gibi farklı şirketlerin uyguladığı PRD/1-pager örnekleri.

• Does anyone else share my frustration around repeated requests for Product requirements? – Link – Bir Reddit kullanıcısından PRD’lerin ekipte karşılık bulamaması üzerine bir serzeniş ve devamındaki konuşmalar.

• Revisiting the Product Spec – Link – Marty Cagan’dan klasik anlamda PRD’lerin nasıl iyileştirebileceğine dair bir blog.

Üretim Bandı Podcast 🎙

• Merthan Öztürk ile sağlık sektörüne ürün geliştirme – Buradan dinleyin

• Serdar Çepniler ile karar verme mekanizmaları – Buradan dinleyin

İş İlanları

Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!

Bu sayılık bu kadar!

Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:

Share Üretim Bandı Bülten