30 sn özet
Ürün yol haritası, ürünün hangi yönde gelişeceğini, hangi problemleri önce ele alacağını ve hangi sonuçları hedeflediğini paylaşır. Strateji ile günlük geliştirme çalışması arasında bağ kurar. Yakın dönem için daha somut, uzak dönem için daha koşullu bilgi içerebilir. İyi bir yol haritası yalnızca özellik adlarını ve tarihleri sıralamaz; müşteri ihtiyacını, beklenen etkiyi ve belirsizliği de açıklar. Yeni kanıt geldiğinde değişebilir. Güvenilirliği, hiçbir zaman değişmemesinden çok, değişikliklerin gerekçesinin anlaşılmasından doğar.
Neden önemli?
Bir ekip güçlü bir backlog’a sahip olduğu hâlde neden bu işleri yaptığını açıklamakta zorlanabilir. Satış belirli bir müşterinin talebini, destek tekrar eden şikâyetleri, mühendislik altyapı ihtiyaçlarını öne çıkarır. Yönetim ise ürünün şirket hedeflerine nasıl katkı sağlayacağını görmek ister. Yol haritası, bu farklı beklentileri ortak bir yön etrafında konuşabilmek için kullanılır.
Bu konuşma yapılmadığında günlük talepler stratejinin yerine geçebilir. Ekip çok sayıda özellik teslim eder; fakat müşterinin asıl işi kolaylaşmaz veya hedeflenen segment ürünü benimsemez. Başarı, tamamlanan madde sayısıyla ölçülmeye başlar. Yol haritasında beklenen müşteri sonucunun açık olması, teslimatla değer üretimi arasındaki farkı görünür kılar.
BA, ihtiyaçların kaynağını ve mevcut sürecin sınırlarını netleştirir. PM, hangi problem alanına yatırım yapılacağını ve bu seçimin ürün stratejisiyle ilişkisini açıklar. PO, seçilen yönün uygulanabilir işlere dönüşmesine katkı sağlar. Yönetici açısından yol haritası, kaynakların nereye bağlandığını ve hangi fırsatların bekletildiğini gösterir. Böylece ürün konuşması, yalnızca “Ne zaman bitecek?” sorusuna sıkışmaz.
Terim nedir?
Ürün yol haritası, ürünün yönünü, önceliklerini ve zaman içindeki gelişimini anlatan stratejik iletişim aracıdır. Her öğenin bir müşteri ihtiyacıyla ve ürün hedefiyle ilişkilendirilmesi gerekir. Ayrıntı düzeyi, kararın olgunluğuna ve paylaşılacak kitleye göre değişebilir. Yönetim için yatırım alanları, ekip için problem bağlamı, müşteri için beklenen gelişmeler daha belirgin olabilir.
Backlog, geliştirme için değerlendirilen ve sıralanan işlerin ayrıntısını taşır. Yol haritası ise bu işlerin hizmet ettiği daha geniş yönü açıklar. Sürüm planı, belirli bir teslimatta hangi kapsamın bulunacağını düzenler. Bu üç araç birbirine bağlanabilir; aynı belgeye bütün görevleri, stratejik amaçları ve kesin tarihleri doldurmak mesajı bulanıklaştırır.
Bir yol haritası tema, problem veya sonuç başlıklarıyla kurulabilir. “Yeni iade ekranı” bir çözüm fikridir. “Müşterinin iadesini daha az destek talebiyle tamamlaması” ise üzerinde çalışılacak sonucu anlatır. Sonuç başlığı çözüm seçeneklerini açık bırakır; fakat ölçüm ve kapsam eklenmezse fazla genel kalır. Bu nedenle hangi müşteri grubu için hangi değişimin beklendiği yazılmalıdır.
Şimdi, sonraki ve daha sonra gibi zaman ufukları, belirsizliği ifade etmek için kullanılabilir. Bu yazıdaki uygulama önerisinde “şimdi” aktif çalışma alanını, “sonraki” başlaması belirli koşullara bağlı adayları, “daha sonra” ise henüz ayrıntılı taahhüt verilmemiş alanları gösterir. Bu etiketlerin ekip içinde aynı anlamda kullanılması gerekir. Her sütunun ne anlama geldiği açıklanmadan yalnızca isimlerini değiştirmek beklenti sorununu çözmez.
Bazı işler gerçek bir teslim tarihi gerektirir. Sözleşme taahhüdü, dış sistem geçişi veya sabit bir iş etkinliği varsa tarih, kapsam ve bağımlılıklar birlikte yönetilir. Keşif aşamasındaki bir fikrin olası dönemiyle onaylanmış bir teslim taahhüdü açıkça ayrılmalıdır. Her tarih aynı kesinlik düzeyini taşımaz.
Gerçek vaka
GitLab’ın 23 Eylül 2021 tarihli rehberi, müşteri ihtiyaçlarının herkese açık ürün yol haritasına nasıl aktarılabileceğini anlatıyor. Şirket, yol haritasının ve özellik taleplerini takip ettiği iş kayıtlarının kamuya açık olduğunu belirtiyor. Böylece müşteriler ve topluluk üyeleri ürünün yönünü, önceliklerini ve tartışmaları görebiliyor; bazı geliştirmelere katkı sunabiliyor.
Rehberdeki süreçte müşteri talebi ilgili iş kaydına ekleniyor. İhtiyacın kullanım bağlamı paylaşılırken gizli müşteri ayrıntıları özel CRM kaydında tutuluyor. Ürün yöneticisi talebi değerlendiriyor; öncelik etiketleri ve gerektiğinde kilometre taşları takip için kullanılıyor. GitLab, geri bildirimin ürün ekibinin planladığı işten kopuk bir yerde tutulmasının sorun yaratabileceğini de açıklıyor.
Bu vaka, yol haritasının arkasındaki ihtiyacın ve tartışmanın izlenebilir olmasına örnektir. Kaynak belirli bir gelir artışı veya teslimat hızlanması raporlamıyor. Ayrıca kamuya açık talep oluşturmak, her isteğin kabul edildiği anlamına gelmez. Buradan çıkarılabilecek yönetim dersi, talebi kaydetmekle teslimat taahhüdü vermek arasındaki ayrımı koruyarak bağlamı paylaşmaktır.
Varsayımsal örnek
Bir e-ticaret operasyon ürününün müşterilerinde iade sürecinin yoğun destek ihtiyacı yarattığını düşünelim. Son dört haftada incelenen 100 iadenin 35’i destek ekibinin müdahalesini gerektiriyor. Ürün ekibi, pilot müşteri grubunda bu oranı yüzde 20’nin altına indirmeyi hedefliyor. Ölçüm dönemi, müşteri kapsamı ve müdahale tanımı başlangıçta belirleniyor.
Yol haritasındaki yakın dönem başlığı “İadeyi müşterinin kendi başına tamamlamasını kolaylaştırma” oluyor. Ekip önce kullanıcı görüşmeleri ve süreç incelemesi yapıyor. Yeni ekran, daha açık durum bilgisi veya bildirim değişikliği aday çözümler arasında bulunuyor. Yol haritası tek bir arayüzü erkenden kesinleştirmediği için keşif bulguları çözümü değiştirebiliyor.
Sonraki alanda stok farklarını azaltma bulunuyor. Bu çalışmanın başlaması, depo entegrasyonundaki veri kalitesinin yeterli hâle gelmesine bağlı. Daha sonraki alanda kurumsal kurulumun hızlandırılması yer alıyor; henüz problem kapsamı netleşmemiş durumda. Satış ekibine paylaşılan görünümde bu koşullar açıkça yazılıyor.
İade araştırması, sorunun büyük bölümünün kargo durum bilgisindeki gecikmeden kaynaklandığını gösterirse ekip planı güncelliyor. Değişiklik, “ekranı erteledik” ifadesiyle sınırlı kalmıyor. Yeni kanıt, seçilen müdahale ve beklenen sonuç açıklanıyor. Pilot sonrasında müdahale oranının yanında hatalı iade ve müşteri şikâyetleri de izleniyor. Böylece bir metrik iyileşirken başka bir sorunun büyümesi gözden kaçmıyor.
Yaygın 3 hata
- Özellik listesini stratejik yön sanmak
Çok sayıda özellik adı, hangi müşteri problemine yatırım yapıldığını açıklamaz. Her başlığın hedeflenen sonuçla bağlantısı kurulmalıdır. Bu bağlantı yoksa yol haritası, farklı ekiplerin taleplerini yan yana koyan bir listeye dönüşür.
- Belirsiz fikirleri kesin teslim sözü gibi paylaşmak
Araştırılmamış kapsam için tarih vermek, müşterinin satın alma kararını yanlış beklentiye bağlayabilir. Paylaşılan görünümde keşif, planlanan çalışma ve onaylanmış taahhüt ayırt edilmelidir. Gerçek bir taahhüt varsa değişiklikler ilgili taraflarla açıkça yönetilmelidir.
- Değişikliği sessizce yapmak
Bir tema kaldırıldığında veya sırası değiştiğinde paydaşların eski varsayımları yaşamaya devam edebilir. Güncelleme tarihi, değişiklik nedeni ve etkilenen kararlar paylaşılmalıdır. Yol haritasını güncel tutmak, yalnızca belgedeki kutuları taşımak değildir.
Mini uygulama/şablon
- Ürün hedefi
- Yol haritasının hizmet ettiği ortak sonuç.
- Tema veya problem
- Ele alınacak ihtiyaç ve etkilenen müşteri grubu.
- Kanıt
- Görüşme, kullanım verisi, destek kaydı veya süreç incelemesi.
- Başlangıç ölçümü
- Mevcut durum, dönem ve ölçüm tanımı.
- Beklenen sonuç
- İyileşme hedefi ve tamamlayıcı göstergeler.
- Zaman ufku
- Şimdi, sonraki veya daha sonra; varsa tarih gerekçesi.
- Olgunluk
- Keşif, doğrulama, uygulama veya sonuç izleme.
- Bağımlılıklar
- Başlamak ve tamamlamak için gereken koşullar.
- Karar sahibi
- Öncelik ve kapsam değişikliğini yönetecek kişi.
- Taahhüt durumu
- Paydaşlarla kesin olarak kararlaştırılmış kapsam ve koşullar.
- Gözden geçirme
- Yeni kanıtın hangi zamanda veya olayda değerlendirileceği.
Üç tema seçerek başlayın. Her birinin neden önemli olduğunu tek paragrafta açıklayın ve ayrıntılı işlerle bağlantısını kurun. Düzenli gözden geçirmede yalnızca teslim edilenleri saymayın; beklenen sonucun oluşup oluşmadığını da değerlendirin. Yeni sürümü paylaşırken değişen kararların gerekçesini ekleyin.
Kavramsal kaynak: Bree Davies, Product Roadmap Guide: What is it & How to Create One, Atlassian.
İlgili terimler
Product Strategy, Product Vision, Product Goal, Product Backlog, Prioritization, RICE, Outcome, Output, Release Planning, Dependency Management, Stakeholder Management