İnsan Odaklı Geliştirme (Glean’den Sam Higham ile)

Michael Luchen

Uygulama yapan veya ürün yöneticisi olmayı hedefleyen kişiler olarak, zanaatımız için gerekli olduğu söylenen sertifikalar ve uzmanlaşmış eğitimlerle sürekli bombardımana tutuluyoruz. Ürünleri geliştirmek için uyarlanmış bir süreci takip etmenin başarının anahtarı olduğu söyleniyor. Dinlemeye devam edin; bugün bu alanı derinlemesine inceleyeceğiz. Sertifikalar ve uyarlanmış süreçler göründükleri kadar gerekli mi? Yoksa daha iyi bir şey mi var?

Bu, ürün yönetimi, geliştirme ve strateji için yol haritasını yazan bir topluluğun seslerini buluşturan The CPO Club podcast’i. Yaratıcılık, teknoloji ve kültür aracılığıyla bireylerin ve şirketlerin gelişmesine yardımcı olan bir dijital ürün ajansı Crema tarafından destekleniyoruz. Daha fazla bilgi için crema.us adresini ziyaret edin. Ürün yönetimi dünyasında başarılı olmanıza yardımcı olacak pratik ve samimi görüşler için dinlemeye devam edin.

Bugünün konusu, ürün yönetimindeki kişisel ilgi alanlarımdan birine oldukça yakın. Bu konu hakkında konuşmak üzere Sam Higham’ı programa davet etmekten büyük mutluluk duyuyorum. Sam, ürünleri, süreçleri ve insanları daha iyiye dönüştürme konusunda kariyeri boyunca kendini kanıtlamış, kullanıcı odaklı bir ürün lideridir. Ürünleri işlevsel temellerinden sundukları ticari beklentilere kadar çalışır hâle getirmenin hem ayrıntı hem de yön verme boyutlarında başarılıdır.

Sam, teknolojinin ve psikolojinin tüketici yolculuklarında nasıl etkileşime girdiğine sınırsız ilgi duyar. Ekiplerin mümkün olan en iyi sonuçları sunabilmek için bu iki alanı birleştirmenin ve hassas biçimde ayarlamanın yollarını belirlemesine yardımcı olur. Sam, öğrenme ve üretkenlik için not alma çözümü olan Glean’de Ürün Başkan Yardımcısıdır.

Glean’in not alma çözümü, daha etkili biçimde yakalayabilmeniz ve bilgilerden öğrenebilmeniz için sesli notları kaydeder. Sam ayrıca Mind the Product’ta yarı zamanlı ürün koçu ve ürün yönetimi eğitmeni olarak görev yapar; burada bireylerin istedikleri ürün yönetimi kariyerinde ilerlemelerine yardımcı olur.

Merhaba Sam! Programa hoş geldin.

Sam Higham

Merhaba, davetiniz için teşekkürler.

Michael Luchen

Seni burada ağırlamak güzel. Başlangıç olarak, bugün bulunduğun noktaya nasıl geldiğini paylaşabilir misin?

Sam Higham

Elbette. Kısaca söylemek gerekirse, çok fazla deneme ve yanılma yaşadım. Sanırım birçok ürün çalışanı gibi ben de yaklaşık son on yıl içinde ürün yönetiminin içine girdim.

Ürün geliştirme açısından yapılabilecek hemen hemen her rolde çalıştım; kod yazmak dışında. Gerçi geçmişte oldukça kötü API’ler geliştirmeyi de denedim. Resmî olarak yaklaşık sekiz yıl önce ürün yönetimi alanında çalışmaya başladım; ancak o zamanlar bu unvanı kullanmıyordum.

O dönemden bu yana ürün çalışanı olmanın ne anlama geldiğini ve her gün nasıl daha iyi olunabileceğini sürekli olarak geliştirmeye çalıştım. Bunun büyük bir kısmı ürün yönetiminin ne olduğunu anlamaya çalışmaktan kaynaklandı. Açıkçası bu, bugün bile her gün kendime sorduğum bir soru.

Michael Luchen

Peki, nedir?

Sam Higham

Bence konu, bulunduğunuz bağlamı, sahip olduğunuz kısıtları ve birlikte çalıştığınız kişileri dikkate alarak değer yaratmanın en iyi yolunu bulmaya çalışmaktan ibaret. Kusursuz ürün yönetimi yaklaşımının pek çok güçlü yanı var; ancak ürün yönetimini kurallara tamamen uygun biçimde uygulamak için gereken her şeye sahip olmayan kuruluşların yüzde 95’inden fazlasının koşullarını her zaman hesaba katmıyor.

Zorlukların bir kısmı da buradan kaynaklanıyor. Elinizde, kusursuz bir laboratuvar ortamında ürün geliştirmenin nasıl yapılacağını anlatan pek çok ilham verici bilgi var; ancak hiçbirimiz gerçekten böyle bir ortamda çalışmıyoruz. Çok azımız, tüm bu uçtan uca yaklaşımları kusursuz biçimde uygulamak için gereken finansmana sahibiz.

Bu nedenle işin büyük bölümü yinelemeli geliştirmeyle ilgilidir. Yalnızca yazılım anlamında değil, süreç ve iş birliği anlamında da yinelemeli düşünmek gerekir. Her şey sürekli olarak ileri ve geri çalışır.

Michael Luchen

İlginç. Yani ürün yönetimiyle ilgili belgelerin ve eğitimin büyük bölümü ürün geliştirmede yinelemeli olmayı anlatıyor; sen ise çalışılan ortama göre süreç ve insanlar konusunda da yinelemeli olmak gerektiğini söylüyorsun.

Sam Higham

Evet, tam olarak öyle. Bunun büyük bir bölümü insanların karmaşık varlıklar olduğu gerçeğini unutuyor.

Hepimiz her şeyi kusursuz biçimde uygulayabilen paketlenmiş bireyler değiliz. Aynı bilgiye sahip değiliz. Bu nedenle bir ürün çalışanı olarak hiçbir hazırlık yapmadan gelip, “Ürün yönetimi uygulayacağız; kullanacağımız çerçeve bu ve her şey kusursuz işleyecek,” demek kolaydır.

Ancak o zaman meslektaşlarımın neyi başarmaya çalıştığımızı anlayıp anlamadığını, bu yaklaşımın neden değerli olduğunu kavrayıp kavramadıklarını ve aynı dili ne ölçüde konuştuğumuzu hesaba katmamış olurum. Önce herkesle birlikte bunu yapmanın en iyi yolunun ne olduğunu açıkça konuşmak gerekir.

Kendi deneyimlerinizi ve geçmişte işe yarayan teknikleri getirebilirsiniz; ancak bunların kendiliğinden işe yaramasını beklememelisiniz. “Google’da işe yarıyor, Amazon’da işe yarıyor” demeden önce bunun bizim için işe yarayıp yaramadığını düşünmek gerekir.

Michael Luchen

Evet. Google’ın veya Amazon’un iç işleyişi hakkında daha fazla şey öğrendikçe, anlattığımız hikâyelerin çoğunun onların başlangıç dönemlerinden, girişimlerin örnek gösterildiği zamanlardan kaldığını düşünüyorum. Oysa şimdi çok farklı ekipleri ve çalışma biçimleri olan dev kuruluşlar.

Sam Higham

Kesinlikle. Pek çok kişi en iyi deneyimlerini girişim aşamasında yaşadığını anlatıyor. Bunun nedeni, herkesin ne yapmaya çalıştığınızı anlaması ve bunu birlikte çözmeye çalışmanız. Ortak bir diliniz var ve neler yapabileceğiniz konusunda çok hızlı biçimde açık konuşabiliyorsunuz.

Bu yalnızca ürün geliştirme ekipleriyle ilgili değil; tasarım, mühendislik, satış, pazarlama, operasyon ve diğer herkes aynı ortamda yer alıyor. Böylece kuruluş olarak çok sıkı bir geri bildirim döngüsüne sahip oluyorsunuz. Kuruluş büyüdükçe süreçler ve çerçeveler devreye giriyor; ancak herkesin kendi iç konuşma biçimi oluştuğu için diğer işlevlerin etkili biçimde iş birliği yapması zorlaşıyor.

Ekibinizin ne yapmaya çalıştığını ve neden bu yaklaşımı seçtiğinizi sürekli açıklamazsanız, geri bildirim döngüsünü kaybedersiniz. Satış ekibi ürün ekibiyle, ürün ekibi de mühendislerle doğru biçimde iletişim kurmaz. Herkes kendi işlevinin ne kadar iyi olduğunu anlatır; ancak kuruluş olarak birlikte ne kadar iyi olabileceklerini konuşmaz.

Michael Luchen

Kulağa çok fazla iş gibi geliyor.

Sam Higham

Öyle zaten.

Michael Luchen

Büyük kuruluşlarda çalışan dinleyicilerimizi düşünüyordum. Bu kişiler bir girişim ortamında olmayabilir ve süreçleri savunmaları gerekebilir; ancak bunun için alan olmadığını hissedebilirler. Böyle bir ortamda çalışmaları için onlara nasıl yol gösterirsin?

Sam Higham

Her şeye küçükten başlamak gerekir. Çevik Manifesto’nun temel ilkeleri hâlâ geçerli. Kontrolünüz dâhilinde bir grup olarak yürütebileceğiniz en yalın deneyi düşünün. Aynı zamanda kontrolünüz dâhilinde olan şeyleri kabullenmeniz gerekir.

Tek seferde çok fazla şeyi değiştirmeye çalıştığınızda hayal kırıklığına uğrayabilirsiniz. Bunun yerine bir geliştirme ekibiyle çalışın; mümkünse ekipler arası bir ekip olsun. Tasarımcılar, mühendisler ve ürün çalışanlarıyla birlikte “Birlikte daha etkili olmamızı sağlayacak hangi deneyleri yapabiliriz?” diye sorun.

Daha sonra başka bir işlevi bu iş birliğine dâhil edin. Yaklaşımı uygulayarak bunun işe yaramayabileceğini de gösterebilirsiniz. Neden işe yaramadığını anlamanız ve bu konuda konuşmanız gerekir. İdeal yönteme ulaşmak düşündüğünüzden daha uzun sürebilir; ancak bu başlamamanız gerektiği anlamına gelmez. Başlamak için en iyi zaman bugündür.

Michael Luchen

Küçükten başlama yaklaşımını seviyorum. Özellikle farklı müşterilerle çalışırken, süreçlerin sürekli değiştiği ortamlara girip çıkıyoruz. En başarılı olduğumuz yöntem, “İki haftalık bir deney yapacağız” diyerek kapsamı daraltmak oldu. Bir yıllık çalışma biçimini satmıyorsunuz; iki haftalık deneyi öneriyorsunuz. İnsanların size güvenmesini, süreci denemesini ve değerini görmesini sağlıyorsunuz.

Ürün çalışanlarının koçluk rolünü de çok konuşuyoruz. Günlük çalışmada koçluk sorumluluğu bu başarının bir parçası mı?

Sam Higham

Kesinlikle. Benim için koçluk, cevap vermekten çok soru sormaktır. En üst düzeyde mesele cevapları birlikte bulmaktır; bunun yolu da daha iyi sorular sormaktan geçer. “Burada ne gibi seçenekleri değerlendirdin?”, “Neden bunları değerlendiriyorsun?”, “Başka seçenekleri düşündün mü?” ve “Bu sürece başkalarını nasıl dâhil edebilirsin?” gibi sorular sorarsınız.

Amaç, insanların bu soruları kendilerinin sormasını ve başkalarına da yöneltmesini alışkanlık hâline getirmektir. Koçluk yaparken başarının gölgesinde kalmaktan rahat olmalısınız. İnsanların kazanmasına yardımcı olursunuz; ancak başarıyı kendinize mal etmezsiniz. Ekip sorunun üstesinden kendi başına gelmiş olmalıdır.

Michael Luchen

Bu, başarısızlıklar için de geçerli. İnsanların koçluk yoluyla başarısız olmalarına izin vermek, deneyim kazanıp bir sonraki sefer nasıl ilerleyeceklerini öğrenmelerini sağlar.

Sam Higham

Evet. Bazen başarısızlıktan korkuyoruz. Kuruluşlarda başarısızlığın aşırı biçimde görünür hâle geldiği ve insanların risk almaktan çekindiği kültürler oluşabiliyor. Küçük bir yazılım hatası olduğunda üst düzey yöneticilerin aşırı tepki vermesi, insanlara her küçük değişikliğin tehlikeli olduğunu öğretebilir.

Aynı şey tasarım değerlendirme oturumları için de geçerlidir. Tasarımları erken ve açık biçimde paylaşmak iyi bir uygulamadır; ancak eleştiriler kişisel ve aşırı sert olursa tasarımcılar çalışmalarını erken paylaşmayı bırakır. Böylece öğrenme ve başarısızlıktan yararlanma gücünü kaybedersiniz.

Bir lider olarak buna dikkat etmeli ve insanların deneyleri öğrenme fırsatları olarak görmesine yardımcı olmalısınız. İnsanların denemeye istekli olması için güvenli bir ortam oluşturmanız gerekir.

Michael Luchen

Bir lider için soru şu olabilir: Ürün çalışanlarının sonuçlara ulaşırken başarısızlıklar yoluyla öğrenmesine izin vermenin kuruluş sonuçlarına değeri nedir?

Sam Higham

Kendine güvenen, yetkilendirilmiş ve rahat ekiplerin küçük deneyler yapıp sonuçlardan öğrendiklerini açıkça paylaşabildiğini görürsünüz. Bu, çalışma hızını da artırır. Burada kastettiğim hikâye puanları değil; insanların sürekli onay almak veya küçük bir deneyi yürütmek için herkesin imzasını beklemek zorunda kalmadan rahat, güvenli ve hızlı çalışabilmesidir.

Ekiplerle hangi kararları kendilerinin alabileceği, hangi konularda sizinle konuşmaları gerektiği ve hangi kararların hâlâ sizin sorumluluğunuzda olduğu konusunda anlaşın. Bu, kuruluşun risk iştahıyla ilgilidir. Büyük ve riskli bir veritabanı değişikliği için daha yüksek düzeyde onay gerekebilir; ancak kullanıcıların yüzde 10’u üzerinde yapılacak küçük bir A/B deneyi için ekibin doğrudan ilerlemesi daha doğru olabilir.

Michael Luchen

Yani ürün ekibiyle liderler arasında bir çalışma anlaşması gibi.

Sam Higham

Evet. Ayrıca bir kararın riskinin çok yüksek veya çok düşük olup olmadığını değerlendirmek için koçluk konuşmaları yapabilirsiniz. Bundan daha karmaşık olmasına gerek yok.

Michael Luchen

Ürün geliştirme konusunda tek bir doğru süreç veya çerçeve olmadığını söylüyorsun. Bu alana yeni giren bir ürün yöneticisi nereden başlamalı?

Sam Higham

Kendi yolculuğumu paylaşabilirim. Ben işleri son sorumlu ana kadar öğrenen biriyim. Ürün çalışanı olarak başladığımda, yapmam gereken şeyi tam olarak yapmam gerektiği anda öğreniyordum.

İlk kez bir sunum hazırlamam gerektiğinde sunum yapmayı öğrendim. Yol haritasını hazırlamam gerektiğinde yol haritasının nasıl oluşturulacağını ve seçeneklerin nasıl sunulacağını öğrendim. Daha sonra birikmiş işleri önceliklendirmem gerektiğinde birikmiş işleri önceliklendirmeyi öğrendim.

Bilgi tüketirken bunalmaktan ve sonra her şeyi unutmaktan çekindiğim için böyle öğreniyorum. Ürün yönetimi hakkında 20 kitap okuyup ihtiyaç duyduğunuz anda tüm bilgileri hatırlayacağınızı varsayabilirsiniz; ancak bu herkes için işe yaramaz. Benim uygulama yapmam, öğrenmem ve bunun benim için işe yarayıp yaramadığını görmem gerekiyor.

Bir kursa katılmanın da yanlış olduğunu düşünmüyorum. Temel bilgi edinmek yararlı olabilir. Ancak öğrendiklerinizi gerçek hayatta katı biçimde uygulayacağınızı varsaymamalısınız. İnsanlarla ve karmaşık koşullarla çalışırken çok sayıda iç ve dış etken vardır.

Michael Luchen

Ekiplerin uzun vadeli gelişimini de göz önünde bulundurmak gerekiyor. Bir ürün yöneticisi bunu günlük çalışmalarına nasıl dâhil edebilir?

Sam Higham

Retrospektifler iyi bir başlangıçtır. Bir ekibin kendi performansını değerlendirmesi, bilet yönetim sisteminden alınan rastgele göstergelerden daha sağlıklıdır. Ekip sağlığı retrospektifleri veya atölyeleri de düzenleyebilirsiniz. Ekip olarak odaklanmak istediğiniz on konuyu belirleyip bunları üç ayda bir gözden geçirebilirsiniz.

Normal retrospektifler daha çok mevcut duruma odaklanır. Ekip sağlığı değerlendirmesi ise daha geniş temaları takip etmenizi sağlar. Ekip üyelerinin davranışlarındaki değişikliklere de dikkat etmelisiniz. Etkileşimin azaldığını fark ederseniz bunun nedenini varsaymak yerine insanlarla konuşun.

Hepimiz insanız ve iletişim kurarak hayatta kaldık. İş birliği ve topluluklar kurma yoluyla ilerledik. Bir ürün ekibini küçük bir topluluk olarak görürüm; bu topluluk kuruluş genelinde büyür.

Michael Luchen

Ürün ekibinin küçük bir topluluk olması gerçekten güçlü bir ifade. Peki liderlik ekibi ekip sağlığı çalışmalarını ve retrospektifleri zaman kaybı olarak görürse ne yapılmalı?

Sam Higham

Bunları açık biçimde yürütmek gerekir. Neden bu çalışmayı yaptığınızı ve başarılı bir deneyin göstergelerinin neler olacağını açıklayın. Ekip sağlığı için çalışan bağlılığı veya memnuniyeti gibi göstergeler kullanılabilir. Ekibin performansını ve karşılaştığı zorlukları da değerlendirebilirsiniz.

Örneğin işler sürekli olarak bloke oluyorsa, bunun nedeninin ilgili departmanla yeterince erken iletişim kurulmaması olduğunu varsayabilirsiniz. Bu durumda planlama sürecine ilgili departmanı dâhil etmeyi, haftalık gösterimlere çağırmayı ve son dakika sürprizlerini azaltmayı deneyebilirsiniz.

Liderlik ekibine “Ne görmek istersiniz ve bunları nasıl ölçmemizi önerirsiniz?” diye sorun. Bazen liderler hızın ve hikâye puanlarının artmasını isteyebilir; böyle bir durumda dikkatli olmalısınız. Onları sorunun içine yaklaştırmaya ve endişelerinin ne olduğunu anlamaya çalışın.

Michael Luchen

Ürün yöneticileri olarak genellikle süreçler ve araçlar hakkında geniş bir bilgiye sahip oluyoruz; ancak paydaşlarımızın aynı bilgiye sahip olduğunu varsayamayız.

Sam Higham

Kesinlikle. Ortak anlayış ve ortak dil bazen sorunun büyük bir parçasıdır. “Ürün odaklı” gibi ifadeler bile farklı biçimlerde anlaşılabilir. İnsanlar bunun ürün ekibinin her şey üzerinde en güçlü ve belirleyici işlev hâline gelmesi anlamına geldiğini düşünebilir.

Bu nedenle kullandığınız terimlerin herkes tarafından anlaşılıp anlaşılmadığını kontrol edin. Anlaşılmıyorsa sadeleştirin veya açıklayın. İnsanlar bir şeyi anlamadıklarında soru sormaya çekinebilir. Toplantıdaki en özgüvenli kişi soru sorabilir; diğerleri ise sessizce yanlış bir anlam çıkarabilir.

Michael Luchen

Herkese karşı sabırlı bir rehber olma yaklaşımını benimsememiz gerekiyor.

Sam Higham

Evet.

Michael Luchen

Son bir soru: Ürün yönetiminin önümüzdeki üç yılda nasıl değişeceğini düşünüyorsun?

Sam Higham

Ürün yönetiminin daha fazla uzmanlık alanına ayrılacağını düşünüyorum. Başlangıçta çok geniş bir alandı ve farklı insanlar için çok farklı anlamlara geliyordu. Yazılım mühendisliğinde olduğu gibi büyüme, B2B, B2C ve pazar yeri gibi daha belirli ürün yönetimi uzmanlıkları ortaya çıkabilir.

Ürün çalışanlarının oluşturduğu topluluk çok büyüdü ve bu nedenle bu uzmanlaşmanın doğal olarak gerçekleşmesini bekliyorum.

Michael Luchen

Kapanıştan önce birkaç hızlı kişisel soru sorabilir miyim?

Sam Higham

Elbette.

Michael Luchen

Başarına en fazla katkıda bulunan kişisel alışkanlığın nedir?

Sam Higham

Dayanıklılık. Bugün başarısızlık hakkında konuştuk. İşler yolunda gitmediğinde ve güvenli bir ortam olmadığında zorlanabilirsiniz. Uyum sağlama da önemli. Bilgiler değiştikçe sürekli uyum sağlayarak öğreniyorum. Son olarak alçakgönüllülük. Bilmem gerekenlerin yarısını bilmediğimi açıkça söyleyebilirim. Başarılı olmak için benden çok daha yetenekli insanlara güveniyorum ve her şeyi bildiğimi iddia etmiyorum.

Michael Luchen

Düzenli olarak kullandığın en sevdiğin araç hangisi?

Sam Higham

Miro. Nasıl telaffuz edildiğinden emin değilim; ancak en esnek araç. Onsuz ne yapardım bilmiyorum. Her gün, her şey için kullanıyorum. İçeriklerimi de onunla hazırlıyorum.

Michael Luchen

Son olarak, ürün yolculuğuna başlayan birine vereceğin tek tavsiye nedir?

Sam Higham

Yardım isteyin. Ürün çalışanlarının her şeyi bilmesi gerektiği varsayılıyor; çünkü çoğu zaman her şeyin kesişiminde yer alıyorlar. Ancak bilmediğinizde yardım istemekten çekinmemelisiniz. Bu, başka bir ürün çalışanı, birlikte çalıştığınız bir mühendis, bir tasarımcı veya kuruluş içindeki başka biri olabilir. Tanıdığım en iyi ürün yönetimi çalışanları sürekli yardım isteyenlerdir; çünkü bunun gelişmelerine yardımcı olduğunu bilirler.

Ürün çalışanları için Twitter’da büyüyen harika bir topluluk da var. İnsanların çoğu başkalarının öğrenmesine yardımcı olmak istediği için orada. Bu nedenle bir numaralı tavsiyem yardım istemek. Aslında bu yalnızca ürün çalışanları için değil, herkes için geçerli.

Michael Luchen

Harika bir tavsiye. Bildiğinizi düşünseniz bile yardım istemek ve ikinci bir görüş almak değerlidir.

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

Sam Higham

Davetiniz için teşekkürler.

Michael Luchen

Sam’in çalışmaları hakkında Twitter veya LinkedIn üzerinden daha fazla bilgi edinebilirsiniz. Sam, katıldığın için tekrar teşekkürler. Dinlediğiniz için herkese teşekkürler; podcast için bir değerlendirme bırakmayı unutmayın. Henüz katılmadıysanız theproductmanager.com adresindeki topluluğumuza katılın.

Herkese tekrar teşekkürler. Bir sonraki bölümde görüşmek üzere. Kendinize iyi bakın!