Ürün yöneticisi rolü bir hatadır

• Bir yazılım ürün şirketi product-led yaklaşımını “tüm kararları PM’in verdiği yapı” diye yanlış anlarsa, istisnai kurucu tipi liderlere uygun bir modeli sıradan kariyer PM’lerine uygulamış olur
• Ürün kontrolünü tek bir lidere verme yaklaşımında asıl mesele modelin kendisinden çok kime verildiğidir; bu model vizyon, karizma, teknik güç ve güçlü inançlara sahip nadir kişileri varsayar
• Sıradan bir PM’e aşırı yetki verildiğinde veri, çerçeveler, onay süreçleri, toplantılar ve rol yapıları karar aracı değil sorumluluktan kaçış ve politikanın kalkanı hâline gelir
• Bu akış, yetenekli insanları uzaklaştırır; şirket de düşük riskli işler ve iç süreçlere hapsolup vizyonunu ve yeteneğini kaybeder
• Alternatif, PM unvanı merkezli bir yapı değil; her alanda teknik ve kaliteye takıntılı insanları tek ekipte toplayıp ürün keşfi, gözlemlenebilirlik, mühendislik, tasarım, iş ve alan bilgisini birlikte ele alan bir yaklaşımdır

---

product-led yaklaşımını PM tekeli sanma sorunu

• Birçok yazılım ürün şirketi, güçlü yazılım ürünü geliştirme deneyimi olan kişilerden çok yatırım toplama ve hedef sektörü anlama konusunda iyi olan kişiler tarafından kurulur
• Bu kurucular şirketi sektör deneyimi ve ilişkileriyle başlatır, ancak tüm kararları bizzat yönlendirdiklerinde alan uzmanı özgüveni şirkete zarar verebilir
• Bazı kurucular kendilerinin risk oluşturabileceğini kabul eder ve kararları devredecek birini işe alır
  • Bu noktada “biz hizmet organizasyonu değil ürün şirketi olmalıyız ve ürün şirketi de product-led olduğuna göre sorumluluk PM’de olmalı” türü bir yanlış anlama doğar
  • Buradaki product-led, tüm kararları PM’in verdiği anlamına gelmez
• İtiraz geldiğinde, Amazon, Apple, Tesla gibi harika şirketlerin de kontrolü tek bir kişiye verdiği sıkça öne sürülür
• Pek çok harika şirket tek kişilik kontrol modelini kullanır, ama tüm harika şirketler aynı modeli kullanmaz

Tek karar verici modelinin varsayımı

• Şirket kontrolünü tek kişiye verme modeli yanlış olmaktan çok, başarısının kime verildiğine bağlı olduğu bir modeldir
• Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, Leonardo gibi kişiler vizyon, karizma, özgüven, dayanıklılık ve üstünlükleriyle kitlelerin hayranlığını toplar
• Bu kişiler alternatif gerçeklikler hayal eder, yaptıkları işe tamamen gömülür ve iradeleriyle büyük değişimler yaratırlar
• Eğer gerçekten böyle biri varsa, tekil kontrol modeli çok güçlü biçimde çalışabilir

İstisnai kişiler sıradan PM’ler değildir

• Büyük isimler ürün yöneticisi değildi
  • Sanatçı, matematikçi, mucit, bilim insanı, CEO idiler; bazen aynı anda birden fazla rol taşıyorlardı
• Bunlar OKR, KPI, veri ve başkalarının fikirlerinden çok kendi vizyon ve becerilerine takıntılıydı
• İstisnai kişiler güçlü görüşlere, büyük egoya, kendilerine özgü yöntemlere, sert taraflara ve sıradanlığa karşı küçümsemeye sahip olabilir
  • Bu özellikler yüzünden normal şirketlerde işe alınmaları zordur ve kendileri de çoğu şirkette çalışmak istemeyebilir
• Eğer büyük birini bulabilir, ona engel olmaz ve yoğunluğunu kaldırabilirseniz, ürün ve şirket kontrolünü ona verebilirsiniz
• Gerçekte böyle insanları bulmak zordur; birlikte çalışmak istemeyebilirler ya da şirket onların egosunu ve yoğunluğunu kaldıramayabilir

Sıradan PM’lere büyük insanlara göre tasarlanmış yapı uygulandığında

• En büyük hata, istisnai kişi gerektiren bir işletim modelini istisnai kişi olmadan kurmaktır
• Şirketlerin rahatça işe alabildiği kariyer PM’lerin genelde bu seviyede kişiler olmadığı eleştirisi yapılır
  • İş dünyasının uşağı, framework fanatiği, konu uzmanı, kurumsal merdiveni tırmanmış eski üretici, metrik bağımlısı, MBA mezunu gibi ifadeler kullanılır
• product-led yaklaşımını tüm kararları PM’in verdiği yapı diye anlayıp kariyer PM işe almak ölümcül olabilir
• Bu PM’ler vizyon, karizma, uzmanlık, güçlü inanç ve teknik yeterlilikten yoksun oldukları için güvenli oynar ve politik davranır
• Kendi eksiklerini bildiklerinden, başarıyı sahiplenip sorumluluktan kaçma davranışı tekrar eder

Veri ve süreçlerin savunma aracına dönüşmesi

• İlk adım, veriye dayalı karar alma fikrinin silaha dönüştürülmesidir
  • Her iddiayı destekleyecek veri bulunabileceği gerçeğini kabul etmeden, yalnızca kendi kararlarının veriye göre rasyonel olduğunu sunarlar
  • Bir şey ters giderse piyasayı, veri kalitesini ya da şirketin şanssızlığını suçlar, sorumluluğun kendilerinde olmadığını söylerler
• Sonraki adım, her şeye çerçeve ve rol eklemektir
  • 18 adımlı kariyer çerçevesi, çeyreklik performans değerlendirmeleri, PI planning, ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe ortaya çıkar
  • Sürece uymamak, veriye dayalı olmamak, yetersiz dokümantasyon, güncel olmayan dokümanlar suçlama sebebi olur
• Organizasyonda Director of KPIs, Deputy Director of Product Operations, Global Head of Digital Whiteboard Solutions gibi roller ortaya çıkar
• Her şey onaya bağlanır ve hiçbir süreç ya da alan tek bir kişinin tam kontrolünde olmaz
  • Büyük komitelerde herkes “no” diyebilir ama kimse tam olarak “yes” diyemez
• Toplantılar da patlar
  • Durum raporları, hizalama toplantıları, 1:1’ler, staff toplantıları, strateji görüşmeleri, bağlam kurma, release go/no-go, proje raporları artar
• Son aşama, çok sayıda kötü insanı işe almaktır
  • Tehdit oluşturup oluşturmadığına göre işe alım yapılır ve üstünlüğe dair işaretler ret sebebi olur
  • İdeal aday, karşı çıkmayan, kaliteyle pek ilgilenmeyen, verilen işi idare eder şekilde yapan genelci kişidir
  • PM sayısı hızla artar; takımlar ve alanlar boyunca PM katmanları oluşur ve aynı davranışlar tekrar eder

Organizasyonun kaybettikleri

• Sıradan insanların yetkiyi ele geçirdiği süreç başladığında, üstün insanlar sonunda ayrılır
  • Ya sıradan diktatör tarafından dışlanırlar ya da ortamı taşıyamayıp kendileri giderler
• İşlerin hızı durur; bir şeyi hayata geçirmek acı verici, büyük bir taahhüt ve riskli bir girişim hâline gelir
• Büyük vizyonlar gerçek dışı sayılır ve hızla terk edilir
• Şirketin yaptıkları düşük asılı meyveler ve güvenli seçimlerle sınırlanır
• Kendi zanaatına tutkusu çok büyük olmayan insanlar bile acı çekip ayrılır; kalacak kadar hissiz olanlar ise sorunu daha da büyütür
• Şirket en iyi yeteneklerini kaybeder, vizyonunu unutur, içe dönük hâle gelir ve anlamsızlaşır
  • En iyi ihtimalle bir noktada ölür; en kötü ihtimalle ise tutkulu insanları kendi işinden nefret eden zombilere dönüştüren yarım canlı bir hayatta kalma durumuna girer

Alternatif: gündelik olarak üstün insanlardan oluşan ekip

• İstisnai birini bulup işe almak, kontrolü ona vermek ve yoğunluğunu taşımak dışında da başarılı bir ürün şirketi kurulabilir
• Alternatif, gündelik olarak üstün insanları işe almaktır
  • Her biri bir alanda üstün olmalıdır
  • Kendi zanaatına takıntılı olmalı ve kalite tarafından yönlendirilmelidir
  • Ekip, birbirlerinin üstünlük alanları mümkün olduğunca az çakışacak şekilde kurulmalıdır
• Bireysel sorumlulukları parçalara ayırmak yerine, sevdikleri işleri keyifle yapmalarına izin verip zaman ve becerilerini şirkete vermeleri sağlanmalıdır
• Bu insanlar da zorlayıcı, inatçı, egosu yüksek, tuhaf ve değişken olabilir
• Onlara iyi problemler verir ve harika işler yapmalarını sağlarsanız, şirketin başarısına tamamen bağlanırlar

Liderlerin ve PM’lerin olması gereken yer

• Liderlerden tamamen vazgeçmek gerekmez; takım liderliği kaldırılıp alan liderleri dış ve iç koordinatör olarak konumlandırılabilir
• Her alana sorumlu bir lider koyulacaksa, bu role büyük insanlara yakın kişilerin yerleştirilmesi gerekir
  • Vizyon, karizma, yoğunluk, tutku ve uç davranışlar bakımından Jobs, Musk, Bezos’a yakın kişiler buna örnektir
• Kısa vadede rahat, iyi talimat alan ve az ilgi isteyen birini sorumlu yapmak, yukarıda anlatılan duruma düşme riski taşır
• Geleneksel anlamdaki PM rolünün iyi işleyen şirketlerde yeri olmadığı savunulur
• Yine de ürün keşfi, ürün gözlemlenebilirliği gibi geleneksel olarak PM’lere verilen alanlara takıntılı insanlar gerekir
  • Bu insanlar daha önce PM unvanı taşımış olabilir; bunun kendisi sorun değildir
  • İşe alınma sebepleri unvanları değil, takıntıları ve güçlü yanlarıdır
  • Bunları ayrı bir PM rolüne koymak yerine; mühendislik, tasarım, performans, iş ve alan bilgisine takıntılı insanlarla aynı ekibe koymak gerekir

Sorun yalnızca PM’lerle sınırlı değil

• Vizyonu, karizması, tutkusu, teknik yetkinliği ve iradesi olmayan biri sorumluluğa gelirse aynı sorunlar ortaya çıkar
• Odağın PM’lerde olmasının nedeni, yazılım ürün geliştirmede product manager unvanlı birini sorumlu yapma eğilimidir
• Bazı PM’ler gerçekten istisnaidir ve her iki modelde de çok iyi olabilir
• Ancak bu tür PM’ler, farklı geçmişlerden gelen başka harika insanlardan mutlaka daha iyi değildir
• Böyle PM’ler çok küçük bir azınlıktır; çoğu kariyer PM’in üstünlükle liderlik etme kapasitesine yaklaşamadığı düşünülür

[GN⁺]

Hacker News görüşleri

• Şu anki şirkette zeki insan çok ama çeşitli nedenlerle ürün yöneticisi yok ve bunun sonucu olarak ürün yöneticisinin yapması gereken işler resmen yapılmıyor
  Müşteri ilişkilerini sürdürmek, kullanıcı görüşmeleri yapmak, potansiyel özellikleri keşfetmek, liderliği ikna etmek, kaynak dağıtımı için politika yürütmek gibi işleri yapmak isteyen mühendis neredeyse yok
  Önceki şirkette 3 ürün yöneticisinden 2'si yetersiz olduğu için kovulmuştu ama 1'i gerçekten olağanüstüydü; o kişinin zamanının sadece bir kısmıyla bile şu anki şirketin 2 yıldan uzun sürede yaptığından daha fazlası 1 yıl içinde yapılmıştı
  Yeterince iyi ürün yöneticisi olmadığına katılıyorum. İyi ürün yöneticisi olabilecek insan sayısı nüfusla doğrusal oranda artıyor ama yazılım sektörü üstel olarak patladı; bu yüzden gerçekten harika PM'lerden 100 kat fazla PM rolüne ihtiyaç doğduğunu düşünüyorum

  • Aa, demek ürün yöneticisinin yapması gereken şeyler bunlarmış. Eski şirketime ürün yöneticileri geldiğinde bunların neredeyse hiçbirini yapmıyorlardı, müşterilerle de konuşmuyorlardı
    Teknik de değillerdi, bu yüzden Jira ticket'larını yönetmiyorlardı ve liderlik yönetimini de çoğunlukla yöneticiler üstleniyordu
    O ürün yöneticileri daha çok toplantıya giriyor, liderlikle konuşuyor, mühendislerle konuşuyor, belge yazıyor ve uzayıp giden sprint planlama toplantılarını yönetiyor gibiydi
    Müşteri, kullanıcı ve kaynak meseleleriyle ilgilenen ürün yöneticileri olsaydı çok daha değerli olabilirlerdi diye düşünüyorum
  • Hepsi doğru gibi geliyor. 20 yıl mühendis olarak çalıştıktan sonra mühendislik yöneticisi oldum ve geçen yıl ilk PM rolümü aldım; 20 yıllık bir yazılım şirketi iyi ürün yönetimini bir kez bile yapmadığı için durum korkunç
    Sürekli “biz mühendislik öncelikli bir şirketiz” sözünü duydum ama pratikte bunun anlamı mühendislik ekiplerinin kafasına göre en yeni teknolojilerin peşinden gitmesiydi
    Ana ürün sayısı 3,5, fiilen 4,5; her biri farklı bir teknoloji yığınıyla yapılmış ve legacy gereksinimler yüzünden desteklememiz gereken yaklaşık 8 ürün daha var. Ürünler arasında standardizasyon ya da birlikte çalışabilirlik yok, bilgi aktarımı da yok; bu yüzden geliştirme maliyetleri uçmuş durumda
    Bu yıl iki kez, şirkette 20 yıldır çalışan mühendislere bazı API'lerin neden sadece TLS 1.3 kullandığını, bazılarının 1.x kullandığını ve başka birinin neden TLS bile gerektirmediğini açıklamak zorunda kaldım
    Müşteriler bizden nefret ediyor. Benim ürünümde önce pazarlama materyali yazılıp sonra mühendislerin bunu bir şekilde hayata geçirmesi beklendi. Oracle verisini parquet'e taşıyan tek bir aşama, üç dil ve iki ara veritabanıyla (MySQL ve PG) yapılmıştı; içine Redis de sokmaya çalışıyorlardı, onu zar zor engelledim
    Neyse ki şirket 2 yıl önce bir özel sermaye fonu tarafından satın alındı ve artık para kazanamazsak işimiz biter şeklinde son ültimatom verildi. 20 yıllık şirket hiçbir zaman para kazanmayan bir maliyet merkeziydi; hedefleri tutturamasak bile, bizim yarattığımız yazılım tasarım felaketi ortadan kalkarsa evrenin daha iyi bir yer olacağını düşünüyorum
  • Ürün yönetimi zor iş. Neler olduğunu anlayacak ve saçmalığı fark edecek kadar teknik olmak gerekirken, insanlarla konuşabilecek kadar yüksek duygusal zekâya da sahip olmak gerekiyor
    Aptal bir ürün yöneticisi, sadece bir başka iş listesini takip eden sahte bir proje yöneticisine dönüşür; zeki olan ise işi derinlemesine anlayıp ya terfi eder ya da ayrılır
    Bu rolü yönetmek de zor. Bazen başkasının işi üzerinden büyük paye toplarsın, bazen de hiç takdir görmezsin ve kariyerin yerinde sayar
    Bu rol mühendisliğe, mühendislik yönetimine ya da genel yönetime yıkılırsa mühendislik kapasitesi zayıflar. Mühendis alacaksan bunu o yeteneğe göre seçmeli ve onları dışarıdan gelen insanlardan korumalısın; ama ekip etkileşimleri de yürütmek zorunda kalırsa hibrit yetenekli insanlar seçersin ve sonunda mühendislik tarafı sulanır
  • İyi bir ürün yöneticisinin zamanının sadece bir kısmıyla bile, hiç ürün yöneticisi olmayan bir şirkete göre daha fazlasının başarılabilmesi güçlü bir kanıt
    Ürün yöneticisinin kapasitesini bilerek sıkı tutmak, onun üst düzey konulara ve vizyona odaklanmasını sağlayan; fazla derine inip işe yaramaz süreçler kurmasını ya da özellikleri aşırı tanımlamasını önleyen bir zorlayıcı mekanizma olabilir
  • Bunları görmezden geliyorlarsa gerçekten o kadar zeki sayılırlar mı? Kullanıcılarla konuşmak, bir mühendisin yapması gerekenler listesinde her zaman vardı
    10 yılı aşkın süre düşük faizli büyüme ile şişen teknoloji sektöründe, birçok insan için sadece işe gelip gitmek bile başarı için yeterliydi

• Kafa karıştırıcı bir yazı. “PM rolünü kaldırmalıyız” derken bir yandan da “PM’in yaptığı işleri üstlenecek birine hâlâ ihtiyaç var, ama ona PM demeyelim, sadece sıradan şekilde harika biri diyelim” deniyor.
  Yazıyı yazan kişi belli ki PM’lerle kötü deneyimler yaşamış; MBA lafı açılınca da bunun izleri görünüyor ve bu yüzden bebeği banyo suyuyla birlikte atmaya çalışıyor gibi duruyor.
  İşin ölçeği büyüdükçe rol uzmanlaşması ortaya çıkar ve gerekli hâle gelir. Berbat PM’ler de vardır ve bu zor bir iştir, ama ekibimizdeki PM’i kaybetsek gerçekten çok üzülürdüm.

  • Özellikle de PM’e şirketin kontrolünü devretmekten söz eden ifadeleri tekrar tekrar kullanması, bunun kötü bir PM deneyiminden çıkmış bir yazı gibi duyulmasına neden oluyor.
    Belki ben yalnızca PM’lerle iyi deneyimler yaşadım ama bizim şirketteki PM’ler müşterinin ne istediğini ve ürünün ne sunması gerektiğini anlıyor, mühendislik yöneticisiyle birlikte teknik olarak neyin mümkün olduğunu ve uygulama kapasitesini dengeliyor.
    Mühendislik yöneticisi “bu takvimle bu iş kesinlikle olmaz” dediğinde, PM ürün için alternatif bir plan buluyor.
  • Organizasyon liderliğinde çok yaygın bir başarısızlık modu şudur: “Bu rol/şey işe yaramıyor, kaldıralım... aa, aslında gerekiyormuş. Hata yaptığımızı kabul etmemek için başka bir adla geri getirelim.”
    Bu yazı da ara aşamaları atlayıp hiçbir gerekçe olmadan sadece adını değiştirmek istiyor gibi görünüyor.
  • Herkes harika bir ekip kurmaktan söz ediyor ama önce o işe alım büyüsünü başarmak zor, sonra da “onlara iyi problemler verin” deniyor.
    Ekibin hangi problemi önceliklendirmesi gerektiğine tam olarak kimin karar verdiği sanılıyor? Bu, tam da PM rolünün temel sorumluluğu.
    Sonuçta öncelik kararı veremeyen bir PM’le kötü deneyim yaşanmış gibi duruyor.
  • Şanslıyım ki sürekli gerçekten iyi ürün yöneticileriyle çalıştım; tek bir istisna vardı, o da büyük zarar vermeden önce uzun süre dayanamadı.
    Yine de onun yüzünden hayatımda katıldığım en tuhaf toplantılardan birine girmek zorunda kaldım; bir saat boyunca, baştan sona, ürünü hiç anlamadığını üst düzey bir yöneticinin önünde açıkça gösterdi ve o üst düzey yönetici ürünü gayet iyi anlıyordu.
    İyi PM’ler müşterinin ne istediğini, bizim ne sunabileceğimizi, gerçekçi takvimi ve hukuk ile iş tarafındaki paydaşlarla nasıl çalışılacağını anlar; bu da çok yardımcı olur. Teknik tarafı doğrulamaları gerektiğinde ben onlara yardımcı olurum.
    Ekipte ne inşa edileceğine dair fikir ya da ürün/operasyon deneyimini iyileştirmenin yolları nadiren eksik olur. Ürün yöneticisi, doğru şeyi inşa ettiren kişidir.
  • MBA programlarında sektör deneyimi ön koşulu olmasını gerçekten isterdim. Bazılarında zaten var ama daha yaygın olması gerekir.
    Ben 20 yıllık IT kariyerine sahip bir PM’im; bilgi ve resmî iş anlayışı kazanmak, ayrıca ileride büyümeme yardımcı olması için MBA yapmayı düşünüyorum.
    Benim gibi PM’ler MBA alır almaz, askerî bir tabirle söylersek, saçmalık oyununa başlamaz.
    Sorun, liseden, üniversiteden, MBA’den çıkıp doğrudan yöneticiliğe geçen insanlar. Lisans sırasında kısa bir staj dışında çoğu zaman sahada tek bir gün bile deneyimleri olmuyor.

• Tuhaf bir yazı. Bir sürü laf edilmiş ama sonuçta söylenen şey “düşük performanslı insanları işe alırsanız bu şirkete zarar verir” değil mi?
  Alternatif de “iyi insanları işe alın ama PM rolü için işe almayın” gibi duruyor.
  Sanki kendini Steve Jobs sanan bir PM’le kötü deneyim yaşamış birinin yazısı gibi okunuyor. PM’ler de sonuçta sıradan insanlar; bu unvana sahip herkesin ayrıcalık duygusuna sahip olduğunu neden varsaydığını anlamıyorum.
  Bir organizasyonda binlerce PM olabilir ve her birinin bir yöneticisi vardır. Kısacası garip bir yazı.

  • Ben o kısmı tam tersine anladım. Steve Jobs, muazzam iradesiyle harika ürünler yapan olağanüstü bir liderdi; böyle birini sıradan bir ürün yöneticisiyle değiştirmeye kalkarsanız ortaya vasat ürünler çıkar demek istiyor gibi okudum.
  • Ben de neredeyse aynı şeyi yazacaktım.
    “Ürün yöneticisi işe almayın, çünkü onlar harika insanlar olmayacak. Onun yerine harika insanlar alın, hem de tek bir kişi değil tüm ekip olarak!” gibi bir şey deniyor.
  • İnsanları işe alanlar, düşük performanslı kişileri işe almayı bir türlü bırakamıyor gibi görünüyor. Özellikle de bunun olmaması için süreç gerektiğini en çok söyleyenler.
    Her gün düşük performanslı insanlar işe alıyorlar ama nedenini anlamıyorum. Elinde CV yığını olan eğitimsiz bir şempanze bile daha yüksek isabet oranı tutturabilir gibi geliyor.

• PM çok belirli bir ihtiyacı karşılar. Bunu nicelleştirmek zor olabilir ama iyi bir PM olmadığında her şeyin dağıldığını söyleyebilirim.
  Genelde sıradan kullanıcı için neyin işe yarayıp neyin yaramadığını toplar, yöneticilerden şirketin yürümesi için ne gerektiğini dinler, sektör liderlerinden endüstrinin nereye gittiğini anlar, tasarımla çalışır ve bütün bunları gerçekten inşa edilmesi gereken özelliklere dönüştürür.
  Ayrıca mühendislikle birlikte neyin pratik olduğunu, kabaca ne kadar süreceğini değerlendirir; çok zaman alıp az değer üreten özellikleri ayıklar ve tahminlerin ile ekip hızının belli ölçüde öngörülebilir olmasına yardımcı olur.
  Şimdiden 1,5 kişilik işi tarif etmiş oldum. Ürün organizasyonunu kaldırırsanız bütün bu işler mühendislik ekibine dağılır ama ekipteki herkes bunları iyi yapamaz.
  Diyelim ki dengeyi kurdunuz, yine de biri ayrıldığında işe alımda hiç aramadığınız görünmez bir boşluk oluşur.

  • Kesinlikle katılıyorum. İşleyen bir ürün organizasyonu olmadan çalışmak istemem.
    Birçok ekip, işlev bozukluğu yaşayan ürün organizasyonlarından yara almış gibi görünüyor. Böyle organizasyonlar müşteri, sektör ve organizasyon tarafıyla kopuk ya da ilgisiz görünürken bunun yerine mockup’ları evirip çevirdikleri toplantılarda inanılmaz zaman harcıyor, tasarımcıları mikro yöneterek iyi insanları kaçırıyor ve mühendisleri gereksiz ürün toplantılarına bağlı tutuyor.
  • Buna proje için bütçe savunusu yapmak ve paydaşları sürece dahil etmeye çalışmak da dahildir.
  • Son dönemde birlikte çalıştığım PM’ler çoğunlukla yalnızca yöneticilerin istekleriyle ilgilendi. Yukarıda sayılan diğer sorumlulukların tamamı kelimenin tam anlamıyla başkaları tarafından yapıldı.
  • Bir PM olarak bu tanım doğru. PM, yazıda anlatıldığı gibi ekibe ne yapılacağını buyuran otoriter bir karar verici değil, ekibin yakın bir müttefiki olmalıdır.
    PM, ekiple yakın çalışarak yol haritasını tanımlar ve müşteriye ve işe en büyük etkiyi yaratacak işleri önceliklendirir.
    PM işini iyi yaptığında, mühendisler sırada hangi problemi çözmeleri gerektiğini ve neden çözmeleri gerektiğini son derece net biçimde anlar.
  • Harika ürün yönetiminin nicelleştirilmesinin zor olduğu fikrine katılmakta zorlanıyorum. Yaratıcı bir tarafı var ama kolay görülebilecek metriklerden biri, basit bir özellik bingosu yerine stratejik rekabet analizini anlayıp anlamadığıdır.
    İkinci olarak, bir proje hakkında üst yönetimle iletişim kurabilecek organizasyon içi ağırlığa sahip olup olmadığı da önemlidir. Her iki özelliğe de sahipse durum iyidir.

• Teknoloji sektöründe 12 yıldan fazla çalışarak öğrendiğim şey, rollerin yalnızca organizasyonun ne istediğini ifade etme biçimi olduğudur.
  Birinin ürün odaklı düşünmesini istiyorlarsa PM pozisyonu açarlar, takım liderliği istiyorlarsa engineering manager pozisyonu oluştururlar.
  Unvanlar, işi bir RPG gibi farklı açılardan oynamamızı sağlayan kurgusal unsurlardır. Sonuçta iş yerine götürdüğümüz şey, her birimizin yetenek ve deneyimlerinin kendine özgü birleşimidir.
  Bazı insanlar sık sık bu rol sınırlarını aşar ve bunda sorun yoktur. Onların fikirleri vardır ve hatta kendi unvanlarını bile yaratabilirler.
  Organizasyonlar, böyle insanların büyüyüp gelişmesine izin verecek kadar akıllı olmalıdır. Bu, PM olarak başarılı olunamayacağı ya da harika işler yapılamayacağı anlamına gelmiyor; daha çok, organizasyonların genelde bünyelerine kattıkları kişiyi derinlemesine tanımaya yeterince zaman ayırmadıkları için önceden pişirilmiş roller sundukları anlamına geliyor.

  • Evet. Son zamanlarda bu fikri gerçekten benimsedim. Roller, birini sürekli belirli bir bakış açısından düşünsün diye işe almaktır.
    Mühendisler de PM rolünü üstlenebilir ama her şeye PM bakış açısından yaklaşmazlar. Çünkü birincil kimlikleri PM değil, mühendistir.
    Rol sınırlarını aşma bağlamında fark ettiğim bir başka şey de, çoğu zaman bir kişinin rolündeki en değerli kısmın açıkça tanımlanmamış sorumluluklar olduğudur.
    Bunu açıklamak zor, ama insanlar çoğu zaman tarif etmesi ya da nicelleştirmesi zor şekillerde değer üretir.
  • Organizasyonların insanların büyüyüp gelişmesine izin verecek kadar akıllı olması gerektiğine %100 katılıyorum. Ama özellikle büyük organizasyonlarda en çok tam bu noktada başarısız olunduğunu görüyorum.

• Genel olarak oldukça harsh bir bakış açısı, ama kesinlikle doğru tarafları da var. Şirket içinde bir ürün organizasyonu oluştuğunda, yazarın tarif ettiği gibi bunun komitelere, OKR’lere, gözden geçirme döngülerine, planlamaya ve bol miktarda bürokrasiye kayma eğilimi oluyor.
  Eskiden müşteriyle yüz yüze çalışan bir sales engineering rolünde, etki gücüyle ürünü çok başarılı biçimde yönlendiriyordum ve resmi kontrolü de alacağımı düşünerek naifçe product manager işini üstlendim.
  Oturup işe başlayınca bunun aşırı derecede kısıtlı bir masa başı işi olduğunu ve bana hiç uymadığını gördüm. İşin büyük kısmı ticket ve backlog yönetmek, karar vermek yerine koordinasyon yapmak ve bitmek bilmeyen PowerPoint raporları hazırlamaktı; en yaratıcı kısım ise şirketin ürün roadmap’ini resmileştireceği süreci oluşturmaktı. 6 ay içinde kaçtım.
  Bu işlev, neyin üretildiğine görünürlük sağlamak ve büyüyen bir ürünün çatışan önceliklerini yönetmek için oldukça faydalı. Ama ürünün nasıl evrileceği yönünü şekillendirmek ya da kontrol etmek değil.
  Sıralama, filtreleme ve şanslıysan veri toplama işlevidir; ayrıca denetlenebilir bir karar izi ve olgun karar alma izlenimi yaratarak üst taraftaki MBA’lerin biraz daha rahat uyumasını sağlayan bir roldür.

  • Başka bir bakış açısından, PM olarak çalıştığım üç B2C şirketin tamamında, iki farklı sektörde, ürünün nasıl evrileceği yönünü oluşturma ve kontrol etme işine yakından dahildim.
    Genelde ayda 4 ila 12 yeni özellik önerisi(PRD) hazırlıyordum; sayı şirketin büyüklüğüne ve gereken süreç miktarına göre değişiyordu.
    Biçim her zaman şuydu: “Kullanıcının şu anda X sorunu var ve bunu çözmek için Y’yi yapmamız gerekiyor. Y şöyle görünecek...”
    Elbette koordinasyon ve iletişim zorlukları var, ama bunlar her zaman sırada neyi inşa etmemiz gerektiğini bulmak içindi.
    Tüm PM rollerinin böyle olmadığını anlıyorum, ama PM’liğin “sıralama/filtreleme/karar alma olgunluğu tiyatrosu”ndan daha iyi olamayacağı fikrine katılmıyorum.
    Eğer rol sadece mevcut backlog’daki sırayı belirlemekten ibaretse, backlog’a eklenecek yeni maddeleri kimin tanımladığını merak ediyorum.
  • Sonuçta sorun, PM rolü için net rol/sorumluluk tanımının eksik olması ve hesap verebilirliğin yetersiz olması.
    Ürün organizasyonlarının destekleyici olmak yerine siyasi ve bürokratik yapılara dönüşebileceğine katılıyorum.
    Kişisel olarak ürün rolünün engineering takımının içine gömülü olması ve aynı lidere rapor vermesi gerektiğini düşünüyorum. Seviyesi tartışılabilir, ama böylece kötü PM’lere de kötü mühendisler gibi davranılabilir.
    Tabii şirket kötü mühendisleri bile gönderemiyorsa, orada zaten başka sorunlar vardır.
  • Katılıyorum. O yüzden soru, ürün sorunları için stewardship ve hesap verebilirliğin özel bir organizasyon olmadan nasıl etkili biçimde hayata geçirileceği.
    Yazar bunun için pek bir çerçeve sunmuyor.

• Yazının çözümü büyük adam teorisi kokuyor.
  “Muhteşem insanlar alternatif gerçeklikler hayal eder, işe tamamen adanır ve irade gücüyle dağları oynatır” diyen son bölüm fazla indirgemeci.
  Dağları yerinden oynatan şey irade gücü değil, vizyonu gerçekten hayata geçiren alttaki insanlardır. En fazla o “büyük insan”, gerçek uygulayıcıları ve uzmanları harekete geçirmek için teşvikleri hizalayan biri olabilir.

  • İçinde MBA’lere yönelik klasik bir laf sokma da var.
  • Evet. “En fazla” Maxwell’in şeytanı gibi davranıyorlarsa, bu da aslında faydasız oldukları anlamına gelir.

• Şu anda PM rolünün neredeyse hiç olmadığı büyük bir teknoloji şirketinde çalışıyorum, o yüzden doğrudan izlenim paylaşabilirim.
  Şimdiye kadar tablo karmaşık. Çok sayıda PM’in olduğu organizasyonlarda da çalıştım ve o yapıların pek iyi olmadığına katılıyorum. Ama günün sonunda PM’lerin yaptığı işlerin hâlâ yapılması gerekiyor.
  Bizim organizasyonda bu sorumluluk resmî olarak software manager’lara ve senior seviye ya da üzeri geliştiricilere düşüyor.
  Örneğin senior engineer olarak takımın bir inisiyatifine liderlik ediyorsan, PM’in yaptığı tüm faaliyetlerden sen sorumlu oluyorsun. Diğer faaliyetleri ise manager ya da senior manager üstleniyor.
  Geliştirici açısından bu oldukça zor. Bireysel katkı sağlayıcı olarak kendi işini de yapman gerekiyor, ama aynı zamanda başkalarını koordine edip işin tamamlandığından da emin olmalısın.
  Bu yalnızca ek iş yükü değil; açıkçası birçok geliştirici etkili bir PM olmak için gerekli becerilere sahip değil. Farklı raporlama zincirlerindeki insanları koordine etmek gerektiğinden, takımlar arası iş birliği de zorlaşıyor.
  Bu yaklaşım sık sık sahiplenme eksikliğine, hesap verebilirlik eksikliğine, yinelenen çabaya, arada kaynayan işlere ve genel bir düzensizliğe yol açıyor.
  Yine de birkaç kişinin dahil olduğu küçük takım içi inisiyatiflerde iyi çalışıyor. Çünkü PM overhead’ini ortadan kaldırıyor ve kontrolü işi yapanlara veriyor. Ama daha büyük inisiyatifler için de uygun olup olmadığından emin değilim.

  • Başka bir açıdan bakarsak, bireysel katkı sağlayıcı olarak kendi işini yaparken aynı zamanda başkalarını koordine etmek ve işin bittiğinden emin olmak bana göre senior/lead engineer tanımıdır.
    Birçok geliştiricinin etkili PM becerilerine sahip olmadığı doğru, ama adil olmak gerekirse birçok PM de etkili PM becerilerine sahip değil.
    Farklı raporlama zincirlerindeki insanlarla koordinasyon zorluğu PM’ler için de aynı şekilde geçerli.
    Temel farkın, “bu işi ayrı bir role dönüştürmeye değer mi” sorusundaki değerlendirme gibi göründüğünü düşünüyorum. Bana göre mühendisler açısından buna neredeyse hiçbir zaman değmez.

• Sadece başlığa bakınca hoşlanmamaya hazırlanmıştım. Bunun tipik bir “PM’ler aptaldır ve bir şirketin ihtiyacı olan tek şey dünyayı yöneten zeki mühendislerdir” yazısı olacağını sanmıştım
  Ama öyle bir yazı değildi ve bence sorunun kendisini neredeyse kusursuz biçimde tespit etmiş
  Yine de çözüm el sallayıp kayboluyor. “Her biri bir konuda iyi olan, kendi zanaatına takıntılı ve kaliteyle hareket eden sıradan ama harika insanları işe alın, onları bir ekip olarak bir araya getirin ve bireysel sorumluluk olmadan çalışmalarını sağlayın” gibi bir şey
  Kulağa hoş geliyor ama pratikte 100’den fazla çalışanı olan bir şirkette bunun işe yaradığı bir örneği kim verebilir? Gerçekte nasıl işleyebileceğini bilmiyorum

  • Biz bunu yapıyoruz ama 15 kişiyiz, yani kapsam dışı kalıyoruz
    Valve da çok benzer bir şey yapıyor ya da en azından yapıyordu gibi görünüyor. Çalışan el kitabı[0] eskiden HN’de sık sık gündeme gelirdi ama bugünlerde pek görünmüyor. Onlar için iyi çalışıp çalışmadığını merak ediyorum
    [0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
  • Bu “çözüm”, 10’dan az çalışanı olan şirketlerde bile genel olarak işe yaramıyor

• Yazının yazarı gerçekten vasat ürün yöneticileriyle çalışmış gibi görünüyor. Ben kendi kendini yetiştirmiş bir mühendislik geçmişine sahip bir PM’im ve birçok alanda vasat insanlardan bolca gördüm
  İşimi büyük ölçüde risk yönetimi olarak görüyorum. Harika mühendis ve tasarımcı ekipleri bile iyi bir ürünü piyasaya sürme sürecinde pek çok riskle karşılaşıyor
  Bir vizyonu anlatıp başkalarını ikna etme becerileri olmayabiliyor ve hukuk ekibi de neyin yapılabileceği ya da yapılamayacağı konusunda gereksinimler veya kısıtlar koyabiliyor
  Benim işim bunları yönetip ekibin güçlü yanlarını ortaya çıkarmak ve ekibin gerçekten önemli olan şeye, yani iyi bir ürün yapıp onu piyasaya sürmeye odaklanmasına yardımcı olmak
  Başarıyı, ne kadar gereksiz hale geldiğime göre ölçüyorum. Amaç, bana ihtiyaç kalmaması; ekibin bensiz de iyi kararlar alabilecek bağlama, güvene ve desteğe sahip olması
  Mühendislerin bu yetenekleri geliştirmesine yardımcı olmak için onlarla birlikte çalışmayı seviyorum ve mühendislik yöneticisi partnerlerimle birlikte her mühendisin güçlü ve zayıf yanlarını ve hedeflerini anlayıp gelişme yolları bulmaya çalışıyorum
  İdeal bir ütopyada bana ihtiyaç olmayabileceği iddiasını da anlıyorum. Ama çoğu durumda gerçekten harika işler yapmak için zorluklar ve risklerle yüzleşmek gerekir ve iyi bir PM, ekiple birlikte çalışıp bunların aşılmasına yardımcı olan net değer katan kişidir

  • Ben de bir PM’im ve katılıyorum. İşimi iyi yapıp yapmadığımı, ekip için her şeyin ne kadar pürüzsüz işlediğine bakarak değerlendiriyorum
    Ekibin en iyi işini yapabilmesi için gerekli bağlama, gereksinimlere, içgörülere, metriklere ve hedeflere sahip olmasını ve hangi sorunu kimin için neden çözmeleri gerektiğini anlamasını sağlamak bu işin özü
    İyi bir PM, mühendisin “PM hiçbir şey yapmıyor, demek ki gerekli değil” diye düşüneceği kadar iyi bir ortam yaratır. Bu tür bir yargı dar görüşlüdür ve açıkçası aşağılayıcıdır.