top of page

Ürün Yönetiminde Roller Netleşmeden Başarı Olmaz!

ree

Ü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.

 

  1. 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.

 

  1. 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.

 

  1. 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ı:

  1. Teknik mimari & altyapı:

    • Monolith vs microservice, event-driven mimari vs klasik yapılar

    • Versiyonlama, API tasarımı, veri modeli

  2. Non-functional requirements (NFR):

    • Performans, latency, uptime, güvenlik, loglama, monitoring

    • “Kullanıcı fark etmiyor ama üretimi kurtaran” tüm kriterler

  3. Teknik borç yönetimi:

    • Refactoring ihtiyacı

    • Legacy sistemlerle entegrasyon

    • Altyapı upgrade’leri, versiyon güncellemeleri

  4. 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.

 

  1. 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

 

  1. 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.

 

  1. 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

 

  1. 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:

  1. PM, PO ve Product Technical Manager rollerimiz net mi?

    • Kim hangi kararı veriyor?

    • Çatışma çıktığında son söz kimde?

  2. Product Manager’lar gerçekten strateji ve müşteriyle mi uğraşıyor, yoksa task mi takip ediyor?

  3. Product Technical Manager rolü var mı yoksa kritik teknik kararlar “boşta” mı kalıyor?

  4. Ürünün hikâyesini sahiplenen bir Product Marketing yapısı var mı?

  5. UX araştırmaları ve deneyim tasarımı, roadmap’in doğal parçası mı, “vaktimiz kalırsa bakarız” mı?

  6. Growth tarafında, sistematik deney kuran ve funnel’ı sürekli iyileştiren biri/ekip var mı?

 

 

Dr. Hakan TETİK

Yorumlar


bottom of page