Ürün keşfi: neyi geliştireceğine kanıtla karar vermek

Ürün keşfi nedir?

Ürün keşfi (product discovery), bir ekibin hangi problemi çözeceğini ve önerdiği çözümün gerçekten işe yarayıp yaramayacağını geliştirmeye büyük emek harcamadan önce kanıtla anlama çalışmasıdır. Amaç, kimsenin kullanmayacağı özelliği üretmeden önce yanılma payını azaltmaktır.

Keşif, geliştirme (delivery) aşamasının önünde duran ve onunla paralel yürüyen bir döngüdür. Geliştirme 'doğru şeyi doğru yapmak' ile ilgilidir. Keşif ise önce 'doğru şeyin ne olduğunu' bulmaya çalışır. Bu ayrım, ürün ekiplerinde zaman ve bütçe kaybının en büyük kaynaklarından birini adreslediği için ayrı bir kavram olarak anılır.

Keşif hangi sorulara cevap arar?

Keşif çalışması şu temel riskleri azaltmaya odaklanır:

• Değer: Kullanıcı ya da müşteri bunu gerçekten isteyecek mi?
• Kullanılabilirlik: Kullanıcı ürünü yardım almadan anlayıp kullanabilecek mi?
• Uygulanabilirlik: Ekip bunu mevcut teknoloji ve yetkinlikle üretebilir mi?
• İş uygunluğu: Çözüm şirketin gelir modeline, mevzuata ve diğer kısıtlarına uyuyor mu?

Her riskin sahibi farklı olabilir; bu yüzden keşif yalnızca ürün yöneticisinin değil, tasarımcının ve mühendisin de katıldığı ortak bir çalışmadır.

Keşif adım adım nasıl yürür?

Çalışma çoğu zaman şu sırayla ilerler:

• Problem alanını belirle: iş hedefine bağlı, ölçülebilir bir sonuç seç.
• Kullanıcıyla konuş: görüşmelerde çözüm sormak yerine kullanıcının yakın zamanda yaşadığı gerçek durumları anlatmasını sağla.
• Fırsatları haritala: görüşmelerden çıkan ihtiyaçları, sıkıntıları ve istekleri bir fırsat ağacında topla ve hedefle ilişkilendir.
• Çözüm fikirlerini üret ve varsayımlarını yaz: her fikrin doğru olması için neyin doğru olması gerektiğini açıkça listele.
• En riskli varsayımı ucuzca test et: prototip, tıklanabilir ekran, sahte kapı (fake door) testi ya da küçük bir deney kullan.
• Sonucu yorumla: fikri sürdür, değiştir ya da bırak.

Birkaç düzenli kullanıcı görüşmesi bile tahminlere dayalı yol haritasından çok daha değerli bir girdi verir; önemli olan görüşmelerin tek seferlik değil, ekibin ritminde sürekli olmasıdır.

Hangi teknikler kullanılır?

Kullanıcı görüşmeleri ve gözlem, problemi derinlemesine anlamanın temel yoludur. Jobs-to-be-Done yaklaşımı kullanıcının hangi 'işi' ürüne yaptırdığına bakar. Empati haritası ve yolculuk haritası, deneyimdeki kopuş noktalarını görünür kılar. Kullanılabilirlik testleri prototip üzerinde kullanıcının nerede takıldığını gösterir.

Sayısal tarafta ise anketler, ürün analitiği ve A/B testleri devreye girer. Henüz ürün yokken en hızlı yöntemler sahte kapı, duman testi ve yalnızca vaadi sunan açılış sayfalarıdır. Fikirleri sıralarken RICE gibi puanlama yöntemleri kullanılabilir, ancak puanların girdisi tahmin değil keşiften gelen kanıt olmalıdır.

Keşif ile delivery nasıl ayrılır?

Ölçüt: Temel soru. Keşif: neyi, kim için geliştirmeliyiz? Delivery: seçilen çözümü nasıl hızlı ve kaliteli üretiriz?

Ölçüt: Çıktı. Keşif: doğrulanmış problem, test edilmiş varsayımlar, kanıtlanmış fikir. Delivery: çalışan, yayına çıkmış ürün parçası.

Ölçüt: Başarı göstergesi. Keşif: öğrenme hızı, çürütülen ya da doğrulanan varsayımlar. Delivery: kalite, yayın sürekliliği, kullanım.

Bunlar ardışık aşamalar değil, aynı anda yürüyen akışlardır. Mühendisler mevcut doğrulanmış işi geliştirirken ürün ekibi bir sonraki dönemin fikirlerini test eder.

Örnek: bir mobil bankacılık özelliği

Örneğin bir banka ekibi 'harcama analizi' özelliği eklemeyi düşünüyor olsun. Doğrudan geliştirmeye geçmek yerine önce müşterilerle ay sonunda paranın nereye gittiğini nasıl takip ettiklerini konuşur. Görüşmelerden birçok kişinin asıl derdinin harcamaları görmek değil, düzenli ödemelerin hesaba ne zaman yansıyacağını bilmek olduğu çıkarsa fırsat ağacı buna göre yeniden şekillenir.

Ekip basit bir ekran prototipi hazırlayıp kullanıcılarla dener, mevzuat ve veri erişimi konusunu uyum ekibine danışır ve ancak değer ile uygulanabilirlik netleştikten sonra geliştirme kapasitesi ayırır. Böylece yanlış özellik için harcanacak emek, baştan kısa bir öğrenme çalışmasına dönüşmüş olur.

Sık yapılan hatalar

• Keşfi bir kerelik araştırma projesi saymak ve sonuçları raflarda bırakmak.
• Görüşmede çözümü kullanıcıya satmaya çalışmak veya yönlendirici sorular sormak.
• Doğrulamak yerine kendi fikrini onaylatacak kanıt aramak.
• Yalnızca ürün yöneticisinin yürütmesi; tasarım ve mühendislik bakışını dışarıda bırakmak.
• Kanıt toplamadan yol haritasını tarih ve özellik listesi olarak taahhüt etmek.

Bu hataların ortak noktası, kararların kanıtla değil kanaatle verilmesidir.

Mindset programlarında ürün keşfi

Ürün keşfini sektöre özgü ele alan programlar var. 'Yapay Zeka Ürün Yönetimi: Ürün Liderliği Programı' yapay zeka ürünlerinde keşif ve kullanıcı araştırması modülünü içerir; 'FinTech Ürün Yönetimi' kullanıcı araştırması ve ürün keşfini düzenleyici çerçeveyle birlikte işler.

'Bankacılıkta Ürün Yönetimi ve Müşteri Deneyimi' müşteri deneyimi ve segmentasyon başlıklarıyla bankacılık ürün ekiplerine, 'API Ürün Yönetimi ve Geliştirici Deneyimi (DX)' ise geliştirici yolculuğunu haritalayan ekiplere uygundur.