Skip to content

Bölüm Notları: Ömer Özener ile ürün kültürü oluşturma

Bu bölümün notları Ezgi Samut tarafından hazırlanmıştır. Bölümü buradan dinleyebilirsiniz.


Farklı coğrafyalarda, farklı sektörlerde ve farklı product rollerinde bulunmuş biri olarak iyi pm nedir?

Coğrafyadan coğrafyaya değişen bir ekosistem var fakat şirketten şirkete değişen de bir kavram. Bu yüzden asıl belirleyici şirket kültürü oluyor. Şirket kültürü iyi pm kavramına etki eden anahtar kelime. Çünkü çok iyi pmler bile belli metodolojilerin iyi çalışmadığı şirketlerde görevini çok iyi yapamayabilir veya ürün kültürü çok iyi oturmuş şirketlerde belli metodolojilere hakim olmayan pmler çok iyi işler başarabiliyor.

Kavram : Ürün kültürü 

Peki iyi ürün kültürü nedir?

Erken aşama startuplarda kurucu genelde business veya teknoloji kökenli oluyor ve bir problem/fırsat görüyorlar ve o problemi çözmek/fırsatı değerlendirmek için yola çıkıyorlar. Genelde startuplarda PM kurucu ekipte yer almıyor. Bu rolü kuruculardan biri üstleniyor. Ama startup ve haliyle ekipler genişledikçe bir product manager ihtiyacı doğuyor. Ama burada şöyle bir hata yapılıyor: product manager diye işe alınan kişi genelde product owner oluyor aslında. Yani mühendislik ekipleri ile birlikte çalışan, backlogu önceliklendiren işin müşteri/kullanıcı trendleri ile ilgili olmayan bir ilk hali oluyor. Bu durum böyle devam edince de aslında o organizasyon Feature Factory ‘e dönüşüyor.

Kavram : Feature Factory

Ne demek bu Feature Factory ?

Feature factory müşteriden gelen talepleri çeşitli metriklerle analiz etmeden metodolojik olarak önceliklendirmeden sadece yeni özellik çıkarmaya odaklanarak çalışan ekipler olarak tanımlanabilir. Bir feature’ı gündeme alırken: 

  1. O feature’ın ürün vizyonuna katkısı ne oldu?
  2. Müşterinin hangi problemlerini ne derece çözdü?
  3. Ne kadar yeni müşteri kazandırdı?
  4. Var olan müşterilerin hangi KPI’larını (Key Performance Indicator)  nasıl etkiledi?

gibi metrikler analiz edilmeli ve bu şekilde o feature çıkacak mı, çıkacaksa nasıl önceliklendirilecek belirlenmelidir.

Kavram : KPI (Key Performance Indicator)bir şirketin temel iş hedeflerine ulaşmasında ne kadar etkin olduğunu gösteren ölçülebilir bir değerdir. Organizasyonlar KPI’ları hedeflerine ulaşmakta ne kadar başarılı olduklarını değerlendirmek için birden fazla seviyede kullanırlar. Yüksek seviyeli KPI’lar, firmanın genel performansına odaklanırken, düşük seviyeli KPI’lar satış, pazarlama ya da çağrı merkezi departmanlarındaki süreçlere odaklanırlar.

Bir product ekibinin çıktısı feature listesi olmamalı. Ekiplere product vizyonuna dahilinde belirlenen KPI’lar ve bu KPI’lara yönelik hedefler verilmeli ki problemi çözmek için yeterli alan bulabilsinler. Bu anlamda bir product manager’ın başına gelebilecek en kötü şey kullanıcıdan kopmaktır.

Product ve satış ekiplerinin karşılıklı iletişimi ve sürecin işleyişi nasıl olmalıdır?

Feature bazlı çalışma mantığını belirleyen ve bu tarihte bu özelliğin çıkması lazım şeklinde yaklaşımları olan satış ekipleri hem kendi içinde hem de product ekibi için iyi ve örnek bir çalışma kültürüne sahip değildir. Biz bu tarz durumlara çözüm getirmek için product manager’ların müşteriye satış ekipleri ile beraber gitmelerini sağladık. Ayrıca satış ve product ekiplerine 

  1. Product nasıl geliştiriliyor?
  2. Discovery nedir nelere dikkat edilir?
  3. Bir problemi nasıl define ediyoruz?
  4. Nasıl design ediyoruz?
  5. Nasıl delivery e geçiliyor delivery tarafında neler oluyor? 

 içeriğinde eğitimler aldırdık. Burada ekip liderinin rolü çok önemli. Ekip lideri satış ekiplerine product ekibinin nasıl çalıştığını çok iyi bir şekilde anlatmalı ve bu çalışma süreçlerinin bir kural olduğunu ve uyulması gerektiğini belirtmeli. Fakat bu satış ekibini tamamen aradan çıkaralım demek de değildir. Sonuçta onların KPI’ları da satmak. Sürecin beraber yürütülmesi gerekiyor. Ayrıca müşterinin iyi analiz edilebilmesi için tüm müşteri grupları ile iletişim halinde olunması gerekir. Çünkü karar alan başka ve ürünü kullanan başka olabiliyor.

Yönetim tarafında ürün vizyonu nasıl oluşturulur?

Başlangıçta kurucu product rolünü kendi üstleniyor. Ve kafasındakileri bir şekilde erken aşama ürüne aktarıyor. Eğer geçiş yapamıyorsa kendi kafasındaki özellikler aşağı yukarı bir şekilde ekiplere dönmüş oluyor. Ama bir süre sonra son kullanıcıdan giderek uzaklaşılıyor ve o noktadan sonra yapması gereken en iyi şey bir product manager işe alıp ona feature vermektense product discovery yetkisi vermesidir. Yönetim ekibinin sorumluluğu iş modelini iyi anlayıp odakları çözmüş olarak ekibi yönlendirmektir. Genel olarak ürünün nereye gitmesi gerektiği konusunda rehberlik etmeli ama bunu feature seviyesine inmeden yapmalı. Ayrıca insan ilişkileri tarafında güven ortamının yaratılması da çok önemli. Güven ortamının olmadığı bir ortamda ekipleri güçlendiremiyorsunuz, haliyle yine ürünü analiz etmek ve KPI’lara odaklanmak yerine feature üretmeye başlıyorsunuz.

Head of Product Rolü

Bazı şirketlerde hala ayrı bir product ekibi yok. Benim tercihim product ekibinin ayrı olması yönünde. Yönetici product kökenli değil ise veya product kültürü yok ise yine pazarla ve satış ekiplerinin altında kısa vadeli hedefleri gerçekleştirmek için feature çıkarmaya odaklanılmış bir ekiple karşılaşıyoruz. Ama head of product altında organize olan ekiplerde daha uzun vadeli düşünebilme, en üstten en alt hiyerarşiye kadar aynı dili konuşabileceği bir product vizyonu geliştirebilme ve de planlamalarını belirli metodolojiler (bu metodoloji OKR olabilir) üzerinden belli KPI’lar ile yönetebilecekleri bir yapı kurma tarafında çok başarılı oluyorlar.

Kavram : OKR (Objectives and Key Results) modeli, özellikle çevik (Agile) şirketlerde geçerli olan yenilikçi bir yönetim yöntemdir. Hedefler (Objectives) ve Anahtar Sonuçlar (Key Results) takip edildiği bir metodoloji anlamına geliyor.

Business metrikler ile ürün metriklerini nasıl bir araya getirebiliriz?

Ekipleri yalnızca feature üretmeye iten şey KPI’ları iyi anlamamış olmaları olabilir. Böyle olunca da etki odaklı ekipler oluşturmak zorlaşıyor. Bu durumda KPI monitor etmek yerine feature çıkarmaya odaklanılıyor. Ama her şeyi KPI’lar ile anlatabileceğimiz durumda müşteriden gelen her talebi kabul etmeyerek etkiye odaklanabilirler. Böylece çıkacak olan özellikleri analiz ederek hangi problemi nasıl çözdüğünü hangi metriğe ne kadar etki ettiğini analiz ederek değerlendirebilirler. Böylece satış ekipleri kendi aralarındaki metodolojileri tartışıp önceliklendirmeyi yapmış oluyorlar ve kendi aralarında o business case’i daha mantıklı hale getiriyorlar. Bu durum birden fazla satış ekibi olduğunda ekipler arasındaki benim önerilerim dikkate alınmıyor problemini de çözen bir durum. Bu dinamikleri önce kendi aralarında hissederek ve uygulayarak nasıl düşünmeleri gerektiğini de öğreniyorlar ve böyle metriklere dayanmayan benim önerim senin önerin sorununu da çözüyor. Bu sistem şeffaflığı da artırıyor. Böylece bütün ekiplere etki odaklı olmayı da öğretiyorsun.

İyi ürün kültürüne geri gelirsek…?

En başta müşterinin problemini anlamak. Her etkinin müşteriden çıkması. Bütün hedeflerin ve ürün vizyonunun etki odaklı kurulması. Etki odaklı KPI’ları kurmanın zorluğu şirketten ve üründen dolayı değişebilir. B2C’de B2B’ye göre durum daha zor. Hem kısıtlı kullanıcı hem de kısıtlı dataya sahip oluyorsunuz.

Kavram : B2B – bir firmanın ürün ve hizmetlerinin başka bir firmaya pazarlanması ve B2C – şirketlerin tüketicilerle direkt olarak kurduğu ticari ilişki

Ürün yöneticiliğinin en zor kısmı nedir? Kendini geliştirmek için neler yapıyorsun?

Zor ama heyecanlı. Bir pm olarak çok farklı alanlarda bilgili olmanız gerekiyor. Bir pm olarak bütün süreci düşündüğünüzde bütün ekiplerin dinamiklerini, ürünlerin etkilerini sektörün ihtiyaçlarını iyi bilmek gerekiyor. Burada her zaman okuma araştırma değil iç güdü de gerekli. Metodolojiyi iyi uygulayıp etkiyi iyi tahmin edemeyen pmler olduğu zaman iş zorlaşıyor.

Şu anki odağım product management değil biraz daha ekip yönetimi tarafında, product ekiplerini daha iyi nasıl daha iyi koçluk edebilirim yönünde.

Bir pm’i işe alırken nasıl sorular soruyorsun?

Belli büyük şirketler deneyimsiz pm’i işe almıyor. Bu sebeple deneyim olmalı. Ama product manager ve project manager farklı kavramlar. Birçok pm deneyimi olduğunu söyleyen kişi aslında project ya da program manager/owner. Startup kökenli pmlerin product kültürü daha iyi oluyor. Daha geleneksel şirketlerde çalışan pmlerin etki odağı daha çok odağı koordinasyon tarafında oluyor ve sahiplik çok olmuyor. 

Kişisel özellikleri değerlendirdiğimde teknik odaklı pmlerdense iş odaklı pmleri tercih ederim. Mühendislik ekipleri ile çok yakın çalışma deneyimi olmasa bile ya da kendisi teknik kökenli gelmese bile commercial mindseti varsa işin/ geliştirdiği ürünün yaratabileceği ticari etkiyi iyi kavrayabiliyorsa benim için bu çok önemli bir işaret. Ve tabiki analitik olmaları gerekiyor. Hangi KPI’ları takip ediyorlar ve bu KPI’ların birbirleri ile ilişkilerini nasıl analiz ediyorlar bu çok önemli. Diğer bir önemli nokta da kullanıcı odaklılık. Görüşme boyunca kullanıcının adını ne kadar ağzına alıyor? Ne kadar kullanıcı araştırması deneyimi var ve bu deneyimi kendi ürününü geliştirmek için kullanıyor? Tasarım ekipleri ile ne kadar birlikte çalışmış?  Bunlar çok önemli.

Mühendisler ve pm’ler bizde aynı ekipte çalışıyor. Bu durumda sorumlulukların da iyi belirlenmesi gerekiyor. Benim gördüğüm risklerden biri ve çoğu zaman da olan şey mühendislik  ve product ekipleri beraber çalıştığında bir çok farklı sorumluluk producta yükleniyor ve product kendilerini backlog management’da zaman geçirirken buluyor ve  ürün keşfine yeterince zaman ayıramayıp problemi iyi analiz edemeyebiliyor. Product ekipleri yalnızca mühendislik ekipleri ile değil diğer ekiplerle de zaman geçiriyor olmalı. Product’ın 4D’si dediğimiz Discover, Define, Design, Delivery süreçlerinde eşit zaman geçirilmesi gerekiyor. Bu 4 aşama beraber yapılıyor olmalı. Fakat bu sürece bütün ekipleri dahil edemiyorsanız bile en azından bilgi aktarmanız gerekiyor ki ilgili ekibe diğer ekiplerin de çok değerli katkıları olabiliyor.

Kavram : 4D of Product -Discover Define Design Delivery 

    Leave a Reply

    Your email address will not be published. Required fields are marked *