Ürün Yönetiminde Roller Netleşmeden Başarı Olmaz!
- Dr.Hakan Tetik
- 4 gün önce
- 5 dakikada okunur

Ürün ekipleri büyüdükçe işler genellikle daha netleşir sanırız; oysa çoğu organizasyonda tam tersi olur. Roller bulanıklaşır, herkes her şeye biraz dokunur ama hiçbir şey tam sahiplenilmez. Sonuç? Strateji ile günlük operasyon birbirine karışır, teknik kararların kimin alanına girdiği belirsizleşir, pazara anlatılan hikâye ürünün gerçekliğinden kopar ve ekiplerin enerjisi verimsiz bir döngüde erir. Aslında çoğu şirket “kötü ürün” yapmaz; “kim, neye karar veriyor?” sorusu net olmadığı için iyi ürün yapamaz. Rol ayrımlarının keskinleştiği bir ürün organizasyonu ise hem karar alma hızını artırır hem de ürünün pazardaki değerini yükseltir. Bu yazı, modern bir ürün ekibinde en çok karıştırılan bu rollerin sisini dağıtmak ve her birinin ürüne nasıl farklı —ve hayati— bir katkı sunduğunu net şekilde ortaya koymak için yazıldı.
Giriş: Neden Rol Tanımları Bu Kadar Kritik?
Birçok şirkette şu cümleyi duyuyoruz:
“Bizde de product management var ama… kim aslında ne yapıyor çok belli değil.”
İlk başta sorun yokmuş gibi görünür; herkes çok çalışıyordur.
Ama zamanla şu belirtiler çıkar:
Ürünün roadmap’i her ay değişir
Geliştirme ekibi “her şey acil” baskısıyla koşar
Müşteriye anlatılan hikâye ile ürünün gerçekliği arasında boşluk oluşur
Teknik borç birikir, kimse sahiplenmez
Aslında problem genelde basit:
Roller, sorumluluklar ve karar alanları net değildir.
Aşağıda modern bir ürün organizasyonunda en çok karışan rolleri netleştirelim.
Product Manager (PM) – “Ne yapıyoruz ve neden yapıyoruz?”
Kısa tanım:
Product Manager, ürünün iş ve müşteri tarafına bakan stratejik sahibidir.
Temel soruları:
Bu ürüne neden yatırım yapıyoruz?
Hangi problemi, hangi segmentte çözüyoruz?
Bu ürünün iş hedefi ne: gelir, kârlılık, pazar payı, NPS, adoption?
Hangi özellikler, hangi sırayla gelmeli?
Sorumluluk alanları:
Pazar ve müşteri ihtiyaçlarını anlamak (research, müşteri görüşmeleri, veri analizi)
Rekabet analizi ve farklılaşma noktalarını netleştirmek
Ürün vizyonu ve product strategy oluşturmak
Roadmap’i hazırlamak ve iş hedefleriyle hizalamak
Feature’lara “evet/hayır” diyebilmek (ve nedenini açıklayabilmek)
PM’in günlük işinden örnekler:
Sabah: Müşteri/veri ile ilgili metriklere bakar (kayıt, kullanım, churn, NPS…)
Gün içinde: Satış, pazarlama, teknik ekip ve yönetimle görüşerek beklentileri toplar
Haftalık: Roadmap review, önceliklendirme, discovery oturumları
Metafor: PM, ürün gemisinin kaptanı gibidir. Rotayı çizer, nereye gidileceğine karar verir; ama motoru bizzat o çalıştırmaz.
Product Owner (PO) – “Bugün ne yapıyoruz, hangi sırayla?”
Kısa tanım:
Product Owner, belirlenmiş vizyon ve stratejiyi geliştirme ekibinin günlük işine çeviren kişidir.
Temel soruları:
Bugün/sprint boyunca ekibin önünde hangi işler olacak?
Bu user story’nin kabul kriterleri ne?
Bu özelliği “bitti” sayabilmemiz için ne olması gerek?
Sorumluluk alanları:
Backlog yönetimi ve önceliklendirme
User story yazımı ve netleştirme
Sprint planlama, refinement, review ve demo süreçlerine liderlik
Geliştirme ve test ekipleriyle yakın çalışma
PM vs PO ayrımı:
PM: “Bu pazara girelim mi, girmeyelim mi?”
PO: “Karar verildi, o zaman bunu 3 sprintte şu sırayla hayata geçirelim.”
Bazı şirketlerde PM ve PO aynı kişide birleşir; özellikle küçük yapılarda bu normal.
Ama zihinsel olarak rolü ayırmak yine de önemli:
Bir zihin stratejiye, diğeri günlük delivery’e odaklanır.
Product Technical Manager (PTM / Technical Product Manager) –
“Bunu teknik olarak nasıl, hangi omurgayla yapıyoruz?”
Bu rol, Türkiye’de ismi en az geçen ama projeleri en çok kurtaran rollerden biri.
Kısa tanım:
Product Technical Manager, ürünün teknik mimarisinin, entegrasyonlarının ve görünmeyen kalite kriterlerininsahibidir.
Temel soruları:
Bu ürün hangi mimariyle uzun vadede ayakta kalır?
Performans, güvenlik, ölçeklenebilirlik açısından riskler neler?
Bu entegrasyonu nasıl tasarlarsak hem esnek hem sürdürülebilir olur?
Teknik borcu nasıl yöneteceğiz?
Sorumluluk alanları:
Teknik mimari & altyapı:
Monolith vs microservice, event-driven mimari vs klasik yapılar
Versiyonlama, API tasarımı, veri modeli
Non-functional requirements (NFR):
Performans, latency, uptime, güvenlik, loglama, monitoring
“Kullanıcı fark etmiyor ama üretimi kurtaran” tüm kriterler
Teknik borç yönetimi:
Refactoring ihtiyacı
Legacy sistemlerle entegrasyon
Altyapı upgrade’leri, versiyon güncellemeleri
Entegrasyon & platform bakışı:
Ürünün CRM, ERP, ödeme sistemleri, partner API’leriyle konuşması
API-first yaklaşımı ve ekosistem düşüncesi
Nerede özellikle kritik?
B2B SaaS ürünler
Fintech, bankacılık, ödeme sistemleri
Telekom, yüksek hacimli işlem yapan platformlar
IoT / cihaz + bulut birleşimi ürünler
Metafor: PM geminin kaptanı ise, Product Technical Manager gemi mühendisi ve baş makinisti gibidir. En iyi rotayı çizsen bile, motoru doğru tasarlamazsan yolun yarısında kalırsın.
Product Marketing Manager (PMM) – “Pazarda nasıl görünmek istiyoruz?”
Kısa tanım:
PMM, ürünün pazardaki konumlandırmasının, mesajının ve hikâyesinin sahibidir.
Temel soruları:
Bu ürünü kime, ne vaadiyle sunuyoruz?
Mesajımız rakiplerden nasıl farklı?
Lansmanı nasıl yapacağız, hangi kanalları kullanacağız?
Satış ekipleri bu ürünü müşteriye nasıl anlatmalı?
Sorumluluk alanları:
Segmentasyon ve hedef kitle tanımı
Value proposition ve konumlandırma
Go-to-market (GTM) ve lansman planı
Satış enablement (pitch deck, battlecard, objection handling)
Ürünün pazardaki algısını ve performansını takip etmek
PMM, PM ile çok yakın çalışır:
PM: Ürünü tasarlar
PMM: Ürünün hikâyesini ve sahne performansını tasarlar
UX / UI & Research – “Kullanıcı gerçekten rahat mı?”
Kısa tanım:
UX / UI ekipleri, ürünün kullanılabilirliğini, deneyimini ve akışını tasarlar.
Temel soruları:
Kullanıcı bu ekranda neden takılıyor?
Bu süreci daha sade nasıl hale getiririz?
Farklı persona’lar bu ürünü nasıl kullanıyor?
Sorumluluk alanları:
Kullanıcı araştırması (interview, gözlem, anket, kullanılabilirlik testi)
Persona, journey map, experience map hazırlama
Wireframe, prototip ve ara yüz tasarımı
Deneyim testleri ve iyileştirme önerileri
Metafor: UX, ürünün “içerideki organları” değil, kullanıcının yaşadığı “deneyim hissi”dir.
Aynı fonksiyon, kötü tasarlanınca eziyet; iyi tasarlanınca keyif olur.
Growth / Product Growth – “Bu ürün nasıl daha hızlı ve akıllı büyür?”
Kısa tanım:
Growth, ürünün büyüme motorunu optimize eden ekip/roldür.
Temel soruları:
Nerede kullanıcı kaybediyoruz?
Hangi adımda küçük bir dokunuş büyük fark yaratır?
Hangi testler bize en çok öğrenmeyi sağlar?
Sorumluluk alanları:
Funnel analizi (acquisition, activation, retention, revenue, referral)
A/B testleri ve deney tasarımı
Fiyatlandırma, paketleme, onboarding deneyimi üzerinde testler
PM, PMM, veri ve satış ekipleriyle ortak büyüme denemeleri yapmak
PM – PO – Product Technical Manager Üçgeni
Bu üç rol birlikte çalıştığında ürün hem ticari, hem teknik, hem de operasyonel olarak sağlıklı olur.
Product Manager:
Ne yapıyoruz, neden yapıyoruz?
Pazar, müşteri, iş hedefi
Product Owner:
Bugün ne yapıyoruz, hangi sırayla?
Backlog, sprint, story’ler
Product Technical Manager:
Bunu teknik olarak nasıl yapıyoruz, hangi omurgayla?
Mimari, NFR, entegrasyon, teknik borç
Eğer bu üçgen net değilse:
PM task takipçisine dönüşür
PO sadece “iş atanmış proje yöneticisi” gibi kalır
Product Technical Manager ya hiç yoktur ya da “işler bozulunca çağrılan itfaiyeci” olur
Kendi Organizasyonunuza Bakmak İçin Sorular
Bu yazıyı okuduktan sonra kendi organizasyonunuza şu soruları sorabilirsiniz:
PM, PO ve Product Technical Manager rollerimiz net mi?
Kim hangi kararı veriyor?
Çatışma çıktığında son söz kimde?
Product Manager’lar gerçekten strateji ve müşteriyle mi uğraşıyor, yoksa task mi takip ediyor?
Product Technical Manager rolü var mı yoksa kritik teknik kararlar “boşta” mı kalıyor?
Ürünün hikâyesini sahiplenen bir Product Marketing yapısı var mı?
UX araştırmaları ve deneyim tasarımı, roadmap’in doğal parçası mı, “vaktimiz kalırsa bakarız” mı?
Growth tarafında, sistematik deney kuran ve funnel’ı sürekli iyileştiren biri/ekip var mı?
Dr. Hakan TETİK







Yorumlar