Çoğu PRD okunmaz - ancak harika bir PRD sunumu görülür. Trupeer ile ücretsiz bir PRD sunum şablonuyla başlayarak, marka yönergelerinizi ekleyip özelleştirerek ve PRD’leri paydaşlarla hızlıca uyum sağlayan video anlatımlara dönüştürerek PM iletişiminde saatler kazanabilirsiniz.

PRD sunumu nedir ve PRD’den nasıl farklıdır?

Ürün gereksinimleri dokümanı, neyin inşa edileceğini, kimin için inşa edileceğini ve tamam sayılması için neyin doğru olması gerektiğini ortaya koyar. Bunu inşa edecek ekip için yazılır; ayrıntılıdır ve sunulmaktan ziyade okunur.

PRD sunumu ise farklı bir artefaktır ve farklı bir işi vardır. Ürün incelemesi, yönlendirme grubu ya da yönetici forumunda karar almak için aldığınız az sayıda slayttır ve dokümanın neredeyse hiçbirini içermemelidir.

Bunları birbirine karıştırmak standart bir başarısızlıktır. Sunum, dokümanın sayfalara bölünmüş hâline dönüşür; toplantı sayfa sayfa bir anlatıma, toplantının vermek için var olduğu karar ise alınamaz.

İhtiyacınız olan şey dokümanın kendisiyse, lean PRD şablonumuz hangi gereksinimlerin kısıtlanması gerektiğini ve hangilerinin ekibe bırakılacağını da dahil olmak üzere yapıyı kapsar. Bu sayfa ise başkalarının önünde geçecek yirmi dakikayı anlatır.

Oda gereksinimlerinizi değerlendiremez

Ürün inceleme toplantıları hakkında kimsenin söylemediği şey şu.

Odadaki kişiler; yani yöneticiler, ticari liderler, fonksiyon başkanları, gereksinim 14’ün doğru olup olmadığını değerlendiremez. Müşterilerle konuşmamışlardır, destek taleplerini okumamışlardır, sistemi bilmezler ve materyali, üzerinde beş başka öğe bulunan bir zaman diliminde ilk kez görürler.

Bu onlara yönelik bir eleştiri değil. Bu, yetkilendirmenin ne anlama geldiği. Tam olarak onların zorunda kalmaması için sizden işi yapmanız istendi.

Ama otuz bir gereksinim gösterilen bir oda, bir şeyle ilgilenir; çünkü inceleme dediğimiz şey budur. Ve ilgilendiği şey, gerçekten değerlendirebildiği her şeydir: ürün adı, grafiğin renkleri, müşterilerin gerçekten bunu isteyip istemediği, yayın tarihi ve dışa aktarımın CSV mi XLSX mi olması gerektiği.

Dolayısıyla gereksinimlerle dolu bir sunum, gereksinimlerin sorgulanmasını üretmez. Onların yanındaki her şeyin, yetkiyle sunulmuş hâlini üretir; sonra da katkıda bulunduklarını hisseden ve katkılarının onurlandırılmasını bekleyen kişiler tarafından.

Sunumun görevi, yalnızca odanın karar verebileceği konuları sunmaktır.

Bu şablon Trupeer’da nasıl özelleştirilir

Adım 1: Şablonlar bölümünü açın

Ana navigasyondan Şablonlar bölümüne gidin.

Adım 2: Bir şablon seçin ve açın

Açmak istediğiniz herhangi bir şablonun üzerine tıklayın.

Adım 3: Şablon görünümünü genişletin

Gerekirse, tam düzeni ve ayrıntıları net görmek için şablon görünümünü genişletin.

Adım 4: Şablonu düzenleyin

Seçili şablonda değişiklik yapmaya başlamak için Düzenle’ye tıklayın.

Düzenleyicide şunları yapabilirsiniz:

• Yeni bölümler ekleyin

• Biçimlendirme kurallarını tanımlayın veya güncelleyin

• Bir logo ekleyin ve konumunu ile ilgili ayarları düzenleyin

Adım 5: Özelleştirilmiş şablonunuzu kaydedin

Gerekli tüm değişiklikleri yaptıktan sonra, güncellenmiş şablonu kendi şablonunuz olarak saklamak için Kaydet’e tıklayın.

Adım 6: Şablonu önizleyin ve ince ayar yapın

Özelleştirilmiş şablonunuzun nasıl göründüğünü görmek istediğinizde Önizleme’yi açın.

Önizleme ekranından, gerekirse doğrudan ayarlamaya devam edebilir; böylece şablonun tam olarak istediğiniz gibi göründüğünden emin olabilirsiniz.

Bir PRD sunum şablonuyla şunları yapabilirsiniz:

• Yazmaya ayırdığınız zamanı kazanın: Ürün iletişimi için tasarlanmış bir yapıyla boş sayfayı atlayın.

• Paydaşları hızlıca uyumlayın: Yerleşik bölümler yöneticilerin ve mühendislerin ihtiyaç duyduğu konuları kapsar.

• Markanızla uyumlu kalın: Trupeer’ın marka kitini kullanarak logonuzu, yazı tiplerinizi ve renklerinizi uygulayın.

• Daha iyi kararlar alın: Yoğun PRD’leri herkesin anlayabildiği video anlatımlara dönüştürün.

• Tüm ürünlerde standardize edin: Her PRD incelemesi için aynı şablonu kullanın.

• Küresel ekiplere ulaşın: PRD’leri tek tıkla 65+ dile çevirin.

Bir ürün inceleme odasının gerçekten karar verebileceği şeyler

Sunumu yalnızca sol sütundan oluşturun. Her slayt, oradaki bir şeye karşılık gelmelidir; karşılık gelmeyen her slayt, toplantıda değil, ön-okumada yer alması gereken bağlamdır.

Ödünleşim satırı, ürün yöneticilerinin en az kullandığı satırdır. Yöneticiler, farklı sonuçları olan iki seçenek arasında gerçekten iyi seçim yapar ve incelemenin üretebileceği en yüksek değerli şey budur. Onlara kaçınılmazlık gibi giydirilmiş tek bir öneri yerine iki gerçek seçenek getirin.

Karar getiren altı slaytlık PRD sunumu

Slayt bir. Gerekli karar. Tarihli tek bir cümle. "4 Mayıs’ta başlayarak, dokuz mühendislik haftası maliyetle raporlama modülünü geliştirmek için onay istiyoruz." Ne bir gündem, ne bir başlık slaytı. Önce istek; kimse başka bir şey hakkında görüş oluşturmadan.

Slayt iki. Sayıyla birlikte sorun. Neler oluyor, ne sıklıkta oluyor ve maliyeti ne. En fazla bir grafik. Bu, isteği haklı çıkaran şeydir ve kanıtın ait olduğu tek slayttır.

Slayt üç. Önerdiklerimiz. Tek bir paragraf ve yardımcı olursa tek bir görsel. Bir özellik listesi değil. Odanın, içeriğini değil, şeyin şeklini anlaması gerekir.

Slayt dört. Ödünleşimler ve reddettiklerimiz. İki ya da üç gerçek seçenek; alınmayan seçenek ve nedenleriyle birlikte. Toplantıyı yapmaya değer kılan slayt budur ve çoğu sunum bunu atlar.

Slayt beş. Gerekenler. İnsanlar, zaman, para ve bu insanların bunun yerine yapmayacağı işler. Fırsat maliyeti satırı, kolay evet’i gerçek karara dönüştüren şeydir.

Slayt altı. Yapmadıklarımız. Bu odadaki insanların daha önce istediği şeyler de dahil olmak üzere açıkça. Bunları adlandırmak, toplantıda eklenmelerini engeller.

Altı slayt, on beş dakika ve detay isteyen herkes için PRD, toplantıdan kırk sekiz saat önce dolaşıma girer.

Ücretsiz PRD sunum şablonu: kopyalanacak slaytlar

Buradan kopyalayın.

Başlık ve karar. Ürün veya özellik adı. Sunan. Tarih. Tarihli ve maliyetli tam bir cümle olarak gerekli karar.

Sorun. Gözlem, sıklık, maliyet veya fırsat maliyeti; bir destekleyici görsel ve kaynağıyla birlikte.

Öneri. Şu anda var olmayan, ancak var olacak şeyi anlatan tek bir paragraf; ekip dışından biri tarafından tekrar edilebilecek şekilde yazın.

Ödünleşimler. İki ya da üç satır: seçim, alınan seçenek, reddedilen seçenek, her birinin sonucu.

Maliyet ve taahhüt. Mühendislik zamanı, dahil olan diğer fonksiyonlar, para ve yerinden edilecek işler.

Kapsam dışı. Bu bilerek neleri içermiyor; daha önce bu odadaki kişiler tarafından istenen her şeyi listeleyin.

Ek, sunulmayan. Başarı ölçütleri, bağımlılıklar, riskler, zaman çizelgesi ayrıntısı. İstenirse kullanılabilir; asla toplantıda anlatılmaz.

Ön-Okuma. PRD’nin kendisi; en az kırk sekiz saat önce gönderilir ve hangi kararın isteneceğini belirten bir not içerir.

Buraya kopyalayın. İşe yaratan kural: Sunulan slaytlarda hiçbir gereksinim hiçbir yerde görünmez. Biri sorarsa yanıt, bunun dokümanda olduğu ve bunun iyi bir yanıt olduğudur.

Altmış bir yorum ve karar olmayan bir inceleme

Kirkwall Systems, yaklaşık üç yüz elli kişilik bir B2B yazılım şirketi, çeyreklik bir ürün incelemesi yürüttü. Bir ürün yöneticisi, esasen dokümanın sayfalara bölünmüş hâli olan otuz dört slaytlık bir sunum olarak yeni bir raporlama modülü için bir PRD getirdi.

Odadakiler: genel müdür, finans direktörü, satış başkanları, mühendislik ve müşteri başarısı başkanları ve iki mühendislik lideri. Yetmiş beş dakika.

Birisi sonrasında yorumları kaydetti. Toplamda altmış bir soru ve yorum.

Dokuz tanesi odanın karar verebileceği konularla ilgiliydi: bunu şimdi inşa edip etmeme, iki başka girişim karşısında nasıl sıralandığı, bunun yerine mevcut bir aracı satın alıp almama ve maliyetine ne kadar izin verildiği.

Elli ikisi ise karar veremeyeceği konularla ilgiliydi. Ürün adı. Taslak bir grafikteki renkler. Kanıt olmadan iki yönde de iddia edilen, müşterilerin gerçekten bunu isteyip istemediği. Tek tek gereksinimlerin ifadesi. Ve bir dışa aktarmanın CSV mi XLSX mi olması gerektiği üzerine on iki dakikalık bir tartışma; bu, toplantıdaki tek en uzun kalemdi ve PRD bunu açıkça ekibin kararı olarak işaretlemişti.

Karar alınmadı. Kaydedilen aksiyon, ürün yöneticisinin revize edip geri getirmesiydi.

Üç hafta sonraki ikinci inceleme, yirmi sekiz slaytlık bir sürüm kullandı. Kimsenin maliyetini hesaplamadığı odada iki kapsam eklemesiyle birlikte onaylandı.

İlk incelemeden işin başlamasına kadar geçen gecikme altı haftaydı. Maliyeti hesaplanmamış iki ekleme, tahmini olarak inşa süresine beş hafta daha kattı. Başlangıçta dokuz haftalık kapsamda olan bir özellik, ilk incelemeden teslimata kadar yaklaşık yirmi hafta sürdü.

Değişiklik bir süreç değişikliği değil, bir sunum standardıydı. Altı slayt; önce karar; gereksinim sunulmuyor; PRD, kırk sekiz saat önce ön-okuma olarak dolaşıma giriyor.

Sonraki dört çeyrek boyunca on dokuz PRD incelemesi yeni formatla yürütüldü. Toplantı süresi ortancası yetmiş beş dakikadan otuz dört dakikaya düştü. Oda içinde gerçekten karar verilen oran yaklaşık %40’tan %89’a çıktı. Ve toplantılar sırasında maliyeti hesaplanmamış kapsam eklenmesi, inceleme başına ortalama 1,8 kalemden üçte birinin altına indi.

Gereksinimler de daha iyi değildi. Sorun hiç onlar değildi.

PRD’nin içinde neler olur, sunumda değil?

Sunumun bilerek dışarıda bıraktığı her şey; yani içeriğin çoğu.

Kabul kriterleri; siz ve bir mühendis, bunların karşılanıp karşılanmadığını bağımsız olarak kabul edebilecek şekilde belirtilir. Kısıtlanmış gereksinimler; her biri, neden böyle olması gerektiğiyle birlikte. Ekibe açıkça yetkilendirilen alanlar. Kapsam dışı listesinin tamamı. Sahipleri ve tarihleri olan açık sorular. Ve yayından sonra bakacağınız ölçümler.

Bizim lean PRD şablonumuz bu yapıyı ayrıntılı olarak kapsar; ayrıca ekibin yapmak zorunda olduğu ile ekibin karar verebileceği şeyleri ayıran etiketleme yaklaşımını ve maliyetleri fazla ayrıntılandırmanın, tasarruf ettiğinden daha pahalıya mal olmasını da açıklar.

İki doküman arasındaki ilişkiyi açıkça söylemek gerekir. PRD, ekiple yapılan sözleşmedir. Sunum ise iş dünyasına yapılan taleptir. Farklı okuyucuları, farklı yaşam süreleri ve farklı ayrıntı düzeyleri vardır; paylaşmaları gereken tek içerik problem ifadesi ve öneri paragrafıdır.

Ürün gereksinimleri dokümanı nasıl yazılır, adım adım

Kabul kriterlerini önce yazın; yani bu yayınlandığında doğru olacak ama şu an doğru olmayan tek bir cümle. Olmayacaksa, iş belirtilecek kadar hazır değildir.

Neden şimdi olduğunu iki ya da üç cümleyle yazın; çünkü ekip, asla görmeyeceğiniz yüzlerce küçük ödünleşimi yapmak için bunu kullanır.

Her bir gereksinimi filtrelemeden listeleyin; sonra her biri için cevabı gerçekten önemsediğinize karar verin. İlk taslakların çoğu, yazarın aslında sahip olduğu görüşten çok daha fazla kısıtlar.

Her kısıtlanmış gereksinime bir gerekçe verin. Gerekçenin "bunu genelde böyle yapıyoruz" olduğu her şey bir kısıt değildir; bir alışkanlıktır.

Yapılmayacaklar listesini, insanlar daha ne istiyormuş diye hatırladığınız sırada yazın.

Sonra kısıtlanmış listeyi bir mühendis gibi okuyun. Neden diye soracağınız ama dokümanın yanıt vermediği her yerde gerekçeyi ekleyin ya da satırı kaldırın.

Bir PRD’yi veya sunumunu nasıl kullanmamalısınız

Bir durum güncellemesi olarak. Masada karar yoksa bir PRD incelemesi, eklenmiş görüşlerle birlikte bir ilerleme raporuna dönüşür; bu, hiç toplantı olmamasından daha kötüdür.

Ekip ile konuşmanın yerine geçecek şekilde. Mühendisliğin gereksinimleri ilk kez gördüğü yer bir inceleme ise, inceleme yanlış forum ve yanlış kitle demektir.

İkna dokümanı olarak. Onay almak için yazılmış bir PRD belirsizliği saklar; oysa ekip tam olarak bunu görmeye ihtiyaç duyar.

Onaylandığında dondurulmuş. Açık sorular inşa sırasında yanıtlanır ve değişemeyen bir doküman, kimsenin danışmadığı bir dokümana dönüşür.

Düzenlemeye tabi veya güvenlik açısından kritik bir inşa için bir spesifikasyon olarak. Bir düzenleyici, güvenlik gerekçesi ya da sözleşmesel bir yükümlülük geçerliyse, PRD yerine izlenebilirliği olan tam bir spesifikasyona ihtiyacınız vardır ve uygulama detayını yetkilendirmek tam olarak yapamayacağınız şeydir.

Sayfa sayfa sunmak. Yukarıda uzun uzun anlatıldı ve altı slayttan en yaygını bu.

Bir PRD yazarken ve sunarken yapılan yaygın hatalar

İstekle başlamayıp bağlamla başlamak; oda, kendisinden ne istendiğini bilmeden görüşler oluşturur.

Tek bir seçeneği, sanki tek seçenekmiş gibi sunmak; bu da odanın en iyi yaptığı şeyi yapma yeteneğini ortadan kaldırır.

Aslında önemli olan gereksinimi otuz dördüncü sıraya gömmek; böylece “olsa iyi olur” gibi görünür.

Karar toplantısına mock-up getirmek; gündemde ne olursa olsun tartışmayı güvenilir şekilde tüketir.

Fırsat maliyetini atlamak; böylece onay ücretsizmiş gibi hissedilir.

Odadaki kişilerin daha önce istediği kapsam dışı kalemleri adlandırmamak; bu, onları canlı olarak eklemeye davet olur.

Ve toplantıda eklenen kapsamı maliyetlendirmeden kabul etmek; böylece dokuz haftalık bir özellik yirmi haftalık olana dönüşür.

Google Docs, Word ve Confluence’ta PRD şablonları

Google Docs, tartışılacak bir PRD için uygundur; çünkü tartışmanın yaşandığı yer yorum başlıklarıdır. Zayıf tarafı, kararların kimsenin okumadığı çözümlenmiş yorumlara düşmesidir; bu yüzden çözmeden önce dokümanda değişen her şeyi gereksinimin gerekçe alanına kopyalayın.

Confluence, mühendislik organizasyonlarında en yaygın yerdir ve standart PRD şablonu konvansiyoneldir. Gövdeyi daha yalın bir yapıyla değiştirmek sorunsuz çalışır; durum ve sahip için sayfa özelliklerini korumaya değer.

Word, PRD’nin resmi bir onay paketinin parçası olduğu organizasyonlara uygundur ve numaralandırılmış gereksinimleri ile çapraz referansları iyi yönetir.

Notion, gereksinimleri bir veritabanı olarak istiyorsanız iyi çalışır; çünkü kısıtlanmış veya yetkilendirilmiş etiket, çeyrek boyunca filtreleyip sayabileceğiniz bir özellik haline gelir.

Sunumun kendisi için, organizasyonunuzun kullandığı her şeyi kullanın ve bunu altı slaytla sınırlı tutun. Araç, gereksinimlerin sunumun dışında kalıp kalmamasından çok daha az önemlidir.

Word, Excel veya PDF’de PRD şablonu alabilir miyim?

PRD için Word veya Google Docs. İçinde numaralı bir liste olan bir metindir ve yorum alır.

Özellikler boyunca gereksinimler kaydı için Excel: tek bir PRD için değil; özellik, gereksinim, kısıtlanmış ya da yetkilendirilmiş, gerekçe ve inşa sırasında yeniden müzakere edilip edilmediği. Son sütun, davranışları güvenilir şekilde değiştiren tek PRD ölçütüdür.

Açık sorular kapatıldıktan sonra, karar kaydına eklenen veya şirket dışıyla paylaşılan sürüm için PDF.

Sunum için PowerPoint veya Slides: altı slayt; PRD gömülü değil, ön-okuma olarak gönderilir. Sunum, partner ya da yönetim kurulu gibi harici bir kitleye gidiyorsa, marka kitleri kimse şablon yeniden oluşturmak zorunda kalmadan tutarlılığı korur.

Karardan sonra ne inşa ettiğinizi nasıl gösterirsiniz

PRD, iş başladığı gün okunmayı bırakır ve sunum, toplantıdan sonraki hafta unutulur. Kimsenin üretmediği şey, döngüyü kapatan artefaktır: onaylayanlar için ve artık onu desteklemek ya da satmak zorunda olan herkes için, gerçekten neyin inşa edildiğine dair kısa bir gösterim.

Trupeer AI bunu ucuz hale getirir. Bunu kim yaptıysa bitmiş özelliği bir kez kaydeder ve çıktı; yazılı bir anlatım, yayın notu için bir video ve kendi markalamanızdaki knowledge base için bir dokümandır. Bu tek kayıt, inceleme grubu, destek ekibi ve müşteriyle yüz yüze makale için de işe yarar; knowledge base makale şablonlarımız bunu kapsar.

Kaydedin. Markalayın. Çevirin. Trupeer’layın.

Ayrıca bir sonraki incelemeyi de iyileştirir. Son onaylanan özelliğin gerçekte neye dönüştüğünü iki dakikalık bir kayıt, bu birinin ne olabileceğine dair herhangi bir slayttan çok daha ikna edicidir. Teknik dokümantasyon, inşa edilen şeyin dahili kaydını kapsar. Kurulum talimatları doküman şablonu kurulum kılavuzunda yer alır.

Sık Sorulan Sorular

Word’de ücretsiz bir PRD şablonu var mı?

Doküman yapısı lean PRD şablonumuz içinde ele alınır ve doğrudan Word veya Google Docs’a yapıştırılır. Bu sayfadaki sunum yapısı altı slayttır. Kilitli bir indirme yoktur ve her ikisi için de bir form bulunmaz.

Google Docs için bir PRD şablonu var mı?

Yapıyı bir Google Doc’a kopyalayın ve şablon olarak ekip sürücünüze kaydedin. Google Docs özellikle iyi bir seçimdir; çünkü PRD’ler yorumlarda tartışılır. Ancak bir iplikte alınan her karar, iplik çözümlenmeden önce dokümana yazılmalıdır.

Excel’de bir ürün gereksinimleri dokümanı şablonu var mı?

Excel, tek bir PRD’den ziyade birden fazla özellik boyunca gereksinimler kaydı için uygundur. Sütunlar: özellik, gereksinim, kısıtlanmış mı yoksa yetkilendirilmiş mi, gerekçe ve inşa sırasında yeniden müzakere edilip edilmediği. Bu son sütunu çeyreklik olarak incelemek, hangi ürün yöneticilerinin gereksinimleri fazla ayrıntılandırdığını görmenizi sağlar.

PDF’de bir PRD örneği veya örnek şablon var mı?

Yayınlanmış örnekleri bulmak kolaydır ve içerikten ziyade bölüm sırası açısından okumaya değerdir; çünkü herhangi bir gerçek PRD’deki gereksinimler tek bir ürüne aittir. Daha faydalı alıştırma, yakın zamanda teslim ettiğiniz bir özelliği alıp bunun için altı slaytlık sunumu geriye dönük olarak yazmaktır; bu genellikle kararın hiç net şekilde belirtilmediğini ortaya çıkarır.

AI PRD araçları kullanmaya değer mi?

İlk taslak için evet. Özelliği açıklayın; en güncel araçlar, unutmuş olabileceğiniz bölümlerle birlikte yapılandırılmış bir doküman döndürür. Ancak sizin gerçekten önemsediğiniz gereksinimleri seçmek onların yapamayacağı bir şeydir; çünkü bu yalnızca sizde olan bilgiye bağlıdır. Tek başına bırakıldıklarında, kaçınmanız gereken başarısızlık modu olan, kendinden emin şekilde fazla ayrıntılandırılmış bir doküman üretirler.

Bir PRD sunumu kaç slayt olmalı?

Altı; yaklaşık on beş dakikada sunun ve ek kısmını anlatmayın. Daha uzun sunumlar daha fazla yorum ve daha az karar üretir; yukarıdaki çalışılmış örneğin ölçtüğü ilişki budur. Yönetişiminiz sabit bir format gerektiriyorsa, devamında ne olursa olsun kararı ilk slaytta tutun.

PRD’yi kim sunmalı?

Bunu yazan ürün yöneticisi; mühendislik lideri odada olsun ama sunum yapmasın. Ödünleşim slaytı için mühendislerin odada bulunması önemlidir; çünkü "daha hızlı yapabilir miyiz" sorusuna güvenilir yanıtı ikinci el yerine onlardan almak daha iyidir.

PRD ile gereksinimler dokümanı arasındaki fark nedir?

PRD ürün odaklıdır: ne inşa edilecek, kimin için ve tamam ne demektir. İş gereksinimleri dokümanı daha önce gelir ve iş problemini ile herhangi bir çözümün neyi başarması gerektiğini, inşa kararı alınmadan önce açıklar. Teknik spesifikasyon daha sonra gelir ve nasıl inşa edileceğini anlatır. Birine ihtiyaç varken diğerini aramak yaygındır ve yanlış yükseklikte dokümanlar üretir.