Bu konuyu ilk kez 2017’de yazmıştım. O yazıda kabaca şunu söylüyordum: Product Owner işin business tarafında durur, iş analisti teknik tarafta kalır.
Aradan dokuz yıl geçti. Aynı soruyu bu süre boyunca mülakatlarda, yeni kurulan ekiplerde ve “biz de bir Product Owner alalım” diye başlayan yönetim toplantılarında defalarca duydum. Bugün o cümlenin arkasında duramıyorum. Tümüyle yanlış sayılmaz ama iki rolü ayırt etmek için bakılması gereken yere bakmıyor.
Sınır, masanın hangi tarafında oturduğunuzla ilgili değil. Asıl soru şu: kim neyin hesabını veriyor?
Eski ayrım neden yetersiz kalıyor?
“Product Owner business bilir, iş analisti teknik bilir” ayrımı rolleri tarif etmiyor. O rollere gelen insanların geçmişini tarif ediyor. İş analistlerinin büyük kısmı mühendislikten geliyor. Product Owner’ların önemli bir bölümü ise bir süre iş analistliği yaptıktan sonra bu role geçiyor; kariyerine doğrudan Product Owner olarak başlayanlar da çoğunlukla iş birimlerinden çıkıyor. Ortadaki fark kişisel birikimden ibaret kalıyor.
Ayrım pratikte de kolayca çöküyor. Teknik derinliği yüksek bir Product Owner görürsünüz. İş tarafını herkesten iyi bilen bir iş analisti de görürsünüz. İkisi de sahada bolca var.
O halde sınır nerede çiziliyor?
Sorumlulukta. İşi başkasına devredebilirsiniz, sorumluluğu devredemezsiniz. Kulağa klişe gelen bu cümle iki rolün arasındaki bütün mesafeyi açıklıyor.
Product Owner neyin hesabını verir?
Scrum çerçevesinde Product Owner, ürünün yarattığı değeri en üst düzeye çıkarmaktan sorumlu tek kişidir. Komite değildir. Product Backlog’un içeriği, sıralaması ve herkes tarafından anlaşılır olması da aynı sorumluluğun kapsamına girer.
Buradaki ince nokta çoğu zaman gözden kaçıyor. Product Owner bu işlerin yapılmasını pekâlâ devredebilir. Backlog kalemlerini bir iş analisti yazabilir, refinement toplantılarını başka biri yürütebilir, analiz dokümanını bambaşka bir ekip hazırlayabilir. Sonuçta hesabı veren yine Product Owner olur.
Bir de kimsenin konuşmayı pek sevmediği ikinci şart vardır. Organizasyonun, bu kişinin kararlarına saygı duyması gerekir. Kararı her toplantıda ezilen birinin unvanı Product Owner olabilir, işi Product Owner’lık olmaz.
Backlog’un kendisine dair temelleri daha önce ayrı bir yazıda toplamıştım: Product Backlog Nedir?
Bu ayrımın altı, PSPO II’ye çalışırken iyice doluyor. Sınav, Product Owner’ı “gereksinim yazan kişi” olarak gören cevapları eliyor. Sorular ısrarla değeri kimin ölçtüğünü, kararı kimin verdiğini, hayır deme yetkisinin kime ait olduğunu soruyor. Oradan bakınca 2017’de yazdığım “Product Owner business tarafında durur” cümlesinin neden eksik kaldığı da görülüyor. Mesele hangi tarafta durulduğu değil, sonucun hesabını kimin verdiği.
İş analisti neyin hesabını verir?
Scrum çerçevesinde iş analisti diye tanımlanmış bir rol yok. Ama o iş fazlasıyla var.
Bir ürünün etrafında, Product Owner karar verebilsin diye önce netleşmesi gereken bir yığın şey birikir:
- Mevcut sistem gerçekte nasıl çalışıyor (dokümandaki hâli değil, çalışan hâli)
- Süreçler, aktörler, istisna senaryoları
- Gereksinimlerin izlenebilirliği; hangi ihtiyaç hangi maddeye, hangi maddeye hangi teste bağlanıyor
- Entegrasyon noktaları, veri akışları, bağımlılıklar
- Paydaşlar arasındaki çelişkilerin, karar masasına gelmeden önce ayıklanması
İş analisti bu bilginin doğruluğundan sorumludur. Product Owner ise o bilgiyle alınan kararın sonucundan.
Örnekleyelim. İş analisti “sistem şöyle çalışıyor, bu değişiklik şu üç yeri etkiler” der ve bu tespitin yanlış çıkması onun sorunudur. Product Owner “o halde önce bunu yapıyoruz, şunu erteliyoruz” der. Bu kararın yanlış çıkması da onun sorunudur. İki cümle de aynı toplantıda kurulur, faturaları farklı yerlere gider.
Yan yana
| Product Owner | İş Analisti | |
|---|---|---|
| Sorumluluk | Ürünün yarattığı değer | Bilginin ve gereksinimin doğruluğu |
| Temel çıktı | Sıralanmış backlog, ürün hedefi | Analiz dokümanı, süreç modeli, izlenebilirlik |
| Kritik yetki | Hayır diyebilmek | Öneri sunar, kararı vermez |
| Kime hesap verir | Paydaşlara ve organizasyona | Product Owner’a ve ekibe |
| Başarı ölçüsü | Sonuç: ürün ne getirdi | Kalite: analiz tuttu mu, sürpriz çıktı mı |
| Sayısı | Ürün başına bir kişi | Ürünün büyüklüğüne göre birden fazla |
Sahadaki gerçek: Product Owner şapkalı iş analisti
Şirketlerin çoğunda bu iki rol aynı kişide toplanıyor. İlanda “Product Owner” yazıyor, iş tanımı iş analistliğine denk düşüyor, karar yetkisi ise bambaşka bir yerde duruyor.
Bu her zaman kötü bir şey değil. Küçük ekiplerde, tek ürünlü yapılarda ve domain bilgisinin derin olduğu alanlarda tek kişide toplanması işi hızlandırır. Analiz eden ile karar veren aynı kafa olduğunda aradaki çeviri kaybı da ortadan kalkar.
Asıl sorun, sorumluluk verilip yetki verilmediğinde ortaya çıkıyor. Backlog’u sıralayan kişi sizseniz ama sıralama her hafta üst yönetimden gelen bir müdahaleyle yeniden şekilleniyorsa, ortada Product Owner sorumluluğu değil, backlog’un bakımını üstlenen bir rol vardır. Bu tablo çalışan tarafında da yorucudur. Hesabı sorulan ama kararı sorulmayan bir pozisyon, zamanla hem motivasyonu hem de ürünün tutarlılığını aşındırır.
Bunu anlamanın pratik bir yolu var. En son ne zaman “bunu yapmıyoruz” dediniz ve o karar ayakta kaldı?
2026’da ne değişti?
Gereksinim taslağı çıkarmak, user story yazmak, test senaryosu üretmek. Bunlar artık büyük ölçüde yapay zeka modellerine yaptırılabiliyor ve buradan sıklıkla “iş analistliği bitiyor” sonucu çıkarılıyor. Oysa rutin üretim ortadan kalktıkça geriye her iki rolde de asıl iş kalıyor. Regülasyona tabi bir alanda çalışıyorsanız bunun bir de imza tarafı vardır; bir kararın arkasında adı geçen bir insan olmak zorundadır. İş analistinde yargı, Product Owner’da karar.
Peki hangisi olmalıyım?
Şu soruya verdiğiniz cevap yolu ayırıyor: kararın sonucuyla mı yaşamak istiyorsunuz, doğruluğuyla mı?
Belirsizlik içinde karar vermek, eksik bilgiyle hayır demek ve sonucun faturasını üstlenmek size enerji veriyorsa Product Owner tarafındasınız. Karmaşayı çözmek, kimsenin göremediği bağımlılığı bulmak ve zamanında “burada bir sorun var” diyerek felaketi önlemek tatmin ediyorsa iş analizi tarafındasınız. İkisi de kariyer. Biri diğerinin basamağı değil.
Mülakata gidiyorsanız unvana değil, yetkiye bakın. Sorulacak üç soru var:
- Backlog’un sıralamasına son kararı kim veriyor?
- Bu rolün “hayır” dediği bir örnek verebilir misiniz?
- Ürünün başarısı burada hangi metrikle ölçülüyor?
Üçüne de net cevap geliyorsa gerçek bir Product Owner rolü var demektir. Cevaplar bulanıksa, iş tanımında ne yazarsa yazsın sizden beklenen şey analiz ve koordinasyon olacaktır. Bunu bilerek girmek, altı ay sonra hayal kırıklığı yaşamaktan iyidir.
2017’de yazdığım ilk versiyonu merak edenler için: Product Owner vs. Business Analyst.