Roadmap Hazırlamak: Feature Takvimi Yerine Now-Next-Later ve Outcome Roadmap'leri

Sürüm notu: Bu yazı kavramsaldır; Now-Next-Later için ProdPad'in (Janna Bastow) yazıları, appetite ve betting table için Basecamp'in "Shape Up" (Ryan Singer, 2019) kitabı esas alınmıştır.

Önce Tahmin Et

Kasım 2026. Bookstore'un satış direktörü 2027'nin ilk yarısı için bir roadmap istiyor: "Hangi feature hangi ay çıkacak, bir slayt yeter. Yayınevleriyle yıllık görüşmelerde göstereceğim." Geçen yıl hazırlanan roadmap'e bakınca ekip şunu görüyor: üzerinde ay ay dağıtılmış dokuz feature vardı; üçü söylenen ayda çıktı, dördü bir iki ay kaydı, ikisi hiç yapılmadı çünkü yıl içinde öncelikler değişti.

Bu yıl aynı formatta bir slayt hazırlansa sonuç farklı olur mu? Satış direktörünün gerçekte neye ihtiyacı var: tarihlere mi, yoksa yayınevlerine "bu yıl müşterilerimiz için şunları iyileştireceğiz" diyebilmeye mi? Bir de şunu düşün: geçen yıl yapılmayan iki feature'ın yapılmaması kötü bir şey miydi?

Vision, Strategy, Roadmap, Backlog

Roadmap tek başına anlam taşımaz; bir hiyerarşinin ortasında durur. En üstte product vision vardır: ürünün birkaç yıl içinde müşteri için ne olmak istediği. Bookstore için "okurların aradıkları kitabı en kolay bulup en güvenilir şekilde aldığı yer" gibi bir cümle. Altında strateji gelir: bu vizyona hangi yoldan gidileceği, hangi müşteri segmentine ve hangi probleme öncelik verileceği. "Önümüzdeki yıl ilk kez alışveriş yapan misafir müşterileri sadık müşteriye dönüştürmeye odaklanıyoruz" bir strateji cümlesidir.

Roadmap, stratejinin zaman içinde nasıl ilerleyeceğini gösteren bir iletişim aracıdır: hangi problemler önce, hangileri sonra ele alınacak. En altta backlog durur: ekibin önümüzdeki haftalarda üzerinde çalışacağı somut item'lar. Scrum'da bu Product Backlog'dur; mekaniği Scrum serisinin konusu.

Bu hiyerarşide her seviye bir öncekinden daha somut ve daha kısa ömürlüdür. Vision yıllarca, strateji birkaç çeyrek, roadmap birkaç ay, backlog birkaç hafta yaşar. Sorunların çoğu, roadmap'in backlog kadar somut olmaya zorlanmasından çıkar.

Tarihli Feature Roadmap'in Sorunları

Satış direktörünün istediği format, çoğu şirkette bilinen formattır. Bookstore ekibinin ilk taslağı şöyle:

Bu tablonun üç sorunu var. Birincisi, her satır bir output ve hiçbiri neden yapıldığını söylemiyor; Haziran'da abonelik çıktığında bir şeyin iyileşip iyileşmediğini bu tablodan anlayamazsın. İkincisi, tarihler en az bilgi olan anda verilmiş: Haziran'daki bir feature için Kasım'da tahmin yapmak, 05. yazıdaki Monte Carlo diliyle konuşursak, olasılığı söylenmemiş bir tahmindir ve büyük ihtimalle %50'nin altındadır. Üçüncüsü, tablo bir söz gibi okunur. Yayınevi Haziran'da abonelik bekler; Mart'ta yapılan bir discovery aboneliğin iyi bir fikir olmadığını gösterse bile, ekip söz verildiği için onu inşa eder.

Geçen yılın dokuz feature'ından ikisinin hiç yapılmaması bu açıdan bakınca bir başarısızlık değil, bir öğrenme olabilir. Asıl soru, yapılmamalarının bir karar mı yoksa bir kayma mı olduğu ve bunun paydaşlara nasıl anlatıldığıdır.

Now-Next-Later

Janna Bastow, ProdPad'in kurucu ortağı olarak, Now-Next-Later formatını 2010'ların başında geliştirdiğini anlatır; ilk sürümü 2012'de "Current / Near Term / Future" başlıklarıyla çizilmiş, Now-Next-Later adlarını sonra bir müşterileri önermiş. Fikir basit: tarih kolonları yerine belirsizlik kolonları.

Now, ekibin şu an aktif olarak çalıştığı işlerdir; en yüksek kesinliğe sahiptir ve ayrıntılı, iyi tanımlanmış parçalara bölünmüştür. Next, Now bittikten sonra gelecek işlerdir; daha az kesin, daha az ayrıntılıdır ve Now'dan öğrenilenlere göre değişebilir. Later, ekibin gözden kaçırmak istemediği daha büyük ve daha bulanık problemlerdir; kesinlik en düşüktür ve henüz çözümlere bölünmemiştir.

Bu formatın gücü, belirsizliği gizlememesidir. Tarihli roadmap, Haziran'daki bir feature'ı Ocak'taki kadar kesin gösterir; Now-Next-Later ise Haziran'a ait bir işin henüz bir problem cümlesi olduğunu açıkça söyler.

Outcome Roadmap: Satırlar Problem Olsun

Now-Next-Later'ın kolonları zamanı çözer; satırların ne olacağı ise ayrı bir karardır. Bir outcome roadmap'te her satır bir feature değil, bir problem ya da bir outcome'dur. Bookstore'un 2027 ilk yarısı için ikinci taslağı:

Bu tabloda ilk taslağın bütün feature'ları hâlâ var: guest checkout Now'da, kayıtlı kart ve öneriler Next'in aday çözümlerinde, mobil uygulama ve abonelik Later'da. Fark, her birinin bir problemin altında, aday çözüm olarak durması. Mobil uygulama artık bir söz değil, "mobilde alışveriş deneyimi" probleminin olası çözümlerinden biri; discovery daha iyi bir mobil web'in yeterli olduğunu gösterirse roadmap değişmez, yalnız aday çözüm listesi değişir.

Ödeme SDK'sı satırı bilinçli olarak bir outcome değil, bir zorunluluk. Outcome roadmap tarihi sabit işleri yok saymaz; onları açıkça işaretler. Önceki yazıda CD3'ün (Cost of Delay Divided by Duration) bu işi neden en üste koyduğunu görmüştük.

Stakeholder'a Nasıl Anlatılır?

Satış direktörü bu tabloyu görünce ilk olarak "peki ne zaman?" diye soracak. Bu soru meşrudur ve cevapsız bırakılmamalı. Üç ilke işe yarar.

Birincisi güven aralığı vermek. Now'daki işler için tarih verilebilir, ama olasılıkla: Kanban serisinin Monte Carlo yazısındaki gibi "guest checkout'un %85 olasılıkla Şubat sonuna kadar çıkacağını öngörüyoruz." Next için çeyrek düzeyinde bir aralık, Later için hiç tarih vermemek dürüst olandır.

İkincisi Later'ın bir söz olmadığını açıkça söylemek. Roadmap'in altına tek bir cümle yeter: "Now kolonundaki işler taahhüttür; Next ve Later, bugünkü bilgimizle önceliklerimizi gösterir ve öğrendikçe değişir." Yayınevine gösterilecek bir slayt bu cümleyi taşımalıdır.

Üçüncüsü roadmap ile release planını ayırmak. Roadmap hangi problemlerin hangi sırayla ele alınacağını anlatır; release planı ise belirli bir sürümün hangi tarihte, hangi içerikle çıkacağını. Satış direktörünün 27 Kasım kampanyası gibi sabit tarihli bir ihtiyacı varsa, bu ihtiyaç bir release planıyla karşılanır. Sürüm numaralandırma ve release süreçleri ilerideki Versioning ve Release Management serisinin konusu.

Shape Up: Appetite ve Betting Table

Roadmap'e tamamen farklı bir açıdan bakan bir yöntem daha var: Basecamp'in Ryan Singer tarafından yazılan "Shape Up" kitabı. Shape Up "bu iş ne kadar sürer?" diye sormaz; "bu işe ne kadar zaman harcamaya razıyız?" diye sorar. Buna appetite denir. Appetite bir tahmin değil, bir bütçedir: "Guest checkout'a altı haftalık bir appetite'ımız var" demek, altı haftada çıkabilecek en iyi guest checkout'u şekillendirmek demektir; kapsam süreye uyar, süre kapsama değil.

Shape Up'ta çalışma altı haftalık cycle'lar ve aralarındaki iki haftalık cool-down dönemleriyle ilerler. Her cycle'dan önce bir betting table toplanır: şekillendirilmiş (shaped) teklifler masaya konur ve hangisine bir sonraki cycle'da "bahis" yapılacağına karar verilir. Bahis yapılmayan teklif bir sonraki cycle'a otomatik olarak devretmez; önemliyse yeniden gündeme gelir. Bir iş cycle sonunda bitmezse varsayılan olarak uzatılmaz, bu kitabın deyişiyle bir circuit breaker'dır.

Shape Up her ekibe uymaz ve Scrum ya da Kanban'la birebir eşleşmez. Ama iki fikri her roadmap için değerlidir. Appetite, "bu ne kadar sürer?" tartışmasını "bu bize ne kadar değer?" sorusuna çevirir. Backlog'u biriktirmemek, yani bahis yapılmayan fikirleri bir sonraki döneme otomatik taşımamak, roadmap'in her dönem bayat fikirlerle şişmesini engeller.

Üretimde Dikkat

Roadmap'i bir doküman değil, bir ritim olarak yönet. Now-Next-Later tablosu ayda bir ya da her çeyreğin başında gözden geçirilmeli: Now'dan bitenler çıkar, Next'ten bir satır Now'a geçer, Later'dan biri Next'e. Her güncellemede neyin neden değiştiğini bir iki cümleyle not et; paydaşlar değişikliğin kendisinden çok, açıklanmamış değişikliğe tepki verir.

Roadmap'in versiyonlarını sakla. Satış direktörüne Kasım'da gösterilen roadmap ile Mart'taki arasındaki fark, ekibin neyi öğrendiğinin kaydıdır. "Mobil uygulamayı Later'dan çıkardık, çünkü discovery'de mobil kullanıcıların %80'inin web'den alışverişten memnun olduğunu gördük" cümlesi, bir feature'ın yapılmamasını bir başarısızlıktan bir karara çevirir.

Ekip roadmap'ten habersiz kalmasın. Geliştiriciler roadmap'i yalnız kendilerine gelen backlog item'larından görürse, Later'daki büyük bir değişikliğin (mobil, abonelik) bugünkü mimari kararlarını nasıl etkileyeceğini bilemezler. Roadmap'i Sprint Review'da ya da aylık bir toplantıda ekiple birlikte okumak, feasibility sorularını erken getirir.

Sık Düşülen Tuzaklar

İlk tuzak Now-Next-Later'ı tarih tablosuna geri çevirmek. "Now = Ocak, Next = Şubat-Mart, Later = Nisan-Haziran" diye eşleştirilen bir tablo, kolon adlarını değiştirmiş bir tarihli roadmap'tir.

İkinci tuzak Later kolonunu söz gibi sunmak. Yayınevine gösterilen slaytta "Later: Abonelik" yazıyorsa ve altında hiçbir uyarı yoksa, yayınevi aboneliği bekleyecektir. Later'daki satırları problem olarak yazmak bu riski azaltır.

Üçüncüsü roadmap'i backlog gibi ayrıntılandırmak. Roadmap'te story seviyesinde item görüyorsan, iki farklı aracı birbirine karıştırmışsındır. Roadmap problemleri ve sırayı, backlog ise işin kendisini taşır.

Dördüncüsü teknik işi roadmap'ten çıkarmak. Ödeme SDK'sı gibi zorunluluklar roadmap'te görünmezse, paydaşlar ekibin kapasitesinin neden azaldığını anlayamaz. Görünür kılmak, onları açıklamaktan daha kolaydır.

Küçük Bir Deneme

★☆☆ Ekibinin son roadmap'ini aç ve her satırın bir output mu yoksa bir outcome mu olduğunu işaretle. Output olan bir satırı, arkasındaki problemle yeniden yaz.

★★☆ Ürünün için bir Now-Next-Later tablosu hazırla: her kolonda en fazla üç satır, her satırda bir outcome, bir ölçü ve aday çözümler. Now'daki satırlardan biri için %85 olasılıklı bir tarih vermek için hangi veriye ihtiyacın var?

★★★ Önümüzdeki dönemin en büyük işi için bir appetite belirle: "buna en fazla şu kadar hafta harcamaya razıyız." Sonra o süreye sığacak en küçük çözümü bir sayfada şekillendir. Neyi bilinçli olarak dışarıda bıraktın?

Roadmap'teki her satır bir outcome ve bir ölçü taşıyor. Bir sonraki yazıda bu ölçülerin kendisine odaklanacağız: North Star metric'i, HEART (Happiness, Engagement, Adoption, Retention, Task success) framework'ünü, AARRR'ı (Acquisition, Activation, Retention, Referral, Revenue) ve Bookstore için bir metric ağacını, guardrail metric'leriyle birlikte kuracağız.