Ürün Yöneticisinin İşi: Önceliklendirme, Deney ve Tasarım Sınırı

Ürün yöneticisi tarifleri genelde bir yetkinlik listesine dönüşüyor: stratejik düşünme, iletişim, analitik beceri, biraz teknik kavrayış. Liste yanlış değil, ama hiçbir şeyi ayırt etmiyor; aynı dört madde proje yöneticisi için de yazılabilir. Rolü ayıran şey becerilerin toplamı değil, kararın nerede bittiği.

Görev listesi rolü anlatmıyor

Backlog bakımı, rakip incelemesi, dönemsel raporlar, paydaş toplantıları. Bunlar bir ürün yöneticisinin takviminde görünen işler, rolün tanımı değil. Daha ayırt edici soru şu: hangi kararı yalnızca bu kişi verebilir? Cevap genelde tek bir yere çıkıyor, neyin yapılmayacağına.

Önceliklendirme bir toplama değil, çıkarma işi. Bir çeyrekte onaylanan altı maddenin yanında, gerekçesiyle birlikte reddedilmiş kırk madde durur; ekibin hızını belirleyen de o kırk madde hakkında ne kadar çabuk ve ne kadar açık karar verildiğidir. Kaynak kısıtının görünür olmadığı bir ekipte ürün yöneticisinin işi, gelen istekleri geliştiricilere aktarmaktan ibaret kalır.

Puanlama modeli ölçüm değil, tahminlerin çarpımı

Değere göre önceliklendirme çoğu yerde bir formüle bağlanıyor. RICE bunun yaygın hali: erişim çarpı etki çarpı güven, bölü efor. Formülün verdiği tek sayı tabloyu sıralanabilir hale getirdiği için ikna edici görünüyor.

Girdilere bakmak gerekiyor. Erişim ölçülebilir, analitikten gelir. Etki ise 0,25 ile 3 arasında elle seçilen bir katsayı, güven bir yüzde tahmini, efor da kod yazılmadan önce verilen bir gün sayısı (bu sütundaki sayıyı ikiyle çarpmadan okumuyorum). Etki ve efor tahminlerinin her biri iki kat yanılırsa bölme işlemi hataları üst üste bindirir ve skor dört kat kayar. Bu, listenin ilk beşini tamamen değiştirmeye yeter.

Puanlama modelinin değeri sıralamada değil, varsayımı yazılı hale getirmesinde. Tabloyu sonucu tartışılmaz bir hesap makinesi gibi değil, üç ay sonra geri dönüp hangi tahminin tuttuğuna bakılacak bir kayıt gibi kullanmak gerekiyor. Sütunları doldurup skora göre sıralamakla biten bir toplantı, kararı modele devretmiş olur.

Hızlı deney çoğu üründe hızlı değil

Varsayımları testle sınamak doğru tavsiye. Sorun, A/B testinin bu tavsiyenin varsayılan aracı sayılması.

Dönüşümün yüzde 3'ten yüzde 3,3'e çıktığını görmek istiyorsunuz, yani bağıl yüzde 10'luk bir artış. Yüzde 80 güç ve yüzde 5 anlamlılıkla kol başına gereken kullanıcı sayısı kabaca 16·p(1-p)/δ², yani 16 × 0,0291 / 0,000009 ile 52 bin civarı. İki kol için 104 bin kullanıcı. Günde 2.000 ziyaretçi alan bir ürün için bu, testin iki aya yakın sürmesi demek, o da tek bir buton metni için.

Küçük etkiyi ölçmek pahalı; A/B testinin çabuk cevap verdiği yer büyük etkiler. Arayüz ayrıntılarında beş kişilik bir kullanılabilirlik oturumu iki günde sonuç verir ve dönüşüm yerine neden sorusunu cevaplar. Ekibin trafiği yukarıdaki hesabın altındaysa, deney kültürü söylemini bırakıp kararların çoğunu nitel kanıtla verdiğinizi kabul etmek daha dürüst olur.

Tasarıma müdahale ile tasarım bilgisi aynı şey değil

Standart tavsiye iki şeyi aynı anda söylüyor: ürün yöneticisi tasarım sürecine fazla karışmamalı, ama tasarım bilgisine sahip olmalı. Bu ikisi kağıt üzerinde çelişiyor. Pratikte çelişmemesinin tek yolu, bilginin nereye harcandığı.

Tasarım bilgisi kanıt okumak için kullanıldığında işe yarıyor: bir kullanılabilirlik oturumunda kaç katılımcının nerede takıldığını doğru yorumlamak, araştırma bulgusuyla kişisel tercihi ayırt etmek, tasarımcının gerekçesini dinleyip zayıf yerini sorabilmek. Çözüm önerisi üretmek için kullanıldığında süreçte dolaşan şey bilgi değil, yetki olur.

Ayrım şurada net: ürün yöneticisinin masaya ekran taslağı getirmesi sorun değil, o taslağın karar sayılması sorun. Getirilmesi gereken şey kısıt. Bu ekran depodaki el terminalinde tek elle kullanılacak. Arama sonucu sunucudan 400 milisaniyeden önce dönmüyor. Fiyat alanı üç farklı para biriminde gelebiliyor. Bu cümleler tasarımcının çözüm alanını daraltırken işini kolaylaştırır, taslak ise sadece kapatır.

İki rolün hizalandığı yer de burası. Ortak hedef metni yazmak, haftalık toplantı koymak ya da çapraz fonksiyonlu atölye yapmak bunu kendiliğinden getirmiyor; problem tanımı ve kısıtlar yazılı değilse o toplantılar, kimin fikrinin daha yüksek sesle söylendiğine bakan oturumlara dönüşüyor.