Müşteri geri bildiriminden ürün roadmap'i nasıl oluşturulur

Ürün roadmap’i nasıl oluşturulur sorusunun cevabı şudur: müşterilerin zaten istediklerini toplayın, her talebin arkasındaki soruna göre gruplayın, grupları açıklayabileceğiniz bir kuralla sıralayın, her biri konusunda ne kadar emin olduğunuza karar verin ve sonucu okuyucuya uyan bir formatta yayımlayın. Sıra önemlidir. Bir düzenle başlayıp onu fikirlerle dolduran ekipler bitmiş görünen ama hiçbir kanıt taşımayan bir belge elde eder. Taleplerle başlayan ekipler ise her satırın bir nedeni olan daha kısa bir roadmap alır.

Ürün roadmap’i oluştururken nereden başlarsınız?

Boş bir sayfayla değil, elinizdeki kanıtla başlayın. Açık özellik talepleri, aynı şikayetle etiketlenmiş destek konuşmaları, satış görüşmesi notları ve kendi ürününüzün kullanım verisi girdidir. Hepsini tek bir listeye koyun ve her maddenin nereden geldiğini yazın.

Talepler nadiren kullanılabilir biçimde gelir. “Slack entegrasyonu ekleyin” ile “bir görev değişince ekibime haber ver” aynı ihtiyaç olabilir. Bir sonraki adımın gruplama olmasının ve yinelenenleri birleştiren bir tracker’ın değerli olmasının nedeni bu; yinelenen özellik talepleri yazısı bunu nasıl yapacağınızı anlatır. Destek biletleri ve özellik talepleri farklı türde sinyal taşır; yalnızca birinden kurulan bir roadmap yanlış tarafa eğilir, bunu aklınızda tutun.

Talepleri ürün roadmap’inizde maddelere nasıl dönüştürürsünüz?

Talepleri soruna göre gruplayın, her grubu bir sonuç olarak adlandırın ve sayıyı tutun. Yenilemeden sonra filtreyi kaybetmeyi anlatan on dört talepten oluşan bir grup tek bir madde olur: “En son kullandığınız filtreyi korur”. Sayı kaynak sütununa gider, böylece roadmap’i okuyan herkes arkasındaki ağırlığı görebilir.

Sonucu müşterinin kelimeleriyle yazın. “Kayıtlı görünüm kalıcılığını uygula” bir mühendise ne yapacağını söyler, müşteriye hiçbir şey söylemez. Sonuç ifadesi yararlı bir soruyu da zorlar: müşteri için neyin değiştiğini söyleyemiyorsanız, başka bir listeye ait dahili bir göreve bakıyor olabilirsiniz.

Neyin önce geleceğine nasıl karar verirsiniz?

Tek bir puanlama kuralı seçin, yazın ve her maddeye uygulayın. Erişim, etki, güven ve eforu puanlayan RICE en yaygın olanıdır; Intercom’un RICE yazısı orijinal kaynaktır. Açıklayabiliyorsanız daha basit bir kural da aynı işi görür: talep sayısı, talep edenin aktif ödeme yapan bir hesap olup olmadığına göre ağırlıklandırılmış, kabaca eforla bölünmüş.

Önemli olan kuralın belirtilmiş olmasıdır, çünkü talebi listede olmayan ilk müşteri nedenini soracaktır. Kural ile sizin yargınız ayrıştığında bunu satırda söyleyin. Özellik taleplerine öncelik vermek yazısı puanlama yöntemlerini, gelir ağırlıklandırma sorusunu ve oyların neyi söyleyip neyi söylemediğini ele alır.

Her madde konusunda ne kadar eminsiniz?

Herhangi bir şey yayımlamadan önce her maddeyi güven düzeyiyle etiketleyin. Basit bir üç değerli ölçek yeterli: taahhüt, ekibin o pencerede yayımlamamasına şaşıracağı anlamına gelir; tahmin, bir şey değişmedikçe plan budur demektir; araştırma ise hiçbir söz olmadığı anlamına gelir.

Bu tek sütun roadmap hasarının çoğunu önler. Onsuz, bir müşteri araştırma maddesini taahhüt diye okur, satış onu alıntılar ve bir çeyrek sonra bu bir şikayete dönüşür. Marty Cagan’ın roadmap’lere alternatif yazısı altta yatan savı yapar: tarihli bir özellik listesi plan gibi sunulan tahminlerin listesidir ve çözüm, ne bildiğiniz konusunda açık olmaktır.

Roadmap hangi formatı almalı?

Düzeni en son, okuyucuya göre seçin. Müşteriler duyulup duyulmadıklarını sorarken kısa bir herkese açık görünüm ister. Yönetim bu işin neden gerektiğini sorarken temalar veya sonuçlar ister. Yönünü ayda bir değiştiren bir ekip için tarihsiz Now, Next ve Later iyi çalışır. Ürün roadmap örnekleri gerçekçi maddelerle altı formatı ve her birinin nasıl başarısız olduğunu gösterir; ürün roadmap şablonu ise seçtikten sonra kopyalanacak alanları verir.

Çoğu ekip iki belgeyle sonuçlanır: dahili okuyucular için stratejik bir roadmap ve yalnızca hesabını vermeye razı olduğunuz şeyleri gösteren küçültülmüş bir herkese açık roadmap. Birini yayımlarsanız, genel roadmap yazısı onu zaten takip ettiğiniz issue’lardaki etiketlerle nasıl yöneteceğinizi anlatır.

Roadmap’in bayatlamasını nasıl önlersiniz?

Her satıra bir gözden geçirme tarihi verin ve roadmap’i işin zaten olduğu yerde tutun. Ayrı bir araçta elle güncellenen roadmap bayatlar, çünkü kimsenin günlük işi onu içermez. Her sütun issue üzerindeki bir etikete karşılık geliyorsa, roadmap etiket değiştiğinde değişir.

Bir madde yayımlandığında döngüyü kapatın. İsteyenler bunu duymalı ve changelog girdisi bunun olağan yeridir; müşteri geri bildirim döngüsü yazısı tüm yolu anlatır. Bir şeyi yapmamaya karar verirseniz bunu da söyleyin. Net bir hayır, isteyen kişi için yararlıdır ve özellik taleplerini reddetmek yazısı ifadeyi ele alır.

FAQ

Ürün roadmap’i nasıl oluşturulur, adımlar nelerdir? Talepleri ve verileri toplayın, her birinin arkasındaki soruna göre gruplayın, yazılı bir kuralla sıralayın, her maddeyi ne kadar emin olduğunuza göre etiketleyin, okuyucu için bir format seçin ve bir gözden geçirme tarihi koyun. Kanıttan başlamak roadmap’i kısa ve savunulabilir tutar.

Bir ürün roadmap’i neye dayanmalı? Müşteri taleplerine, destek temalarına, kullanım verisine ve stratejinize; bu sıra, hangisinin ne sıklıkla atlandığını yansıtır. Satırlarının arkasında kaynak olmayan bir roadmap, dilek listesidir.

Bir ürün roadmap’i ne kadar süreyi kapsamalı? Yararlı olacak kadar uzun, inanılır kalacak kadar kısa. Birçok küçük ekip için bu, ayrıntılı olarak içinde bulunulan çeyrek ve tema olarak sonraki bir iki çeyrektir. Daha ilerisi tarihsiz olarak “later” altına aittir.

Ürün roadmap’i oluştururken kimler yer almalı? Ürün sahibi karar verir, mühendislik fizibiliteyi ve eforu kontrol eder, destek ve satış da duydukları talepleri ve temaları sağlar. Müşteriler sonucu herkese açık bir sürümde görür ama onu düzenlemez.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Geliştirici dokümantasyonu, Changelog örnekleri