Ürün Yönetiminde Kahramanlar Olmalı mı?

Deşifre Metnini Okuyun:

Podcast’lerimizin deşifresini bir yazılım programı kullanarak yapmayı deniyoruz. Bot her zaman yüzde 100 doğru çalışmadığı için lütfen yazım hatalarını mazur görün.

Hannah Clark: Konuya girmeden önce, ürün yönetiminde kahramanlardan tam olarak ne anladığımı açıklığa kavuşturmak istiyorum. Marty Cagan veya Lenny Rachitsky gibi düşünce liderlerinden bahsetmiyorum; SİZDEN bahsediyorum. Ürün ekibinizin bir şeyler alev aldığında günü kurtarmak için bel bağladığı kişiden bahsediyorum. Pek çok şapka takan ama hiç pelerin takmayan kahramandan bahsediyorum. Haftada 50 saatten az çalışamıyor gibi görünmenizin ve yine de bir önceki haftaya göre hiç ilerleme kaydetmemiş gibi hissetmenizin nedeninden bahsediyorum.

Eğer bu kişi sizseniz iyi haberlerim var: Bugünkü konuğumuz Product Teacher’ın kurucusu Clement Kao. Erken aşamadaki girişimlerden Fortune 500 şirketlerine kadar her ortamda ürün yöneticilerine koçluk yapan Clement, ürün ekiplerinin dinamiklerini ve ciddi biçimde kurtarılmaya ihtiyaç duyan pek çok ekibi yakından gördü.

Bir ürün ekibinin kahramanı olmanın neden başlı başına bir tehlike olduğunu konuşacağız. Bu söylediklerimiz size tanıdık geliyorsa, işleri nihayet nasıl tersine çevireceğinizi ve insanüstü gücü nasıl elde edeceğinizi öğrenmek için sonuna kadar bizimle kalın. Hadi başlayalım.

Ürün Yöneticisi Podcasti’ne tekrar hoş geldiniz. Bugün Clement Kao ile birlikteyim. Kendisi Product Teacher’ın kurucusu.

Clement, bugün bize katıldığınız için çok teşekkürler.

Clement Kao: Beni davet ettiğiniz için ben teşekkür ederim.

Hannah Clark: Her zaman yaptığımız gibi başlayalım. Bize biraz geçmişinizden ve Product Teacher’ı kurmanıza neyin öncülük ettiğinden bahseder misiniz?

Clement Kao: Harika bir soru. Üniversiteden mezun olduğumda aslında doğrudan ürün yönetimi alanında çalışmaya başlamadım.

İşe yönetim konsolunda başladım. Ardından, yönetim konsolunda çalışırken tesadüfen bir kullanıcı deneyimi araştırmacısı oldum. Sonra yine tesadüfen veri analisti oldum. Daha sonra da tesadüfen ürün yöneticiliğine geçtim. Yani oldukça geleneksel olmayan bir geçmişim var. Ürün yöneticisi olarak kariyerimde ilerlemeye devam ederken, kariyer basamaklarının en altında yardımcı ürün yöneticisi olarak başladım; ardından ürün yöneticisi, kıdemli ürün yöneticisi, grup ürün yöneticisi ve baş ürün yöneticisi oldum.

Fark ettiğim şeylerden biri, benim yaşadığım zorlukların aynısını yaşayan pek çok insanın olmasıydı. Ellerinde mutlaka doğru kaynaklar bulunmuyordu. Belirli bir sorunu nasıl ele alacaklardı? Belirli bir hatanın üstesinden nasıl geleceklerdi? Tüm bu farklı terimler ne anlama geliyordu ve bunlar neden önemliydi?

Bu nedenle, bireysel katkıcı olarak ürün yöneticiliği kariyerimde giderek daha kıdemli hâle gelirken kendime şu soruyu sormaya başladım: Mümkün olan en büyük etkiyi nasıl yaratabilirim? En büyük etkiyi yaratmamın mutlaka bir şirket içinde ürün yönetimi yapmaya devam etmek anlamına gelmediğini fark etmeye başladım. Asıl büyük etki, yüzlerce, hatta binlerce ürün yöneticisinin ilk kez ürün yöneticisi olduklarında başarılı olmasına yardımcı olmak olabilirdi.

Çünkü bu geçiş çok kafa karıştırıcı olabilir. Ayrıca onların kariyer basamaklarında yükselmelerine yardımcı olmak istiyordum. Product Teacher’ı kurmaya bu nedenle karar verdim. Product Teacher, ister ilk kez ürün alanına girmek, ister terfi almak, ister ürün lideri olarak ürün stratejisini belirlemek ve tüm ekip arkadaşlarımız için gerçekten net süreçler oluşturmak olsun, 7.000’den fazla ürün yöneticisinin işlerinde başarılı olmasına yardımcı oldu.

Bu yolculuk benim için son derece tatmin edici oldu.

Hannah Clark: Güzel. Kariyer yolculuğunuzun en bilinçli bölümü bu olmuş gibi görünüyor; diğerleri ise biraz daha…

Clement Kao: Evet. Tesadüfen yapmadığım tek şey buydu.

Hannah Clark: Bugün ürün yönetimindeki kahramanlık fikrini inceleyeceğiz. Bu fikre karşı belirli bir tutum aldığınızı görüyorum. Ancak bağlamı netleştirmek gerekirse, bu ne anlama geliyor ve birlikte çalıştığınız kuruluşlarda nasıl ortaya çıktığını görüyorsunuz?

Clement Kao: Harika bir soru. Öncelikle şunu açıklığa kavuşturayım: Kahramanlığın bütünüyle kötü olduğunu söylemiyorum. Ürün yöneticisi olmanın temel unsurlarından biri, sorumluluğun sizde olmasıdır.

Ürünün başarılı olmasını sağlamak sizin sorumluluğunuzdur ve gerekli olan her şey için elinizi taşın altına koymaya istekli olmanız gerekir. Örneğin, bir kalite güvence uzmanımız yoktur ve bir şeylerin üretime alınmadan önce iyice test edilmesini sağlamamız gerekir. Ya da tasarımcımız hastadır ve mühendislerimizin önünü açmak için süreci ilerletmemiz gerekir.

Belki de müşterilerimiz ürünün belirli bir bölümünü anlamakta zorlanıyordur ve ürün operasyonları rolünü üstlenip ürünü kullanıma sunmamız, insanların başarılı olmasını sağlamamız gerekiyordur. Her ne olursa olsun, ürün yöneticisi gerektiğinde devreye girebilmelidir. Ancak ürün yönetiminde kahramanlıkla ilgili gördüğüm temel sorun, bunun yalnızca bir istisna ortaya çıktığında başvurulacak bir yöntem yerine her zaman yapılması gereken bir şey olarak kullanılmasıdır.

Açık olmak gerekirse, ürün yöneticisi gerektiğinde devreye girip işlerin gerçekleşmesini sağlamalıdır; ancak her zaman her şeyi yapan kişi olmamalıdır. İnsanların “Bu ürün yöneticisi tam bir kahraman” dediğini sık sık görüyorum.

Aslında yaptıkları şey, ürünün çalışmasını sağlamak için işlevlerin büyük bir bölümünü diğer çalışma arkadaşlarından devralmak. Bunun sonucunda kuruluşun geri kalanında körelme meydana geliyor. Ürün pazarlaması, ürün analitiği, müşteri başarısı veya satış açısından gerekli işlerini olması gerektiği gibi yapmayan insanlar ortaya çıkıyor.

Her şeyi tek bir kişiye yaptırdığınızda, tüm bu farklı alanlar daha zayıf ve daha az tekrarlanabilir hâle geliyor. Ürün yöneticisi hastalandığında, tatile çıktığında veya kuruluştan ayrıldığında herkesin çok zor durumda kaldığını bizzat gördüm.

Bu nedenle vurgulamak istediğim nokta şu: Ürün yöneticileri ihtiyaç ortaya çıktığında sorumluluk almaya kesinlikle istekli olmalı. Ancak ihtiyaç her gün veya her hafta ortaya çıkıyorsa, muhtemelen daha derin bir sorunun ele alınması gerekir.

Hannah Clark: Bir ürün yöneticisinin sürekli böyle bir konumda olmasının mantıksal sonuçlarını hayal edebiliriz. Peki sizce neden hâlâ bu durumda olan bu kadar çok ürün yöneticisi var?

Clement Kao: Bunun nedenlerinden biri, çalışma biçiminin zaman içinde değişmesi. Artık herkes aynı anda pek çok farklı işi yapabilecek şekilde birden fazla ekibe yatay olarak bağlanıyor.

Geçmişte bir kullanıcı deneyimi tasarımcınız olurdu ve tek bir girişime odaklanırdı. Şimdi aynı kişinin beş ürünü desteklediğini görebilirsiniz. Bir iş analistinin tek bir temel girişim grubuna odaklanması beklenirken, artık yedi farklı ekibi destekliyor olabilir.

Bu çapraz görevlendirmeler nedeniyle topun kimde olması gerektiği çok daha belirsiz hâle geliyor. İşler ters gittiğinde kimin devreye girmesi gerektiği net olmuyor. Netlik olmayınca da varsayılan olarak ürün yöneticisi devreye girmek zorunda kalıyor.

“Bu tür şeyler olduğunda bunu şu kişi yapmalı” konusunda daha fazla netlik olursa ürün yöneticisinin devreye girmesi gerekmez. Ancak teknoloji girişimlerinin ve daha küçük, daha özerk ekiplerin yükselişiyle birlikte kimin ne yapması gerektiğine dair net yönergeler çoğu zaman bulunmuyor.

Bu yüzden “Bunu kimin yapması gerektiğinden emin değiliz” dediğimiz anda, iş ürün yöneticisinin görevi hâline geliyor. Ürün yöneticisi bunu bir kez yaptığında da kendi kendini güçlendiren bir döngü oluşuyor: “Bunu daha önce ürün yöneticisi yaptı ve çok iyi yaptı. Bir dahaki sefere de o yapsın.”

Bir anda tüm analitiği sürekli ve sonsuza kadar yapmayı üstlenen ürün yöneticileri gördüm. Tüm pazar araştırmalarını ve müşteri görüşmelerini üstlenen ürün yöneticileri gördüm. Tüm satış görüşmelerini yapan ve satışları kapatan kişiler hâline gelen ürün yöneticileri de gördüm.

Çünkü diğer ekiplerin yürüttüğü başka girişimler vardır ve ürün yöneticisi bu işlerde onlardan daha iyi performans gösterebileceğini düşünür. Bu nedenle işi ürün yöneticisine bırakmak daha kolay görünür. Son on yılda bu durumun giderek daha sık ortaya çıkmasının nedeni büyük ölçüde bu.

Hannah Clark: Bir kuruluşun ürün yöneticilerini kahraman olmak zorunda kalmaktan korumak için yeterince çalışma yapmadığını veya süreç açısından hazırlıklı olmadığını gösteren erken işaretler var mı?

Clement Kao: Bunu genellikle yaşandığında anlarsınız. Bir kez devreye girmeniz tamamen normaldir ve beklenen bir şeydir. Ancak sık sık devreye girdiğinizi fark ediyorsanız —neredeyse her ay, her lansmanda veya her hata çıktığında— ortada bir örüntü var demektir.

Aynı tür şey arka arkaya iki kez olursa daha derin bir konuşma yapmanız gerekir. Kuruluşunuzda geriye dönük değerlendirmelere değer veriliyorsa bu konuyu değerlendirmeye taşımalısınız. Böyle bir uygulama yoksa geriye dönük değerlendirmeleri başlatmalısınız: “Bu sorun neden yaşandı?”

İlk seferde bunu yaparsanız sorunun ikinci kez yaşanmasını ideal olarak önlersiniz. İkinci kez de yaşanırsa değerlendirme, bir örüntünün neden oluştuğunu ele almalıdır. Böylece ürün çalışanlarının düzenli olarak görev kapsamlarının dışındaki işleri yapıp yapmadığını fark edebilirsiniz. İstediğimiz şey bu değil.

Hannah Clark: Geriye dönük değerlendirmeleri yürütmek bu tür bir sorunun biraz sıkıcı çözümü gibi geliyor.

Clement Kao: Gerçekten de çok sıkıcı.

Hannah Clark: Ne yazık ki öyle. Ürün yöneticisi, herkesin böyle bir durumu düzeltmek için gerekli değişiklikleri yapmasını sağlayacak yeterli bir geriye dönük değerlendirme yürütmek için nasıl bir süreç izlemeli?

Clement Kao: En önemli şeylerden biri, geriye dönük değerlendirmenin suçlayıcı olmamasını ve insanları değil sistemi konuşmamızı sağlamaktır. Örneğin, bir kurumsal müşteri ürün deneyiminin mevcut hâlinden çok rahatsız olabilir. Kod yazmayı bilen bir ürün yöneticimiz vardır, ancak yazılım mühendisleri yoğun teslim tarihleri veya başka nedenlerle belirli bir metin değişikliğini yapamıyordur.

Ürün yöneticisi kendi kodunu yazar, bunu birleştirir ve üretime alır. Bu durumda geriye dönük bir değerlendirme yapmalıyız. Ancak değerlendirme “Bu mühendis çok meşguldü ve yapamadı, ben de yapmak zorunda kaldım” diye başlamamalı.

Bunun yerine şöyle sormalıyız: “Bu müşteri sorunu altı ay önce gündeme getirdiğinde neden daha fazla dikkat etmedik? Müşteri çok öfkelenip sözleşmeyi iptal etmek üzereyken ürün yöneticisinin müdahale etmesine neden izin verdik?”

Bir adım geri çekilip sistemin bakış açısını ele almalıyız. “Bu kişi o anda konuyu gündeme getirmedi” demek yerine “Bu durum tekrar yaşansaydı, bir sistem ve süreç olarak bunu daha iyi yapmak için neler yapabilirdik?” diye sormalıyız.

Geçenlerde hava trafik kontrolü hakkında bir şey okuyordum. Hava trafik kontrolörünün görevi uçakların kalkış ve inişlerini güvenli biçimde yönetmek ve kazaları önlemektir. Bir kaza olduğunda hava trafik kontrolörü oradadır; ancak bu, yüzde 100 onun hatası değildir. Tek bir hata noktası oluşmasını zorlaştıran pek çok birbirine bağlı unsur vardır.

Bizim istediğimiz tek bir hata noktası daha oluşturmak değil, hatayı daha erken önlemeye yardımcı olacak pek çok farklı kontrol noktası yaratmaktır. Bu sorumluluk yalnızca “ürün yöneticisi” unvanını taşıyan kişinin üzerinde olmamalıdır.

Her türlü en iyi uygulama kılavuzu elbette faydalıdır. Ancak herhangi bir geriye dönük değerlendirmenin temelindeki en önemli zihniyet şudur: “Bu süreci birlikte yürütüyoruz. Parmakla işaret etmiyoruz. Belirli bir kişiyi suçlamıyor ve onun kariyerini tehlikeye atmıyoruz. Sistemi denetliyoruz. Sistem nerede yanlış çalıştı ve bir dahaki sefere hepimiz için nasıl daha iyi hâle getirebiliriz?”

Bu yaklaşım, doğru destekleyici rollere ve süreçlere sahip olduğumuzdan emin olmak açısından son derece güçlü olabilir. Her seferinde kodu birleştirmek veya bir müşterinin kaybedilmesini önlemek için ürün yöneticisinin devreye girmesi gerekmemelidir.

Elbette sözleşmesini iptal etmek üzere olan bir müşteriniz varsa ve ürün yöneticisi bir kez devreye girip görüşmeyi iyi sonuçlandırırsa bu harika olabilir. Ancak her müşteri görüşmesinde odada bir ürün yöneticisine ihtiyaç duyuyorsanız, bu sürecin nasıl işlediğini yeniden ele almanız gerekir.

Hannah Clark: Bu mantıklı. Sorunu tersine mühendislikle inceleyip çözümü başlangıç noktasından itibaren bulmak gerekiyor. Ürün ekipleriyle çalıştığınız görevinizde, böyle bir sorunu başarıyla düzelten kuruluşlar gördünüz mü?

Clement Kao: Önce kendimle ilgili bir hikâye anlatayım. Bir dönem, yapmamam gereken hâlde tüm ürün operasyonları işlerini yapan kişi konumuna geldim. B2B SaaS alanında sahip olduğum ürünlerden biri için tamamen yeni bir ürün dikeyi başlatıyorduk. Bu, mevcut ürün dikeyimizin yanında konumlanan bir üründü.

Müşteri araştırmasını yapan, müşteri sorunlarını anlayan, doğru sürüm notlarına sahip olduğumuzdan emin olan, kayıtları düzenleyen ve müşterilerimizin ürünü nasıl kurup başarıyla kullanacağını açıklayan kişi bendim.

Sadece üç müşterimiz varken bu sorun değildi. Ancak 70. müşteriye ulaştığımızda kötü yaptığım bir şey olduğunu fark ettim: Daha 10. veya 15. müşterideyken elimi kaldırıp “Her müşterinin demosunu ve eğitimini yürütmek benim işim değil. Bu sorumluluğu başka biri üstlenmeli” dememiştim.

O zamanki düşüncem “Bu benim işim. Ben ürün yöneticisiyim ve ne pahasına olursa olsun ürünün başarılı olmasını sağlamalıyım” şeklindeydi. Ancak böyle davranarak müşteri başarısı veya ürün pazarlaması ekiplerindeki insanların bu süreci uçtan uca sahiplenme fırsatını ellerinden aldığımı fark etmemiştim.

İyi niyetli olmama rağmen ekip arkadaşlarımın önünü kesiyordum. Onlara bir işi baştan sona sahiplenme fırsatı vermiyordum; ihtiyaç olduğunda sürekli devreye giriyordum. Bunun sonucunda insanlar yeni bir müşteriyi ürüne dahil ederken bana “Bu şeyi nasıl yapılandıracağımı bilmiyorum” diye gelmeye başladılar.

Daha geniş dokümantasyona, farklı yapılandırmaların nasıl çalıştığını açıklayan videolara, müşterilerin hangisini kullanması gerektiğine dair yönlendirmelere ve müşteri kabul sürecinde sorulması gereken sorulara ihtiyacımız vardı.

Bunları yapmadığım için harika bir yöneticiyle çalışma şansına sahip oldum. Ürün direktörüm bana “Clement, son zamanlarda biraz boğulmuş görünüyorsun. Teknik olarak sana ait olmayan pek çok işi yapıyorsun” dedi.

Ben de “Ama sorumluluk bende bitiyor” dedim. O da “Evet, ancak yaptığın şey müşterileri uzun vadede destekleyebileceğimiz sağlam bir sistem kurmamızı engelliyor. Birden on müşteriye kadar bizi destekleyebildin, fakat artık sınırına geldin. Gelecek yıl 140 müşteriye çıkmak istiyoruz. Bunu nasıl yapacaksın?” diye sordu.

Bu adil bir noktadaydı. Bunun üzerine diğer tarafları bir araya getirip kimin neyi sahiplenmesi gerektiğini konuştuk. Sahiplenmenin bir yük değil, bir fırsat olduğunu çerçevelememiz gerekiyordu. İnsanlara, benim daha önce ellerinden aldığım parçaları sahiplenmeleri için yeni yetkiler ve yeni süper güçler veriyorduk.

Bu örnekte işe yarayan birkaç şey vardı. Birincisi, ürün yönetimi liderlerinin desteğini almaktı. Liderlik ekibiniz “Git ve sen yap” derse, işi daha uygun kişilere devretmek çok zorlaşır.

İkincisi, bu sorumlulukları kimin üstleneceğini çerçeveleme biçimiydi. “Size daha fazla iş veriyoruz ve bu iş eğlenceli değil” demedik. “Size daha fazla sahiplik vermek ve bu işin tamamını uçtan uca kontrol etmenizi sağlamak istiyoruz. Bunu haksız biçimde sizden almışız” dedik.

Böylece insanlar daha güçlü bir kimlik kazanıyordu. Müşteriler ürünün tüm değerini görebiliyor, ekip arkadaşlarımız da müşterilerin bizden ne deneyimlemesi gerektiği konusunda daha büyük söz sahibi oluyordu.

Ardından sorumlulukları düzenli olarak kontrol ettik. Başlangıçta haftalık veya iki haftada bir görüşüp bilgi aktarımını sağladık. Daha önce benim yaptığım işleri onların devralabilmesi için gerekli bağlamı paylaştık.

İşi bir anda duvarın üzerinden atıp “Artık senin” demek istemedik. Hepimiz ekip arkadaşıydık. Geçişi birlikte yürüttük, birkaç temas noktası oluşturduk ve geçmişte ne olduğunu, bundan sonra bunu nasıl ele almak istediğimizi tam olarak anlamaya çalıştık.

Hannah Clark: Bu yaklaşımın ekibe yeniden hareket alanı kazandırmasını ve iş yükünü paylaşmasını gerçekten beğendim. Birinin aslında kendisine ait olmayan bir sorumluluğu haksız biçimde üstlenmesinin hem kendi gelişimini hem de başkalarının katkıda bulunma fırsatını engellediğini ben de gördüm.

Clement Kao: Daha yakın zamanda yaşanan canlı bir örnekten bahsedebilirim. Şu anda ürün ekibi oldukça yeni olan büyük bir kuruluşla çalışıyorum. Ekip üyelerinin çoğu daha önce çözüm mimarı olarak görev yapıyordu.

Kuruluş geçmişte “Bir BT ekibimiz var ve her müşteri için bunları özel olarak oluşturacağız” yaklaşımıyla çalışıyordu. Bu nedenle ölçeklenebilir bir ürün yoktu. Liderlik, oluşturdukları özel çözümlerin desteklemek istedikleri müşteri kullanım senaryolarında pek çok ortak noktaya sahip olduğunu fark etti ve bir ürün ekibi kurmaya karar verdi.

Amaç, her seferinde tek bir çözüm oluşturmak yerine sağlam ve ölçeklenebilir bir ürün geliştirmekti. Çözüm mimarisi ekibindeki bazı kişiler ürün tarafına geçti ve her şeyi ölçeklenebilir teknoloji ürünleri oluşturacak şekilde nasıl yeniden tasarlayabileceklerini incelemeye başladı.

Ancak geçmişleri nedeniyle ürün çözümü geliştirirken çözüm mimarisi işlerini de yapmaya devam ettiler. Ürünün bu bölümünü kullanan müşterilere hangi süreçleri ve sistemleri kullanmaları gerektiğini anlatıyorlardı. Oysa gerçek çözüm mimarları “Ben ne yapıyorum?” diye sormaya başladı.

Ürün ekibi ürünün iyi benimsenmesini istiyordu; bu nedenle yalnızca ürünün nasıl oluşturulacağını değil, ekosistemdeki diğer sistemlerin müşteriler tarafından nasıl kullanılacağını da belirlemeye çalışıyordu. Ancak müşterinin bugün kullandığı diğer sistemleri incelemek ve bunların nasıl bağlanacağını belirlemek çözüm mimarının göreviydi.

Ürün ekibinin ölçekli çalışabilmesi için temel ürüne odaklanması gerekiyordu. Ürün yöneticisi sağlam platformu oluşturmalı, çözüm mimarı ise müşteriye özel bağlantıları kurmalıydı. Böylece bire bir ürün yöneticisi-müşteri ilişkisinden bire çok modele geçilebilirdi.

Bu değişim, ekip genelinde birden fazla görüşme gerektirdi. Ürün yöneticilerinin müşteriler için iyi iş çıkarmak istediğini anlayabiliyorduk ve bu özveriye hayranlık duyuyorduk. Ancak çözüm mimarlarının müşteriler için çözüm üretme yetkisini ellerinden alırsak, ürün ekibinin teknoloji temelini geliştirmeye zamanı kalmayacaktı.

Kısa vadeli ihtiyaçları uzun vadeli hedeflerle değiştirmemeliydik. Neyi neden reddettiğimizi açıkça belirtmeli ve sahipliği çözüm mimarlarına geri vermeliydik. Böylece kendilerini dışlanmış hissetmezlerdi.

Bu ekip bir yıldan kısa süredir vardı; dolayısıyla ilişkiyi erken aşamada yeniden tanımlamamız çok değerliydi. Üç yıl bekleyip düzenin katılaşmasından sonra “Bir dakika, bunu yanlış yapmışız” demek yerine sorunu erkenden yakaladık.

Ürün yöneticisi her müşteri dağıtımının kahramanı olmamalıydı. Ürün yöneticisi ürüne, çözüm mimarı ise çözüme sahip olmalıydı.

Hannah Clark: Zihniyetlerden ve bir kuruluşun olgunluğunun işleyişi nasıl etkilediğinden biraz daha bahsetmek istiyorum. Kuruluş büyüdükçe kurallar ve süreçler karmaşıklaşıyor, bunalmışlık hissi artıyor ve sürdürülebilir olmayan bir döngüye sıkışıyorsunuz. Sanki tek mümkün yol buymuş gibi geliyor.

Bu durumdan çıkmak çok zor. Kişi üzerine teknik olarak kendisine ait olmayan pek çok sorumluluk aldığında, kuruluşta körelme de başlamış oluyor. Böyle bir durumda olan, sorumluluklarının ağırlığı altında ezilen bir ürün yöneticisi kendisini bu zincirlerden kurtarmak için nasıl bir yol izlemeli? Kendini böyle bir kuruluşta nasıl savunmalı?

Clement Kao: Bunu tabandan yukarı doğru ele almak istiyorum. İlk adım, kabul etmediğiniz bir biçimde iş yükünüz altında ezildiğinizi fark etmektir. Bazen bu farkındalık hiç oluşmaz; çünkü o kadar yoğunsunuzdur ki düşünmeye zamanınız kalmaz.

Haftada 70 veya 80 saat çalışıyorsanız “Bir dakika, bu ürün yönetimi gibi görünmüyor” diye düşünmeye vaktiniz olmayabilir. Bu nedenle haftanın başında veya sonunda 10 dakikanızı ayırıp kendinize şunu sormak çok değerlidir: “Yaptığım iş hakkında ne hissediyorum? Gerçekten ürün işi mi yapıyorum? Etkilemem gereken ölçümleri etkiliyor muyum? Yaptığım bazı işler düşük değerli olduğu hâlde neden bunları yapmak zorunda olan kişi benim?”

Bu öz değerlendirme, içinde bulunduğunuz koşulları fark etmenize yardımcı olabilir. “İşim müşterinin sorununu anlamak, tasarım ve mühendislikle birlikte çözüm geliştirmek, ardından işletmeyle birlikte ürünü kullanıma sunmak değil miydi? Şimdi neden bunların dışındaki işleri yapıyorum?” diye düşünmeye başlarsınız.

İkinci adım, yöneticinizin desteğini almaktır. Yöneticiler çoğu zaman tüm bu işleri yaptığınızı bilmiyor olabilir. Bu onların hatası değildir; onların da ulaşmaları gereken ölçümler ve yönetmeleri gereken başka insanlar vardır.

“Haftada yaklaşık 10 saatimi bu işlere harcıyorum” dediğinizde yöneticiniz “Neden? Bunu daha önce söylemeliydin; bu işler sana ait değil” diyebilir. Sizin ölçümleriniz yöneticinizin ölçümlerinin bir parçası olduğu için, bu konuyu gündeme getirmeniz onun da daha etkili olmasını sağlar.

Yöneticinize, kendi ölçümlerinizle veya onun ölçümleriyle örtüşmeyen işlere ne kadar zaman harcadığınızı ve neden böyle olduğunu düşündüğünüzü anlatın. Ardından bu sorumlulukların hangi ekiplere ait olması gerektiğini birlikte belirleyebilirsiniz.

Örneğin, bir tasarımcınız varken tüm kullanıcı deneyimi tasarımlarını ve tel kafesleri neden siz yapıyorsunuz? Bir analitik ekibiniz varken neden geçici SQL sorgularını siz hazırlıyorsunuz? Analitik ekibi bunu kalıcı bir gösterge tablosuna dönüştürerek tüm müşteri başarısı ekibinin yararlanmasını sağlayabilir.

Kahraman olmak için her şeyi kendi üzerinize almak kuruluşunuzun ölçeklenmesine yardımcı olmaz. Hangi işleri yaptığınızı, bunların neden başka bir ekibe ait olduğunu düşündüğünüzü ve diğer ekibin nasıl daha fazla ölçeklenebilirlik, görünürlük ve süreç bütünlüğü sağlayacağını açıkça ortaya koyun.

Sorumlulukları aktardıktan sonra başlangıçta sık sık kontrol edin, ardından kontrolleri azaltın. Yeni sahiplerin geçmiş bağlamı anlamasını ve başarıya hazır olmasını sağlayın.

Tünelin sonunda sizi bekleyen şey, en başta sahip olmanız gereken zamandır: temel ürün çalışmalarına odaklanmak. Müşterileri gerçekten anlamak, tasarım ve mühendislikle yaratıcı biçimde çalışmak, uzun vadede keyif veren, ölçeklenebilir ve kârlı ürünler oluşturmak için zamanınız olur.

Ayrıca işletmeyle derin bir ortaklık kurarak pazara giriş konumlandırmasını, nasıl farklılaşacağınızı, müşterilerin nasıl başarılı olacağını ve hangi yeni segmentlere gireceğinizi anlayabilirsiniz. Zihniniz çok daha berrak hissedecektir.

Bunun zor olduğunu biliyorum; ben de aynı süreçten geçtim ve uzun sürdü. Ancak sonuçta ürünler üzerinde çok daha büyük etki yaratabildim ve müşterilerimi çok daha derin biçimde anlayabildim.

Vermek istediğim ek bir tavsiye de şu: Ürün yöneticileri çoğu zaman başkalarının başarılı olmasını çok ister ve bu nedenle kendilerini sürekli ikinci plana atarlar. Haftanızı değerlendirmek veya bir işi devretmek için 10 dakika ayırmak yerine, bu zamanı yeni bir lansman planı hazırlamakla ya da mühendisler için dokümantasyonu düzenlemekle geçirirsiniz.

Benim için çok faydalı olan yöntem, kendimi ikiye ayırmak oldu. Bir tarafta işleri yürüten “Clement, ürün yöneticisi” var. Diğer tarafta ise “ürün lideri” var. Bu ürün lideri, gelecek hafta daha sürdürülebilir çalışmak için bir plan hazırlamamı talep ediyor.

İsterseniz bu kişiye kendi adınızı vermeyin. Benim ikinci adım Richard. Bu yüzden “Ürün yöneticisi Richard, gelecek hafta daha ölçeklenebilir çalışmak için bir plan hazırlamanı bekliyor” dedim. Richard bunu benden talep ediyordu ve bundan kaçamıyordum.

Böylece ölçeklenebilirliği artırma planını gözden geçirmek için Richard’la bir toplantı ayırdım. İlerleme kaydetmezsem Richard hayal kırıklığına uğrayacaktı. Bu, sürekli uygulayan kişi olmaktan çıkıp stratejinin de sahibi olduğumu hatırlamamı sağladı.

Ürün yöneticilerinin çoğu zaman unuttuğu şey, kendilerinin de kritik bir paydaş olduğudur. Ürün yöneticisi görevini yerine getirirken, ürün yöneticisi olarak kendi ihtiyaçlarını ihmal edemez.

Bu yaklaşım yalnızca sorumlulukları yeniden dağıtmak için değil, kendinize zaman ayırmadan elde edemeyeceğiniz pek çok gelişim fırsatı için de son derece faydalıdır.

Hannah Clark: Alışılmadık taktikleri, özellikle de kendi değerinizi ve ekibe katkınızı dışsallaştırmanızı sağlayan böyle bir yöntemi seviyorum. Kuruluşunuzda yapabileceğiniz en kahramanca şeyin başkalarını ve dolaylı olarak kendinizi güçlendirmek olması gerçekten etkileyici.

Clement, bize katıldığınız için çok teşekkürler. Bu gerçekten harikaydı. İçgörülerinizi her zaman takdir ediyorum. Bu alana katabileceğiniz çok şey var. İnsanlar sizi çevrim içi olarak nereden takip edebilir?

Clement Kao: Beni her zaman LinkedIn’de bulabilirsiniz. Sanırım tek Clement Kao benim. Ayrıca productteacher.com adresinden de ulaşabilirsiniz. Arada boşluk veya tire yok. Genellikle orada bulunuyor ve diğer ürün çalışanlarının başarılı olmasına yardımcı oluyorum.

Hannah Clark: Harika. Orada görüşürüz.

Clement Kao: Beni davet ettiğiniz için teşekkürler.

Hannah Clark: Bizi dinlediğiniz için teşekkürler. Daha fazla harika içgörü, nasıl yapılır rehberi ve araç incelemesi için theproductmanager.com/subscribe adresinden bültenimize abone olun. Podcast’lerinizi dinlediğiniz her yerde The CPO Club’a abone olarak bunun gibi daha fazla sohbet dinleyebilirsiniz.