Önce iki kelime: proje ve ürün
Üç rolü karıştırmanın kökünde çoğu zaman iki kelimenin karışması yatar. Proje bitiş tarihiyle tanımlanır; başlar, teslim edilir ve biter. Ürün ise birden çok müşterinin problemini çözer ve yaşar; doğar, gelişir, değişir ve bir gün bilinçli olarak kapatılır. Tek bir müşteri için özel geliştirilen çözüm, adı ne konursa konsun, bir projedir.
Bu ayrım bir dil inceliği değildir. Proje teslim edildiği gün biter; ürün ise teslim edildiği gün yaşamaya başlar. Proje yöneticisi bitişi yönetir, ürün yöneticisi yaşamı. Kavramın kendisi için ürün yönetimi nedir sayfasına bakabilirsiniz.
Yan yana
| Ürün yöneticisi | Product owner | Proje yöneticisi | |
|---|---|---|---|
| Temel soru | Neyi, kimin için, neden yapıyoruz? | Ekip şu an en değerli işi mi yapıyor? | İşi zamanında, bütçesinde, kapsamında teslim ediyor muyuz? |
| Ölçtüğü başarı | Müşteride yaratılan değer ve iş sonucu: kullanım, elde tutma, gelir, memnuniyet | Ekibin çıktısının değeri ve ürün hedefine ilerleme | Zaman, bütçe, kapsam ve kalite |
| Zaman ufku | Ürünün yaşam döngüsü; yıllar | Sprintler ve ürün hedefi; haftalar ve aylar | Projenin başlangıcından bitişine |
| Karar hakları | Neyin yapılacağı ve yapılmayacağı; kime hizmet edileceği, öncelik ve kapsam | Ürün iş listesinin içeriği ve sırası | Plan, takvim, kaynak dağılımı, risk ve bağımlılıklar |
| Tipik çıktı | Persona, problem ve temas anları, Fayda/Zorluk Matrisi, MVP hipotezi, yol haritası | Önceliklendirilmiş iş listesi, kullanıcı hikâyeleri, kabul kriterleri | Proje planı, iş kırılımı, risk kaydı, durum raporu, teslim |
Tabloyu okumanın kısa yolu şu: ürün yöneticisi neden ve ne sorusunun, product owner hangi sırayla sorusunun, proje yöneticisi ne zaman ve nasıl sorusunun sahibidir. Gerçek hayatta sınırlar bu kadar keskin değildir; ama her rolün asıl hesap verdiği soru bellidir.
Aynı talep, üç farklı soru
Kurumsal bir müşteri, ürüne yeni bir raporlama ekranı eklenmesini istiyor. Üç rol aynı talebe üç farklı soruyla yaklaşır:
- Proje yöneticisi: Ne zamana yetişmeli, kimler çalışacak, hangi işlerle çakışıyor, bütçesi ne?
- Product owner: İş listesinde nereye girer, kabul kriterleri neler, bu sprintin hedefiyle uyumlu mu?
- Ürün yöneticisi: Bu ekran hangi problemi çözüyor? Aynı problemi yaşayan başka müşteriler var mı? Bunu yaparsak neyi yapmaktan vazgeçiyoruz? Yoksa bu, tek bir müşteri için yapılacak bir proje mi?
Üç soru da meşrudur; ama sıraları önemlidir. Ürün yöneticisinin sorusu cevaplanmadan proje yöneticisinin sorusuna geçilirse, kurum yanlış şeyi çok verimli biçimde teslim eder. Ürün yöneticisinin cevabı “bu bir proje” de olabilir; bu da meşru bir karardır. Önemli olan, kararın bilinçli verilmesi ve projenin ürünün yol haritasına sessizce sızmamasıdır.
Product owner: unvandan önce bir Scrum rolü
Product owner, Scrum çerçevesinde tanımlı bir roldür. Scrum Rehberi’ne göre ekibin çalışmasından doğan ürün değerini en üst düzeye çıkarmaktan ve ürün iş listesinin (product backlog) etkin yönetiminden hesap verir; bu rol bir komite değil, tek bir kişidir.
Ürün yöneticisi ise bir çerçeveye bağlı değildir; bir iş rolüdür. Scrum kullanmayan bir kurumda da ürün yöneticisi vardır. Pratikte iki model görürüz:
- Aynı kişi, iki şapka. Küçük ekiplerde ve tek ürünlü yapılarda ürün yöneticisi aynı zamanda product owner’dır. Sağlıklıdır; yeter ki strateji ve keşif zamanı teslimat baskısına kurban edilmesin.
- İki kişi, bir hedef. Büyük yapılarda ürün yöneticisi strateji, pazar ve keşfe; product owner bir ya da birkaç ekibin iş listesine odaklanır. Sağlıklıdır; yeter ki product owner bir “iş listesi sekreterine” dönüşmesin: müşteriyle hiç konuşmayan, yalnızca iş kalemi yazan biri.
Unvan ile rol arasındaki bu fark iş ilanlarında da kafa karıştırır: “product owner” başlıklı bir ilan ürün stratejisi isteyebilir, “ürün yöneticisi” başlıklı bir ilan ise yalnızca iş listesi yönetimi. Unvana değil, sorumluluk listesine bakın.
Birlikte nasıl çalışırlar?
Çok ekipli bir lansmanı düşünün: yazılım, saha kurulumu, eğitim, mevzuat onayı. Üç rol üç el sıkışma noktasında buluşur:
- Yol haritası ile proje planı. Ürün yöneticisinin Şimdi, Sonra, Daha Sonra ufukları, proje yöneticisinin takvimine ve bağımlılık haritasına çevrilir. Yol haritası bir niyet beyanıdır; proje planı o niyetin taahhüdüdür.
- MVP hipotezi ile sprint hedefi. Ürün yöneticisinin test etmek istediği hipotez, product owner’ın iş listesinde bir sıraya dönüşür. Hipotezle bağı kopan iş kalemi kapsamı şişirir.
- Lansman ile ölçüm. Proje yöneticisi için teslim bir bitiş çizgisidir; ürün yöneticisi için bir başlangıç. Proje “kapsamı tamamladık” der; ürün yöneticisi “peki müşteride ne değişti?” diye sorar. Bu gerilim sağlıklıdır; bastırılırsa ilk kaybeden müşteri olur.
Türk kurumlarında sık görülen kayma
Pek çok kurumda kartvizitte “ürün yöneticisi” yazar; ama iş tanımı başka bir rolü anlatır. Ürün yönetimi satışa bağlıdır ve ürün yöneticisi günlerini büyük müşterilerin taleplerini yetiştirmekle geçirir. Fiilen ya bir müşteri temsilcisidir ya da her müşteri için ayrı bir işi yürüten bir proje yöneticisi. Ürün yönetimi birimi sessizce bir proje fabrikasına dönüşür; ürün de birbirine benzemeyen projelerin toplamına.
Kendinize dört soru sorun:
- Geçen haftanızın çoğu tek bir müşterinin talebine mi gitti?
- Yol haritanız satış tahminlerinin bir kopyası mı?
- Büyük bir müşteriye gerekçesiyle “hayır” deseniz, yönetim arkanızda durur mu?
- Başarınız teslim tarihleriyle mi, müşteride yaratılan değerle mi ölçülüyor?
İlk iki soruya “evet”, son ikisine “hayır” diyorsanız, sorun sizin yetkinliğinizde değil, yapıdadır. Yapıyı değiştirmek sizin elinizde olmayabilir; ama görünür kılmak elinizdedir: bir ay boyunca zamanınızın nereye gittiğini kaydedin ve tabloyu yöneticinizle paylaşın. Bunu Projeden Ürüne yazısında ayrıntılı ele aldık; kurumunuzun nerede durduğunu Ürün Kültürü Nabzı ile ölçebilirsiniz.
İki şapka aynı başta
Ürün yöneticisi ile proje yöneticisinin aynı kişi olması, özellikle erken aşamada ve küçük ekiplerde çoğu zaman kaçınılmazdır. Sorun şapka sayısında değil, her seferinde hangi şapkanın kazandığındadır. Takvim yüksek sesle konuşur, müşteri sessiz. Teslimat baskısı geldiğinde ilk feda edilen keşif olur: müşteri görüşmesi ertelenir, persona güncellenmez, öncelik en yüksek sesli paydaşa göre verilir.
İki şapkayı birlikte taşıyorsanız dört koruma kurun:
- Keşif zamanını takvime kilitleyin. Haftada en az bir müşteri teması; teslimat için ertelenmez.
- Ölçütleri ayırın. Teslim ölçütlerini (tarih, bütçe) ve değer ölçütlerini (kullanım, elde tutma, memnuniyet) ayrı raporlayın.
- Şapkanızı söyleyin. “Şu an proje şapkasıyla konuşuyorum” cümlesi toplantıyı netleştirir.
- Önceliği görünür kılın. Talepleri Fayda/Zorluk Matrisi’nde gösterin; bir Zaman Tuzağı’na “hayır” demek kişisel bir tavır değil, görünür bir karar olur.
Hangisi size daha yakın?
Bitiş çizgisini geçmekten keyif alıyorsanız proje yönetimi; ekibin her sprintte en değerli işi yapmasını sağlamaktan keyif alıyorsanız product owner rolü; belirsizliğin içinde “neden?” diye sormaktan ve yıllar sürecek bir yaşamı yönetmekten keyif alıyorsanız ürün yönetimi size daha yakındır. Yetkinlik Pusulası hangi yetkinliklerde güçlü olduğunuzu gösterir. Geçiş düşünüyorsanız ürün yöneticisi nasıl olunur, yeni bir role başladıysanız ilk 90 gün yazısıyla devam edin.