Tek Satırlık Bir Özellik Talebinden PRD Yazmak
4 dk okuma
Çoğu PRD aynı şekilde başlar: boş bir belge ve "kullanıcıların verilerini dışa aktarmasına izin ver" gibi tek satırlık bir fikir. Oradan, akla gelen ilk şeyi, genelde gereksinimleri, özgürce yazmak kolaydır, ve üç paragraf sonra belgede hiçbir yerde bir problem ifadesi veya başarı metriği olmadığını fark edersin. Bir özellik fikrine heyecanlanan bir PM, gerçekte hangi problemi çözdüğünü yazmak için durmadan çok önce, nasıl çalışması gerektiğinin mekaniğini, kesin alanları, kesin düğme yerleşimini yazmaya başlama eğilimindedir.
Dikkat
Boş bir belge sana bir PRD'nin hangi bölümlere ihtiyacı olduğunu hatırlatmaz. Sadece şeyleri hangi sırayla düşündüysen onu yansıtır, ve bu nadiren bir incelemecinin okumayı beklediği sıradır.
Bir özellik fikri bir cümledir. Bir PRD bir yapıdır. Özgürce yazmak sana genişletilmiş cümleyi verir.
Özgürce yazmak sen fark etmeden neden bölümleri atlar
Boş bir sayfadan yazmak, yapıyı giderken icat ettiğin anlamına gelir, ve bariz hissettiren kısımları, genelde gereksinimleri, yazmak kolaydır; daha fazla düşünce gerektiren kısımları, gerçek problemi adlandırmak veya özelliğin işe yaradığını kanıtlayan bir metrik seçmek gibi, atlamak da kolaydır. Gereksinimler bölümü somuttur ve yazması tatmin edicidir, çünkü belirli, kontrol edilebilir şeylerin bir listesidir. Problem ifadesi geri çekilmeyi ve bunların neden önemli olduğunu ifade etmeyi gerektirir, ki bu farklı, daha zor bir düşünme türüdür, ve zaman baskısı altında önce atlanan kısımdır.
"Kullanıcıların verilerini CSV olarak dışa aktarmasına izin ver" gibi tek satırlık bir fikri ele al. Fikre heyecanlanan bir PM, dışa aktarmaya tam olarak hangi alanların dahil edilmesi gerektiğini ve düğmenin ne demesi gerektiğini ayrıntılandırmak için yirmi dakika harcayabilir, ve belgeyi incelemeye gönderirken ancak destek ekibinin aylardır manuel dışa aktarma talebi aldığını açıklayan bir cümlenin hiçbir yerde olmadığını fark eder. Bu belgeyi açan bir incelemeci, önerilen gereksinimlerin gerçek problemi çözüp çözmediğini yargılayacak bir yolu yoktur, çünkü gerçek problem hiç yazılmamıştır.
Önce: boş bir belge aç, özellik fikri için gereksinimleri yazmaya başla, sonra problem ifadesinin ve başarı metriklerinin eksik olduğunu fark et.
Sonra: Claude'a tek satırlık fikri ve çözdüğü problemi ver, yapılandırılmış bir ilk taslak geri al, problem, hedefler, gereksinimler ve metrikler; her bölüm iyileştirmeye hazır halde zaten yerinde.
Yapılandırılmış bir ilk taslak için bir süreç
- 1
Özellik fikrini ve çözdüğü problemi belirt
Başlamak için her biri için bir cümle yeterlidir. "Kullanıcıların verilerini CSV olarak dışa aktarmasına izin ver, çünkü destek bunu manuel olarak sürekli soruyor" Claude'a hem neyi hem de nedeni verir.
- 2
Açık bir taslak değil, sabit bir yapı iste
Özellikle bir problem ifadesi, az sayıda hedef, fonksiyonel gereksinimler ve bu sırayla başarı metrikleri iste. Sabit bir yapı, taslağı bir deneme yerine incelenebilir hale getiren şeydir.
- 3
Hedefler ve metrikler için gerçek bir sayı ver
"Bazı hedefler" yerine belirli bir sayı iste, üç hedef, iki metrik. Bir sayı, büyümeye devam eden açık uçlu bir liste yerine önceliklendirmeyi zorlar.
- 4
Taslağı nihai bir belge değil, başlangıç yapısı olarak ele al
Geri dön ve her bölümü kendi sesinle yeniden yaz. İlk taslağın değeri hiçbir şeyin eksik olmamasıdır, ifadenin nihai olması değil.
Kullanıcıların verilerini CSV olarak dışa aktarmasına izin vermek istiyoruz. Bir problem ifadesi, üç hedef, fonksiyonel gereksinimler ve ilk 30 günde takip edebileceğimiz iki başarı metriği olan bir sayfalık bir PRD taslakla.
”Özellik fikri belirli, bilinen bir kaynaktan geldiyse, bir destek bileti kümesi, bir müşteri talebi, rekabetçi bir boşluk, bunu Claude'a açıkça söylemek değerlidir; çünkü gerçek, adlandırılmış bir kaynağa dayanan bir problem ifadesi, bir incelemeciye makul görünen ama jenerik bir ifadeden çok daha güvenilir okunur.
Bu fikir doğrudan geçen ay içindeki 15 destek biletinden geldi, hepsi destekle iletişime geçmeden verilerini çıkarmanın bir yolunu istiyordu. Problem ifadesini, ihtiyacın genel bir tarifi değil bu gerçek kaynağa özel olarak referans verecek şekilde yeniden yaz.
”
Claude Tutorial içinde
Boş bir sayfa yerine sabit bir yapıdan başlamak aktarılabilir.
Yazarken yapı icat etmek yerine bilinen bir bölüm setinden çalışmak, PRD'lerin çok ötesinde işe yarar. Uygulamada bunun üzerine tam bir ders var, incelemecilerin bekledikleri bir şekle sahip herhangi bir belgeye taşınan pratikle.
Hedefler metriklerle uyuşmadığında
İlk bir taslaktaki yaygın bir boşluk, bağlı bir metriği olmayan bir hedef, veya belirtilen hedefin gerçekleştiğini gerçekte kanıtlamayan bir metriktir. Bu uyumsuzluğu, biri özelliğin işe yaradığını nereden bileceğini sormadan önce, belge çıkmadan önce yakalamak değerlidir. "Destek yükünü azalt" gibi bir hedef "yapılan dışa aktarma sayısı" gibi bir metrikle eşleştirildiğinde ilişkili görünür ama hedefi gerçekte kanıtlamaz, çünkü kullanıcılar tek bir destek bileti önlenmeden sürekli veri dışa aktarabilir.
İpucu
Claude'dan her hedefi metriğine karşı doğrudan kontrol etmesini iste: bu sayıya ulaşmak gerçekten hedefin gerçekleştiğini kanıtlıyor mu, yoksa sadece onunla ilişkili bir şey mi? Ölçülmesi kolay bir metrik otomatik olarak doğru olan değildir.
Bu PRD taslağındaki üç hedef ve iki metrik burada. Her hedef için, bana dürüstçe söyle: metrikler gerçekten gerçekleştiğini mi kanıtlıyor, yoksa sadece ona bitişik bir şeyi mi ölçüyor?
”Bir metriğin mevcut araçlarla gerçekten takip edilmesi zor olduğu ortaya çıkarsa, özellik canlıya çıktıktan sonra kimsenin gerçekte ölçemeyeceği bir başarı metriğiyle bir PRD göndermek yerine, bu kısıtlamayı erken ortaya çıkarmak değerlidir.
Bu metriklerden biri, şu anda yerinde olmayan bir takibi gerektirir. Aynı hedefi kanıtlayan ama mevcut analitik kurulumumuzla ölçülmesi gerçekçi olan bir metrik öner.
”Okumaya devam et
- İncelemeye Göndermeden Önce Bir PRD'yi Keskinleştirmek: bu makalenin ürettiği yapılandırılmış taslağı bir incelemeciye ulaşmadan önce test etmek.
- Takasları Açıklayan Bir Yol Haritası Belgesi Yazmak: bu özellik fikri yol haritasında bir yer için diğerleriyle rekabet etmek zorunda kaldığında ne olur.
- Destek Biletlerini Önceliklendirilmiş Temalara Dönüştürmek: en baştan PRD yazmak için gerçek özellik fikirlerinin bir kaynağı.