Ürün Yol Haritası Oluşturma

Now/Next/Later Framework

Now/Next/Later çerçevesi zaman dilimlerine değil, öncelik ve belirsizlik derecesine göre öğeleri gruplar. "Now" sütunundaki öğeler net kabul kriterleri olan, sprint seviyesinde tanımlanmış işlerdir; ekip bu öğeler üzerinde aktif çalışıyor demektir. "Next" sütunundaki öğeler önceliklendirilmiş ama henüz detaylandırılmamıştır; bir sonraki planlama döneminde "Now"a taşınacak adaylardır. "Later" sütunu ise yüksek belirsizlik taşıyan, yön hakkında fikir yürütülen ancak taahhüt verilmemiş öğeleri barındırır.

Bu framework'ün sprint planlamasıyla karıştırılmaması gerekir. Roadmap ürünün nereye gittiğini gösterir; sprint planı bugün ne yapıldığını. OKR entegrasyonu için her roadmap öğesini bir Key Result'a bağla: bağlanamıyorsa o öğe "nice to have"tir ve "Later"dan da kaldırılabilir. Productboard, Aha! ve Linear bu bağlantıyı görselleştirmek için kullanılabilir; 1–5 kişilik bir ekipte Notion'da basit bir tablo aynı işi görür.

Müşteriye Açık vs Dahili Roadmap

Müşteriye açık roadmap, Linear'ın public changelog'u gibi, güven inşa eder ve beklenti yönetimini kolaylaştırır. Özellikle B2B ürünlerde kurumsal alıcılar roadmap'i satın alma kararında referans alır. Ancak açık roadmap commitment baskısı yaratır: tarih verilen bir özellik geciktiğinde destek taleplerinin arttığını, müşteri görüşmelerinin zorlaştığını görürsün. Bu yüzden açık roadmap'te tarih yerine "2026 Q1" gibi çeyrek dönemler kullan ve "planlıyoruz" ile "taahhüt ediyoruz" arasındaki farkı netleştiren bir not ekle.

Dahili roadmap'te sprint numarası yerine çeyrek dönem kullan. Sprint planları değişir; "Sprint 14'te yapılacak" yazmak iki ay sonra yanıltıcı olur. Ekip için "2026 Q2" yazmak hem esneklik tanır hem de ilerlemeyi ölçmeyi kolaylaştırır. Dahili roadmap'te her öğeye bağlı metrik ve beklenen etki de yazılmalıdır: "Checkout akışını basitleştir → sepet terk oranını %38'den %25'e düşür" biçiminde.

Yatırımcıya Roadmap Sunumu

Yatırımcıya roadmap sunarken mevcut aşamadan sonraki iki milestone'u ve her milestone'un başarı metriklerini göster. "2026'da 10 özellik ekleyeceğiz" yatırımcı için bilgi taşımaz; "Q2'de ödeme altyapısını tamamla → MRR $50K'ya ulaş, Q3'te enterprise tier'ı aç → ortalama sözleşme değerini $200/ay'dan $800/ay'a çıkar" somuttur. Her milestone'u bir finansman veya gelir hedefiyle ilişkilendirirsen yatırımcı para nereye gidecek sorusunun cevabını kendiliğinden görür.

Sunumda aşırı detaydan kaçın: sprint görevleri ve teknik borç kalemleri yatırımcı roadmap'ine girmez. Yatırımcı için önemli olan "bu ürün 18 ay içinde nerede olacak ve nasıl ölçeceğiz" sorusunun cevabıdır. Daha fazla özellik yerine daha az, ama daha güçlü maddeler içeren bir roadmap, ürün ekibinin önceliklendirme disiplini hakkında olumlu sinyal verir.

Roadmap'ı Güncel Tutma

Roadmap haftalık güncellenmez; bunun için sprint review yeterlidir. Roadmap'i çeyrek dönem başında ve önemli strateji değişikliklerinde güncellemek doğru ritimdir. Her çeyrek sonunda bir "roadmap retrospektifi" yaparak şunları değerlendir: taahhüt edilen öğelerden kaçı tamamlandı, hangi öğe tahminlerin dışına çıktı ve neden, "Later" sütunundaki hangi öğeler artık geçersiz?

Eski roadmap'leri silme, arşivle. Geçmişteki taahhütleri ve kararları takip etmek, aynı tartışmaları tekrar açmaktan daha verimlidir. Notion veya Linear'da tarih damgalı roadmap versiyonlarını arşivde tutmak altı ay sonra neden bir özelliğin ertelendiğini hatırlamak için büyük kolaylık sağlar.

Sık Sorulan Sorular

Roadmap ile backlog arasındaki fark nedir? Backlog her potansiyel işi barındıran sıralanmış bir listedir. Roadmap ise stratejik yönü ve öncelikleri gösterir; backlog'daki her öğe roadmap'te yer almaz. Roadmap "neden yapıyoruz" sorusunu yanıtlarken backlog "ne yapıyoruz" sorusunu yanıtlar.

OKR'a bağlanamayan roadmap öğeleri ne yapılmalı? Doğrudan bir Key Result'a bağlanamıyorsa o öğeyi roadmap'ten çıkar ya da hipotetik OKR'ı yaz ve ekiple tartış. "Nice to have" olan öğeler kaynak rekabetinde öncelikli işleri geciktirir; roadmap disiplini bu ayrımı net tutmakla başlar.

Roadmap ne kadar ileriye uzanmalı? Erken aşama startuplarda 6 aylık roadmap yeterlidir; daha uzunu genellikle spekülatiftir. Seri A sonrası 12 ay, kurumsal ürünlerde 18 ay ufku tutulmaktadır. Ne kadar uzak bir ufuk seçersen belirsizlik o kadar yüksektir; bunu roadmap'te görsel olarak ifade et.

Müşteri önerilerini roadmap'e nasıl eklemeli? Müşteri taleplerini ham olarak değil sorunu ve etki büyüklüğünü değerlendirerek al. "Kullanıcı X özelliği istedi" değil, "X kullanıcısı şu problemi yaşıyor, kaç kullanıcı benzer problemi raporluyor ve çözmek hangi metriği etkiler" sorusunu yanıtla.

Roadmap değiştikçe müşterilere nasıl kommunike edilir? Değişen her öğeyi ayrıca duyurmaya gerek yok; çeyrek dönem başında bir changelog formatında özetlemek yeterlidir. "Planladığımız X ertelendi, bunun yerine Y önceliklendirdik ve nedeni şu" formatı şeffaflık sağlarken yönetim maliyetini düşürür.