Product Director Yaklaşımıyla: 3 Katmanlı Roadmap Karar Modeli [Case Study]

Üst Yönetimdeki Roadmap Anlaşmazlıklarını Nasıl Çözerim (2/3)

Bu, büyüyen bir pazaryeri ekosisteminde ürün liderliği üzerine hazırladığım üç yazılık case study serisinin ikinci bölümü. İlk bölümde, Product Director Yaklaşımıyla, Çok Ürünlü Bir Şirkette Organizasyon Nasıl Tasarlanır? yazısında organizasyon tasarımı ve çalışma ritmini ele almıştım. Bu yazıda roadmap önceliklendirme ve üst yönetim anlaşmazlıklarını çözme mekanizmasına odaklanıyorum. Üçüncü yazıda ise NSM, OKR ve KPI’ın birbirine nasıl bağlandığına geçeceğim.

Problem: Herkes Haklı, Kaynak Tek

Böyle organizasyonlarda genelde birbiriyle gerilim yaratan birkaç üst düzey hedef bir arada bulunur — örneğin mevcut işten büyüme, yeni bir alana yatırım ve altyapının sürdürülebilirliği gibi. Roadmap’i kurarken bu hedeflerin hepsinin bir arada nasıl temsil edileceğini netleştirmek gerekir.

Bir Product Director’ın en önemli görevlerinden biri, roadmap belirleme sürecinde üst yönetimde yaşanan anlaşmazlıkları gidermektir. Roadmap oluştururken her iş birimi ve iç müşteri için belirli oran ve kapasitede iş almaya çalışırım. Yaklaşımım şudur: “Bu çeyrek sizin taleplerinizden hiç iş alamıyoruz” demek yerine, “İlettiğiniz 10 talepten bu çeyrek 2 tanesini alabiliyoruz, diğerlerini bir sonraki çeyreğe planlayabiliriz” diyebilmeyi tercih ederim.

3 Katmanlı Roadmap Karar Modeli

RICE ve MoSCoW gibi klasik çerçeveler tek başına yetersiz kalır — çünkü ikisi de “hangi iş daha değerli” sorusuna cevap verir ama “şirketin birden fazla, birbiriyle gerilim yaratan üst düzey hedefi varken kaynağı nasıl paylaştırırım” sorusuna cevap vermez. Bunun için kullandığım modele 3 Katmanlı Roadmap Karar Modeli diyorum:

Katman 1 — Stratejik Uygunluk Filtresi (eleme): Her iş önerisi, şirketin o dönem için belirlediği üst düzey hedeflerden (örneğin: mevcut işten büyüme, yeni alana yatırım, altyapı sürdürülebilirliği) en az birine açıkça bağlanmalı. Bağlanamayan işler roadmap’e girmeden bu aşamada elenir — tartışma burada biter, çünkü kriter nettir.

Katman 2 — Ticari Etki Skoru (sıralama): Filtreden geçen işler için basit bir puanlama yaparım:

Etki Skoru = (Beklenen Gelir Etkisi + Önlenen Kayıp/Risk) ÷ (Geliştirme Maliyeti × Gecikme Maliyeti Çarpanı)

Buradaki fark RICE’tan şu: “Reach” ve “Confidence” gibi göreceli, tartışmaya açık puanlar yerine, mümkün olduğunca gerçek ticari veriyle (tahmini gelir, mevcut kayıp oranı, geliştirme sprint maliyeti) çalışırım. Sayı tam kesin olmasa da, tartışmayı “kimin fikri daha iyi” düzleminden “hangi varsayım daha savunulabilir” düzlemine taşır — ki bu, CEO/CTO/CMO arasındaki anlaşmazlıkları çözen asıl şey.

Katman 3 — Kapasite Tahsisi (dengeleme): Dönem başında, üst düzey hedeflerin her birine roadmap kapasitesinden bir bant ayırırım (örneğin büyüme %50, yeni alan %30, sürdürülebilirlik %20 gibi — oranlar şirketin o dönemki önceliklerine göre üst yönetimle birlikte belirlenir). Katman 2’deki sıralama, bu bantlar içinde uygulanır. Böylece hiçbir hedef tamamen göz ardı edilmez, ama her hedefin içinde de en yüksek etkili işler önce yapılır.

Bu üç katman, roadmap tartışmalarını “kim daha yüksek sesle konuşuyor” değil, “hangi filtreden geçti, hangi skoru aldı, hangi bantta yer buldu” sorularına indirger — ve bu, üst yönetim toplantılarında anlaşmazlığı büyük ölçüde ortadan kaldırır.

Önemli bir not: karar ne olursa olsun, roadmap’teki farklı önceliklerin bir kısmını tamamen feda etmek yerine, hepsini aynı roadmap içinde belirli oranlarla bir arada sağlayacak bir denge kurmayı tercih ederim.

Stakeholder Anlaşmazlığında Son Söz Kimin?

Skorlama modeli çoğu anlaşmazlığı çözse de, üst düzey hedeflerin kendi arasındaki önceliklendirmede (örneğin büyüme mi altyapı mı daha önemli) CEO/CTO/CMO gerçekten anlaşamayabilir. Bu durumda net bir karar mekanizması olmadan Product Director sürekli arabuluculuk yapmak zorunda kalır ve karar sürünür. Ben şu yapıyı kurarım:

• Karar sahibi netleştirilir: Her üst düzey hedef bandı için tek bir karar sahibi tanımlanır — genelde CEO, ama teknik borç bandı için CTO’nun görüşü ağırlıklı sayılır. Bu, dönem başında yazılı olarak netleştirilir, tartışma anında değil.
• Veri masaya önceden gelir: Toplantıya “ne düşünüyoruz” ile değil, Katman 2’deki skorlarla ve varsayımlarla gelinir. Tartışma fikir bazında değil, varsayım bazında yapılır — bu duygusal çatışmayı azaltır.
• Karar kayıt altına alınır ve geri dönülmez: Alınan karar yazılı olarak paylaşılır ve dönem içinde tekrar açılmaz; yeni bilgi çıkmadıkça revize edilmez.

North Star Metric ve OKR/KPI Zincirine Dair Not

Roadmap kapasitesini bu şekilde dengeledikten sonra, her PM ve ekip için bu hedeflere bağlanan OKR/KPI yapısını nasıl kurduğumu ayrı bir yazıda ele alıyorum — bu, roadmap kararlarının günlük ölçülebilir hedeflere nasıl indiği kısmı.

Örnek Gerilim: Lansman Baskısı ve Altyapı Hazırlığı

Böyle organizasyonlarda sık karşılaşılan bir gerilim şudur: teknik ekip bir özelliği çıkarmadan önce altyapı/teknik borç çalışması yapılması gerektiğini savunurken, ticari tarafta bir an önce piyasaya çıkma baskısı vardır. Bu tür durumları roadmap önceliklendirme yaklaşımıma paralel şekilde yönetirim: özelliğin en küçük, teknik riski minimize edilmiş bir versiyonunu (MVP) tanımlar, kapsam dışı bırakılan teknik iyileştirmeleri ise ayrı ve takip edilebilir bir plana yayarım.

Canlıya Alma Sonrası İzleme

Bir ürün canlıya alındığında dashboard’da yalnızca teknik sağlık (uptime gibi) değil, ticari etkiyi gösteren metrikleri de birlikte izlerim: işlemin uçtan uca başarı oranı, kullanıcı davranışındaki değişimler ve bir teknik aksaklığın (gecikme, hata oranı artışı gibi) ticari sonuca (dönüşüm oranı düşüşü, gelir kaybı gibi) ne hızda yansıdığını gösterecek korelasyon metrikleri.

Bu Yapıya Nasıl Geçilir? (Uygulama ve Değişim Yönetimi)

Buraya kadar anlatılanların hepsi “hedef durum”. Ama gerçek zorluk genelde mevcut, farklı şekilde çalışan bir organizasyonu bu yapıya taşımakta ortaya çıkar. Bunu tek seferde, tüm ekipte aynı anda yapmam:

• Önce bir pilot domain seçerim. En çok acı çeken veya en net sınırlara sahip bir domain’de yapıyı önce orada kurar, 1-2 dönem içinde roadmap modelinin gerçekten çalıştığını gösteririm.
• Ölçülebilir bir “önce/sonra” göstergesi belirlerim. Pilot domain’de somut bir gösterge izlerim — bu, geri kalan organizasyonu ikna etmek için “böyle olacak” değil, “işte oldu” demeyi sağlar.
• Direnç noktalarını önceden haritalarım. Bunları rollout öncesi tek tek konuşurum, rollout sırasında sürpriz olarak çıkmasına izin vermem.
• Geçiş takvimini üst yönetimle birlikte, aşamalı olarak paylaşırım.

Kapanış

Yukarıdaki üç katmanlı roadmap modeli ve organizasyon tasarımı, bir noktada birbirinden bağımsız araçlar gibi görünse de aslında tek bir prensibe dayanıyor: karar mekanizmalarını, kişilerin insiyatifinden bağımsız, tekrarlanabilir hale getirmek. Bir organizasyonun büyüme acısı genelde “yanlış insanlar” değil, “her seferinde yeniden icat edilen kararlar” yüzünden ortaya çıkar.

Serinin üçüncü yazısında bu roadmap kararlarının, NSM-OKR-KPI zinciri üzerinden günlük hedeflere nasıl indiğini ele alıyorum.

---

Bu yazı, ürün liderliği mülakat süreçlerinde sık karşılaşılan bir case tipini ve buna yaklaşımımı paylaşmak amacıyla yazılmıştır.