Product Management Nedir? Product Manager, Product Owner ve Project Manager Farkı

Sürüm notu: Bu yazı kavramsaldır; rol tanımları için Scrum Guide 2020 ve Marty Cagan'ın SVPG (Silicon Valley Product Group) yazıları (özellikle "The Four Big Risks", 2017) esas alınmıştır.

Önce Tahmin Et

Pazartesi sabahı Bookstore'un satış direktörü ekibe bir e-posta gönderiyor: "Kasım'daki kampanya dönemi için bir kampanya modülü yapın. Admin panelden kupon tanımlayabilelim, sepette indirim uygulansın, ana sayfada banner çıksın. 27 Kasım'a yetişmesi lazım."

Bu e-postayı üç kişi okuyor. Product Owner, Product Backlog'a "Kampanya modülü" diye bir epic ekleyip ekibe ne kadar süreceğini soruyor. Proje yöneticisi bir Gantt şeması açıp 27 Kasım'dan geriye doğru görev listesi çıkarıyor. Product Manager ise satış direktörüne bir soru soruyor: "Kampanyayla neyi değiştirmek istiyoruz? Geçen yılki kampanyada en çok neyi kaçırdık?"

Üçünden hangisi doğru davrandı? Peki sen, bu talebi geliştirecek .NET geliştiricisi olarak, hangi sorunun cevabını bilmeden kod yazmaya başlamamalısın? Bir de şunu düşün: geçen yıl yapılan kupon sisteminin kaç kişi tarafından kullanıldığını ekipte bilen var mı?

Product mı, Project mi?

İki kelime birbirine çok benzediği için sürekli karışır, ama yönetilen şey farklıdır. Project (proje), başı ve sonu olan, belirli bir kapsamı belirli bir tarihte ve bütçede teslim etmeye çalışan bir iştir. "Kampanya modülünü 27 Kasım'a kadar canlıya almak" bir projedir; 27 Kasım'da biter.

Product (ürün) ise bir müşteri grubuna sürekli value üreten şeydir ve bitmez. Bookstore'un online mağazası bir üründür; kampanya modülü o ürünün bir parçası olur, ama ürün 28 Kasım'da da yaşamaya devam eder. Kampanya modülü canlıya çıktı diye ürünün sorunu çözülmüş olmaz; asıl soru, modülün müşterinin ve şirketin bir sorununu çözüp çözmediğidir.

Bu ayrım geliştiriciyi doğrudan etkiler. Proje bakışında başarı "zamanında ve kapsamda teslim etmek"tir; ürün bakışında başarı "teslim ettiğin şeyin bir şeyi değiştirmesi"dir. Proje bakışıyla yazılan kod 27 Kasım'da tamamlanmış sayılır. Ürün bakışıyla yazılan kod için 27 Kasım bir başlangıçtır: kupon kullanım oranı, kampanyalı siparişlerin sepet büyüklüğü, kampanya sonrası müşterilerin geri dönüp dönmediği ölçülür ve modül buna göre değiştirilir ya da kaldırılır.

Üç Rol: Product Manager, Product Owner, Project Manager

Üç rolün adı kısaltılınca ikisi aynı kalıyor: ikisinin kısaltması da PM (Product Manager ya da Project Manager) oluyor ve bu karışıklığı büyütüyor. Bu yazıda kısaltma kullanmayacağız. Farkları bir tabloda toplayalım:

Scrum Guide 2020'ye göre Product Owner, Scrum Team'in çalışmasından ortaya çıkan ürünün value'sunu en üst düzeye çıkarmaktan sorumludur; bir komite değil, tek bir kişidir ve Product Backlog'u etkili biçimde yönetmekle sorumludur. Guide, Product Owner'ın bir iş unvanı olduğunu söylemez; bir accountability tarif eder. Pratikte bu accountability'yi çoğu şirkette ya Product Manager unvanlı biri üstlenir ya da işi yalnızca backlog'u yazmak olan, ürün kararlarına katılmayan biri. İkincisi Scrum serisinin Scrum Team ve accountability'ler yazısında anlatılan "proxy Product Owner" sorununa çok yakındır. Product Backlog'un mekaniği de aynı serinin üçüncü yazısının konusu; bu seri oraya girmiyor.

Proje yöneticisi ise başka bir dünyadan gelir: PMBOK gibi standartların tarif ettiği, kapsam, zaman, maliyet ve riski yöneten bir rol. Bir ürün ekibinde proje yöneticisi olmayabilir; olduğunda da genellikle birden fazla ekibin ya da bir dış tedarikçinin dahil olduğu, tarihi sabit işlerde bağımlılıkları koordine eder. Kampanya modülü gibi bir işte proje yöneticisi faydalıdır: pazarlama, tasarım ve ödeme sağlayıcısıyla koordinasyon gerçek bir iştir. Ama "kampanyayla neyi değiştirmek istiyoruz?" sorusu onun sorusu değildir.

Cagan'ın Dört Riski

Marty Cagan, SVPG'deki 2017 tarihli "The Four Big Risks" yazısında bir ürün fikrinin dört farklı sebeple başarısız olabileceğini söyler. Value riski: müşteri bunu satın alacak ya da kullanmayı seçecek mi? Usability riski: kullanıcı bunu nasıl kullanacağını anlayabilecek mi? Feasibility riski: mühendisler bunu elimizdeki zaman, beceri ve teknolojiyle inşa edebilir mi? Business viability riski: bu çözüm satış, hukuk, finans, marka gibi işin diğer parçaları için de işe yarıyor mu?

Cagan bu risklerin sahiplerini de ayırır: value ve business viability riski product manager'ın, usability riski product designer'ın, feasibility riski ise tech lead'in, yani ekipteki kıdemli mühendisin sorumluluğudur. Bu son madde senin için önemli. Feasibility, "bunu yapabilir miyiz?" sorusundan daha fazlasıdır: "bunu 27 Kasım'a, mevcut sipariş akışını bozmadan, kampanya günündeki trafiği kaldıracak şekilde yapabilir miyiz?" sorusudur ve bu soruya ekipte en iyi cevabı verebilecek kişi kodu bilen kişidir.

Kampanya modülüne dört riskin gözüyle bakalım. Value: geçen yılın kupon sistemini kaç müşteri kullandı? Kuponlu siparişler kuponsuz siparişlerden büyük müydü, yoksa zaten alışveriş yapacak müşterilere indirim mi verdik? Usability: kupon kodu sepette mi girilecek, ödeme adımında mı? Feasibility: sepette indirim hesabı mevcut OrderPricing akışının neresine girecek; kampanya günü ana sayfa trafiği üç katına çıkarsa banner'ı hangi cache stratejisiyle servis edeceğiz? Viability: kuponların muhasebede nasıl kaydedileceği, yayınevleriyle anlaşmalara uyup uymadığı. Bu soruların hiçbiri e-postada yok ve her biri modülün şeklini değiştirebilir.

Feature Factory ve Empowered Product Team

Baştaki e-postaya tipik bir cevap şöyledir: Product Owner epic'i açar, ekip story'lere böler, Sprint'lere yayar, modül 27 Kasım'da canlıya çıkar, ekip bir sonraki talebe geçer. Kimse kampanyanın bir şeyi değiştirip değiştirmediğine bakmaz. John Cutler'ın 2016'da popülerleştirdiği adla bu bir feature factory'dir: başarının teslim edilen feature sayısıyla ölçüldüğü, sonuçların ölçülmediği ve ekibin "ne" sorusuna hiç katılmadığı bir çalışma biçimi.

Cagan'ın karşı modeli empowered product team'dir: ekibe çözülecek bir problem ve ulaşılacak bir outcome verilir, çözümü ekip (product manager, designer ve mühendisler birlikte) bulur. Bookstore örneğinde bu, ekibe "kampanya modülü yap" yerine "Kasım kampanyasında yeni müşteri kazanımını geçen yıla göre artır, kampanya sonrası 60 günde ikinci siparişi verenlerin oranını düşürmeden" demek olurdu. Belki çözüm bir kupon modülü olur. Belki ücretsiz kargo eşiğini düşürmek daha etkili ve yapması çok daha ucuz bir çözümdür. Bunu bilmek için problemi anlamak gerekir; bu da serinin geri kalanının konusu.

Empowered olmak "ekip ne isterse onu yapar" demek değildir. Şirketin stratejisi, ürün vizyonu ve hedefleri çerçeveyi çizer; ekip bu çerçevenin içinde problemi çözmekten sorumludur. Satış direktörünün 27 Kasım tarihi gerçek bir kısıttır ve ekibin bunu yok sayma lüksü yok. Empowered bir ekipte değişen şey, o tarihe neyin yetişeceğine kimin, hangi bilgiyle karar verdiğidir.

Geliştiricinin Yeri

Bu seri geliştiriciler için yazıldı, çünkü ürün kararları yalnız product manager'ların kararı değildir. Geliştirici üç yerde vazgeçilmezdir.

Birincisi feasibility. Bir fikrin maliyetini ve riskini en iyi bilen kişi sensin. "Bu iki hafta" ile "bu iki hafta, ama sipariş tablosunda migration gerektiriyor ve kampanya haftasında deploy dondurulacak" arasındaki fark, ürün kararını değiştirir. Cagan'ın tavsiyesi, mühendislerin fikirlerin ilk tartışıldığı yerde, yani discovery sırasında bulunmasıdır; teslim aşamasında değil.

İkincisi veri. Ürün kararlarının çoğu "kaç kişi bunu kullanıyor?" sorusuna dayanır ve bu sorunun cevabı genellikle senin yazdığın kodun log'larında, veritabanında ya da event'lerinde durur. Bu serinin 07. yazısında product metric'lerini Angular ve ASP.NET Core ile kendimiz ölçeceğiz.

Üçüncüsü fikir. Teknolojinin bugün neyi mümkün kıldığını en iyi mühendisler bilir. Cagan, en iyi ürün fikirlerinin bir kısmının mühendislerden geldiğini sık sık vurgular. "Kargo ücretini ürün sayfasında göstermek için kargo firmasının API'sinden (Application Programming Interface) önceden hesaplanmış bir tablo çekebiliriz" cümlesi, ürün ekibinin aklına gelmemiş bir çözümü masaya koyabilir.

Üretimde Dikkat

Ürün bakışı teslimden sonra başlar. Kampanya modülü canlıya çıktığında, kullanım verisini toplayacak altyapı da hazır olmalı; "önce yapalım, ölçmeyi sonra düşünürüz" denen her feature, ölçülmeden unutulur. Teslim tanımına (Scrum'daki Definition of Done'a) "ilgili event'ler production'da toplanıyor" maddesini eklemek, ekibi ürün bakışına zorlamanın basit bir yoludur.

Rollerin kâğıt üstündeki tanımına değil, kararların gerçekte nerede verildiğine bak. Ekibinde "Product Owner" unvanlı biri olabilir, ama Product Backlog'un sırası her hafta bir yöneticinin e-postasıyla değişiyorsa, ürün kararı gerçekte o yöneticidedir. Bunu görmek, kiminle konuşman gerektiğini söyler.

Kampanya gibi tarihi sabit işlerde, kapsamı tarihe göre esnet; tarihi kapsama göre değil. "27 Kasım'a ne yetişirse kampanya onunla çıkar" bir product kararıdır ve bunu erken konuşmak, son hafta mesaiyle kurtarmaya çalışmaktan iyidir.

Sık Düşülen Tuzaklar

Geliştirici için en yaygın tuzak "bana ticket gelsin, ben yapayım" pozisyonuna çekilmek. Bu pozisyon rahattır: kararın sorumluluğu başkasındadır, iş tanımı nettir. Ama bedeli ağırdır. Yanlış problemi çözen bir feature'ı en iyi şekilde kodlamak, onu hiç kodlamamaktan daha pahalıdır; hem yazılma maliyeti hem de yıllarca bakım maliyeti vardır. "Bu feature hangi problemi çözüyor, bunu nasıl ölçeceğiz?" sorusunu sormak, senior bir geliştiricinin işinin parçasıdır.

İkinci tuzak Product Owner'ı backlog yazıcısı sanmak. Scrum Guide Product Owner'a ürünün value'sundan sorumlu olma görevini verir; story yazmak bunun yalnız küçük bir parçasıdır ve Developers'a da devredilebilir.

Üçüncüsü product manager'ı "mini CEO (Chief Executive Officer)" sanmak. Product manager kimsenin yöneticisi değildir ve kararlarını otoriteyle değil, veriyle ve ikna ile alır. Ekip ona rapor vermez; onunla birlikte çalışır.

Dördüncüsü üç rolü birbirinin alternatifi sanmak. Büyük bir organizasyonda üçü aynı anda bulunabilir ve farklı sorulara cevap verir. Küçük bir şirkette tek kişi üç şapkayı birden takabilir; o zaman hangi şapkayla konuştuğunu bilmek önemlidir.

Küçük Bir Deneme

★☆☆ Son üç ayda ekibine gelen en büyük talebi bul. Talep bir çözüm mü tarif ediyordu ("kampanya modülü yapın") yoksa bir problem mi ("Kasım'da yeni müşteri kazanımı düşüyor")? Talebin arkasındaki problemi bir cümleyle yaz.

★★☆ Ekibinin son teslim ettiği feature için Cagan'ın dört riskini tek tek yaz. Hangisi teslimden önce gerçekten test edildi, hangisi edilmedi? Feasibility riskini kim, ne zaman değerlendirdi?

★★★ Ürününde son bir yılda yapılmış üç feature seç ve her biri için kullanım verisini bul (event, log, veritabanı sorgusu). Kaç tanesinin kullanımını ölçebildin? Ölçemediklerin için hangi verinin eksik olduğunu yaz.

Ekibe "kampanya modülü" yerine bir problem ve bir outcome verilmesi gerektiğini söyledik. Bir sonraki yazıda bunu nasıl yapacağımızı konuşacağız: output ile outcome arasındaki farkı, iyi bir problem tanımını, hipotez formatını ve Jobs to Be Done fikrini Bookstore'un sepet terk problemi üzerinden açacağız.