Product Discovery Nedir? Doğru Problemi Bulmanın Yolu

Product discovery, yani ürün keşfi; mühendislik ekibi haftalarını bir şeyi geliştirmeye ayırmadan önce — ve geliştirirken — hangi problemin çözülmeye, hangi çözümün yapılmaya değer olduğunu anlama işidir. Bir defa yapılıp geçilen bir atölye çalışması değil; ürün ekiplerinin yanlış şeyi yapma riskini düşürmek için sürekli sürdürdüğü bir pratik.

Bu yazıyı seyahat marketplace'lerinde, konaklama platformlarında ve büyük ölçekli tüketici operasyonlarında hem discovery hem delivery yürütmüş bir Lead Product Manager olarak yazıyorum. Araçlar şirketten şirkete değişiyor; ama hata hep aynı: kimsenin ihtiyaç duymadığı özelliklerle dolu, göz alıcı bir roadmap.

Discovery ile delivery arasındaki fark

Delivery, "bunu nasıl iyi yaparız?" sorusuna cevap arar. Discovery ise "bunu yapmalı mıyız, yapacaksak hangi biçimde?" sorusuna.

Fırsat → varsayımlar → kanıt → karar → delivery → tekrar öğrenme
Olmaması gereken: fikir → backlog → sprint → umut

İyi işleyen ekiplerde bu ikisi iç içe yürür: geliştirirken keşfetmeye devam edersiniz, her küçük parçadan bir şey öğrenirsiniz. İşlemeyen ekiplerde ise discovery "bizi yavaşlatan" bir araştırma faslı olarak görülür; sonra da yüksek velocity'nin neden hiçbir sonuca dönüşmediği sorgulanır.

Product discovery neleri kapsar?

1. Fırsatı doğru çerçevelemek

Yanlışlanabilecek kadar somut bir kullanıcı ya da iş problemiyle başlamak gerekir. "Dönüşüm oranını artırmak" bir temenni. "Tekrar gelen kullanıcılar mobilde filtreler sıfırlandığı için otel aramayı yarıda bırakıyor" ise üzerine gidilebilecek bir fırsat.

2. Varsayımları açıkça yazmak

Her fikrin içinde saklı bahisler vardır: bu problem kimde var, ne sıklıkla yaşanıyor, bugün nasıl çözüyorlar, davranışlarını değiştirir mi, onlara ulaşabilir miyiz, işin ekonomisi tutar mı? Bunları yazıya dökün. En riskli varsayımı adlandıramıyorsanız discovery yapmıyorsunuz; baştan seçilmiş bir çözümü süslüyorsunuz.

3. Riske uygun kanıt toplamak

Ne kadar kanıt gerektiği riskin büyüklüğüne bağlıdır. Basit bir metin değişikliği için analitik ve hızlı bir test yeter. Yeni bir tedarik tarafı açmak ya da fiyatlama modelini değiştirmek içinse görüşmeler, prototipler, talep testleri ya da sınırlı deneyler gerekir. Hedef akademik kesinlik değil; karar verebilecek kadar güven.

4. Karar vermek: yap, değiştir ya da vazgeç

Discovery ancak backlog'u değiştirdiğinde — bazen bir şeyleri sildiğinde — işe yaramış demektir. Her seferinde ilk fikri "doğrulayan" bir discovery süreci, discovery değil tiyatrodur.

Pratikte işleyen bir discovery döngüsü

1. Hedeflenen sonucu netleştirin — hangi metrik ya da kullanıcı davranışı, kim için değişmeli?
2. Mevcut akışı haritalayın — kullanıcı gerçekten nerede takılıyor, nerede vazgeçiyor?
3. Varsayımları listeleyin — yanlış çıkma ihtimaline ve yanlış çıkarsa yaratacağı maliyete göre sıralayın.
4. En riskli olanı test edin — görüşme, prototip, concierge MVP, A/B testi, satış ekibinden gelen sinyaller, destek kayıtları.
5. Fırsat özetini güncelleyin — problem, kanıt, önerilen bahis, kapsam dışı bırakılanlar.
6. Ancak bundan sonra delivery'yi planlayın — bir şey öğreten ya da değer üreten en küçük parçayla başlayın.

Seyahat ve marketplace ürünlerinde bu döngü daha da önemlidir çünkü tek bir kullanıcınız yoktur. Misafir, tedarikçi, operasyon ekibi ve iş ortakları roadmap'i farklı yönlere çeker. Yalnızca bir tarafı dinleyen discovery, şık ama dengesiz bir ürün ortaya çıkarır.

Zamanınıza değecek yöntemler

• Problem görüşmeleri — geçmiş davranış, gelecekle ilgili görüşten daha güvenilirdir. "Bunu en son ne zaman yaşadınız, anlatır mısınız?" diye sorun.
• Prototip testleri — arayüz riskini ölçmek için tıklanabilir bir akış, sunumdan çok daha fazlasını söyler.
• Verileri çaprazlamak — funnel'lar, session kayıtları, destek etiketleri ve satış notları birlikte okununca tek bir dashboard'dan daha çok şey anlatır.
• Fake-door ve talep testleri — arkasını kurmadan önce ilginin gerçekten var olup olmadığını ölçün.
• Operasyonu yerinde izlemek — B2B ve operasyon ağırlıklı ürünlerde işin gerçekten nasıl yapıldığını gözlemleyin; anketler kibar olduğu için gerçeği söylemez.

En riskli varsayımınızı hedef alan yöntemi seçin. Bir framework öyle önerdiği için bütün araştırma yöntemlerini sırayla uygulamak zorunda değilsiniz.

Discovery nerede rayından çıkar?

• Çözümden başlayan brief'ler — "Sadakat programı lazım" cümlesi, "kim, neden bizi terk ediyor?" sorusundan önce gelir.
• Yalnızca yöneticilerle konuşmak — yöneticiler sunum dosyasının kullanıcısıdır, ürünün her zaman değil.
• Bitmeyen araştırma — karar tarihi olmayan discovery bir süre sonra karar vermekten kaçmanın yoluna dönüşür.
• Göstermelik doğrulama — beş arkadaşınızın "ben kullanırdım" demesi kanıt sayılmaz.
• Dosyayı atıp gitmek — problemi birlikte sahiplenmeden kırk sayfalık discovery dokümanını mühendisliğe teslim etmek.
• Kısıtları görmezden gelmek — seyahat teknolojisinde hukuk, tedarik, sezonluk dalgalanma ve iş ortağı sözleşmeleri dipnot değil, problemin kendisinin parçasıdır.

İki taraflı pazarlarda ve operasyon ağırlıklı ürünlerde discovery

Konaklama platformlarında ve seyahat marketplace'lerinde "kullanıcıya değer" tek parça değildir. Gezgine yardımcı olan bir filtre, otel tarafında eşleştirmeleri bozabilir ya da destek yükünü artırabilir. İyi bir discovery süreci şunları sorar:

• Bu problemi bugün kim yaşıyor, çözümün bedelini kim ödeyecek?
• Darboğaz talepte mi, tedarikte mi, güvende mi, arayüzde mi, operasyonda mı?
• Biraz yanılırsak yoğun sezonda ne kırılır?

Asıl sorun eski müsaitlik verisi ya da karışık rate plan'lar iken kusursuz bir tüketici arayüzü geliştiren ekipler gördüm; channel manager yazısında anlattığım dağıtım gerçekliği tam olarak bu. Tüketici funnel'ından hiç dışarı çıkmayan bir discovery, sistemin bütününü kaçırır.

Discovery'nin işe yaradığını nasıl anlarsınız?

• Roadmap'teki kalemler büyük bir geliştirme başlamadan önce düzenli olarak eleniyor ya da yeniden tanımlanıyor.
• Mühendisler problemi ve en riskli varsayımı kendi cümleleriyle anlatabiliyor.
• Yalnızca özellik teslimleri değil, öğrenme hedefleri de planlanıyor.
• Değerlendirme toplantılarında aktivasyon, elde tutma, katkı marjı, çözüm süresi gibi sonuç metrikleri konuşuluyor; "kaç story point bitti" tek başına konuşulmuyor.
• Paydaşlar son toplantıda kimin sesinin daha çok çıktığını değil, kanıtın kalitesini tartışıyor.

Ekiplerin gerçekten kullandığı discovery çıktıları

Tek sayfalık bir fırsat özeti yeterken roman gibi PRD yazmanın anlamı yok. İşe yarayan bir özet genelde şunları içerir:

• Bağlam — pazarda, metriklerde ya da kullanıcı davranışında ne değişti?
• Problem — kim yaşıyor, ne sıklıkla, bugün nasıl çözüyor?
• Kanıt — görüşmeler, sorgular, destek konuları, deney sonuçlarına bağlantılar.
• Bahis — çözümün yönü ve neden işe yarayabileceği.
• Riskler ve kapsam dışı olanlar — bilinçli olarak şimdilik çözmediğiniz şeyler.
• Başarı sinyali — ilk sürüm için öncü göstergeler.

Yanına da canlı bir varsayım günlüğü koyun. Bir kanıt bir varsayımı çürüttüğünde günlüğü herkesin gözü önünde güncelleyin. Discovery kültürü, hikâyenin sessizce değiştirilmesi değil; anlaşmazlıkların açıkça konuşulup verilerle çözülmesidir.

Discovery'de mühendislik ve tasarımla birlikte çalışmak

En iyi discovery ortak sahiplenilen discovery'dir. Tasarımcılar çözümün istenirliğini ve anlaşılırlığını sınar; mühendisler yapılabilirliği ve uç durumları erkenden ortaya koyar; ürün yöneticisi ise bahsi strateji ve ekonomiyle uyumlu tutar. Bu insanları çözüm kesinleşmeden önce masaya çağırın. Hayal edilen akışın API tarafından desteklenmediğini iki günlük bir spike ile öğrenmek, bunu bir çeyrek sonra öğrenmekten çok daha ucuzdur.

Ritim için bir öneri: delivery'nin yanında ince bir "discovery hattı" tutun. Görüşmeler için sabit saatler, açık varsayımlar için ortak bir pano ve haftalık bir karar toplantısı. Karar toplantısı yoksa içgörüler birikir ama plan hiç değişmez.

Ekibi işe koşmadan önce kısa kontrol listesi

• Hedef kullanıcı ve yapmaya çalıştığı iş tek paragrafta yazılı mı?
• En riskli varsayım ne, hangi kanıt onu karşılıyor?
• Lansmandan sonraki 2–4 haftada "yanılmışız" metriklerde nasıl görünür?
• Kapsam dışı olanlar açıkça belirtilmiş mi?
• Devam, yön değiştir ya da dur kararını kim veriyor?
• Öğrenme ya da değer üreten en küçük teslim parçası ne?

Sık sorulan sorular

Product discovery ile UX research aynı şey mi?

Hayır. UX research discovery'nin önemli girdilerinden biri. Discovery bunun yanında iş modelini, teknik yapılabilirliği, pazara çıkışı ve operasyonel gerçekliği de kapsar. Bahsi ürün yöneticisi kurar; araştırmacı, tasarımcı, mühendis ve operasyon ekipleri onu keskinleştirir.

Discovery ne kadar sürmeli?

Riskin izin verdiği kadar kısa. Bir fiyat deneyi birkaç günde tamamlanabilir; yeni bir tedarik dikeyi açmak haftalarca sürebilir. Süreyi ritüele göre değil, verilecek karara göre sınırlayın.

Yönetim kararı zaten verdiyse discovery'ye gerek var mı?

Var, ama kapsamı daraltın. Yukarıdan gelen bahislerde bile sıralama, arayüz ve devreye alma konusunda varsayımlar vardır. Bu durumda discovery hangi dağa tırmanılacağını seçmez; yanlış çıkarsa hasarı küçültür.

Roadmap bu resimde nereye oturur?

Roadmap bir özellik alışveriş listesi değil; hedeflenen sonuçları ve bahisleri sıralayan bir plandır. Discovery roadmap'i besler, delivery sıradaki en iyi bahsi hayata geçirir.

Son söz

Product discovery, sprint harcamadan önce merak harcamaktır. Bunu atlayan ekipler daha hızlı gitmez; aynı şeyi daha geç, canlı ortamda ve tam bedelini ödeyerek öğrenir.

Ürün yönetimi ve seyahat teknolojisi üzerine diğer yazılar için Hakkında ve Projeler sayfalarına bakabilir ya da bir görüşme ayarlayabilirsiniz.