Domain Bazlı Product Management Organizasyonu Nasıl Tasarlanır? [1/3]

Büyüyen Bir Pazaryeri Ekosisteminde Product Management Organizasyonunu Nasıl Kurarım? (1/3)

Ürün liderliği mülakat süreçlerinde karşıma sıkça çıkan bir case tipi var: Birden fazla iş kolunu bünyesinde barındıran, büyümekte olan ve “süper app” potansiyeline sahip bir pazaryeri ekosisteminde, ürün organizasyonunun nasıl kurgulanması gerektiği.

Bu gibi case çalışmaları, aslında şirketler için bir çeşit danışmanlık çalışması da sayılabilir. Çünkü şirketler çoğu zaman gerçekten yaşadıkları problemleri, işe alım sürecinin bir parçası olarak adayların önüne koyuyor. Adaydan beklenen ise sadece birkaç saat içinde bir cevap vermek değil; problemi anlamak, analiz etmek, varsayımlar oluşturmak ve kendi deneyimi doğrultusunda uygulanabilir bir çözüm geliştirmek.

Üstelik bu çalışma için günlerce emek harcamanıza rağmen hazırladığınız çıktıyı sunma fırsatı bile bulamayabiliyorsunuz.

Ben de gerçek bir mülakat sürecinde hazırladığım bir case study’yi, hem bu sürecin nasıl ilerlediğine hem de kendi ürün liderliği yaklaşımıma örnek olması açısından yayımlanabilecek şekilde yeniden düzenledim. Her ne kadar açık olmayan herhangi bir bilgi kullanmamış olsam da şirket adını ve şirkete özgü özel isimleri gizledim.

Cevaplarım ve yaklaşımım case study’de çizilen kapsama göredir.

Bu çalışmada gösterdiğim düşünme şekli, gerçek projelerde kullandığım yaklaşımların da bir yansıması. Ancak burada önemli bir ayrım var: Anlattıklarım, gerçek bir şirketin ürün stratejisini veya organizasyon yapısını anlatmıyor. Bir Product Director yaklaşımıyla, case study’de sorulan sorular ve verilen bilgiler doğrultusunda geliştirdiğim kişisel cevapları ve düşünme şeklimi ortaya koyuyor.

Çalışmayı tek bir sayfada gereğinden fazla uzatmamak ve farklı uzmanlık alanlarını birbirinden ayırmak için üç bölüme ayırdım. Bu üç yazılık serinin ilk bölümünde, böyle bir senaryo üzerinden organizasyon tasarımı yaklaşımımı paylaşıyorum. İkinci yazıda product roadmap önceliklendirme ve üst yönetim anlaşmazlıklarını çözme mekanizmasına, üçüncü yazıda ise NSM, OKR ve KPI tasarımına geçeceğim.

Senaryo

Çoklu iş kolu barındıran (uçak/otobüs bileti, konaklama, sigorta, finansal ürünler gibi) büyük bir seyahat pazaryeri ekosistemi düşünelim. Şirket, ürün ekibinin yoğun çalışmasına rağmen ölçülemeyen etki ve performans sorunu, OKR sürecinin işletilmesinde yaşanan sıkıntılar ve paydaş ekiplerle yaşanan önceliklendirme anlaşmazlıkları yaşıyor.

Bir Product Director olarak bu duruma girdiğimde önce şu dört soruyu sorarak analiz ederim:

• Tüm birim ve rollerin görev tanımları ve hedefleri net mi? Görev tanımları ile OKR’lar somut ve erişilebilir mi?
• PM’lerin şirket hedefleri ve stratejisini bildiğinden, bunları destekleyecek doğrultuda çalıştığından emin miyiz?
• Şirket stratejisi ve öncelikler yapısal olarak net ve somut mu?
• Domain ve takım sorumlulukları (ownership) net olarak belirli mi?

Domain-Based Tribe/Squad Yapısı (Hibrit Model)

Böyle bir ekosistemde genelde birbirinden bağımsız birkaç platform/iş kolu bulunur (örneğin ana pazaryeri, finans ürünleri, sigorta ürünleri gibi). Bu yapıda Domain-Based Tribe/Squad modelinin hibrit bir versiyonunu en verimli yöntem olarak görüyorum.

Domain bazlı tribeları oluştururken şu etkenleri değerlendiririm:

• Benzer kullanıcı davranışı (biletleme, rezervasyon gibi benzer iş akışları)
• Ortak veya benzer teknolojik altyapı (benzer ödeme yapısı gibi)
• Cross-sell ilişkisi (örneğin uçak yolculuğu yapan bir kullanıcının ardından araç kiralamak isteyebilmesi)

Süper app potansiyeli taşıyan böyle bir yapıda domain know-how’ı PM’ler için çok kıymetlidir; bağımlılık oluşturmadan uzmanlaşmaya fırsat vermek isterim. Growth sorumluluğunu ayrı bir ekibe değil, her domain’in kendi PM’ine veririm — büyüme, o domain’i en iyi bilen kişinin OKR’ının bir parçası olmalı; core teknik ve platform entegrasyon işlerini ise bu domain PM’lerinden ayrı bir yapıda yürütürüm.

Bu yapı, kendi backlogunu oluşturabilen ve hangi işi yapması gerektiğini bilen PM’lere, birbirine bağımlılığı minimum seviyede olan, kendi kendini yönetebilen takımlara sahip olmayı sağlar.

Bu ilkeleri somut bir organizasyona döktüğümde ortaya şöyle bir yapı çıkıyor:

Ürün Ekibinin Organizasyon İçindeki Konumu ve Çalışma Ritmi

Organizasyon yapısı şirkete özgüdür; bu tür kararları verirken şirketin kültürünü, çalışan profilini, sektörünü ve iş modelini dikkate almak gerekir. Genel prensip olarak PM’i Business ile Product & Tech organizasyonunun merkezine konumlandırırım: PM, üst yönetim ve paydaşların taleplerini toplarken aynı zamanda son kullanıcıyı dinler, acı noktalarını tespit eder ve bunları gelişim projelerine dönüştürür.

Bunu somut bir ritme oturturum:

• Haftalık discovery syncleri: PM, Tech Lead ve UX’in birlikte katıldığı, henüz backlog’a girmemiş fikirlerin tartışıldığı kısa (30-45 dk) bir oturum. Amaç, bir işin geliştirme aşamasına gelmeden önce teknik ve tasarım açısından “sürprizsiz” hale gelmesi.
• Backlog refinement PM liderliğinde ama tek taraflı değil: Refinement PM’in sorumluluğunda yürür, ama Tech ve UX’in erken itiraz/uyarı hakkı vardır — bir iş refinement’tan “teknik olarak belirsiz” ya da “tasarım açısından net değil” etiketiyle çıkamaz.
• Aylık cross-domain senkronizasyon: Farklı domain tribeları arasında cross-sell veya paylaşılan altyapı gerektiren işlerin konuşulduğu, Product Director’ın moderatörlüğünde bir toplantı — domainler arası bağımlılıkların erken görülmesini sağlar.

---

Bu serinin ikinci yazısında roadmap önceliklendirme ve üst yönetim anlaşmazlıklarını çözme mekanizmasını, üçüncü yazısında ise NSM, OKR ve KPI tasarımını ele alıyorum.