Yerleşik Bir Şirket İçinde Kurucu Zihniyetinden Nasıl Yararlanılır (Brendan Fortune ile)

Transkripti Okuyun:

Podcast yayınlarımızı bir yazılım programı kullanarak yazıya dökmeyi deniyoruz. Bot her zaman yüzde 100 doğru çalışmadığı için lütfen olası yazım hatalarını mazur görün.

Hannah Clark: Dürüstçe soruyorum: Sizce hangisi daha zor—bir girişimin kurucusu olmak mı, yoksa o kurucu girişimdeki ilk ürün yöneticisi olmak mı? Geçmiş deneyiminize bağlı olarak her iki seçenek için de bir gerekçe sunabileceğinizi düşünüyorum. Bu soru biraz öznel olsa da her iki rolün de bir ürünün başarısına derinden bağlı olduğu konusunda hemfikir olabiliriz. Ancak asıl mesele şu: Bir ürün yöneticisinin başarısı, liderliğin güvenini kazanma ve koruma becerisiyle de bağlantılıdır. Bir kurucunun size güvenmesini istiyorsanız, bir kurucu gibi düşünmeye başlamanız gerekebilir.

Bugünkü konuğum Customer.io’da Genel Müdürlük Başkanı olarak görev yapan Brendan Fortune. Brendan kariyeri boyunca, özellikle sıfırdan bire bağlamında, kurucu zihniyetini benimsemenin ürün yöneticileri için ne kadar büyük bir avantaj sağladığını ilk elden gördü. Birazdan onun gerilimleri yönetmek ile sorunları çözmek arasındaki fark, hızlı başarısız olmak (en sevdiği başarısızlıklar da dahil) ve sıfırdan bire yolculuğunun en duygusal anı hakkındaki önemli görüşlerini dinleyeceksiniz. Hadi başlayalım.

The CPO Club podcastine tekrar hoş geldiniz.

Brendan, bugün bizimle olduğunuz için teşekkürler. Nasılsınız?

Brendan Fortune: Harika gidiyor. Beni davet ettiğin için teşekkürler Hannah.

Hannah Clark: Bize biraz geçmişinizden ve Customer.io’da bulunduğunuz noktaya nasıl geldiğinizden bahsedebilir misiniz?

Brendan Fortune: İnsanların hikâyelerini dinlemeyi her zaman ilginç buluyorum; çünkü genellikle ürün alanına geçiş yaptıkları noktada duruyorlar. Bu yüzden kendi hikâyemi biraz daha ayrıntılı anlatmaya çalışacağım.

Üniversitedeyken Los Angeles’ta BT desteği alanında çalışmaya başladım. Mezun olduktan sonra da büyük bir şans eseri, hiç tanımadığım bir işe alım uzmanı tarafından ses üzerinden IP iletişimi alanında faaliyet gösteren, 150 kişilik bir girişimde çalışmak üzere bulunduğum. Oldukça teknik bir şirketti. Orada teknik destek ekibindeydim. Geceleri ise hâlâ büyük Hollywood hayalimi sürdürdüğüm için film müzikleri yazıyordum.

Zamanla film müziğinin benim için bir işten ziyade hobi olarak çok daha sağlıklı olduğunu fark ettim. Bu yüzden bıraktım. Çalışırken tamamlanan bir MBA programına girdim. Böyle programları daha önce duymamış olanlar için söyleyeyim: Ben de hiç duymamıştım. Yarı zamanlı bir şey gibi; tam zamanlı bir işiniz oluyor, aynı zamanda okula gidiyorsunuz ve üç yıl sürüyor.

Ürün yönetimini de orada öğrendim. Teknoloji becerileriyle yaratıcılık ve liderliğin birleşimi gerçekten çok heyecan vericiydi. Bu nedenle MBA’i, teknik destek alanında dört yıl çalıştığım şirkette yardımcı ürün yöneticisi pozisyonu elde etmek için bir kaldıraç olarak kullandım ve ardından BT’ye geçtim.

Bu kolay olmadı. Zordu. İlk başta bana bu fırsatı vermek istemediler. Muhtemelen haklıydılar ama neyse ki işi yine de yapmaya başladım. Birkaç ay sonra da pozisyonu resmen alabildim. Daha sonra o şirketten ürün direktörü olarak ayrıldım. GoDaddy’de barındırma departmanında bir süre çalıştım.

Ardından bir pazarlama otomasyonu SaaS platformu olan Drip’te çalıştım. Şimdi ise Customer.io’dayım. Ürün alanında başladım; şu anda Genel Müdürlük Başkanı olarak görevim, mühendislik, ürün ve tasarım liderlerinin en iyi işlerini ortaya koymalarına yardımcı olan kurumsal sistemleri oluşturmak. Bunun anlamı çok farklı şeyler olabilir; burada yapılacak çok fazla iş var.

Hannah Clark: Bugün kurucu zihniyetine ve bunun yerleşik bir şirketin kısıtları içinde nasıl göründüğüne odaklanacağız. Bu, bir girişimde olduğundan oldukça farklı bir durum.

Önce konumuzu biraz çerçeveleyelim. Kurucu zihniyetini nasıl tanımlarsınız? Özetleyecek olsanız, bunun uygulamadaki karşılığı sizin için nedir?

Brendan Fortune: Bence bu çok eğlenceli bir konu; çünkü bazen “kurucu zihniyeti” ifadesini duymak bana tehditkâr geliyor. “Ben hiç kendi şirketimi kurmadım. Kurucu zihniyetine sahip olabilir miyim? Bende bir sorun mu var?” diye düşünüyorum.

Ürünler geliştirmeye çalışıyorsam neden kendi şirketimi kurmadım? Ancak yıllar boyunca dört farklı kurucuyla çalıştıkça konuya bakışım değişti. Bana göre kurucu zihniyeti, başkasının işini takip etmek yerine kendi işinizi yaratmaya yönelik bir eğilimdir. Bu, oluşturduğunuz yeni bir ürün olabilir veya yeni bir felsefe olabilir.

Yeni bir yönetim yaklaşımı da olabilir. Aslında her şey olabilir. Ancak belirleyici davranış şudur: Bir zorlukla karşılaştığınızda içgüdünüz, çıkış yolunuzu kendiniz yaratmak mı olur, yoksa cevapları kendi dışınızda mı ararsınız? Bence kurucu zihniyeti, çıkış yolunuzu yaratmanızdır. Bu, başkalarının söylediklerini tamamen görmezden gelip her şeyi kendiniz yapmanız anlamına gelmez; ancak başka kaynaklarda bulunan malzemelere ve fikirlere, onları gerçekten derinlemesine anlamadığınız sürece doğal olarak şüpheyle yaklaşmanız anlamına gelir.

Kurucu zihniyeti benim için bu demek. Bunun nasıl uygulanabileceğine dair birkaç örnek düşünebilirim. Bu bir Ürün Yöneticisi podcasti olduğuna göre, ürünle ilgili bir örnek vereyim. GoDaddy’de işe alındığımda liderlik ekibi bana “Bulut barındırma ürünü geliştirmene ihtiyacımız var” dedi.

Bu, Amazon Web Services’ın nispeten ilk dönemleriydi. Sanırım Google da bu alana yeni girmişti. GoDaddy de “Bu işte bizim de bir şansımız var” diye düşünüyordu. Bana yapmam gerekenin bu olduğunu söylediler. Üç ay sonra geri dönüp “Hayır, bu iş için doğru fikir değil” dedim.

Bunun yerine Amazon Web Services üzerinde yönetilen hizmetler işi geliştirmemiz gerektiğini söyledim. O dönem bu oldukça tartışmalı bir plandı. Bazı meslektaşlarım ve yöneticilerimle konuştuğumu hatırlıyorum. “Bir dakika, senin bunu yapmaman gerekiyordu. Bunun siyasi sonuçları ne olacak?” gibi bir hava vardı.

Bence burada kurucu zihniyeti, gerçekten inandığınız şeyi mümkün olduğunca açıkça söylemeye çalışmanızdır. Bir şeyi tam olarak anlamıyorsanız, doğru olduğunu düşündüğünüz veya başka birinin doğru olduğunu düşündüğü şeyi söylemek yerine kendi inancınızı ortaya koyarsınız. Bunun birkaç başka uygulaması da var. En sevdiklerimden biri, biraz teknik olduğu için, Genel Müdürlük Başkanı olarak çalıştığım döneme ait bir operasyon örneği.

Customer.io’da, teknik destek, müşteri başarısı veya satış gibi müşterilerle doğrudan iletişim kuran ekiplerimizin mühendislik, ürün ve tasarım departmanına soru sorması ya da sorunları iletmesi gereken bir süreç vardı. Hatalar veya başka konular için.

Uzun süre boyunca süreç şöyleydi: Bir insan sisteme girip kayıt oluşturuyordu. Sonra bir mühendislik yöneticisi kayıtları inceliyor, hangi ekibe atanacağına karar veriyordu. Bu oldukça zahmetli bir süreçti. İnsanların ne kadar meşgul olduğuna bağlı olarak kayıtlar bazen bir saat, bazen bir gün orada kalıyordu.

Karar, “Bunu ya bir insan yapacak; bir mühendislik yöneticisi bu kayıtları sınıflandıracak ya da başka bir insan, örneğin teknik destek çalışanı, hangi ekibe ait olduğuna karar verecek” şeklinde çerçevelenmişti. Mutlaka bir tür manuel inceleme yapılması gerektiği düşünülüyordu. Bence kurucu zihniyetinin bir başka örneği de yeni teknolojileri uygulamaktır.

Bu durumda çok basit bir yapay zekâ Zapier LLM botu kullandık. Bot, daha önce oluşturulmuş kaydın girdisini alıyor, inceliyor, bunu ekiplerin sorumlu olduğu özellik alanlarından biriyle eşleştiriyor ve otomatik olarak atıyordu. Kayıtlarımızın neredeyse tamamı bu şekilde anında önceliklendiriliyor. Önceden ise bu işlem uzun zaman alıyordu.

Bu da size “Ya böyle çalışmalı ya da şöyle çalışmalı” şeklinde sahte bir ikilem sunulduğunda, işlerin yürümesinin başka bir yolu olabileceğini gösteriyor. Bence kurucu zihniyetinin ortaya çıkardığı şeylerden biri de bu.

Hannah Clark: Evet, sanırım burada kaynakları verimli kullanmaya, daha azıyla daha fazlasını nasıl başarabileceğimize ve çözümler konusunda nasıl yaratıcı olabileceğimize vurgu yapılıyor. Yaratıcılığın kısıtlamalarla beslendiği fikrine gerçekten inanıyorum. Bu da biraz o zihniyete benziyor.

Biraz yakınlaşıp kurucu zihniyetinin sıfırdan bire ürün projelerine nasıl uygulandığından bahsedelim. Tamamen yeni bir ürün geliştirmeye çalışan bir ürün yöneticisinin karşılaşacağı temel zorluk sizce nedir?

Brendan Fortune: Bu soruyu çok seviyorum. Aslında konuyu biraz tersine çevireceğim. Bence böyle bir durumda ürün yöneticisinin karşılaştığı temel zorluklardan biri kurucu zihniyetinin üstesinden gelmektir. Bu ilk bakışta mantığa aykırı gelebilir; çünkü yeni bir şey yaratıyorsanız elbette yaratıcı düşünmeniz gerekir.

Ancak kurucu zihniyetinde bir tehlike de var. Bu tehlike, “Bunu ben yarattım, dolayısıyla tamamen bana ait” duygusundan kaynaklanıyor. Şunu sorayım: Birilerinin bir projeden “benim bebeğim” diye bahsettiğini hiç duydunuz mu? Duyduysanız, bunun bir nedeni var. Sahiplenme duygusu o kadar güçlü olabiliyor ki proje bir çocuk gibi hissediliyor. İnsanlar bazen bunu şaka olarak söylüyor ama benim deneyimimde bu durumların bazılarında komik bir taraf yok.

Sıfırdan bire bir şey geliştirmek için bir ekibe katıldığınızı ve aynı zamanda gerçekten bir ekip ile ürün oluşturmaya çalışırken kurucu zihniyetini uygulamak istediğinizi varsayalım. Ben bunu yapmanın tek yolunun, ebeveynlik yolculuğunu paylaşmak olduğunu düşünüyorum. Benzetme bu kadar ileri gider mi bilmiyorum ama birlikte ebeveynlik yapmanız gerekir. Yani bu işe yaslanın. Bir çocuğu büyütmek için bir köy gerekir. Bence temel zorluklardan biri bu.

“Fikirlere benim sahip olmam gerekiyor, bunu benim sahiplenmem gerekiyor, bütün kararları benim vermem gerekiyor” düşüncesine kapılmak çok kolaydır. Ancak bu yaklaşımın, işi bir ekiple yürütmekten daha fazla başarısızlığa yol açtığını düşünüyorum. Dolayısıyla temel zorluk, işi tek başına yürütmeye çalışmaktır. Fakat sıfırdan bire gibi tehlikeli bir yolculuğa çıkarken, en başından itibaren doğru insanları ekibe katmanız gerekir.

Bu ifadeyi James Collins’in İyi’den Mükemmel’e kitabından ödünç alıyorum. Hâlâ çok sevdiğim bir kitap. Artık biraz eskidi ama içinde gerçekten harika bilgiler var. Buradaki fikir şu: Nereye gittiğinizi veya tam olarak ne inşa ettiğinizi bilmeden önce, yolculukta kime ihtiyacınız olduğunu anlayabilirsiniz. Bu, en azından benim için, sezgilere aykırı bir başka düşünceydi.

“Bu işe katılın, şu işi yapmanıza ihtiyacım var” diyebilmeniz gerekmez mi? Sorumlu davranmak bu değil mi? Ancak kitaptaki “otobüse doğru insanları almak” kavramı şunu söylüyor: Güçlü ve zayıf yönlerinizi bilmeli, zayıf yönlerinizi mümkün olduğunca tamamlayan güçlü yönlere sahip insanları bulmalısınız.

Bu, yapboz parçalarının birbiriyle iyi şekilde birleşmesiyle ilgilidir. Bence kurucu zihniyetinin veya sahiplenme eğiliminin, yani “bu benim bebeğim” anlayışının üstesinden gelmenin yolu budur.

Hannah Clark: Ebeveynlik benzetmesini sürdürecek olursak, bir partner bulmak istersiniz. Çocuk yetiştiriyorsanız, bazı ortak değerlere sahip olan ama aynı zamanda zayıf yönlerinizi dengeleyen ve güçlü yönlerinizi tamamlayan bir partner bulmak istersiniz. Bence bu gerçekten iyi bir benzetme.

“Otobüse doğru insanları almak” fikrini biraz daha açmak istiyorum. Bunun gerçek hayatta nasıl uygulanabileceğine dair soyut bir yaklaşım geliştirmek kolay. Ancak deneyiminize göre, otobüste kimin olması gerektiğini nasıl değerlendiriyorsunuz? Bu güçlü ve zayıf yönleri nasıl belirliyorsunuz?

Brendan Fortune: Basit birkaç örnekle başlayalım. Diyelim ki teknik açıdan bir dâhisiniz veya teknik bir ürün yöneticisisiniz. Ancak ekip yönetmeye yardımcı olan hikâye anlatımı ve karizma konusunda iyi değilsiniz. Bu çok yaygın bir durum.

Muhtemelen aramanız gereken kişi budur. Bu durum, özellikle yerleşik bir şirkette yeni bir ürün geliştirirken geçerlidir. Savunuculuk çabanız yalnızca ürünü satın almaya ikna etmeye çalıştığınız müşterilerle sınırlı değildir. Şirket içindeki insanları, özellikle liderliği de ikna etmeniz gerekir; çünkü bu işe insan, enerji ve para aktarıyorsunuz. Dolayısıyla bu beceriye sahip olmanız gerekir. Bunun sizde olmadığını biliyorsanız, aramanız ve ekibe katmanız gereken kişi bu olabilir.

Birkaç örnek daha vereyim. Bu benim de başıma geldi. Hakkında fazla bilgi sahibi olmadığınız bir ürün geliştirmeniz istenirse; alanı, pazarı ve müşterileri henüz anlamıyorsanız, bu bilgileri bilen birini bulmalısınız. Ya da kendinize bu ürünü yönetmek ve sıfırdan geliştirmek için doğru kişinin siz olup olmadığınızı sormalısınız.

En büyük risklerden biri, alanı gerçekten anlamayan, o alanda yaşamamış ve çalışmamış birinin liderlik pozisyonuna getirilmesidir. Bir alanı gerçekten tanımak uzun zaman alır. Ben bunu daha önce hızlıca öğrenebileceğimi düşünerek hata yaptım ve başarısız oldum.

Hannah Clark: Evet, ürünü anlayabilmek için kullanıcı girdilerine, geri bildirimlere ve kendinizi temel bir anlayış seviyesine taşımak için yapmanız gereken tüm öğrenme sürecine ne kadar yoğun şekilde güvenmeniz gerektiğini hayal edebiliyorum. Böyle bir pozisyonda olan pek çok kişi için bunun ne kadar büyük bir zorluk olabileceğini görebiliyorum.

Biraz da hızlı başarısız olmaktan bahsetmek istiyorum. “Hızlı başarısız olmak” neredeyse bir slogan gibi. Pek çok ekip kültürü bunu fikir olarak benimsiyor ama bunun pratikte ne anlama geldiğini nadiren netleştiriyoruz. Örneğin, bir fikrin başarısız olduğunu söylemeden önce ona ne kadar zaman ve çaba ayırmalıyız?

Başarısızlığı nasıl tanımlarız? Katkı sağlayan kişilere “Bunun işe yaradığını düşünmüyorum” deme iznini nasıl veririz? İnsanlar psikolojik güvenliğe sahip mi? Hızlı başarısız olma kültürünü benimsemek ve bunu bir ekipte pratik olarak yönetmek için ne önerirsiniz?

Brendan Fortune: Bu soruyu seviyorum. “İnsanlar bunu söylüyor ama gerçekten uyguladıkları veya inandıkları şeyle örtüşüyor mu?” şeklindeki çerçeve bana çok tanıdık geliyor. Hızlı başarısız olma fikrinde bir değer var ama bu ifade genellikle yanıltıcı biçimde kullanılıyor.

“Hızlı başarısız ol” ifadesini, istediğim kadar başarısız olabileceğim şeklinde düşünmek kolay. En azından benim deneyimim bu yönde oldu. Bunun tam tersi de yaşanabiliyor: “Hızlı başarısız ol” deniyor ama bunun kabul edilebilir olduğuna dair gerçek bir beklenti bulunmuyor. Başarısız olduğunuz anda hemen bir değişiklik yapılıyor.

Burada Amazon’un liderlik ilkelerinden birini düşünüyorum: Liderler çoğu zaman haklıdır. Kardeşim bir süre Amazon’da çalıştı. Bu konu hakkında konuştuğumuzda bana “Bu liderlik ilkesi saçmalık. Ekibini güçlendirmen bekleniyor. Kararları liderlerin vermemesi gerekir” demişti.

Bu biraz farklı bir tartışma ama bence hızlı başarısız olma fikri aslında çoğu zaman “çoğu zaman haklı olmalısınız” anlamına geliyor. Evet, bazen başarısız olursunuz ama sonunda başarılı olmak için başarısızlıklar yoluyla hızlıca öğrenirsiniz.

Bu bizi başarıyı ve başarısızlığı nasıl tanımladığınız sorusuna getiriyor. Klasik bir akıllı insan sorusu vardır: Bir toplantının ortasında biri bir projeyi sunarken “Evet, kulağa harika geliyor ama başarı ölçütleriniz neler?” diye sorarsınız. İşte o an herkes durur.

Bu iyi ve düşündürücü bir sorudur. Aklınızda bazı başarı ölçütleri olmalıdır. Ancak bazen hiçbir adım atmadan önce başarı ölçütlerini kesin biçimde belirlemeniz gerektiği ve bu ölçütlerin değişmeden kalacağı varsayılır. Sonuç da ikili bir değerlendirmeye indirgenir: Bu başarılı mı, başarısız mı?

Belki bazı yerlerde bu yaklaşım işe yaramıştır. Ancak sıfırdan bire geliştirdiğim hiçbir üründe işler bu şekilde sonuçlanmadı. Şu anda çalıştığım Customer.io’dan aklımda taze olan bir örnek vereyim. Üzerinde çalıştığımız en son ürün Customer.io Data Pipelines olarak adlandırılıyor.

Bu bir müşteri veri platformu. Daha önce duymamış olanlar için, şirketin tüm verilerini tek bir noktada birleştiren bir veri entegrasyon platformu. Müşterilerinizin adları, ürün içindeki davranışları ve diğer verileri burada toplanıyor. Daha sonra bunları CRM, Close veya Salesforce gibi satış sistemlerine ya da Customer.io ve Drip gibi pazarlama otomasyonu araçlarına gönderebiliyorsunuz.

Bu proje üzerinde yaklaşık bir buçuk yıl önce çalışmaya başladığımızda planladığımız başarı ölçütleri şunlardı: CDP rakiplerinden müşteri kazanmak ve bunu daha düşük fiyatlı bir ürün sunarak yapmak. CDP’nin metalaşacağına bahse giriyorduk; yani fiyatların aşağı doğru yarışacağı bir sürecin başlayacağını düşünüyorduk.

Ayrıca yalnızca bu ürünü kullanan yeni müşterilerden çift haneli aylık yinelenen gelir elde etmek istiyorduk. Yerleşik pazarlama otomasyonu ürünlerimiz vardı ve yeni ürünü bunlara ekliyorduk. İnsanların diğer ürünü kullanmasına gerek kalmadan yalnızca bu ürün için ödeme yapmasını sağlayacak kadar iyi bir ürün geliştireceğimizi düşünüyorduk.

Finans Direktörümüze de ekibin maliyetini karşılayacak kadar para kazanacağımızı söyledik. Ürünü piyasaya sürdükten altı ay sonra bu başarı ölçütlerinden kaçına ulaşmıştık, tahmin edin.

Hannah Clark: Sıfır veya bir derdim.

Brendan Fortune: Evet. Sıfır. Ama projeyi durdurmadık. Peki neden? Bunun batık maliyet yanlılığı olduğunu mu düşünüyorduk? “Bu projeye çok yatırım yaptık, devam edelim” mi diyorduk? Belki daha fazla zamana ihtiyacımız olduğunu mu düşünüyorduk? Hayır. Bu ölçütlerde başarıya ulaşamamış olsak da beklemediğimiz başka alanlarda başarı elde etmiştik.

Daha önce hiçbir müşteri veri platformu kullanmamış müşterilerin ürünü benimsemede en başarılı grup olduğunu gördük. Ayrıca yeni bir ekonomik büyüme döngüsünün başlangıcını da gözlemledik. Ürünü çoğu CDP’nin fiyatlandırdığı şekilde, API çağrıları üzerinden fiyatlandırmıştık. Bu değişken bir fiyatlandırma modelidir.

İdeal olarak sisteme ne kadar fazla veri gönderirseniz üründen o kadar fazla değer elde edersiniz ve bunun sonucunda sizden daha fazla ücret alırız. Ürünü benimseyen müşterilerin kullanımının aydan aya arttığını gördük. Bu, Customer.io’nun ekonomik büyüme döngüsü için önemliydi.

Rakipleri daha düşük fiyatla kazanamadık. Rakip ürünleri kullanan kişilerin çoğu “Bu iyi ama indirim alabilirim” diyordu. Orada neredeyse hiç ilgi oluşmadı. Büyümemiz çok daha yavaş oldu. Gelirin peşinden gidiyorduk ama aslında zamanla gelire dönüşecek olan ekonomik büyüme döngüsünün peşinden gitmeliydik.

Bu yavaş gelişen bir yapıydı. Bu yüzden ürün yoluna devam etti. Sıfırdan bire bir ürün geliştiriyorsanız başarı ölçütlerinizi dikkatle belirleyin ama bunların zaman içinde değişmesini ve başarının beklemediğiniz başka alanlarda ortaya çıkmasını bekleyin. Bir yerde başarı bulduğunuz sürece proje devam etmelidir. Hiçbir yerde başarı bulamıyorsanız, başarısızlık noktasına o zaman ulaşırsınız.

Hannah Clark: Bu gerçekten aydınlatıcı. Pek çoğumuzun hayatın farklı alanlarında ilişki kurabileceği bir konu. Beklentinizin tam olarak beklediğiniz biçimde gerçekleşmemesi, bundan başka bir değer elde edemeyeceğiniz anlamına gelmez. İleride başka faydalara yol açacak farklı kilometre taşlarına ulaşabilirsiniz.

Başarısızlıklardan söz etmişken sizi biraz zor durumda bırakmak istiyorum. Customer.io’nun dışına çıkalım. Kariyerinizde, hayatınıza en fazla değer kattığını düşündüğünüz en sevdiğiniz başarısızlık hangisi?

Brendan Fortune: Çok ilginç bir soru. “O kadar çok var ki” demek istiyorum ama az önce liderlerin çoğu zaman haklı olduğunu söyledim. Şimdi bunu söylememem gerektiğini düşünüyorum. Yine de çok sayıda sevdiğim hata ve başarısızlık var.

İlk aklıma gelen GoDaddy’de yaşadığım bir olay. Enterprise WordPress adında yeni bir ürün geliştirmeye çalışıyorduk. Bu, ABC.com gibi siteler için web siteleri oluşturan büyük ajanslara yardımcı olmayı amaçlayan bir barındırma ürünüydü.

WordPress’in daha az teknik kişiler için erişilebilir olan esnekliğini korurken, bu ajansların ihtiyaç duyduğu trafik miktarına ölçeklenebilen bir ürün geliştirmeye çalışıyorduk. Pazarda başarılı olmuş bazı mevcut ürünler vardı ve “Tamam, bunu anladık” diye düşündük.

Müşterilerle iyi ilişkilerimiz vardı. Bazı ajanslarda pilot kullanıcılar oluşturmuştuk. Gerekli tüm ilişkiler kurulmuştu. Yaklaşık dokuz ay ile bir yıl boyunca çalıştık ve çoğu mühendislerden oluşan beş veya altı kişilik bir ekibimiz vardı. Ürünü piyasaya sürdükten yaklaşık bir veya iki ay sonra projeyi kapattık.

Çünkü kelimenin tam anlamıyla daha baştan başarısız olacak bir şey geliştirmiştik. Hazırlama ortamından üretim ortamına temiz bir şekilde geçiş yapılamıyordu. Çok akıllıca davrandığımızı düşünmüştük. “Üretimde hiçbir şeyi değiştiremeyecekleri şekilde tasarlayarak ürünü son derece güvenli hâle getireceğiz. Bu döngüden geçmek zorunda kalacaklar ve sistem statik olacak” diyorduk.

Teknik açıdan ne kadar zekice bir çözüm bulduğumuzu düşünüyorduk. Gerçekten de teknik olarak zekiceydi. Ancak müşterilerin bununla hiç ilgilenmediği ortaya çıktı. Bunu doğrulamamıştık; yalnızca onlara ne düşündüğümüzü anlatmış ve “Evet, bu olur” şeklinde baş sallamalarını almıştık. Bu, Anne Testi’ne doğrudan düşmekti.

Buradan öğrendiğim şey şu: Zeki olduğunuzu düşünüyorsanız, gerçekten zeki olduğunuzdan emin olun. Ayrıca ekipte alan konusunda güçlü deneyime sahip hiç kimse yoksa dikkatli olun. Bazı müşteriler sizinle çalışıyor olsa bile temkinli davranın. Ben de dahil olmak üzere ekipte Enterprise WordPress hakkında işe başlamadan önce çok şey bilen kimse yoktu.

Hannah Clark: Anne Testi’ni bilmeyenler için, nasıl çalıştığını kısaca özetleyebilir misiniz? Artık biraz komik bir anlatı hâline geldi.

Brendan Fortune: Bunu şöyle özetlerim: Birine “Bunun harika olduğunu düşünüyor musun?” diye soruyorsanız ve bu kişi sizi gerçekten önemsiyor veya başarılı olmanızı istiyorsa, muhtemelen duymak istediğiniz cevabı alırsınız. İhtiyacınız olan dürüst veya eleştirel geri bildirimi alamazsınız.

“Bunu destekliyorum” demekle “Bunun için para ödeyeceğim” demek arasında büyük fark vardır. Anne Testi budur.

Hannah Clark: Bence bu çok komik. Özellikle Kuzey Amerika’da bunun kültürel bir konu olduğunu da düşünüyorum. İnsanlar “Evet, evet, harika” demeye öylesine alıştırılmışlar ki sonunda onlar için hiç önem taşımayan bir şey geliştiriyorsunuz.

Brendan Fortune: Evet, kesinlikle. Bu konu beni radikal dürüstlük tartışmasına götürüyor. Ken Scott’ın zarar verici empati ile rahatsız edici saldırganlık arasındaki dengeyi anlattığı başka bir çerçeve bu.

Kuzey Amerika’da insanların eleştirel geri bildirimlerini doğrudan ifade etmek yerine destekleyici görünmek istemesini duyduğumda bunu düşünüyorum. Radikal dürüstlüğü ortaya koymanız gerekir; bu da tamamen karşı-kültürel bir tutumdur.

Hannah Clark: Bu konuya sapmanız benim için sorun değil; çünkü radikal dürüstlükten kaçınmamız kültürel olarak öğretiliyor. Özellikle bir ürün ekibinde bunun uygulanmaması nedeniyle binlerce, hatta muhtemelen milyonlarca doların boşa harcandığını hayal edebiliyorum.

Brendan Fortune: Milyarlarca dolar bile olabilir. Çalıştığım şirketlerin hiçbirinde bunun gerçekten iyi yapıldığını söyleyemem. Bunun bir nedeni de kültürün çözülmesi gereken bir sorun değil, yönetilmesi gereken bir konu olmasıdır. Hiçbir zaman tamamen ortadan kalkmaz.

“Artık radikal dürüstlük kültürümüz oluştu, bundan sonra her şey harika gidecek” diyemezsiniz. İşler karmaşıktır ve bu karmaşıklık profesyonel görünmeyebilir. Dağınıklık ile derinlik arasında sürekli bir gerilim vardır.

Birisiyle güven oluşturmaya çalışırken, ilk geri bildirim anına girerken kendi kariyer hedeflerim hakkında bir şeyler anlatırım. “Bu işle gerçekten ilgileniyorum ama kendim için bir yol görüyor muyum emin değilim” gibi şeyler söylerim. Bir şey hakkında açılmak risklidir ve bazen siyasi bir hesaplama gibi algılanabilir. Oysa güven kurmaya çalışırken istediğiniz şey bunun tam tersidir.

Radikal dürüstlük için güven gerekir. Bu, “Ben ne düşünüyorsam onu söylerim ve haklı olduğumu varsayarım” yaklaşımından farklıdır. O yaklaşım da zehirlidir; sadece başka türden bir zehirdir.

Bazı yöneticiler bu tür gerilimleri azaltmak ister. İnsanların fikir ayrılığı yaşadığını gördüklerinde “Çatışmayı durduralım, ortamı sakinleştirelim” derler. Ancak böyle yaptığınızda radikal dürüstlüğü de ortadan kaldırırsınız.

Radikal dürüstlük çatışma içerir. Biz genellikle çatışmayı sağlıklı şekilde teşvik etmek yerine çatışmayı çözmeye odaklanırız. Çatışma bir risktir ama aynı zamanda bir ödüldür.

Hannah Clark: Evet. Çatışma aslında bir fırsattır. Bu konuda bir makalemiz de var. Göz atabilirsiniz.

Ancak devam edelim. Gerilimleri yönetmekten bahsetmiştiniz. Gerilimleri yönetmek ile sorunları çözmek arasındaki ayrım hakkında biraz konuşmak istiyorum. Bu, liderlik bağlamında her zaman böyle adlandırılmasa da insan yönetiminin pek çok alanına uygulanan önemli bir kavram.

Bu kavramı biraz açıklayabilir misiniz?

Brendan Fortune: Kendi deneyimimden yola çıkarak konuya ürün yöneticisi perspektifiyle yaklaşayım. Ürün yönetimine başladığımda, teşvik edildiğim şey ürünleri piyasaya sürmekti. Ürünleri piyasaya sürerek müşterilerin sorunlarını çözüyor, ardından ürün çıktığında bir tamamlanmışlık hissi yaşıyorduk.

Elbette ölçekleme ve operasyon süreçleri devam eder ama ürünün piyasaya sürüldüğü bir an vardır. Biletlerle, kullanıcı hikâyeleriyle ve benzeri yapılarla çalışırız. Kullanıcı hikâyeleri tamamlanır. Gördüğünüz ilerleme belirli bir sırayı takip eder.

İnsan yöneticiliği gibi daha geniş etkili bir role geçtiğinizde aynı zihniyeti benimsemek kolaydır: Sorunları belirleyeyim, sonra çözümleri piyasaya süreyim ve sorunlar ortadan kalksın.

Örneğin ürün yöneticileri ekibinin toplantısını yürütme biçiminiz bir çözüm olabilir. Bir gündem belirlersiniz, bazı sorular sorarsınız ve sorunun çözüldüğünü düşünürsünüz.

Gerçek ise şudur: İnsanlar sürekli değiştiği için, ekibinizin üyeleri değişmese bile gerilimler değişir. Sorunlar değişir. Her zaman bir tür dönüşüm vardır. Ayrıca çalışanlarınızı geliştirmeniz gerekir. Onların değişmesini istersiniz ve değiştikçe onları farklı biçimde yönetmeniz gerekir.

Daha önce oluşturduğunuz ve olumlu sonuçlar aldığınız çözümler artık geçerliliğini yitirir. Bu nedenle bunları yönetilmesi gereken gerilimler olarak görmek ve bir şeyi çözdüğünüz anda yeniden çözülmemiş hâle gelebileceğini varsaymak bana yardımcı oldu.

Mümkün olduğunca üretken bir zihniyette kalmalısınız. Bu yorucu olabilir ama kurucu zihniyetiyle bağlantı kurabiliriz. Yaratmayı seviyorsanız bu yaklaşım tam size göredir. Gerilimleri yönetmek kurucu zihniyetine tamamen uyar.

Uyum oluşturmaya ve insan yönetimine gelince de bunu düşünüyorum. Uyum sağlamaya ve yaratmaya hazır olun. Gerilimleri yönetmekten sizi kurtaracak bir uygulama kılavuzu yoktur.

Hannah Clark: Bu fikri çok seviyorum. Bir insan yöneticisi olarak kendinizi her zaman bir çözüm beklememeye hazırlamanız, gerilimleri yönetirken enerjinizi daha iyi kullanmanızı sağlayabilir.

Aynı konudan devam edelim. Uyum fikrini biraz daha ele almak istiyorum. Herkesin ekip bağlamında uyumun ne anlama geldiğine dair farklı bir fikri var ama bu gerçekten kritik. Büyük bir teslimat, örneğin yepyeni bir ürün konusunda bir ekibin uyumunu sağlamak için önerileriniz neler?

Brendan Fortune: Son bir yılda veri hatları üzerinde çalışırken bu konuyu çok düşündüm. İyi çalışan birkaç şey buldum ama bunları uygulamaya çok geç başladım.

İlki bire bir geri bildirim. Burada belirli bir kişiye eleştirel geri bildirim vermekten bahsetmiyorum. Bir örnek vereyim.

Diyelim ki bir yol haritası hazırladım. Sıfırdan bire ürünü bu yıl böyle geliştireceğiz. Bir vizyon panom var, belki bazı taslaklarım da var. Verimli olmaya çalışıp birçok kişiyi aynı odaya toplamak cazip gelebilir. Vizyonu sunarsınız, soru-cevap yaparsınız ve insanların ilgili göründüğünü düşünerek “Harika, uyumu sağladık” dersiniz.

Ancak grup içinde uyum sağlama yaklaşımı işe yaramaz. Beş veya altı kişilik küçük gruplarda bile işe yaramadığını gördüm. Bir veya iki ay sonra, toplantıdaki bir kişinin ne konuştuğunuz hakkında hiçbir fikrinin olmadığını, konuya önem vermediğini, katılım fırsatı bulamadığını ve kendisini dinlenmiş hissetmediğini fark edersiniz.

Kendinizi dinlenmiş hissetmiyorsanız, fikir ayrılığı yaşayıp karara bağlı kalamazsınız; çünkü henüz dinlenmemişsinizdir. Bu nedenle grup formatında paylaşılması gerektiğini düşündüğünüz bir sunum varsa, önce bunu bire bir yapın. İlgili paydaşların geri bildirimlerini bire bir toplayın ve onlara söylediklerini tekrar edebildiğinizden emin olun.

“Bu konuda sizi şöyle duyuyorum. Kafanızın karıştığı nokta burası” diyebilmelisiniz. Uzaktan çalıştığımız için bazen çevrim içi bir beyaz tahta kullanıyorum. İnsanların söylediklerini not olarak panoya ekliyorum. Böylece söylediklerini yakaladığınızı ve onları dinlediğinizi görsel olarak görebiliyorlar.

Özellikle çekirdek ekibiniz için bu alana yeterince yatırım yapın. Liderlik ekibiyle bunu yapmak daha zor olabilir ama özellikle ürünü geliştiren insanlarla bire bir zaman geçirin. Bunu birkaç kez yapmanız gerekir. Otuz dakikalık tek bir toplantı yeterli olmaz.

Liderlik uyumuna gelince, keşke kaynağını hatırlayabilsem ama “öğrenme yol haritası” diye bir kavram var. Yöneticiler, en azından benim deneyimimde, çoğu zaman ilerlemeyi görmek ister. Ne teslim ediyorsunuz? Değer nerede? Para nereye gidiyor? Yatırımın geri dönüşü nerede?

Sıfırdan bire ürün geliştirirken, inşa ettiğiniz şeyin karşılığında para göremediğiniz uzun bir dönem olur. Yöneticiler bunu teorik olarak bilir ama daha önce ürün geliştirmedilerse veya bazen geliştirmiş olsalar bile hızlanmanız için baskı yapabilirler.

“Bu işe yarayacak mı? Ortaya koyduğunuz şey yüzünden aptal gibi görünecek miyim?” şeklindeki temel duygu oldukça sorunlu ve uyumu yok edicidir. Öğrenme yol haritası, henüz para gösteremeseniz bile ilerlemeyi göstermenizi sağlayan bir araçtır.

“Bu özelliği X tarihine kadar piyasaya süreceğiz” demenin yanı sıra şunu söylersiniz: “Bu hafta şu soruları yanıtlayacağız.” Örneğin, bu ürün bağımsız bir ürün mü olmalı, yoksa mevcut ürünümüze entegre mi edilmeli? Bu, öğrenme yol haritanızdaki sorulardan biri olabilir.

Müşteri görüşmeleri, pazar analizleri ve farklı sinyaller toplarsınız. Sonra bir belge hazırlayıp “Sorunun yanıtı bu. Kanıtlarımız bunlar” dersiniz. Bu yanıtı ve öğrenmeyi teslim edersiniz.

Daha sonra örneğin fiyatlandırmaya geçebilirsiniz. Çok ürünlü bir yapıda değişken fiyatlandırma mı yoksa sabit fiyatlandırma mı uygulamalıyız? Bu, ilerleyebileceğiniz bir karar ve öğrenme alanıdır.

Kaç müşteri geliştirdiğiniz şey için sözleşme imzalayıp ödeme yapar? Anne Testi’nin tam tersi budur: Henüz ürüne sahip değilken bir müşteriye para ödemeyi taahhüt eden bir belge imzalatabilir misiniz? Vizyonu satabilir misiniz?

Sıfırdan bire ilerlemek için sorguladığınız varsayımları ve sormanız gereken soruları düşünün. Bunları bir öğrenme yol haritasına yerleştirin. Özelliklerin yanı sıra öğrenme alanındaki ilerlemeyi de gösterin. Bu, yönetici düzeyinde uyum sağlamanın iyi bir yoludur. Yöneticiler süreci takip eder, bir şeylerin ilerlediğini görür ve görüşlerini paylaşabilir. Bu da uyum oluşturmanın başka bir yoludur.

Onları sürece dahil etmeli ve ortak çözüm geliştirmeye davet etmelisiniz.

Hannah Clark: Bahsettiğiniz gibi gerilimi yönetmek için mükemmel bir öneri.

Bitirmeden önce, sıfırdan bire sürecinin biraz “bu sizin bebeğiniz” gibi olduğunu ama bütün bebeklerin büyümesi gerektiğini söylemiştiniz. Bu nasıl görünür?

Başarılı biçimde sıfırdan bire taşıdığınız bir üründen bir adım geri çekilmek neden bu kadar zor? Sahiplenme veya projeye karşı ebeveynlik duygusu hissettiğimizde bu değişimi nasıl yönetebiliriz?

Brendan Fortune: İlk olarak, daha önce konuştuğumuz gibi, bunu yapmanın en iyi yolu ürünün en başta sizin bebeğiniz hâline gelmesine izin vermemektir. Bunu başarabilirseniz ideal olan budur. Ancak bu özellikle sıfırdan bire ürünlerde çok zordur; çünkü buna herkesten daha fazla inanmanız gerekir.

Ürünün savunucusu sizsiniz. Ruhunuzun bir kısmını ona aktarırsınız. Bunu yaptığınızda ürün kimliğinizin bir parçası hâline gelir. Bu nedenle zor bir şeydir.

Önereceğim şey, gerektiğinde kendi tavsiyemi de uygulamam gerekiyor, bir tür bitiş noktası belirlemenizdir. Devir sürecinin kontrolünü elinize alın; böylece olayın sizin başınıza geldiğini değil, onu sizin gerçekleştirdiğinizi hissedersiniz.

Bunun için doğru zamanı bulabilirsiniz. En son piyasaya sürdüğüm ürün Data Pipelines için bu zaman, genel kullanıma açıldıktan birkaç ay sonraydı. İşletmenin Genel Müdürlük Başkanı için başka bir ihtiyacı ortaya çıktı ve ben bu göreve geçtim. “Şimdi başka birini işe almak için iyi bir zaman” dedik.

Bu rol için kime ihtiyacımız olduğuna dair bir fikrim vardı. O kişiyi işe alıp ekibe katılmasını sağlayacaktım. Zamanlamayı siz seçebilirseniz, duygusal açıdan süreç biraz daha kolay olabilir.

Bir de Yoda’ya ait bir söz var. Bunu aslında kimin yazdığını bilmiyorum; yeni Star Wars filmlerinden birindeydi. Yoda’nın sesini taklit etmeyeceğim, bu konuda çok kötüyüm. Ama kabaca şöyle: Öğrendiklerinizi, gücünüzü ve ustalığınızı aktarın; zayıflıklarınızı ve başarısızlıklarınızı da aktarın. Sonra “Biz, bizden sonra gelenlerin ötesine geçtikleri şeyiz” gibi bir şey söylüyor. Bu, tüm ustaların gerçek yüküdür.

Kendinizi ürünün ustası olarak görmek garip olabilir ama fikir benzer: “Bunu ben büyüttüm, bu bana ait.” Gerçek başarı ise bir başkasının bu işi sizden daha iyi yapabilmesidir.

Bence bu, insan yönetimi için de geçerli. Sıfırdan bire projelerde bunu gerçekten benimseyebilirseniz, devir teslim sürecinden heyecan duymak kolaylaşır.

Hannah Clark: Bu çok güzeldi. Yoda’nın sesini taklit etmediğiniz için sizi affetmem gerekiyor.

Brendan, bu çok güzel bir sohbetti. Katıldığınız ve tüm harika görüşlerinizi paylaştığınız için gerçekten teşekkür ederim.

İnsanlar sizi nereden takip edebilir veya çevrim içi olarak sizinle nasıl iletişim kurabilir?

Brendan Fortune: LinkedIn üzerinden bağlantı kurmaktan memnuniyet duyarım. Sorusu olan veya özellikle bu yöntemleri denediği hâlde işe yaramadığını gören biri varsa bunu duymak isterim. Twitter’da da varım. Kullanıcı adım @mnproductmgr veya product MGR; biraz kafa karıştırıcı bir kullanıcı adı. Minnesota’da yaşıyorum, MN de buradan geliyor.

Hannah Clark: Değeri yeterince bilinmeyen bir eyalet. Bundan bahsetmiştik.

Pekâlâ, Brendan, çok teşekkürler. Yakında tekrar konuşmak dileğiyle.

Brendan Fortune: Tamamdır. Teşekkürler Hannah.

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