📣 🎉 Üretim Bandı & Brick Institute Ürün Yönetimi Raporu 2023 için veri topluyoruz. RAPORLAR menüsünden katkıda bulunabilirsiniz! 📣 🎉
📣 🎉 Üretim Bandı & Brick Institute Ürün Yönetimi Raporu 2023 için veri topluyoruz. RAPORLAR menüsünden katkıda bulunabilirsiniz! 📣 🎉
Bültene hoş geldin 👋
“Kullanıcı tutma/Retention” üzerine başladığımız serinin dördüncü sayısındayız: Bu sayıda “hedefleme”ye geldik: Ölçümlemeler sonucu bulduğumuz değerin ne ifade ettiğini nasıl anlayabiliriz, nasıl karşılaştırma yapabiliriz gibi konularda kısa bulgular ile ve örnekler üzerinden giderek konuya genel bir yorumlama yapmaya çalıştık ve faydalı kaynakları da yazının sonuna iliştirdik.
Önceki üç sayıda retention’ı tanımlayıp, kritik eylem’leri ve kullanım aralıklarını anlamaya çalışmıştık ve bu kritik eylemleri nasıl ölçümleyebileceğimizi ve anlamlandırabileceğimizi konuşmuştuk. Konuya vakıf değilseniz, bu sayıdan önce bu yazıları okumanızı tavsiye ederiz (linkler o sayılara gidiyor). Sonraki sayı bu serinin son sayısı olacak ve mevcut durumun nasıl iyileştirilebileceğini anlamaya çalışacağız.
Konu üzerine beğendiğiniz kaynakları, araştırmamızı istediğiniz konuları, fikirlerinizi ve bildiklerinizi paylaşmak isterseniz, Slack’e de bekleriz. Konuk yazar olmak ya da sorularımızı cevaplamak isterseniz de kapımız oldukça açık. 👀 Umarız bilenlere bir tazeleme, bilmeyenlere bir fikir edinme aracı olur!
İyi internetler,
Burcu
Bir önceki sayıda bulduğumuz kritik eylemi ölçümlemeyi ve çıkan sonucu anlamlandırmayı konuşmuştuk. Bu sayı bu sonuca dair nasıl bir hedef koyabiliriz biraz bunun üzerinde duracağız.
En kısa haliyle “nasıl hedef koymalı” sorusunun cevabı: Ne kadar yüksek, o kadar iyi. İdeal dünyada her kullanıcı 3 ya da 6 ay sonunda hala ürünü aktif bir şekilde kullanıyor olsun, retention rate’i %100 olsun, kimse pasif hale gelmesin ya da üyeliğini durdurmuş olmasın. Gerçekler öyle değil tabii ki, bu yüzden paralanmaya da gerek yok o anlamda, ama bakıldığında bu işin en fazla ederi bu ve daha fazlasını hedeflemek zaten mümkün değil.
Gerçekçi bir hedef koymaya niye ihtiyaç var peki? Biraz bulunduğumuz pazarda ne durumdayız’ı görmeye ihtiyaç var, biraz da ürün/pazar uyumunu ne kadar yakaladığımızı görmeye. Retention ölçümlemenin neden kritik olduğunu ilk sayılarda konuşmuştuk: Ürünün nabzını tutmak gibi bir şey, iyi durumda mıyız sorusunun en basit cevabı. Hedef koymak da aslında bu iyi ya da kötü durum evden çıkınca da devam ediyor mu’nun cevabını aramak oluyor.
Hedef koymanın bir yolu ürünü kendi kendiyle benchmark’lamak. Hafta hafta ya da ay ay retention ölçümlemek ve gidişatın trendini anlamak, bu yöne ve ivmeye göre tersine bir modelleme yapıp, sebepleri araştırmak ve üzerine denemeler yapıp sonuç almaya çalışmak gidilebilecek en kesin yol (denemeler üzerine sonraki sayıda, iyileştirme yöntemleri üzerinde duracağız).
Bir diğer yolsa ürünü pazardaki rakipleriyle benchmark’lamak. Bunu yapabilmenin yolu da tabii ki bu veriye bir şekilde erişebilmekten geçiyor: Genelde şirket şirket açık bir şekilde ulaşılabilir değil, ancak çeşitli yöntemlerle yolumuzu bulabileceğimiz kadar veri de var. Burada nelere bakmak gerekir? Okuduklarımdan anladığım kadarıyla en temelde bakılacak dört parametre var: İş modeli, pazar, şirket büyüklüğü, platform. İş modeli oyun ya da e-ticaret olan, ekibin 100-150 kişi olduğu bir mobil uygulama ile 5000+ kişilik bir ekibi olan finans odaklı B2B SaaS bir web platformunun retention ölçümleme kriterleri de, endüstri standartları da oldukça farklı oluyor. Bu farklılığın sebebi genelde şunlar oluyor:
Kullanıcı tipi: Hitap ettiğiniz kullanıcı kitlesi KOBİ’lerse örneğin, kurumsal/enterprise şirketlere göre dükkanı kapatma olasılıkları yüksek olduğundan, doğal yollarla sayıca daha büyük bir kitleye hitap ederken retention’ınız düşük olabiliyor.
Kullanıcı çeşitliliği: Ürünü kullanan birkaç tipte kullanıcı varsa, tüm kaynağı tek bir tipe ayırıp onun ihtiyaçlarını çözen farklı senaryolara aynı ölçüde vakit ayıramayabileceğinizden retention düşebiliyor.
Gelir modeli: Kullanıcı başına ödeme yapılan gelir modellerinde retention, sabit bir ödeme yapılanlara göre daha düşük olabiliyor çünkü fiyatın 30 ya da 300.000 olması çok şeyi değiştirir.
Kullanım sıklığı: Ürünün doğal olarak kullanım sıklığının düşük olması (Airbnb gibi) ya da yüksek olması (Uber gibi) retention’ı etkiliyor.
Acquisition stratejisi: Ürünün kullanıcıları kazanma stratejisi retention’ını da etkiliyor, doğru hedeflenmemiş bir SEO kampanyasıyla milyonlarca yeni ama kalıcı olmayacak kullanıcı kazanmak örneğin.
Ağ etkisi: Bazı ürünlerin doğal olarak bir ağ etkisi oluyor, bir topluluk olarak kullanılan B2B ya da B2C ürünlerin özellikle. Bu ürünleri kullanmaya devam etmek kişisel olarak kullandığımız bazı ürünlere göre daha kolay oluyor.
Farklılığa dair sebepleri anladık, nasıl benchmarking yapabileceğimize dair bir fikrimiz oluştu. Bundan sonrası veriye ulaşmak oluyor, ve sizin için bulduğum birkaç güncel veri kaynağını buraya da ekliyorum.
İlk sıraya bulabildiğim en güncel kaynak olan Lenny’s Newsletter’ın 2020 yılından bir raporu geliyor. Aşağıya görsel olarak bir önizleme bıraktım, şu link orjinal çalışmaya gidiyor, şu da birlikte çalıştıkları Eventbrite CEO’su Casey Winters’ın değerlendirmesi.
Bu çalışma iş modeli odaklı, pazar ya da şirket büyüklüğüne dair parametreler yok. Dikkat edilecek bir başka nokta da bahsedilen “İyi” ve “Çok iyi” değerleri retention’ın düzleşmeye başladığı yerler, yani örneğin consumer SaaS için “iyi” olarak değerlendirilen %40 değeri 6. ayın o anlık görünümü değil, 6. ayda %40 civarında salınması demek oluyor.
Bu rapor yanında faydalı olabileceğini düşündüğüm iki rapor daha buldum: Mixpanel’in 1.2 milyar tekil kullanıcıdan hareketle hazırladığı 2019 Product Benchmarks raporu ve Pendo’dan Product Benchmarks raporu. Mixpanel’de platform ve pazar odaklı parametreler var, Pendo’da ise şirket büyüklüğü de dikkate alınmış. Statista’nın 2020 tarihli şu raporu da platformlar üzerine bir fikir verebilir.
Bu birkaç çalışmayı bir araya getirip, ortalama bir değer üzerinden hedef koymak güzel bir başlangıç olabilir. Bildiğiniz başka raporlar varsa haber edin, ekleyelim, bilgiyi çoğaltalım.
Haftaya bu serinin son sayısında görüşürüz!
“What’s a good retention rate?” — the pitfalls of benchmarking and how you should think about retention – Link
Battle of the (Product) Benchmarks: Pendo and MixPanel – Link
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayılık “Retention” serimize ara verip yıl kapanışı yapıyoruz. Biraz bu yıla dair konuşup, okuyup sevdiğimiz içerikleri derlemeye çalıştık. Üretim Bandı’nın 2021’de en sevilen podcastlerini ve bültenlerini de bir listeleyim dedik ki kaçıranlar için bir kaynak olsun.
Bu yıl benim için 2020’den daha yoğun geçti: Bir yandan yeni işe alışıp sevmek ve artan sorumluluklar, bir yandan dostların birer birer masadan eksilip başka diyarlara göçmesi, bir yandan ekonominin bir acayip halleri derken, 2021’in halet-i ruhiyesi bende güzel bir karmaşa yarattı. Bu güzel karmaşanın içindeyken gönülden ve düzenli içerik üretmek de aslında baya zoru başarmak oldu; özellikle yeni şeyler öğrenmeye vakit yok gibi geldiğinde, yoğun çalışmak gerektiğinde, hayatta başka öncelikler daha çok yer etmeye başladığında, ya da basitçe (aynı zamanda en zoru) insanın içinden gelmediğinde. Yine de sene boyunca hiç aksatmadan yaptığım tek şeyin bülten yazmak olduğunu fark edince güzelce bir seviniyorum: Her iki haftada bir mutlaka bir konuyu araştırıp, öğrenip, şekillendirip bülteni yazdım. Okur sayımız hayli arttı, konuları irdeleyiş biçimlerimiz kuvvetlendi. Ürün geliştirmenin yanında değişik konulara girip çıktık, bir sürü insanın yeni bir şeyler öğrenme yolculuğuna katkımız oldu. Tek bir şeyi sene boyunca düzenli yapmak bile bir sürü kapıyı açtı özetle. “Daha çok şey yapmak isterdim” diyen herkese önerim, “Daha ne yapacaktım” demek olur bu değişik sene için. Bence bu seneyi bir şekilde atlatan herkes yaptıklarını aklında bir listelesin, kendini kutlasın.
Bülten’e 2020’nin Haziran ayında başladık ve kör topal 40. sayısına kadar firesiz geldik 🧿 Daha üzerine düşünülecek, öğrenilecek çok şey var. Bu sene de severek yapabildiklerimize tutunalım. İyi bir 2022 dilerim!
Burcu
Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:
Bülten ve podcastlerde en sevilen içeriklerimiz şöyle oldu:
Bülten #34: Yeni bir şeye başarı metriği belirlemek
Bülten #39: Retention-3: Ölçümleme ve anlamlandırma
Bülten #38: Retention-2: Kritik eylem ve kullanım aralığı
Bülten #21: Ürün gereksinimleri dökümanı (PRD)
Bülten #24: Yeni Özellik Geliştirmek-1: Keşif
Teknik: Cem Başaranoğlu ile Hepsiburada nasıl yazılım geliştiriyor?
Teknik: Adem İlter ile video içerik üretimi ve Product Designer / Frontend Dev olmak
Tüm Üretim Bandı içeriklerini aslında tek bir amaçla üretiyoruz: Bilgiyi ortaya çıkarmak ve toplulukla paylaşmak. Bunu yaparken ilham aldığımız ve yeni şeyler öğrendiğimiz kaynaklar çok, ancak bu seneyi düşününce aklımıza gelen, en çok sevdiklerimiz ve takip ettiklerimiz şunlardı:
Lenny’s Newsletter – Son Sayı
Product Hunt Newsletter – Son Sayı
The Beautiful Mess – Son Sayı
Gibson Biddle’s “Ask Gib” Product Newsletter – Son Sayı
Future by a16z – Sevdiğimiz bir yazı: The Case for ‘Developer Experience’
The Pragmatic Engineer – Link
Product Life – Link
Reforge – Link
The Generalist – Link
hackernewsletter – Link
Changelog – Link
Conor Dewey – Link
This Too Shall Grow – Link
Product Plan – The 2021 State of Product Management Annual Report
Product School – The Future of Product Management
Fjord – Trends 2022
Nielsen Norman Group – Top 10 UX Articles of 2021
Bültene hoş geldin 👋
“Kullanıcı tutma/Retention” üzerine başladığımız serinin üçüncü sayısındayız! Bu sayıda “ölçümleme”ye geldik: Ölçümlemede amacımız ne, ölçümlemeyi nasıl yaparak aradığımız cevaba ulaşabiliriz, bulduğumuz cevap ne ifade eder gibi konularda kısa açıklamalar ile ve örnekler üzerinden giderek konuya genel bir yorumlama yapmaya çalıştık ve faydalı kaynakları da yazının sonuna iliştirdik.
Önceki iki sayıda retention’ı tanımlayıp, kritik eylem’leri ve kullanım aralıklarını anlamaya çalışmıştık. Konuya vakıf değilseniz, bu sayıdan önce bu yazıları okumanızı tavsiye ederiz (linkler o sayılara gidiyor). Sonraki sayılarda da bu kritik eylemlere dair hedef koymayı ve mevcut durumun nasıl iyileştirilebileceğini anlamaya çalışacağız.
Konu üzerine beğendiğiniz kaynakları, araştırmamızı istediğiniz konuları, fikirlerinizi ve bildiklerinizi paylaşmak isterseniz, Slack’e de bekleriz. Konuk yazar olmak ya da sorularımızı cevaplamak isterseniz de kapımız oldukça açık. 👀 Umarız bilenlere bir tazeleme, bilmeyenlere bir fikir edinme aracı olur!
İyi internetler,
Burcu
Bir önceki sayıda “kullanıcının ürünü kullanırken aldığı, ürünün temel değer önermesiyle örtüşen aksiyon” olarak tanımladığımız “kritik eylem”i bulmaya ve “kullanıcının bu kritik eylemi gerçekleştirmek amacıyla ürünü ne sıklıkla kullanacağını” netleştirmeye yarayan “kullanım aralığı”na odaklanmıştık. Bu sayı bu adımları tamamladığımız yerden devam ederek, ölçümleme ve anlamlandırmaya geçiyoruz.
Retention’ı ölçümlemenin türlü yolları var, ancak hepsinin cevap aradığı ortak soru şu: Kullanıcıların ne kadarı zaman içinde bu kritik eylemi yapmaya devam ediyor? Biz de bu ölçümlenenin türlü yollarının detaylarına girmek yerine, bu soruya en basit şekilde nasıl cevap bulabileceğimize odaklanalım dedik.
Bir örnek üzerinden gidelim ki kavramlarda boğulmayalım: Kritik eylemi “içeriği kaydetmek” olarak belirledik diyelim, ve kullanım aralığını da “haftalık” olarak seçtik. İşe “cohort” yaratmakla başlıyoruz: 0. haftadan itibaren (örneğimizde 0. hafta, kullanıcının ürünü kullanmaya başladığı zaman) hafta hafta kullanıcıların ne kadarının kaydetme aksiyonunu en az bir kere yaptığına bakalım istedik. Şöyle bir sonuca ulaşıyoruz:
Bu grafiğin okunuşu şu: 2-8 Kasım arası 120 yeni kullanıcı gelmiş, bu 120 kullanıcının 90’ı ilk hafta içinde geri gelip bir içeriği kaydetmiş, 80’i ikinci hafta geri gelip içerik kaydetmiş, 73’ü üçüncü hafta.. gibi.
Bu adımları her bir cohort için tekrarlayıp, sayıları oranlara çevirdiğimizde şöyle bir tablo oluşuyor:
Bu tablonun hafta hafta ortalamalarının grafiğe dökümünü yaptığımızı ve şöyle bir sonuca ulaştığımız düşünelim (kullanım sıklığı haftalık olduğunda, önerilen 12 haftalık bir ölçümleme yapmak):
Bu grafikten çıkarabileceğimiz ilk sonuç şu: Ürün yaşıyor. Haftalar geçtikçe belirlediğimiz kritik eylemi yapan kullanıcı oranı belirli bir aralıkta kalmış—düzleşmiş. Eğer bu grafiğin %0’a yakınsadığını ya da ulaştığını görseydik, oturup düşünmemiz gerekirdi: Ya ürün-pazar uyumunda bir problem var, ya da yanlış kritik eylemi veya kullanım aralığını seçtik. Eğer ürünün yaşadığını düşünüyorsak bu konulara odaklanarak başlamak gerekli; bunlardan eminsek ve grafik yine aşağı yönlü bir trenddeyse de önümüzdeki sayılarda odaklanacağımız hedefler koyma ya da mevcutu iyileştirme üzerine kafa yormak gerekiyor.
Basitçe gösterimlemeyi umduğumuz bu yaklaşımın bir handikapı var: Her haftanın ortalamasını aldık ve bu yaklaşım örnek uygulamalardan biraz uzak. Önerilen her bir cohortu kendi içinde değerlendirmek.
Biraz daha uzun soluklu bir örneğe bakalım:
Bu grafikten çıkarabileceğimiz birkaç sonuç var:
Retention düşüş trendinde. Örneğin 5 Mayıs haftası kayıt olan kullanıcıların sadece %14’ü 10. haftada hala bir içerik kaydediyor.
Retention oranı zaman içinde %5-6 civarında düzleşiyor gibi. Düzleşmesi bir grup kullanıcının hala üründe bir değer gördüğünü gösteriyor, ama oran muhtemelen bizi mutlu etmedi.
Ölçümleme ve anlamlandırmaya böylece genel bir bakış atmış olduk. Akıllardaki beliren yeni soru muhtemelen şu oldu: Bu oranları nasıl karşılaştırmak lazım (benchmarking)? Biraz düşük gibi geliyor, nasıl iyileştireceğiz? Bu sorulara önümüzdeki sayı cevap arayacağız. Takipte kalın!
June – User Retention – Link — Güzel görsellerine yazıda da yer verdiğim bu rehberi baya beğendim. June ölçümlemeye yeni başlayacak startuplar için de önerilen, YC destekli bir ürün bu arada ilgilisine.
3 Ways to Measure User Retention – Link — Bu sayıda “N-day retention”ı hesaplayan örneklerle gittik, ancak farklı yöntemleri de görmek adına bu kaynağa göz atabilirsiniz.
Lifecycle analysis and tracking movement of users between cohorts – Link — Mixpanel topluluk üyelerinden güzel bir “cohort analizi” pratiği. Bu sayıda örneklediğimiz cohortlarda “yeni kullanıcı” herhangi bir segmentasyon yok, ancak bu yazıda biraz daha bu yönde düşünmeye yarayacak şeyler var.
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
“Kullanıcı tutma/Retention” üzerine başladığımız serinin ikinci sayısındayız. Bu sayıda “kritik eylem”i konuşuyoruz: Nedir, nasıl belirlenir, bu eyleme dair kullanım aralığı nasıl belirlenir ve önemi ne gibi konulara değinip, faydalı kaynakları da yazının sonuna iliştirdik.
Sonraki sayılarda bu kritik eylemleri ölçümlemeyi ve oluşan eğrileri anlamlandırmayı, hedef koymayı ve mevcut durumun nasıl iyileştirilebileceğini anlamaya çalışacağız.
Konu üzerine beğendiğiniz kaynakları, araştırmamızı istediğiniz konuları, fikirlerinizi ve bildiklerinizi paylaşmak isterseniz, Slack’e de bekleriz. Konuk yazar olmak ya da sorularımızı cevaplamak isterseniz de kapımız oldukça açık. 👀 Umarız bilenlere bir tazeleme, bilmeyenlere bir fikir edinme aracı olur!
İyi internetler,
Burcu
🔋Bültenin bu sayısı Talentmelon desteğiyle yayınlanmaktadır.
2022 için ortalama maaş zamları ne olacak?
Yazılım geliştirme dünyasında maaşlarda son durum ne?
Hibrit çalışma modeli şirketler tarafından nasıl uygulanacak?
Talentmelon olarak Endeavor Türkiye ortaklığıyla yürüttüğümüz 2022 Ücret ve Yan Haklar Araştırma Raporları, maaş, satış primleri, bonus ve yan haklara dair sağladığı veriler ile insan kaynağına yatırım yapmak isteyen şirketler için zengin bir rehber niteliği taşıyor.
41 şirketin 4 bini aşkın çalışanı temsilen veri sağladığı Maaş Analizi raporuna erişim ile ilgili detaylı bilgi almak için:
60 şirketin katkı sunduğu Ücret ve Yan Haklar Trend Analizi raporuna ücretsiz erişmek içinse bu bağlantıyı kullanabilirsiniz.
Biz neler yapıyoruz? Talentmelon, büyüyen teknoloji şirketlerine insan ve kültür konularında danışmanlık hizmeti sunan bir yönetim danışmanlığı şirketidir. Talentmelon olarak dört ana alanda hizmet sunuyoruz; Kültür, Ücretlendirme, OKR Danışmanlığı ve Büyüme. Şirketiniz için sunabileceğimiz hizmetlerle ilgili daha kapsamlı bilgi almak isterseniz hello@talentmelon.com aracılığı ile bizlere ulaşabilirsiniz.
☝️Geçen sayıdan bu sayıya geçiş yaparken bahsetmenin önemli olacağı bir detayı yakaladık: Kullanıcı tutma (user retention) ve müşteri tutma (customer/logo retention) birbirlerini besleseler ve aynı gibi görünseler de aralarında iş modeline de bağlı olarak küçük farklar var. Kullanıcı tutma daha çok kullanım metrikleriyle ölçülüp tekil kullanıcıların bağlılığı (engagement) üzerine yoğunlaşırken, müşteri tutma daha çok finansal metriklerle ölçülüp organizasyonun ürünü kullanmaya ve kullanım bedelini ödemeye devam etmesine kafa yoruyor. B2C için bu iki kavram birbirine yakınsıyor çünkü her tekil kişi kendi finansallarından sorumlu, ancak B2B’de durum farklı: Organizasyon ürünü kullanmayı bıraktığında churn bir hayli yükseliyor. Bu organizasyondaki ürünü satın alma kararını veren ya da ürünü en aktif kullanan kullanıcıların özel olarak takibi de öneriliyor, bir nevi özel kullanıcı tutma oluyor bu da, çünkü bu kişilerin gitmesi müşteri tutma seviyesinde negatif etki yaratabiliyor.
Biz bu yazı dizisinde daha çok kullanıcı tutma üzerinde duruyoruz, ancak müşteri tutma özelinde bir şeyler de araya girebilir, oralarda haberleşiriz.
Konuya gelelim: Kritik eylemler. Kritik eylem özetle şu demek: Kullanıcının ürünü kullanırken aldığı, ürünün temel değer önermesiyle örtüşen aksiyon. Bu aksiyon aynı zamanda muhtemelen bizim görmek istediğimiz bir hareket, istiyoruz ki kullanıcı ürünü bu niyetle kullansın. Bu kritik eylemi belirlemek, ürünün kullanımına dair içgörüler edinmek adına ilk adım olarak düşünülüyor. Retention ölçümlemeyle kritik eylem de bu noktada bağdaşıyor: Kullanıcının bize göre aktiflik tanımı, bu kritik eylemi yapıyor olması olmalı. Günlük, haftalık ya da aylık aktif kullanıcıları tanımlarken de bu çizgiden ayrılmamak gerekiyor: Uygulamayı indirmek ya da açmak değil, bu anlamlı aksiyonu almak ürünün büyümesine dair en takip edilebilir kriter.
Ürünün iş modeline göre birden fazla kritik eylem düşünülebilir: Pazaryeri gibi modellerde birbirinden çok farklı akışları olan, farklı kullanım amaçlarına sahip kullanıcılar var örneğin. Çoğu organizasyon için bir tane kritik eylem tüm değer önermesini kapsıyor, ancak birbirinden farklı arka planları ve kullanım amaçları olan kullanıcılar için birden fazla kritik eylemi takip etmek de makul. Aynı kullanıcı için bir dizi eylem de takip edilebilir. Organizasyon içinde farklı ürün ekipleri farklı alanlara eğiliyorsa, bu ekiplerin kritik eylem tanımları da farklı olabilir.
Kritik eylem ya da eylemleri belirlemek, beraberinde bir sürü planlama yapmayı kolaylaştırıyor: Ürünün yol haritasını, kullanıcı deneyimini, pazarlama ve promosyon aktivitelerini kullanıcının bu kritik eylemleri daha kolay, hızlı ve tekrarlı şekilde yapabilmesini sağlayacak şekilde planlamak, herkesin tek bir amaca yönelik hareket etmesini sağlıyor.
Peki doğru kritik eylem nasıl bulunur? Az çok aklınızda canlanıyordur, ama ekipçe karar verecekseniz ya da üzerine bir egzersiz yapmak isterseniz, şu soruları cevaplamak yararlı olabilir:
Kullanıcı ürüne her geldiğinde tek bir şey yapmasını isteseydik, bu ne olurdu?
Farklı kullanıcı tipleri varsa: Her bir grup üründen ne değer kazanıyor? Bu değeri nasıl ölçümleyebilirdik?
Organizasyon genelinde önemsenen, takip edilen metriklere neler? En nihayetinde neyi artırmak istiyoruz? Hangi kullanıcı aksiyonları bu metriklerle ilişkilendirilebilir?
Bu sorulara cevap olarak bir olası kritik eylemler silsilesi oluşturdunuz, ama hangisinin aradığınız kritik eylem olduğuna karar vermekte zorlanıyorsunuz diyelim. Eğer halihazırda ölçümlediğiniz veriler varsa, bundan sonrası bu eylemlere dair hipotezler oluşturmak ve test etmek üzerine. Şöyle bir hipotezi örnek verelim: “Profillerine kredi kartı bilgilerini ekleyen kullanıcılar daha çok ürün satın alıyor”. Bu hipotezi test etmek için şu soruları sorabilirsiniz: Kredi kartı eklemeyen kullanıcılara göre daha fazla mı ürün satın alıyorlar? Ürüne kredi kartı eklemeyen kullanıcılardan daha fazla mı geri dönüyorlar? Benzer soruları her bir hipotez için sorup, belirgin korelasyonlar yakalayabildiğiniz hipotezler için küçük deneyler yaparak validasyon sağlayabilirsiniz. Kredi kartı bilgisi eklemeyi öne çıkarıp ya da promosyonlarla teşvik edip, ekleyen kullanıcıların satın alma davranışları değişiyor mu gözlemleyebilirsiniz örneğin. Bu deneylerin sonucunda veri destekli kritik eylemleriniz ortaya çıkacak.
Kritik eylemleri belirlemek, retention metriğine karar vermenin ilk adımı. İkinci adımsa bu kritik eylemlerin kullanım aralığını ya da başka bir deyişle, ürünün bu amaçla kullanım sıklığını netleştirmek. Kullanım aralığı önemli, çünkü bu kritik eylemin hedeflere olan etkisini gerçekçi şekilde takip edebilmek için, önce ne kadar gerçekleştirildiğini bilmek gerekiyor: Ürününüz her gün kullanmayı gerektirmeyen bir amaca yönelik olabilir örneğin. Bu durumda kullanıcının bu kritik eylemi her gün yapmasını beklemek, aşağıdaki mavi grafikte olduğu gibi davranışları yanlış yorumlamaya sebebiyet verebilir. Her gün yapılması beklenen kritik bir eylemi haftalık olarak ölçmek de, olması gerekenden daha pozitif bir tablo yaratabilir. Reforce’un şu blogu yanlış kullanım sıklığına odaklanmanın risklerini ve olası etkilerini güzelce anlatıyor.
Peki bizi sağlıklı bir stratejiye ulaştıracak kullanım sıklığını nasıl belirleyeceğiz? Bu da aslında aklınızda az çok canlanıyordur, ama daha sistematik bir yol izlemek isterseniz, Amplitude tarafından şu adımları takip etmek öneriliyor:
Son 60 ya da 90 gün içinde, kritik eylemi en az 2 kez yapmış kullanıcıları bulmak.
Bu kullanıcıların kritik eylemi ilk kez ve ikinci kez yapışları arasında geçen zamanı (sıklığı) ölçmek.
Kümülatif dağılım fonksiyonunu çalıştırıp, kullanıcıların hangi yüzdelik dilimlerle farklı zaman aralıklarına düştüğünü saptamak. Örneğin, kullanıcıların %50’si için bu sıklığın 7 gün, %35’i için 12 gün, %10’u için 15 gün ve kalanı için daha uzun olduğunu bulmak.
Kullanıcıların %80’i için bulunan sıklık, bu kritik eylemin kullanım aralığı olacaktır.
Finding Your Product’s Critical Event(s) – Link
Choosing a retention metric – Link
User Retention Depends on Your App’s Critical Event – Link
How Often Should People Use Your App? – Link
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Biraz da analitik düşünelim diyerek, “Kullanıcı tutma/Retention” üzerine bir seriye başlıyoruz: Bu sayıda konu üzerine biraz konuşup başlangıç yaparken, ilerleyen sayılarda nasıl bir plan program yapılabileceğine dair kafa yoracağız. Kritik eylem (critical event), kullanım aralığı (usage interval), kullanıcı tutma eğrileri (retention curves) gibi kavramları didiklerken, retention’ın büyümeye ve rekabete olan etkilerini, zorluklarını, nasıl ölçülebileceğini ve iyileştirilebileceğini, kullanıcı kayıp (churn) ve retention ilişkisini, Amplitude’un meşhur “Retention Lifecycle Framework”’ünü ve nicelerini konuşacağız. Bu seride kaç sayı olacak henüz kestiremiyorum, önümüzdeki sayı netleşiriz ve sınırları çizeriz zira hayat kısa 👵
Konu üzerine beğendiğiniz kaynakları, araştırmamızı istediğiniz konuları, fikirlerinizi ve bildiklerinizi paylaşmak isterseniz, Slack’e de bekleriz. Konuk yazar olmak ya da sorularımızı cevaplamak isterseniz de kapımız oldukça açık. 👀 Umarız bilenlere bir tazeleme, bilmeyenlere bir fikir edinme aracı olur!
İyi internetler,
Burcu
🔋Bültenin bu sayısı Borda Technology desteğiyle yayınlanmaktadır.
Biz kimiz, ne yapıyoruz? 10 yılı aşkın süredir IoT ürünlerimizle hastanelerin hem dijital dönüşümüne hem de bunun ötesinde daha akıllı hale gelmesine katkıda bulunuyoruz. İstanbul ve İzmir/Urla’da toplam 90 kişiyiz. Amerika, Rusya ve İsveç’te de ofislerimiz mevcut. Yukardaki QR sana ne yaptığımızı en iyi şekilde anlatacaktır.
Peki bunu nasıl yapıyoruz? 45 kişilik teknolojik ekibimiz hastanelerdeki demirbaş, hasta ve personel süreçlerini IoT sensörler sayesinde uçtan uca otomatik olarak takip ederek hem süreçsel hem anlık faydalar sağlıyor. Tüm dünyada ürünlerimiz 50’den fazla hastanede aktif olarak kullanılıyor.
Hedefimiz ne? Şirketimizi global pazarda lider konuma getirmek istiyoruz ve bunu yalnız çok iyi bir ekiple gerçekleştirebiliriz. Dünyada sağlığı dönüştürecek ekibin bir parçası olmak ve bunu son teknolojilerle yapmak seni de heyecanlandırıyorsa:
Geçtiğimiz haftalarda gerçekleştirdiğimiz parkur oyunları ve barbekü temalı şirket etkinliğimizi buradan izleyebilirsin. Belki bir sonraki etkinliğimizde sen de aramızda olursun!
Kullanıcı tutma (bundan sonra “retention” diyelim; Google’ın Türkçeleştirdiği kaynaklarda “kullanıcıyı elde tutma” denmiş ama anlatım pek hoşuma gitmedi), en basit tanımıyla “belirli bir zaman dilimi boyunca belirli bir eylemi yapmaya devam ederek aktif kalan kullanıcıların yüzdesi” demek. Yani durup durup ürüne bu eylemi yapmak için geri gelen kullanıcılar bunlar.
Retention aslında bir çıktı ve girdileri sırayla aktivasyon (activation), etkileşim (engagement) ve canlanma (resurrection). “Retention’ı iyileştirmek” gibi bir şey konuşuluyorsa aslında bakılacak yerler bu üçü: Bu girdilerden herhangi birindeki bir olumlu değişiklik, retention’a büyük bir iyileşme olarak yansıyor. Retention’daki bir iyileşme de, ağ etkisi (network effect) ya da doğal olarak kullanıcının kullanım süresini ve organizasyona olan kazanç etkisini (CLV) artırmasıyla aktivasyon/etkileşim/canlanma üçlüsüne olumlu bir etki olarak geri dönüyor. Bu üçlüyü kısaca şöyle tanımlayabiliriz:
Aktivasyon kullanıcının ürünü gördüğü/duyduğu andan itibaren değere ulaştığı ana (ünlü “Aha moment”) kadarki adımları kapsıyor diyebiliriz. Kimi organizasyonlarda bu alana özelleşen “growth” ürün yöneticileri olabiliyor.
Etkileşim kullanıcıya yeni çözüm yolları sağlayarak bu çözümleri kullanan kullanıcı sayısını ve bu kullanımların sıklığını artırmayı hedefleyen aktiviteler bütünü. Burada hedef kullanıcı ne zaman sağladığımız çözüme ihtiyaç duysa ürüne gelmesini sağlayacak alışkanlıklar geliştirebilmek.
Canlanma da uyur halde ve aslında ürünü kullanmaya dönme potansiyeli olan kullanıcıyı bulmak ve geri kazanmak adına yapılan şeylere deniyor. Tabii ki en güzeli uyumalarını engellemek, bu yüzden aktivasyon ve etkileşim’e göre canlanma’nın önemi de bir tık daha az.
Büyümeye en çok etki eden iki faktör kullanıcı edinme (acquisition) ve retention. Biri olmadan diğerinin pek bir anlamı olmuyor çünkü kullanıcı edinmeye eğilinmediğinde ürünün değerini anlatacak kullanıcı bulmak zorlaşırken, retention üzerine düşünülmediğinde kullanıcıların içeride kalmak için nedenleri azalıyor (artık her şeyi yapan bir sürü ürün var). Yine de retention üzerine çalışmanın yeni kullanıcı edinme üzerine çalışmaktan çok daha az maliyetli olduğu ifade ediliyor, çünkü halihazırda ürünü denemiş birine ulaşmak ve kazanmak temelde çok daha kolay. Kullanıcı edinme üzerine kurulu bir ürün stratejisi günün sonunda bir sürü günlük aktif kullanıcıya ya da web sitesi ziyaretçisine dönse de bu metrikler stratejiyi yönlendirip besleyecek içgörüler üretmek yerine yüzeysel başarılar olarak kalıyor.
Çoğu organizasyon çabuk sonuç alınabilen ve başarıya ulaşıldığını hissettiren metrikler üzerine yoğunlaşırken, retention için “sessiz katil” denilmiş çünkü çoğu yerde bu konuya ya hiç öncelik verilmiyor, ya öncelik veriliyor ama metrikler yanlış tanımlanıyor, ya da etkileşime giden kök sebepler araştırılmıyor. Reklam bütçeleriyle desteklenen ve sık kullanılan ürünlerin çoğunlukta olduğu oyun, e-ticaret gibi pazarlarda günlük, haftalık ya da aylık aktif kullanıcı sayısını (DAU/WAU/MAU) takip etmek önerilen, ancak daha düşük tempolu kullanımları olan ya da bütçesini idareli kullanmak isteyen ürünler için en çok önerilen ve anlamlı bulunan değer ölçümleme kriteri retention oluyor.
Bu sayıda yararlandığım, önümüzdeki sayılarda da bakacağım bazı kaynaklar (aklınızdaki kaynakları da lütfen paylaşın—bu maile cevap olarak iletebilirsiniz!):
Amplitude’un Mastering Retention serisi.
Reforce’un Retention blog serisi (ilk sayı).
Conor Dewey’in blogu.
Daha sonraya okumalık kaydettiklerim:
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayının konusu “Ürün geliştirmede bilgiyi organize etmek”: İnsan beyni bilgiyi nasıl organize ediyor kısmını derince inceledikten sonra ürün geliştirmede bu yöntemlerin nasıl karşılıkları olabileceği üzerine fikirler yürüttük.
Konu üzerine fikirlerinizi ve bildiklerinizi paylaşmak isterseniz, Slack’e de bekleriz. Umarız organizasyon yetilerinize yeni pratikler kazandırabiliriz!
İyi internetler,
Burcu
🔋Bültenin bu sayısı Borda Technology desteğiyle yayınlanmaktadır.
Biz kimiz, ne yapıyoruz? 10 yılı aşkın süredir IoT ürünlerimizle hastanelerin hem dijital dönüşümüne hem de bunun ötesinde daha akıllı hale gelmesine katkıda bulunuyoruz. İstanbul ve İzmir/Urla’da toplam 90 kişiyiz. Amerika, Rusya ve İsveç’te de ofislerimiz mevcut. Yukardaki QR sana ne yaptığımızı en iyi şekilde anlatacaktır.
Peki bunu nasıl yapıyoruz? 45 kişilik teknolojik ekibimiz hastanelerdeki demirbaş, hasta ve personel süreçlerini IoT sensörler sayesinde uçtan uca otomatik olarak takip ederek hem süreçsel hem anlık faydalar sağlıyor. Tüm dünyada ürünlerimiz 50’den fazla hastanede aktif olarak kullanılıyor.
Hedefimiz ne? Şirketimizi global pazarda lider konuma getirmek istiyoruz ve bunu yalnız çok iyi bir ekiple gerçekleştirebiliriz. Dünyada sağlığı dönüştürecek ekibin bir parçası olmak ve bunu son teknolojilerle yapmak seni de heyecanlandırıyorsa:
Geçtiğimiz haftalarda gerçekleştirdiğimiz parkur oyunları ve barbekü temalı şirket etkinliğimizi buradan izleyebilirsin. Belki bir sonraki etkinliğimizde sen de aramızda olursun!
Nedir?
Farklı yöntemler
Faydalı kaynaklar
Aklınızdaki tüm düşüncelerin fiziksel bir karşılığının olduğunu ve bulunduğunuz ortamda sağa sola uçuştuğunu bir düşünün. Bayağı bir kargaşa ve düzensizlik olurdu herhalde. Farkında olmasak da insan beyni durmaksızın etrafını ve uçuşan bu düşünceleri algılıyor, işliyor, planlayıp organize ediyor ve hatırlıyor ki bu düzensizliğe mani olsun. Bir gün içinde yaptığınız her şeyi düşünürseniz (düşünemedi) ne kadar kompleks bir yapıyı konuştuğumuzu idrak edeceksiniz.
İnsanın sinir sistemi her gün sayısız kaynaktan bilgiyi duyular aracılığıyla topluyor, uyarıcılara dönüştürüyor ve sinirsel itkilerle beyne taşıyor. Beyin de sürekli gelen bu bilgi tanelerini kullanarak düşünceler oluşturuyor, dil yardımıyla dışarı aktarıyor ya da daha sonra kullanmak üzere hafızaya depoluyor. Bu düşünceler oluşturulurken eski hatıralardan ya da duygulardan gelen içsel etkiler de kullanılıyor. Bir koku duyduğunuzda 20 sene önce gittiğiniz bir yerin görüntüsü gözünüzde bir an canlanabiliyor örneğin (koku hafızayı en iyi körükleyen duyu olarak biliniyor).
Beyin bu kadar bilgiyi bu kadar erişilebilir yapabilmek için memurluk dönemlerinizden hatırlayacağınız “dosya dolabı” gibi bir mantıkla hareket ediyor. Her bir farklı dosyaya bilişsel psikolojide konsept (concept) adı veriliyor: İçinde dilsel, görsel, düşünsel, kişilere ya da olaylara dair hatıralar olan kategorisel gruplar. Aslında etiketlemek gibi bir şey. Beyin bu konsepte dair her yeni gelen bilgiyi etiketliyor ve aynı dosyaya ekliyor. Doğal konseptler yaşamın içinden, kendi kendimize edindiğimiz duyusal öğrenimlerle oluşurken (karın yağışını izlemek, çayın tadını almak), suni konseptler spesifik karakteristiğe sahip bilgilerin üst üste koyulmasıyla öğrenilenler oluyor (matematikte “kare” nedir öğrenmek, daha sonra alanını hesaplamayı öğrenmek). Bu doğal ya da suni konseptlerin değişik kombinasyonlarına da şemalar (schemata) adı veriliyor: Temel görevi eksik bilgi parçacıklarının yerine tahminler yürütmek ya da mevcut bilgilerle rutin işlemleri yapabilmek. Bu iki görev de zaman zaman sekteye uğrayabiliyor: Çok güzel kokan bir yiyeceğin tadı güzel olur (olmayabilir) ya da telefonda bir hareketlenme olduysa ekrana bakılır (araba kullanırken bakılmaz). Beyin bu kısımları biraz otomatik yürüttüğünden, farkına varıp değiştirmek o an zor olabiliyor (zehirli olabilir diye düşünmemizi sağlayan evrimsel biyolojiye ya da yeni iOS sürümüyle gelen focus mode’a teşekkürler).
Beynin bilgiyi nasıl işleyip kullandığını kısaca özetlemiş olduk. Şimdi ürün geliştirmede bu işleyişleri nasıl düşünebiliriz ona bakalım.
Bu sayıda bilgiyi ürün geliştirirken organize etmenin ya da geliştirilen ürün içinde erişilebilir kılmanın yolları üzerine yoğunlaştık. Bir organizasyon içinde bilgiyi organize etmek ya da kişisel hayatta tertipli düzenli olmak bu sayının konusu değil o yüzden.
Ürün geliştirirken bilgiyi organize etmeye dair kabul görmüş birçok kullanıcı deneyimi prensibi var. Aslında bu prensiplere sadık kalındığında ürün içinde de bilgi erişilebilir hale geliyor: Kullanıcı ihtiyaçları ilk sırada olduğunda, geliştirdiğimiz ürünün ya da özelliğin amacı da netse yapılacak tek şey tutarlı olmak.
Kullanıcı ihtiyaçlarını ilk sırada tutabilmek için uygulanan bazı pratikler mevcut: Card sorting, wireframing, prototyping, mind mapping, gibi gibi. Tüm bu pratiklere “Bilgi Mimarisi, Information Architecture (IA)” adı veriliyor ve kullanıcılardan edinilen bilgileri toplamaya, gruplamaya, ilişkilendirmeye ve sıraya koymaya yarıyorlar aslında. Bu bilgi mimarilerini oluşturan sistemleri ortaya çıkarmak için şöyle stratejiler kullanılıyor:
Kategorileme/Classification: Bilgiyi sınıflandırma ve yapılandırma.
Etiketleme/Labeling: Bilgiyi sunma.
Navigasyon/Navigation: Bilgiler arasında gezinme.
Arama/Search: Bilgiyi bulma.
Bu sistemlerin girdileri olarak belirtilen faktörler de şunlar:
İçerik: Organize edilecek bilginin miktarı, tipi, yapısı ve sahibi.
Bağlam: Ürün hedefleri, teknolojik altyapısı, kaynakları.
Kullanıcılar: Ürünü kullanacak kişiler, yapmak istedikleri işler, bilgiyi arayan davranışları ve ürüne dair deneyim düzeyleri.
Tüm bu stratejiler ve faktörlere göre de ürünün içindeki bilginin inşası sağlanıyor. Araştırmalarımda sık gördüğüm bir yöntem daha var: Five Hat Racks. Mimar ve tasarımcı Richard Saul Wurman’ın (kendisi aynı zamanda Information Architecture kavramını ortaya ilk atan kişi ve TED konferanslarının yaratıcısı) bizlere armağan ettiği bu yöntemi fena açıklamayan bir makaleyi de buraya bırakıyorum.
Ürün içinde bilgiyi organize ederek erişilebilir kılmanın da çeşitli yolları var, biraz düşününce ilk aklıma gelen üç örnek şunlar oldu:
Kullanıcının belirli bir dosyalama mantığı oluşturabilmesini sağlayan “İç içe dizinler/Nested directory”.
Bu yöntemin tek başına artık pek de kullanışlı olmadığını ve yavaş yavaş kaybolmaya başladığını, daha insan beynine yakın deneyimlerin tercih edildiğini siz de gözlemliyorsunuzdur. Çünkü bu yöntemle bilgiyi organize eden ürünlerde aradığını bulmak, aradığının nerede olduğunu bilmekten geçiyor. Bu da her gün milyonlarca bilgiyi işleyen beynimiz için ekstra bir bilişsel yük (cognitive load) yaratıyor.
Kaynaklarda bu yönteme dair çok güzel bir makale var, ilgilisine tavsiye ederim.
Üründeki tüm içeriğe hızlıca ulaşabilmeye, aralarında zahmetsizce gezinmeye yarayan “Genel arama/Global search”.
Bu yöntem aslında insan beynine dosyalamalardan çok daha yakın bir deneyim. Biraz düşününce Google Search’ün insan beynine yakınlığının başarıyı getirdiğini görmek de mümkün.
Bu ekolü takip eden MacBook’un Spotlight’ı, çok güzel çalışan bir örnek değil örneğin. Masaüstü uygulamaları için kullanışlı, ancak spesifik bir dosya araması bana göre pek de akıllı çalışmıyor. Spotify’ınki gayet güzel sanki.
O anda ihtiyaç duyulan içeriği, ürün içindeki davranışlara, kullanım amaçlarına, ürünün neresinde olunduğuna göre ayağa getirmeyi amaçlayan “Akıllı öneriler” (İngilizce ve kabul görmüş bir karşılık bulamadım, aklınızdaysa haber edin ki düzenleyeyim).
Genel aramanın da bir tık iyisi olan bu yöntemi birçok yerde görüyoruz: Gmail’de ya da Slack’te aramaya başladığımız yere, aradığımız içeriğe göre gelen öneriler, aramayı tamamlayan kategoriler, etiketler, eski aramalarımızdan öğrenilmiş kısayollar, benzer sonuçlara atıflar, gibi gibi.
İçinde bolca içerik olan ve odağı kullanıcıların bu içeriklere kolayca ulaşabilmesi olan tüm ürünlerin bu yönteme geçiş yapması gerekli gibi duruyor.
Bu sayının konusunu belirlememe önayak olan makale: “File Not Found”. Yeni neslin Google ve dahi nice arama fonksiyonuna nasıl alıştığını, “dosya klasörleme” alışkanlığının tıpkı “otomatik kaydetme”nin “kaydet” aksiyonunu unutturması gibi nasıl değiştiğini ve unutulacağını anlatan harika bir yazı. Mutlaka bir bakın.
Inside Out filmini konuyu bilimle harmanlayarak ele alışı ve bayağı bir eğlenceli oluşu sebebiyle mutlaka tavsiye ediyorum. Çoluk çocuk izlemek de miniklerin zihnini açabilir.
Bilişselliği, konseptleri ve şemaları öğrenmek için şu makaleden çokça faydalandım.
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayının konusu “Araştırma ve keşifte etkiyi ölçümlemek”: Kullanıcı araştırmaları ya da ürün keşif aktivitelerinin yarattığı etkiyi tanımlayıp, anlayabilmenin ve ölçümleyebilmenin yollarını araştırdık ve aktardık. Umarız keyifli bir okuma olur! Konu üzerine fikirlerinizi ve bildiklerinizi paylaşmak isterseniz, Slack’e de bekleriz.
Umarız bu konuya dair farklı bir bakış açısı kazandırabiliriz!
İyi internetler,
Burcu
🔋Bültenin bu sayısı Borda Technology desteğiyle yayınlanmaktadır.
Biz kimiz, ne yapıyoruz? 10 yılı aşkın süredir IoT ürünlerimizle hastanelerin hem dijital dönüşümüne hem de bunun ötesinde daha akıllı hale gelmesine katkıda bulunuyoruz. İstanbul ve İzmir/Urla’da toplam 90 kişiyiz. Amerika, Rusya ve İsveç’te de ofislerimiz mevcut. Yukardaki QR sana ne yaptığımızı en iyi şekilde anlatacaktır.
Peki bunu nasıl yapıyoruz? 45 kişilik teknolojik ekibimiz hastanelerdeki demirbaş, hasta ve personel süreçlerini IoT sensörler sayesinde uçtan uca otomatik olarak takip ederek hem süreçsel hem anlık faydalar sağlıyor. Tüm dünyada ürünlerimiz 50’den fazla hastanede aktif olarak kullanılıyor.
Hedefimiz ne? Şirketimizi global pazarda lider konuma getirmek istiyoruz ve bunu yalnız çok iyi bir ekiple gerçekleştirebiliriz. Dünyada sağlığı dönüştürecek ekibin bir parçası olmak ve bunu son teknolojilerle yapmak seni de heyecanlandırıyorsa:
Geçtiğimiz haftalarda gerçekleştirdiğimiz parkur oyunları ve barbekü temalı şirket etkinliğimizi buradan izleyebilirsin. Belki bir sonraki etkinliğimizde sen de aramızda olursun!
Nedir? Neden zor ama gerekli?
Ne yapılabilir?
Faydalı kaynaklar
Kullanıcı araştırmaları ya da ürün keşifleri yapmak temelde kullanıcıları anlamaya yarıyor. Kullanıcı araştırmalarına dair şu sayılarımızı ön okuma olarak düşünebilirsiniz: Nitel kullanıcı araştırmaları ve nicel kullanıcı araştırmaları. Yeni bir özellik geliştirirken yapılan keşif aktivitelerine ise şu sayımızda yer vermiştik:
Araştırma ve keşfin uzun vadeli en önemli sonucu ise organizasyon genelinde karar alma mekanizmalarını eğitmek: Daha isabetli varsayımlarda bulunabilmek ve tahminlerin gerçeklere daha çok yaklaşabilmesi. Bilgiye dayalı hedefler koyabilmek ve bu hedeflere ulaşmayı güvenle en öncelikli konu haline getirebilmek.
Bu aktiviteleri ölçümlemek ise zor, çünkü ürüne yaptığı direkt etkiyi görmek pek mümkün değil. Keşif ya da araştırma yapma sürecine dair bazı takip metrikleri düşünülebilir: Her bir ekip üyesi ayda 4 kullanıcıyla görüşecek, bu görüşmelerde edindiğimiz bilgileri mutlaka araştırma havuzuna ekleyeceğiz, bulguları ve içgörüleri organizasyon genelinde erişilebilir hale getireceğiz, her çeyrek 10 varsayım test edeceğiz, gibi gibi örnekler. Ancak bunlar gerçekten de sürecin düzgün ilerlediğinden ve zaman içinde iyileştiğinden emin olmak adına varlar, gerçekte cevabını aradığımız sorulara direkt bir katkıları yok: Araştırma ve keşif yapmak işe yarıyor mu? İşe yaradığını nasıl anlayabiliriz? Bu sorulara cevap bulabilmek, yani ürettiğimiz sonuca araştırma ve keşfin kattıkları değeri anlayabilmek için sonuç üzerindeki etkilerini ölçümleyebilmemiz gerekiyor.
Bu sayıda özellikle değindiğim kısmın bir özellik özelinde değil de, şirket genelinde düzenli ve sürekli bir araştırma ve keşif pratiği oturtmakla alakalı olduğunu belirteyim (üretici, generative research). Bir probleme spesifik araştırma ve keşif yapmaktan (değerlendirici, evaluative research) beklenenler az çok net oluyor: Özelliğin doğru probleme odaklanması, çözümün kapsamının ihtiyaçları karşılaması, anlaşılır ve kullanışlı olması, şirket stratejisine uygunluğu ve hedeflenen değeri yaratması gibi gibi şeyler test edilebilir ve ölçümlenebilir şeyler. Zaten sonucunda şirket genelinde önemsenen stratejik alanlara bir katkısı oldu mu’yu görmek, bir ölçümleme sistemi olduğunda hayli kolay.
Şu sıralar bu konu üzerine mevcut rolümde de odaklandığımdan uzunca bir araştırma yaptım, ve şaşırtıcı şekilde etkiyi ölçmeye dair yazan çizen bir kaynağa ulaşamadım. Genelde süreci takip etmeye yönelik metrikler ve uygulamalardan bahsedilmiş, fazlası yok. O yüzden biraz serbest stil olacak bu kısım.
Hedef: İşe araştırma ya da keşfi niye yapmak istediğimizi belirlemekle ve bunu organizasyon geneline aktarmakla başlamamız kritik bir başlangıç.
Ürün/Market uyumunu mu bulmaya çalışıyoruz, yeni bir ürün geliştirmeye mi niyetliyiz, şirket genelince belirlenmiş yıllık hedeflere daha hızlı ya da güvenli ulaşmanın yollarını mı arıyoruz, yoksa bir sonraki dönem için yol haritası oluştururken daha kapsamlı ve kanıt niteliğinde verilere/içgörülere mi ihtiyacımız var? Bu hedefi ya da hedefleri ilk iş olarak belirlemek, aranan çıktı ve etkide hemfikir olmayı da hayli kolaylaştırır.
Bu seviyede özelleşmiş bir amacımız yoksa bile, “kullanıcı ihtiyaçlarından yola çıkarak ürün stratejisini besleyecek, geniş çaplı içgörüler oluşturabilmek” gibi bir hedef beyanı olsa, niyeti iletişebilmek adına güzel olur.
Sonuç (outcome): Sonuçları düşünebilmek için sormamız gereken soru şu: Araştırma ve keşif süreçlerinin sonunda ne görmeyi bekliyoruz?
Yol haritası örneğinden gidersek, sonuç olarak bir sonraki dönemin yol haritasını oluşturmak diyebiliriz (planlamaya yetecek düzeyde kanıt ve veri de çıktılar olur).
Bir başka örnek olarak sonuç, yeni bir ürün geliştirmeye dair test edilebilecek birkaç fikre sahip olmak olabilir.
Daha genel bir örnek olarak ekiplerin özellik bazlı keşif sürelerinin kısalmasını verebiliriz.
Etki (impact): İşte bu kısım biraz çetrefilli. Araştırma ve keşfin hedefe etkisi ne olur? Bu etkiyi nasıl ölçeriz?
Etkiye kendimce bulduğum bir örnek şu oldu: Zaman içinde daha doğru varsayımlarda bulunabilmemiz ve daha isabetli kararlar alabilmemiz.
Bu etkiyi ölçümlemeye dair düşüncem de şu: Ürünün stratejik alanlarına dair belirlenmiş hedef metriklere ulaşma hızımız artıyor mu?
Örneğin, bir sonraki yıl için kullanıcı sayımızı %20 artırmak gibi bir hedefimiz var. Her bir çeyrek sonunda bu hedefe daha ivmeli mi yaklaşıyoruz’u görmek, araştırma ve keşfin ürettiği kolektif bilgiyi de düşünerek etkiyi ölçmenin bir yolu olabilirdi.
Tabii ki bu etki safi bir şekilde araştırma ve keşfin ürettiği bir etki olmayabilir, ama bunu takip etmek de mümkün: Metrikleri oynatan kilometre taşları, araştırma ve keşfin sonucu olarak ortaya çıkan kanıt ve verilerin yönlendirdiği şeyler miydi?
Eran’dan gelen bir öneri de NPS (net promoter score)’te yaşanan değişimi ölçmek oldu. Churn’deki değişimi ölçümlemek de bir başka önerisi, ama oradaki etkiyi görmek biraz daha vakit alabilir dedik.
Girdi, çıktı, sonuç gibi kavramlardan şu yazımızda biraz daha detaylıca bahsetmiştik: Bülten #4: Input > Output > Outcome
Etkiyi ölçümlemekle alakalı farklı düşünceleriniz mi var? Slack’teyiz, buyrun konuşalım.
Podcast’in şu bölümünde “sürekli keşif” denince ilk akla gelen isimlerden olan Teresa Torres ile sohbet etmiştik: Continuous Product Discovery with Teresa Torres
Teresa Torres’in keşif süreçlerini ölçümlemekle alakalı şu yazısından bu sayıda çok faydalandım: Doing Discovery Well: How to Measure and Guide Your Team
Başka da kaynak bulamadım. Sizden öneriler gelse de eklesek!
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayının konusu “başarı” metriklerini (success metrics) belirlemek: Ne olduklarını kısaca bir tanımladıktan sonra belirlemenin zorluğundan bahsedip, ne yapılabileceğine dair fikirlerimizi paylaştık ve faydalı kaynakları yazının sonuna iliştirdik. Umarız bu konuya dair farklı bir bakış açısı kazandırabiliriz!
İyi internetler,
Burcu
🔋Bültenin bu sayısı Borda Technology desteğiyle yayınlanmaktadır.
Biz kimiz, ne yapıyoruz? 10 yılı aşkın süredir IoT ürünlerimizle hastanelerin hem dijital dönüşümüne hem de bunun ötesinde daha akıllı hale gelmesine katkıda bulunuyoruz. İstanbul ve İzmir/Urla’da toplam 90 kişiyiz. Amerika, Rusya ve İsveç’te de ofislerimiz mevcut. Yukardaki QR sana ne yaptığımızı en iyi şekilde anlatacaktır.
Peki bunu nasıl yapıyoruz? 45 kişilik teknolojik ekibimiz hastanelerdeki demirbaş, hasta ve personel süreçlerini IoT sensörler sayesinde uçtan uca otomatik olarak takip ederek hem süreçsel hem anlık faydalar sağlıyor. Tüm dünyada ürünlerimiz 50’den fazla hastanede aktif olarak kullanılıyor.
Hedefimiz ne? Şirketimizi global pazarda lider konuma getirmek istiyoruz ve bunu yalnız çok iyi bir ekiple gerçekleştirebiliriz. Dünyada sağlığı dönüştürecek ekibin bir parçası olmak ve bunu son teknolojilerle yapmak seni de heyecanlandırıyorsa:
Geçtiğimiz hafta gerçekleştirdiğimiz parkur oyunları ve barbekü temalı şirket etkinliğimizi buradan izleyebilirsin. Belki bir sonraki etkinliğimizde sen de aramızda olursun!
Nedir? Neden zor?
Ne yapılabilir?
Faydalı kaynaklar
Başarı metrikleri, yeni bir ürün ya da özellik geliştirilirken üzerine düşünülen, bu ürün/özellik kullanıcılara sunulduğu andan itibaren aktif biçimde ölçümlenmeye başlanan ve bu ürünün/özelliğin başarılı olup olmadıklarını ölçümlemeye ve duruma göre aksiyon alabilmeye yarayan metrikler.
Belirlemek zor, çünkü doğası gereği henüz ortada bir çıktı yokken, belirsizlik halindeyken, varsayımlar ve geçmiş öğrenimler üzerine düşünülerek ortaya çıkarılabiliyor. Bir Google araması sonucunda sayfalarca blog yazısının NPS, DAU/WAU/MAU, MRR, CSAT gibi bir sürü ölçümleme pratiğini ürün başarı metriklerine örnek uygulamalar olarak önerdiğini görebilirsiniz. Ürünün iş modeline ya da gelir modeline göre değişen, farklı bir sürü metrik de var: İçerik sitelerinin, API ürünlerinin, SaaS ya da e-ticaret platformlarının başarı metrikleri de birbirlerinden epey bir farklı örneğin. Bu içeriklere ve önerilere göre hareket etmeye çalışınca nereden başlayacağını bilemeyebiliyor insan çünkü hepsi çoktan yapılandırılmış ölçümleme sistemlerine göre yazılıp çiziliyor ve biraz da jenerikler, geriden geliyorlar (lagging). Mevcutta kullanımda olan ürün ya da özellikler için bu hazır metrikler belki çalışabilir, ancak yeni bir ürün ya da bu ürün için yeni bir özellik geliştirirken başarı metriği belirlemek bana göre o kadar da kolay değil. Özellikle ürün ve şirket stratejisini destekleyecek, uzun soluklu ve anlamlı metrikler belirlenmek isteniyorsa.
Öncelikle belirsizliğin fırsatları yarattığını söylemek gerek. Karar alırken belirsizlik hep olacak ve bu aslında sağlıklı da bir şey, çünkü ürünün hala gelişebileceği bir alanının ve pazarının olduğunu gösteriyor. Metriklere karar vermenin de bu belirsizliğin bir parçası olduğunu unutmamak gerekiyor.
Bir yerden başlamak gerektiğini içselleştirmek önemli. Eldeki mevcut bilgilerle ve varsayımlarla uygun görünen bir metriğe ve nasıl ölçümleneceğine karar vermek, daha sonra bu yapının güncellenebileceğini unutmamak gerekiyor. Ürün geliştirmenin doğasında olan deneme/yanılma ya da “deneyleme” yaklaşımı burada da devam edebilmeli: Zaman içinde tecrübelendikçe sonuçların güvenilirlik düzeyi de artacaktır.
Ürünün ya da özelliğin gidişatını öğrenmeye yarayacak metrikleri “Başarı” metriği olarak isimlendirmeyebiliriz, başarılı olmak adına belirli bir beklenti oluşuyor ve kesinlik aranıyor çünkü. Bu beklenti doğru metriği seçmek konusunda endişe yaratıyor ve hatta ekiplerin bu metriği kendi hedefleri haline getirmelerine kadar gidebiliyor iş.
Bu üç maddenin özeti aslında şu: Ölçümlemeyle öğrenmeyi ve elimizdeki bilgilerle bir yerden başlayıp zaman içinde güvenilirlik düzeyini artırmayı nasıl başarabiliriz?
Seçtiğimiz metriklerin ve amaçladığımız hedeflerin güvenilirlik düzeyini artırmak için öncelikle aldığımız kararlara güvenebiliyor olmamız gerekiyor. Bunun yolu da bilgiye dayalı karar verebilmek: Araştırma yapmak, nicel ve nitel veri toplamak, ekiple bu bilgileri paylaşarak kolektif bir yetkinlik inşa etmek. Bu konuyla alakalı olarak “Araştırma Havuzu” yazımızı tavsiye ederim. Kişinin kendine ve kararlarına olan güvenini arttırması ise bambaşka bir konu, belki önümüzdeki günlerde bir sayıyı buna ayırabiliriz (imposter syndrome 👋).
Güvenilirlik düzeyini artırmanın bir diğer yolu da birim zamanda çok şey denemek ve deneyleme yaklaşımını ürün geliştirmenin bir parçası haline getirebilmek. Bu denemelerin sonuçlarına göre geliştirilecek özelliğin başarı kriterlerine daha çok katkıda bulunacağı konusunda daha emin olabiliyoruz.
Belirlediğimiz metriğin bize bir şeyler öğrettiğinden emin olmalıyız: Kullanıcılar bu ürünü/özelliği ne kadar kullanıyor, aktif kullanıcı sayımız artıyor mu gibi sorular genelde bir şey öğretme odaklı değil, gidişatı takip etmeye yarıyor. Hazır yeni bir özellik geliştiriyorken araya o alanda öğrenmeye çalıştığımız başka konuları da sıkıştırıp cevaplar alabilir ve ölçümlemeyi daha verimli hale getirebiliriz: Kullanıcıların ne kadarı emaillerini kontrol ediyor? Onboarding’de denediğimiz yeni akış görünürlüğü artırabildi mi? gibi gibi.
Peki bu yeni özelliğin beklentilere karşılık verebilmesini/verememesini nasıl tartacağız?
Başarı, bu yeni özellik sayesinde şirketin ve ürünün hedeflerine ve stratejisine ne kadar yaklaşıldığına bağlanmalı. Örneğin bir şirketin o sene için stratejik hedefi kullanıcı sayısını artırmaksa, canlıya alınan yeni özelliğe dair beklentiler ve başarı metriği de buna paralel olmalı —zaten odaklanılacak alanlar arasında bu şirket hedefine göre önceliklendirme yapıldığında, özelliği geliştirmeye başlamadan dahi işin “niye”si ve başarı kriteri gayet net oluyor. Yani aslında kritik nokta başarı metriklerinin tepeden uca belirlenmesi diyebiliriz. Bu yaklaşımın bana göre en güzel örneği North Star Metric, bu da tek başına bir yazı dizisi olacak kadar yoğun bir konu olduğundan keşfetmeyi şimdilik size bırakıyorum.
Bu metriğin ulaşması beklenen hedefi tanımlamak yine de güzel bir pratik. Bunu yaparken de yüzdesel hedefler yerine sayısal olanları tercih etmek öneriliyor: “Kullanıcı sayısını %3 artırmak” değil de, “toplam X yeni kullanıcı kazanmak” gibi. Zaman içinde devamlı ölçümleme sayesinde tahminlemeler de bilgiye dayalı hale gelmeye başlıyor ve hedefler daha gerçekçi hale geliyor.
TBM 17/53: Measuring to Learn vs. Measuring to Conform:
Keeping designers and engineers excited about metrics – Link
Estimating the chances of something that hasn’t happened yet – Link
The problem with metrics is a big problem for AI – Link
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayının konusu empati: Empati kavramını kısaca tanımlayıp sempatiyle olan farkını netleştirdikten sonra, ürün geliştirme süreçlerinde eksikliği nerelerde hissedilir ve nasıl bu eksiklerle başa çıkılabilir anlamaya çalıştık. Yazıyı kısa tutup kaynakları dolu dolu seçtik bu kez. Umarız faydalı bir okuma olur!
İyi internetler,
Burcu
Nedir? Sempatiden farkı ne?
Ürün geliştirme süreçlerine nasıl yansır ve nasıl yönetilir?
Faydalı kaynaklar
Empati özellikle son yıllarda ürün geliştirmenin/tasarlamanın buzzword’ü olmuş, bir sürü insanın dilinden düşmeyen, çoğu işe alım süreçlerinde aranan ve bahsi geçen ama tam da ne demek olduğunu bilmeden kullandığımızı düşündüğüm bir terim. Basitçe tanımı şu: “Diğerlerinin hissiyatını anlayabilme ve paylaşabilme yetisi”.
Daha basit halleriyle empati primatlarda, kedi ve köpeklerde, hatta hiç beklemezsiniz ama farelerde bile var. 12 aylık insan bebeklerinin üzüntülü kişileri (bir ödül mekanizmasına bağlı olmaksızın) teselli etmeye çalıştığına dair çalışmalar yapılmış. Gelişimi ise evrimsel biyolojiye dayandırılıyor: Tüm memelileri karakterize eden ebeveynlik sırasında bakıcı rolünde olan annelerin yavrularının verdiği pozitif ya da negatif tepkileri dinlediği, ve daha iyi bir dinleyici olanların yavrularının yaşama daha yüksek olasılıkla tutunabildiği gibi görüşler var.
Empatinin tanımı üzerine temel bir karışıklık var: Sempati ne, empati ne? Sempatinin anlamı şu: “Bir kişinin duygularına karşı merhamet ya da şefkat hissetmek”. Genelde acıma ya da üzüntü odaklı bu hissiyat diğer kişinin bir yaşanmışlığına dair hislerini paylaşmaya yarıyor. Empati ise bu kişinin hissiyatını paylaşmak yerine kendini onun yerine koymak ve anlamak demek. Sempatinin birçok insanda empatiye göre çok daha gelişmiş olduğu düşünülüyor, çünkü aslında daha kolay. Empati yapabilmek için kişinin kendi hayatından benzer deneyimleri araması ve nasıl hissettirdiğini hatırlaması gerekiyor, bu da kişiyi savunmasız kaldığı, hassas yerlere gitmeye zorlayabiliyor. Doktor Brene Brown’ın sesi üzerine kurgulanan bu kısa animasyon filmini konuyu ele alışını anlamanız üzere tavsiye ederim.
Kullanıcı ihtiyaçlarından yana olabilmek için önce kullanıcıları anlamak gerekiyor ve bunu yapabilmenin en iyi yolu da empati yapmak. Teknoloji ilk zamanlarında olduğunu düşündüğümüz gibi iyi olmaya odaklı olmayabiliyor artık ve bu konuda dikkatli olması gerekenler de aslında ürün geliştiren ekipler olarak biziz. Ancak empati yaparak geliştirdiğimiz ürünün kullanıcıların hayatını nasıl etkilediğini ve değiştirdiğini idrak edebiliriz ve aldığımız kararları şekillendirebiliriz.
Empati eksikliğinin ürün geliştirme süreçlerine olası etkileri şunlar:
Kullanıcı yerine düşünebileceğini düşünmek: Bu hissiyat “The False-Consensus Effect” olarak isimlendiriliyor ve bir bilişsel önyargı: İnsanların diğer insanların da kendileri gibi düşündüğüne ve belirli durumlarda kendileri gibi davranacağına dair bir eğilimi. Ekipçe çalışmayı da zorlaştıran bu eğilim günün sonunda kullanıcıların keşfedemediği, rahatça kullanamadığı ve hatta kullanmadığı çünkü ihtiyaç duymadığı özellikler üretmeye sebep olabiliyor.
Bu eğilimle ekipçe baş etmenin en kolay yolu tüm ürün geliştirme süreci boyunca olabildiğince araştırma yapmak, yaparken de validasyon ve yönlendiren sorular yerine derinlemesine anlamaya odaklanmak ve açık uçlu sorular tercih etmek. Görüşülen kullanıcıların farklı sektörlerden, rollerden, geçmişlerden kişilere dağılmış olması da aslında farklılıkları kolayca su yüzüne çıkarıyor.
Değer odaklı metriklere odaklanmamak: Ürün geliştirirken değer yaratmaya çalışıyoruz ve bunu başarabildik mi’nin ölçüsünün de değer bazlı olması gerektiği düşünülüyor. Kazanç odaklı metrikler genelde geriden gelen (lagging) metrikler oluyor ve hem ölçümlemek zorlaşıyor, hem de daha kuşbakışı metrikler olduğundan değişimleri anlamlandırmak ya da değiştirmek hayli zor. Haftalık aktif kullanıcı, harcanan zaman gibi metrikler de keza pek empati odaklı değiller. Değer odaklı metrikleri de ölçümlemek kolay değil belki, ama anlamlandırmak ve hızla aksiyon almak çok daha kolay olduğundan o efore değiyor.
Bu pratiği geliştirmek için “en çok ödeyen kullanıcılar” kadar “en çok fayda sağlanan kullanıcılar”ı da dinlemek ve ölçümlemek öneriliyor. Kazanç odaklı metrikleri takip ederken yanlarına mutlaka bir öncü (leading) metrik eklemek ve bu ikiliyi birlikte ölçümlemek de yine öneriler arasında.
Otorite ile ekip yönetmek gayreti: Ürün yöneticileri için en kritik konulardan biri de bu: beraber çalışılan ekibin saygısını ve desteğini kazanmak ve bunu otoriteye başvurmadan yapmak gerekiyor çünkü aslında bu ekiplerin çıktılarından sorumlu olsak da çoğunlukla yöneticileri değiliz. Empati yapamadığımızda da aslında otorite ile yerini doldurmaya çalışıyoruz.
Ekiple iletişirken odağın haklı olmak ya da baskılamak değil, anlayarak ve çözüm üreterek ilişkiler geliştirmek olduğunu hatırlamak gerekli. Bu anlama eforu zaten ekibin gözünden kaçmıyor ve karşılıklı bir güven ilişkisi oluşturmaya yetiyor.
Aktif dinleyici olamamak ve etraflı bir gözlem yapamamak: Birileri konuşurken bir şey söylememek için kendimizi zor tuttuğumuzda ve hatta konuşmayı böldüğümüzde aktif bir dinleyici olamıyoruz çünkü aslında sadece söylenenlere ya da cevap olarak ne söyleyeceğimize odaklanmak oluyor bu. Kişinin bu konuşmayı yaparken nasıl hissettiğine, ifadelerine odaklanmak gerekiyor ki tam bir dinleme sağlanmış olsun. Kullanıcılarla görüşürken aktif dinleyici olamamak da kök sebeplere inecek sorular soramamaya sebep oluyor örneğin.
Bunun üstesinden gelebilmek için karşıdaki kişi konuşmasını bitirene kadar cevabı düşünmemeye çalışmak çözüm olabilir.
Daha yavaş konuşmaya çalışmak, her iki tarafın da sözlerini bitirdikten sonra aralar vermesi de bu alanı korumaya yardımcı oluyor.
Eğer ifadeleri ya da hisleri anlamakta zorlanıyorsak da direkt olarak sormanın, ya da anladığımız şekliyle betimleyip doğru anlayıp anlamadığımızı teyit etmenin hiçbir zararı yok.
Brené Brown on Empathy — Yazıyı okurken es geçtiyseniz diye tekrar eklemek istedim, bahsettiğim animasyonlu kısa film.
Product Management Is Empathy — Empatiyi farklı sorumluluklar üzerinden tanımlayışı ve yaptığı öneriler sebebiyle önerdiğim bir blog.
I feel hopeless, rejected, and a burden on society – one week of empathy training — Hafta hafta farklı engellere sahip olmayı deneyimleyen birinin notları.
Ask HN: How to build empathy? — Güzel bir sohbet dönmüş.
FBI’s Behavioural Change Stairway Model — Yukarıdaki sohbetten zıplayıp geldiğim bir model, FBI’ın sorguladığı kişileri nasıl bir şeylere ikna ettiğini anlatıyor.
The Psychology of Emotional and Cognitive Empathy — Duygusal ve bilişsel empatiyi tanımlayıp, empatinin nereden geldiğine dair güncel nörobilimsel/evrimsel yaklaşımları aktaran bir makale.
☝️Bu sayıyla alakalı karşılıklı yorumlaşmak isterseniz Slack grubumuza bekleriz.
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayının konusu mükemmeliyetçilik: İnsanın içinin içini yerken başarılı olmasına, ekibiyle ya da yöneticisiyle çalışırken kendini ve herkesi türlü türlü durumlarda zorlamasına sebebiyet verebilen bu düşünce şeklinin nasıl tespit edilebileceğini, ürün geliştirme süreçlerini nasıl etkileyebildiğini ve nasıl yönlendirilerek makul sonuçlar alınabileceğini anlamaya ve anlatmaya çalıştım. Umarım bir şeyler fark etmene ve daha iyi hissetmene yardımcı olur!
İyi internetler,
Burcu
Nedir? Sebebi ne? Nasıl anlaşılır?
Ürün geliştirme süreçlerine nasıl yansır?
Nasıl yönetilir?
“Mükemmel” kelimesi hepimize gayet pozitif bir betimleme gibi gelir, hatta günlük hayatta “Ben biraz mükemmeliyetçiyim, bunu yapmak için günler harcadım” benzeri söylemler duyduğumuzda kişinin kendinden gayet memnun olduğunu düşünürüz. Çoğu zaman kastedilen anlamıyla “mükemmeliyetçilik”se pek öyle değil, yani bu sözü söyleyen kişi genelde ne kendinden, ne de yaptığı şeyden memnun değil. Kendinden memnun olan, “uyumlu mükemmeliyetçi” denilen grubun da standartları yüksek, amaçları öğrenmek ve daha iyi olmak; ancak bu grup yaptığı işi keyifle ve optimist bir tavırla yapıyor. “Uyumsuz mükemmeliyetçi” grupsa “mükemmeliyetçi” grubun çok büyük bir kısmı ve hedefleri yine bu yüksek standartlara ulaşmak, ancak bu grup bu süreçte pek de iyi hissetmiyor.
Mükemmeliyetçiliği bir “davranış”tan çok, kişinin kendi hakkında düşünme, kendi kendine muamele şekli gibi düşünebiliriz. Genelde kişinin başarısız olmaktan ya da sert yargılamalardan kaçınmak gibi içsel yönelimleriyle ortaya çıkıyor. Bu içsel yönelimlerin kaynağı da çoğunlukla dışsal faktörler: Ebeveynlerin, büyüklerin, çevrenin kişiden çocukken çok şey beklemesi, yaptığı hataları çok eleştirmesi, başarılı olmanın ne olursa olsun tek yol olduğunu ima etmesi; çocukların ilgi görmek için tek yöntem olarak başarılı olmalarının gerektiğini düşünmeleri; medyanın en ufak bir hatada başarılı kişileri alaşağı etmesi ve çocukların buradan yanlış bir ders çıkarması, gibi gibi.
Psikoterapide güncel yaklaşımlardan biri olan ve erken dönemde gelişen, kendini-sürdürücü davranış kalıplarına odaklanan “şema terapi” modelinde mükemmeliyetçiliğin “Yüksek standartlar” kalıbı ile bağlantılı olduğu ifade ediliyor ve “Cezalandırıcılık” da bu kalıpla kardeş: Kişi normalmişçesine kendinden çok şey bekliyor, koyduğu yüksek hedeflere ulaşamadığında (genelde ulaşılamayacak hedefler oluyor zaten bunlar) kendini acımasızca eleştiriyor ve bakıldığında kendi motivasyonunu, şevkini kırıyor. Maalesef bu ikili birbirini beslediğinden ortaya negatif bir döngü çıkıyor ve kişi bu döngüden bir müdahale olmadan çıkamıyor. Bu durum kişinin mental sağlığını tek etken olarak bozmasa da farklı faktörlerle bir araya geldiğinde genel sağlığı hayli etkileyebiliyor.
Amerikan Psikoloji Topluluğu’nun 1989’dan 2016’ya kadar düzenli olarak üniversite öğrencileri arasında yaptığı bir araştırmaya göre jenerasyonlar gençleştikçe kendilerine daha çok yükleniyor, diğerlerinden daha çok şey bekliyor ve daha iyi olmaları için dış dünyadan bir baskı hissediyorlar. Akademide ya da iş hayatında artan bireyci rekabet, ebeveynlerin gittikçe kontrolcü hale gelmesi, sosyal medya sebepli herkesin her şeyden haberdar olması ve karşılaştırmaya meyillenmesi bu halin belirleyici sebepleri olarak görülüyor. Durumun ciddiyeti gittikçe arttığı için hem kendimiz, hem de birlikte çalıştığımız, yaşadığımız insanlar için bu halin farkında olmak boynumuzun borcu. Eğer kendinizde ya da çevrenizde birinde şöyle eğilimler gözlemliyorsanız, ortada bir uyumsuz mükemmeliyetçilik olabilir:
Başarılı olmadığını düşünme ve kendini takdire layık görmeme: Başarılı oldukları ifade edildiğinde bunu şansa ya da başka dış faktörlere bağlıyorlar ve hatta ileride tekrar bu sonucu alamamaları halinde başarılı kalamayacaklarını düşünüp endişelenmeye başlıyorlarsa.
Hata yaptığında ya da yaptığı bir şeye dair yapıcı bir geri bildirim aldığında çok kötü hissetme: Utanç ve hatta sinir halinde olup, savunmaya geçiyor ve hatalarını ya da yapılan önerileri kabul edemiyorlarsa.
Hata arama ve hataları kritize etme: İstemeden ve devamlı olarak bir yerlerde hata arıyor ve bu hataları yapan kişiyi (ya da kendilerini) hoşgörmeden, acımasızca eleştiriyor ve yargılıyorsa.
Ya hep ya hiç yaklaşımı: Basbaya başarılı bir iş ortaya çıkmasına rağmen, süreç içinde küçük bir eksiklik ya da terslik olduysa buna odaklanıyor ve koca başarıyı çöpe atıyorsa.
Yeni şeyleri erteleme: Zor olduğu düşünülen şeylere (yeni bir hobi edinmek, yeni bir süreci başlatmak gibi çoğunluk daha önce deneyimlenmemiş bir şeyler) başarısız olma korkusu yüzünden bir türlü başlamıyorsa.
Mülakatlarda “Kendinde bir şeyi değiştirmek isteseydin?” sorusuna verilen en makbul cevaplardan biri olarak görülen mükemmeliyetçilik kişinin hem iyi olma halini, hem de iş hayatındaki başarısını uzun vadede kötü etkileyebiliyor. Ürün geliştiren bir ekipte çalışıyorsanız, bu eğilimin hem ortaya çıkan işlerin kalitesini ne kadar artırdığını, hem de bu işleri ortaya çıkarma sürecinde ekibi ne kadar zorladığını gözlemlemiş olabilirsiniz. Ben bu yazıda “Steve Jobs da mükemmeliyetçiymiş, bak Apple ne güzel ürünler üretiyor”dan ziyade kişinin kendine ve ekibine olası etkilerini aktarmaya ve değişik çevrelerce yapılan önerilere odaklanacağım ki işin boyutu ortaya çıksın.
Sonsuz iterasyon ve kontrol: Hiçbir zaman “yeterince iyi” olmayan işler bir türlü bitmez. Buna basit bir dökümanı günlerce bitirememekten, geliştirilen bir özelliği sürekli iyileştirmeye çalışmaktan aylarca canlıya alamamaya kadar bolca örnek bulabiliriz. Bu durum kişinin genel verimliliğini de düşürüyor çünkü vaktin çoğu minik detaylara ayrılmış oluyor.
Bu eğilimin en iyi çözümü sık sık geri bildirim almak. Yapılan şey bir dökümanı bitirmekse sık sık ekiple üzerinden geçmek ve fikir almak, bir özelliği canlıya almaksa da bu süreci adım adım gerçekleşecek şekilde aşamalandırmak ve her bir adımda kullanıcıları dinleyerek görüşlerini öğrenmek mükemmeliyetçiliğin önünü kesiyor.
Bir başka çözümse kişinin kendini zamanlaması. Teslim tarihleri, bitirme günleri gibi tarihler belirlemek ve bunu işin her bir küçük parçası için yapmak, sonrasında hangi tarihlerin tutmadığını gözlemlemeye ve o kısımları iyileştirmeye odaklanmaya yarayacaktır.
Kontrolün bu kişinin elinde olmadığı durumlardaysa kişinin neyi kontrol edip neyi edemeyeceğini belirlemesine yardım etmek gerekiyor: Örneğin geliştirdiğiniz ürünün bulunduğu pazarı ya da rekabet edilen diğer ürünleri kontrol edemeyeceğini, bunun yerine kontrol edebileceği alanları ve eforu bu alanlara harcamasının doğru olacağını fark etmesini sağlayabilirsiniz.
Karar verememek/Analiz felci: Yanlış bir şey yapma korkusuyla her şeyi aşırı analiz etmek, 2-3 seçenek yerine 9-10 seçeneğe sahip olmaya ve bunlar arasında seçip yapmakta zorlanmaya sebep oluyor.
Bu yola giren kişinin durumunu önceden fark etmek, kararsızlık halinde yanında olmak, işin yapılma amacını hatırlatıp, sık sık iterasyonlara beraber göz atarak işini basitleştirecek öneriler yapmak bolca işe yarıyor ve uzun vadede kişiyi “basit tutma”ya motive ediyor.
Bir başka yöntem de verilecek kararları listelemek ve aralarından en önceliklileri/önemlileri seçmek. Hangileri daha öncelikli ya da önemli anlamak için de tersine mühendislik yapmak mümkün: Hangi karar sonucu daha çok etkiliyor belirleyip, onlara cevap aramak gibi bir akış düşünülebilir.
İşleri başkalarına delege edememek: Kontrol etme ve hata yapmama güdüleri başkalarından yardım istememeye ve bu baskı altında zorlanmaya sebep oluyor.
Bu durumdaki kişilerin işlerini küçük parçalara bölmelerini istemek ve bazı parçaları diğer ekip üyeleriyle paylaşmalarını istemek en basit çözüm.
Bu delegasyon sonrası dahi en ufak ayrıntıya kadar kontrol etme davranışı (micromanagement) devam edebileceğinden, bu konuda da kişiye yardımcı olmak ve gözlemlemeye devam etmek gerekli.
Sürekli yüksek hedefler koymak: Hedefleri gerçekçi tutmamak hem ekibin sürekli başarısız hissetmesine sebep oluyor, hem de bu hedefler gözetilerek yapılan planları yönetilemez hale getiriyor.
Yüksek beklentiler varsa da bunları anlaşılır ve ölçülebilir şekilde ifade etmek gerekiyor.
Hedefleri kişi ya da ekip odaklı tutmak yerine, süreç odaklı tutmak öneriliyor ki kişiler sonuçları bireyselleştirmesin.
Başarıyı kutlamamak ve başarılı hissetmemek: Başarıyı kutlamamak hem performansı, hem diğerlerinin bu başarısız hisseden kişi hakkınızdaki görüşlerini etkiliyor: Bu kişinin iş yapma kabiliyetinin kişinin hissettiği kadar olduğu düşünülüyor ve bu durum kişinin kariyerini dahi etkileyebiliyor.
Her imkanda başarıyı kutlamanın hiçbir zararı yok: İşe başlama yıldönümü, yeni bir özellik canlıya almak, bir projeyi tamamlamak, güzel bir kullanıcı geri bildirimi, yeni ve büyük bir anlaşma yapmak, gibi gibi. Bu durumdan muzdarip ekip üyeleriniyse bireysel olarak da takdir etmek, iyi yaptıkları düşünülen kısımları özellikle dile getirmek gerekiyor ki kendilerine güvenleri artsın ve başkalarını takdir etmeyi alışkanlık edinsinler.
☝️Bu sayıyla alakalı karşılıklı yorumlaşmak isterseniz Slack grubumuza bekleriz.
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
