Netlik Eksikliği Ürününüzü Sessizce Öldürüyor mu?

Deşifreyi 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 olası yazım hatalarını mazur görün.

Hannah Clark: Neredeyse bir klişe gibi ama bu her zaman olur—üç kişiye bir şey söylersiniz ve üçü de farklı şeyler duyar. Eğer söylediğiniz şey “Kahve almaya gidiyorum, isteyen var mı?” ise bu o kadar da kötü değildir. Ancak giderek kısalan bir kaynak süresiyle bir MVP geliştiriyorsanız ya da sıkı bir teslim tarihine yetişmeye çalışıyorsanız, bu netlik eksikliği bir startup için ölüm öpücüğü olabilir.

Bugünkü konuğumuz Bijan Shahrokhi—Product Management Exercises ve Product Monkey AI’ın kurucusu. Bijan, kariyerinin son bölümünü ürün yöneticilerinin daha üretken olmalarına ve ekipleri daha iyi yönetmelerine yardımcı olarak geçirdi. Bir ürün ekibine netlik ve uyum kazandırma becerisi de bu yetkinliklerin temelini oluşturuyor. Birkaç dakika içinde Bijan, başlangıçta biraz zamanınıza mal olacak ancak zor durumdaki bir startup’ı kurtarma potansiyeline sahip, kolayca tekrarlanabilir bir süreç paylaşacak. Hadi başlayalım.

Tekrar hoş geldiniz sevgili dinleyiciler. Bugün Bijan Shahrokhi ile birlikteyim. Kendisi ProductManagementExercises.com‘un kurucusu ve kısa süre önce yalnızca ürün yöneticileri için ProductMonkey.ai adlı bir üretkenlik aracı başlattı.

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

Bijan Shahrokhi: Beni davet ettiğiniz için çok teşekkür ederim.

Hannah Clark: Harika. Her zaman aynı şekilde başlıyoruz. Bize biraz geçmişinden ve bugün bulunduğun noktaya nasıl geldiğinden söz eder misin?

Bijan Shahrokhi: Elbette. Ben özünde bir ürün yöneticisiyim. Tamamen tesadüfen, 10 yılı aşkın süredir ürün yöneticiliği yapıyorum.

Bir startup’ım iyi gitmeyene kadar ürün yönetiminin ne olduğunu bile bilmiyordum. Bir arkadaşıma bundan sonra ne yapmam gerektiğini düşündüğünü sordum ve bana “ürün yöneticisi olmalısın” dedi. Ben de “Bir dakika,” dedim. Kulağa çok ilginç geliyor; ürün ve ürünü yönetmek. Yapmak istediğim şey bu.

Bundan sonra bir ürün yöneticisi oldum. Son 10 yılda birkaç farklı iş yaptım. Kariyerimin ilk birkaç yılında banka gibi daha büyük kuruluşlarda, önce ürün yöneticisi, ardından ürün stratejisti olarak çalıştım. Daha sonra iki startup’ın parçası oldum. Her ikisinde de şirkete katıldığımda ürünü piyasaya sürdük ve bunlardan biri, ekosistemdeki daha büyük bir oyuncu tarafından bir buçuk yıl içinde satın alındı.

Diğeri ise gerçekten başarılı bir projeydi. En yüksek değerine ulaştığında milyarlarca dolar değerindeydi. Hâlâ faaliyet gösteriyor ve büyümeye devam ediyor. O zamandan beri kariyerimin son birkaç yılında çoğunlukla Product Management Exercises’a odaklandım. Yakın zamanda da ürün yönetimi topluluğu için ProductMonkey.ai adlı başka bir ürün başlattık.

Hannah Clark: Harika. Bugün kuruluşlarda netlik hakkında konuşacağız; bu senin kişisel olarak oldukça önem verdiğin bir konu. Netlik derken, tüm paydaşların aynı hizaya gelmesini ve neler olup bittiğiyle nelerin geliştirileceği konusunda aynı anlayışı paylaşmasını kastediyorum.

Peki bir kuruluşta netlik duygusu olmadığında bu senin için nasıl görünüyor?

Bijan Shahrokhi: Güzel soru. Bence görebileceğiniz en büyük, en belirgin işaret; kuruluş genelinde farklı kişilere bir sonraki büyük kilometre taşı olarak teslim edilmesi gereken şeyin başarı kriterlerini sorduğunuzda farklı hikâyeler duymaya başlamanızdır.

Bir örnek vereyim. Diyelim ki gecikme, hız, saniye başına işlem sayısı veya tamamlanabilecek görev hacmi gibi çok sayıda performans metriğiyle uğraşacak, son derece teknik bir ürün üzerinde çalışıyorsunuz. Bu gereksinimler kuruluş içindeki teknik bir kişi tarafından açıkça tanımlanmazsa, örneğin son derece yüksek işlem hacmine dayanabilecek bir şey geliştirmeye çalışabilirler.

Ancak daha çok iş odaklı ve müşterilerle iletişim hâlinde olan birine sorarsanız, “Müşterimizden geri bildirim almaya başlayabilmek için bir şeyi hemen piyasaya sürmemiz yeterli,” diyebilir. Kuruluşun farklı yerlerindeki insanlarla konuşmaya başladığınızda ve farklı sayılar duyduğunuzda ya da “Bunu hiç düşünmedik veya hiç konuşmadık,” dediklerini işittiğinizde netlik eksikliği olduğunu anlarsınız. Bu da bir ürün yöneticisi olarak size “Bir dakika, burada netlik eksikliği var,” demeniz için oldukça büyük bir uyarıdır.

Hannah Clark: Görünüşe göre bunu ilk elden deneyimlediğin birkaç durum olmuş. İsim vermeden bir anekdot paylaşabilir misin?

Bijan Shahrokhi: Elbette. Bahsettiğim ve milyarlarca dolar değerine ulaşan son proje, nakdinin tükenmesine yalnızca birkaç ay kalmış, henüz bir proje bile başlatmamış bir şirkete aitti.

Ürünlerini piyasaya sürmelerine yalnızca birkaç ay kaldığını düşünüyorlardı. Ben katıldığımda başlangıçta bana üç ay kaldığı söylendi. Katıldıktan sonra, kurucuların bazılarının zihnindeki zaman çizelgesinin gerçeklikten belki 5 ila 10 yıl uzakta olduğunu fark ettim.

Bazı mühendislerin teslim edeceklerini düşündükleri şeyin tamamlanmasına da yalnızca birkaç ay vardı. Yani ikisi arasında büyük bir boşluk bulunuyordu. Bu nedenle üç yıldan uzun süre geliştirme döngüsünde kaldılar; çünkü mühendislik ekibi sürekli hazır olduklarını sunuyordu. Kurucuların veya iş tarafındaki kişilerin bazıları ise bakıp “Bir dakika, siz hazır değilsiniz. Bu, bizim zihnimizdeki şeyle gerçekten örtüşmüyor,” diyordu.

Ardından neyin geliştirilmesi gerektiğini yeniden tanımlıyorlardı. Mühendislik ekibi de hayal kırıklığına uğramış ve kuruluşa gerçek bir değer katmadığını düşünerek yeniden geliştirmeye dönüyordu. O noktada yaptığımız şey, ürün yöneticisi olarak geçirdiğim ilk üç ayı çok sayıda paydaşla görüşmeye ve kuruluş genelinde farklı bakış açılarına neden olan özelliklerin neler olduğunu gerçekten anlamaya ayırmaktı.

Örneğin, belirli bir özelliğin veya birkaç kişinin kuruluş içinde bunun ilk sürümün parçası olması gerektiğini düşündüğünü, diğer yarının ise böyle düşünmediğini fark ettim. Sonra bu maddeler hakkında birçok görüşme yapmaya ve geliştirilip geliştirilmeyecekleri konusunda netlik kazanmaya başladık. Bu, ya sıfır-bir şeklinde bir karardı ya da özelliğin çok sınırlı bir sürümünü geliştirecektik.

Bunun parçası olarak tam olarak ne yapacağımızı belirledik. Ancak bundan sonra, başlangıçta “üç ay içinde piyasaya süreceğimiz şey bu” diye düşünülen ürünün sınırlı bir sürümünü gerçekten geliştirmemiz yaklaşık bir yıl sürdü. Dürüst olmak gerekirse, bir yıl içinde neyin geliştirileceği konusunda netlik kazanmak bile birkaç ayımızı aldı.

Umarım bu, çok fazla netlik sağladığınızda gerçekten bir şeyi piyasaya sürebileceğiniz bir duruma örnektir. Ürünü piyasaya sürdükten sonra kullanıcılarınızdan, topluluktan ve tüm ekosistemden gelen geri bildirimleri kullanarak sıradaki adımda geliştirme hattındaki hangi maddelere daha fazla öncelik vermeniz gerektiğini belirleyebilirsiniz.

Hannah Clark: Evet, böyle bir boşluğu kapatmak başlı başına büyük bir başarı; görünüşte imkânsız bir görev. Bu yaklaşımı benimsemek oldukça güçlü. Biraz daha geriye çekilirsek, bir kuruluş genelinde, yalnızca ürün ekibinde değil, netlik sağlayan süreçleri kültürüne yerleştirmemiş olmanın daha geniş sonuçları neler olur?

Bijan Shahrokhi: En büyük etkisi, genellikle ürünlerini piyasaya sürememeleri olur ve bu oldukça büyük bir sorundur. Birçok harika proje, şirketlerine gelir kazandırmaya başlayamadan önce nakitleri tükendiği için hiçbir zaman gerçek dünyaya ulaşamaz. Ne yazık ki bu, araştırma ve geliştirmeye dayalı projelerde daha da sert bir gerçekliktir. Çünkü son derece bilimsel olan ve bir tür buluş gerçekleştirmeye çalışan araştırma-geliştirme projeleri genellikle güçlü akademik geçmişe sahip kurucular tarafından yönetilir.

Güçlü akademik geçmişe sahip insanlar hakkında—onları eleştirmek istemem, benim de güçlü bir teknik ve akademik geçmişim var ve bunun olumlu bir şey olduğunu düşünüyorum—şunu söyleyebilirim: Bir kuruluş onlar tarafından yönetildiğinde mükemmeli ararlar. Mükemmeli aradıkları için de sürekli geliştirmeye, eklemeye devam ederler. Dürüst olmak gerekirse, bir projenin kuluçka veya erken aşamalarında gerçekleşmeleri dünyanın sonu olmayan uç senaryolar için sürekli endişelenirler.

Sonuçta ürünlerini hiçbir zaman piyasaya süremezler ve dünya, bu yeni teknoloji için sahip oldukları vizyonu gerçekten göremez.

Hannah Clark: Evet, şu “tamamlanmış mı, mükemmel mi?” meselesi. Hepimiz bununla mücadele ediyoruz; bir tarafta mükemmeliyetçiler, diğer tarafta ise yalnızca ürünü piyasaya sürmek isteyenler var. Bu arada, netliğin son derece hayati olduğu konusunda hemfikir olabileceğimiz bir alandan söz ettin: MVP geliştirmek. Bence bu alan birçok yanlış adıma ve günün sonunda felaket olabilecek iletişim kopukluklarına çok açık.

MVP geliştiren ekiplerin dikkat etmesi gereken yaygın tuzaklar ve bunlardan kaçınmak için çözüm yolları neler?

Bijan Shahrokhi: Startup’ların MVP kavramıyla ilgili yaptığı en büyük hatanın, bunu kullanılamayacak kadar bozuk bir ürün teslim etmekle karıştırmak olduğunu gördüm.

Bunu defalarca gördüm. İsim vermeden bir örnek vereyim. Kurumsal bir çözüm olan belirli bir ürüne yatırım yaptım. Bu ürün konusunda çok heyecanlıyım. İlk günden itibaren beni heyecanlandırmasının nedeni, kendimi bunu kullanmak isterken görebilmemdi.

Product Management Exercises’taki kuruluşumun da bunu günlük olarak kullanmak isteyeceğini görebiliyordum. Bunu benimsememizin önündeki en büyük engel, ürünün o kadar hatalı olmasıydı ki kullanamıyorduk. Ürün liderleri olarak buna dikkat etmemiz ve bir MVP gördüğümüzde ürünün değer önerisini aktaramayacak kadar hatalı bir üründen söz etmediğimizden emin olmamız çok önemli.

Yine de kullanıcıya sunmaya çalıştığınız temel kullanıcı deneyiminin veya temel ürün değerinin uçtan uca çok iyi ve sorunsuz çalıştığından emin olmalısınız. Gereksiz olan birçok şeyi kapsam dışı bırakabilirsiniz ancak temel ürün deneyimini sunabildiğinizden emin olmalısınız.

Şirketlerin yaptığı en büyük hatalardan biri de MVP’nin ne anlama geldiğini yanlış anlamaları ve bunun bozuk bir şeyi piyasaya sürebileceğiniz anlamına geldiğini düşünmeleridir.

Hannah Clark: Evet. Bir tarafta her şey mükemmel olana kadar ürünü piyasaya sürmek için beklemek istemeyenler var. Spektrumun diğer tarafında ise bunun tam tersi bulunuyor. Mantıklı.

Kuruluşlarda netlik aramak için oldukça kapsamlı bir sürecin var; daha önce buna değindin. Dinleyenler bu yaklaşımı kendi iş akışlarına kopyalayıp yapıştırmak isteseler, ekipteki herkesle aynı hizaya geldiklerinden emin olmaları için hangi adımları önerirsin?

Bijan Shahrokhi: Bunu sorduğun için teşekkürler. Bu soruyu sorman ilginç, çünkü PM Exercises’taki birçok kişi bu süreci çok faydalı buluyor. Dürüst olmak gerekirse oldukça basit ve bir projeye başlamadan önce zor işi erkenden yapmaya odaklanıyor. Adım adım ilerliyor; kısaca anlatayım.

Temel olarak ilk aşamada, adım adım ilerleyen bir süreçle kuruluş genelinde uyum sağlamak için çok zaman harcarsınız. Ancak herkesin aynı hizaya geldiğini düşündüğünüzde işe başlarsınız. İlginç olan, bu yaklaşımın finans kuruluşları gibi birçok büyük kuruluş tarafından benimsenmiş olmasıdır.

Ancak Şelale yönteminden Çevik ve Scrum metodolojisine geçtiğimizde, bunun nereye gittiğiniz konusunda netliğe sahip olmanız gerekmediği ve yalnızca önümüzdeki iki hafta içinde ne yapacağınızı bilmenizin yeterli olduğu anlamına geldiğini düşündük. Hayır, Çevik’in amacı bu değildi. Çevik’in amacı, birkaç ay içinde nereye gitmeye çalıştığınızı açıkça bilirken iki haftada bir anlamlı bir şey teslim etmektir.

Peki bunu nasıl yaparsınız? Benim yaklaşımım şöyle: Örneğin bir projeye veya çok fazla netlik eksikliği olduğunu fark ettiğim bir ürüne liderlik ederken yaptığım ilk şey, paydaşlarla bire bir toplantılar ayarlamaktır. Bunun bire bir olması gerekir. Grup ortamında değil; çünkü biri hassas konularda bir görüş paylaştığında başka biri araya girer ve ürünün kâhini olarak tüm bağlamı gerektiği gibi özümseyemezsiniz.

Bu nedenle her kişiyle ayrı ayrı konuşmalı ve bakış açılarını gerçekten anladığınızdan emin olmalısınız. Diyelim ki bir ödünleşimle uğraşıyorsunuz: X’i geliştirmeli miyiz, geliştirmemeli miyiz? Bu ikili bir karardır ancak model başka birçok konu için de işe yarar.

Onlarla görüşür, neden yapılması veya yapılmaması gerektiğine dair bakış açılarını öğrenirsiniz. Ayrıca bu kararı verirken dikkat etmeniz gereken şeylerin neler olduğunu sorarsınız. Muhtemelen kendi dünyalarında onlar için çok önemli olan dört veya beş farklı şey söyleyeceklerdir.

Özellikle araştırma ve geliştirme dünyasında bu daha da önemlidir. Ürününüz ne kadar teknikse veya kuruluş içindeki diğer araçlarla ne kadar fazla teknik bağımlılığı varsa, konu o kadar önemli hâle gelir; çünkü orada konu uzmanları bulunur. Bir sonraki kişiye gidersiniz, sonra diğerine; herkesle bire bir görüşürsünüz.

Zaman geçtikçe kendi fikriniz ya güçlenir ya da yeni fikirler geliştirmeye başlarsınız. Ödünleşimleriniz değişmeye başlar ve başlangıçta düşündüğünüz bazı şeylerin sandığınızdan daha zor veya daha kolay olduğunu fark ederek bunları düzenlersiniz.

Ancak süreç boyunca yaptığınız şey şudur: Bire bir görüşmelerle daha fazla bilgi topladıkça bu kişilerden bazılarına geri dönüp şöyle dersiniz: “Sizinle ilk görüştüğümde en büyük endişelerinizin 1, 2 ve 3 olduğunu söylemiştiniz. Diğer kişilerle yaptığım görüşmelerden sonra bunların endişe olmaması gerektiğine inanıyorum. İşte gerekçem. Neden yanıldığımı söyleyin veya haklı olup olmadığımı belirtin.”

Bu zaman alan karşılıklı süreçten geçerken ekibin karşılaştığı zorlukların çoğunun aslında iletişim eksikliğinden kaynaklandığını fark edersiniz. Hiç kimse tüm bu farklı ödünleşimleri kuruluştaki farklı paydaşlara açıkça anlatmak için zaman ayırmıyordur ve birçok konu çözüme kavuşur.

Zaman geçtikçe dikkat etmeniz gereken farklı ödünleşimler konusunda giderek daha fazla netlik kazanırsınız. Bu yaklaşım ürün önceliklerinde de işe yarayabilir; bu konuya daha sonra biraz değinebiliriz. Bir noktada hâlâ farklı görüşlerin bulunduğu birkaç madde olduğunu fark edersiniz. Örneğin ekibin yarısı belirli bir özelliğin, diyelim güvenliğin, çok önemli olduğunu düşünür. Diğer yarısı ise güvenliğin bir özellik olarak çok önemli olmadığını düşünür.

Bunun için kendi gerekçeleri vardır. İşte o zaman bir grup toplantısı düzenlersiniz. “Bu kararı verebilmemiz için bu özellik bizim açımızdan çok önemli. İki farklı bakış açısı var. Bir görüşme yapalım,” dersiniz. Bu canlı görüşme sayesinde genellikle bir karara varabilirsiniz.

Bazen birkaç aksiyon maddesi çıkar: “Gidip bunu daha fazla araştıralım.” Harika. Ardından bir sonraki toplantıyı düzenleyebilir ve “Başlangıç hedefimiz buydu. Araştırmayı yaptık. Yeni bulgu bu. Ne yapıyoruz?” diyebilirsiniz. Ancak sonunda bir karar verirsiniz.

Tüm bu ödünleşimlerin ne olduğunu net biçimde belirlediğinizde, ekip olarak belirli bir yola girip girmeme konusunda veya ürün önceliklerini belirlerken karar vermeniz çok daha kolaylaşır. Böylece gelip “Bu bizim önceliğimiz ve buna odaklanacağız,” diyebilirsiniz.

Çok genel hatlarıyla düşündüğümde birinci adım, her bireyin bakış açısını açıkça anlamaya çalıştığınız bire bir toplantılarla başlamaktır. İkinci adım, farklı görüşlere sahip oldukları maddelerin hepsinin ele alındığından emin olmak için gerekirse bu kişiler arasında gidip gelmektir. Ele alınmayanları grup görüşmelerine ayırırsınız.

Üçüncü adım ise grup görüşmeleridir. Sonunda bu süreç tutarlı bir ürün stratejisi, ürün tanımı veya ürün öncelikleriyle sonuçlanır. Elbette senaryoya göre arada ek bir adım olabilir. Örneğin ürün öncelikleri için hedefin ne olduğunu daha fazla düşünmeniz gerekir.

Başlangıçta biraz zaman ayırıp “Amacımız hızlıca bir şey piyasaya sürmek ve öğrenmek,” demeniz gerekebilir. Ardından herkesin sizinle aynı fikirde olup olmadığına bakarsınız. Herkes hemfikirse harika; sürece devam edebilirsiniz.

Hannah Clark: Evet, genel olarak ürün öncelikleri hakkında biraz daha konuşmak istiyorum. Görece bir fikir birliğine sahip olduğumuzda veya hedefler ve başarının nasıl görüneceği konusunda anlaşmaya vardığımızı düşündüğümüzde bile, birbiriyle yarışan öncelikleri dengelemek zor olabiliyor.

Elbette ürün özelliği önceliklendirmesi için yüzlerce farklı çerçeve var. Ancak bu bağlamlarda, birbiriyle yarışan önceliklerle çalışırken en başarılı ve genel olarak uygulanabilir bulduğun yöntemler neler?

Bijan Shahrokhi: Benim için yaklaşımlardan biri, bunlara puan vermek ve birkaç farklı açıdan düşünmektir.

İlki, söz konusu özelliğin veya ürünün hedef kitlem ya da hedef kullanıcılarım üzerindeki etkisidir. İkincisi, bu etkiyi gerçekten elde edebilme olasılığımızdır. Çünkü birçok durumda yeni ürününüzün hedef kitlede karşılık bulup bulmayacağından emin bile değilsinizdir.

Bu durumda olasılık daha düşüktür. Üçüncüsü ise uygulama kolaylığıdır. Zihnimdeki formül “etki çarpı etkinin olasılığı artı uygulama kolaylığı” şeklindedir. Etki için puan bir ile beş arasındadır; beş en yüksek, bir ise en düşük etkidir.

Uygulama kolaylığında da şöyle düşünürüm: Beş, uygulamasının kolay olduğu anlamına gelir. Bir ise çok fazla çaba gerektirdiği anlamına gelir. Ardından bir puan elde edersiniz. Bu yaklaşımın sevdiğim yanı nesnel olmasıdır ve az önce anlattığım bir, iki, üç süreci sayesinde benzer görüşmeler de yapabilirsiniz.

Bir ekip üyesine dönüp “Herkesle yaptığım görüşmelerden sonra kuruluş içindeki temel projelerin şöyle bir tablosunu hazırladım. Etki ve uygulama çabası açısından puanlamam bu şekilde. Puanlarıma göre en yüksek puanlı projeler bunlar olmalı,” diyebilirsiniz.

Bunun üzerine size “Öncelikle üzerinde çalıştığımız şu üç projeyi atlamışsın,” diyebilirler. Ya da eklediğiniz bir projenin düşündüğünüzden daha büyük olduğu ve üçe bölünmesi gerektiğini söyleyebilirler. Etki veya çaba puanlamanız konusunda sizinle aynı fikirde olmayabilirler. Ancak artık son derece nesnel görüşmeler yapmaya başlarsınız; konu kişilerden çok maddelerle ilgilidir.

Bu puanlama sisteminin ilginç yanı, her şeyin ne kadar süreceğini tahmin etmeye çalışmamanız ve projeleri birbirleriyle karşılaştırmalı olarak değerlendirmenizdir. Böylece ne kadar değer sağlayacağı veya ne kadar çaba gerektireceği konusunda hızlıca bir fikir birliğine varmak çok daha kolay olur.

Bu da net biçimde tanımlanmış bir öncelik listesi oluşturmanızı sağlar. “Önümüzdeki çeyrekte odaklanacağımız beş madde bunlar,” dersiniz. Yeni bir madde geldiğinde veya kuruluş içindeki yeni ya da mevcut bir çalışan “Bunu yapmalıyız,” dediğinde öncelik tablonuza bakıp şöyle dersiniz: “Bir bakalım. Bunu görüştük ve şu nedenle şu anda öncelik olmadığına karar verdik; ancak şu iki veya üç maddeyi tamamladıktan sonra buna öncelik vereceğiz.”

Bazen eklenmesi gereken başka şeyler olduğunu fark edebilirsiniz. Bu senaryoları nasıl ele alabileceğiniz hakkında da konuşabiliriz.

Ancak bu yaklaşımın daha nesnel olduğunu ve öncelikler belirlemenizi kolaylaştırdığını düşünüyorum.

Hannah Clark: Bunu takdir ediyorum. Daha önce The Product Manager’da geri bildirimleri ve bu önceliklendirme görüşmelerini kişiselleştirmemekten söz etmiştik. Böylece insanlar kendi projelerinin veya gündemlerinin kişisel bir nedenle daha düşük önceliğe alındığını ya da düşündüklerinden farklı bir öncelik sırasına yerleştirildiğini hissetmez.

Bu çok uygulanabilir bir yöntem. Az önce tekrar ele almak istediğin şey neydi? Biraz önce, buna kısa süre sonra değineceğimizi söylemiştin.

Bijan Shahrokhi: Bazen insanlar gelip “Bunun öncelik olması gerekiyor,” derler ve siz de bunun herhangi bir nedenle gerçekten öncelik olması gerektiğini fark edersiniz. Bu durumda ne yaparsınız, bundan söz ediyordum.

Böyle bir durumda ne yapacağınızı düşünebilirsiniz. Bu madde öncelikler listesine öylece eklenemez. Ya bunu, hâlihazırda yüksek öncelikli maddelerin teslim hızını etkilemeyecek şekilde yapmanın bir yolunu bulmalısınız.

Birkaç başka yaklaşımınız da var. Birincisi, listeden başka bir şeyi çıkarmanız gerekir. O maddenin önceliği düşürülmelidir. Puanlama sistemiyle o maddenin yerini yeni madde alır. Diğer yol ise bu yeni öncelik üzerinde çalışacak ek kaynaklara sahip olmanızdır.

İzlediğiniz ilke şudur: Öncelik listenizde bulunan maddeler, listeye başka bir madde eklediğiniz için yavaşlamamalıdır. Bence bazı kuruluşlarda bu ürün yöneticisinin görevidir, bazılarında ise değildir. Sorun da burada başlar; işler teslim edilmez.

Bence iyi bir ürün yöneticisi buna çok dikkat eder ve yeni bilgiler ortaya çıktığı için başka bir şeyin önceliklendirilmesi gerektiğinde bunu nasıl ele alacağını düşünür. Ya listeden bir şeyi çıkarır ya da diğer maddedeki teslim hızını etkilemeden bu yeni iş üzerinde çalışabilecek ek kaynaklar bulur.

Hannah Clark: Büyüleyici. Zamanımızın sonuna yaklaşırken biraz konu değiştirmek istiyorum. Üretkenlikten de söz etmek istiyordum; bunun senin çok önem verdiğin bir konu olduğunu ve ProductMonkey.ai’ı kurmanın temel nedenlerinden birinin bu olduğunu biliyorum.

Dinleyicilerimiz için genel olarak ürün ve üretkenlik konusunda bazı ipuçların ve insanların ilginç bulabileceği Product Monkey AI hakkında bilgilerin var mı? Gerçekten çok güzel bir araç.

Bijan Shahrokhi: Elbette. Product Monkey AI ile yaptığım şey, ürün yöneticileri olarak bizim için çok gerekli olduğunu düşündüğüm ancak yapmayı sevmediğim bir görevi otomatikleştirmek: bahsettiğim nedenlerden ötürü ayrıntılı gereksinimler ve kabul kriterleri yazmaya çok zaman ayırmak.

Product Monkey AI olarak üzerinde çalıştığınız belirli proje, kuruluşunuz ve ilgilendiğiniz belirli kullanıcı akışı hakkında mümkün olduğunca fazla bilgi edinmeye çalışıyoruz.

Ardından, yapay zekâyı kullanarak sizden aldığımız doğru yönlendirmelerle ayrıntılı ürün gereksinimleri, kabul kriterleri, test senaryoları ve hatta ürünü geliştirirken dikkat etmeniz gereken olaylar ve metrikler sunabiliyoruz.

Böylece bunları alıp üzerinde çalışmaya başlayabilir ve mühendislik iş takip kartlarınız ile ürün gereksinim belgeleriniz için işin yaklaşık yüzde 80’ini oluşturan hızlı bir taslak elde edebilirsiniz. Daha sonra son yüzde 20’yi tamamlamak için zaman ayırırsınız. Bence ürün yöneticileri olarak sağlayabileceğimiz faydalardan biri, söylediğim gibi, netlik kazandırmaktır. Product Monkey AI da ürün yöneticilerinin mühendislik ekiplerine netlik kazandırması için gereken süreyi azaltarak bunu yapabilir.

Hannah Clark: Harika. Eminim dinleyenlerin çoğu bu araçta büyük değer bulacaktır. Bijan, bugün bize katıldığın için çok teşekkürler. İnsanlar yaptıklarını takip etmek isterse internette sana nereden ulaşabilir?

Bijan Shahrokhi: Twitter’a veya artık adlandırdığımız şekliyle X’e gelebilirler. X kullanıcı adım bijan_sha. Beni orada bulabilirler. Ayrıca PM Exercises’a veya Product Management Exercises’a da gelebilirler. Her ikisini de aratabilirler. Sitemize ulaşır ve benimle oradan da iletişim kurabilirler.

Hannah Clark: Harika. Zaman ayırdığın için çok teşekkürler.

Bijan Shahrokhi: Beni davet ettiğiniz için çok teşekkür ederim.

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.