30 saniyelik özet
Continuous Discovery, yani sürekli ürün keşfi, kullanıcı ihtiyaçlarını ve çözüm varsayımlarını düzenli olarak araştırıp öğrenilenleri ürün kararlarına taşımaktır. Keşif, yalnızca proje başında yapılan görüşmelerden ibaret kalmaz. Ekibin geliştirme sürerken de kullanıcılarla temas kurması ve önemli bilinmeyenleri küçük çalışmalarla incelemesi gerekir. Başarı, görüşme sayısıyla sınırlı değerlendirilmez; öğrenilenlerin hangi kararı değiştirdiği açıklanmalıdır. Product Owner, yani ürün sahibi, bu bilgiyi öncelik ve kapsam kararlarıyla ilişkilendirir. Süreklilik, her hafta yeni bir özellik istemek veya her geri bildirimi geliştirme listesine eklemek anlamına gelmez.
Neden önemli?
Bir raporlama ürünü, müşterilerin ihtiyaçlarını ilk kurulum görüşmelerinden öğrendiğini düşünüyor. Aylar sonra kullanım biçimi değişmiş, yeni kullanıcılar eklenmiş ve destek talepleri farklılaşmış olabilir. Ekip hâlâ başlangıçtaki varsayımlarla çalışıyorsa doğru geliştirilmiş özellikler bile artık öncelikli ihtiyacı karşılamayabilir.
Düzenli keşif, kararların dayandığı bilgiyi güncel tutmaya yardımcı olur. Kullanıcıların ne istediğini sormanın yanında yakın zamanda yaptıkları işleri anlamak önemlidir. Raporu kim hazırlıyor, kim inceliyor, bilgi nerede eksik kalıyor? Bu bağlam görülmeden yalnızca talep edilen ekranı geliştirmek, asıl güçlüğü olduğu yerde bırakabilir.
İş analisti için keşif, ihtiyaç kayıtlarını yeni kanıtlarla karşılaştırma fırsatıdır. Geliştirici, teknik bir varsayımın kullanıcı davranışına etkisini görebilir. Tasarımcı, çözümün anlaşılmasını inceleyebilir. Aynı gözleme farklı uzmanlıklarla bakılması, sorunun yalnızca bir açıdan tarif edilmesini önleyebilir.
Yönetici açısından yaklaşımın katkısı, yatırım seçeneklerinin daha erken değerlendirilebilmesidir. Geliştirmeye devam mı edilmeli, kapsam daraltılmalı mı, farklı bir problem mi ele alınmalı? Keşif bulguları bu kararları beslemelidir. Araştırma raporunun hazırlanmış olması, kararın kendiliğinden iyileştiğini göstermez.
Bunun için ekibin öğrendiği bilgiyi kullanabileceği alan da bulunmalıdır. Her çözüm ve tarih değişmez kabul ediliyorsa kullanıcı görüşmeleri yalnızca planı gerekçelendirmek için kullanılabilir. Yönetici, hangi sınırların sabit olduğunu ve hangi seçeneklerin yeni bilgiyle değişebileceğini açıkça belirtmelidir. Böylece keşif, beklentisi belirsiz bir faaliyet olarak kalmaz.
Terim nedir?
Teresa Torres, Continuous Discovery Habits yaklaşımında sürekli keşfi, ürünü geliştiren ekibin hedeflenen ürün sonucuna yönelik küçük araştırmalar yaparak müşterilerle en az haftalık temas kurması olarak tanımlar. Bu sıklık, Torres’ın yaklaşımının parçasıdır; bütün araştırmaların aynı biçimde yürütülmesini gerektirmez.
Outcome, yani sonuç, kullanıcı davranışında veya iş performansında amaçlanan değişimdir. Örneğin kullanıcının ilk raporunu yardım almadan paylaşabilmesi bir sonuç olarak ele alınabilir. Görüşme yapmak ve yeni ekran geliştirmek ise faaliyet veya çıktıdır; beklenen değişimin gerçekleştiğini ayrıca değerlendirmek gerekir.
Product Trio, ürün, tasarım ve mühendislik uzmanlıklarının keşif kararlarında birlikte çalışmasını ifade eden üçlü yapıdır. Opportunity, yani fırsat, karşılanmamış bir kullanıcı ihtiyacı, güçlük veya istektir. Ekip görüşmelerle bunları araştırır ve çözüm seçeneklerinin dayandığı varsayımları sınar.
Yöntem kaynağı: Teresa Torres, Everyone Can Do Continuous Discovery—Even You! Here’s How, Product Talk, 2 Ağustos 2023.
Düzenli görüşme, tek başına düzenli öğrenme değildir. Hep aynı kullanıcı grubuyla konuşmak başka ihtiyaçları görünmez bırakabilir. En istekli katılımcılar, ürünü bırakan veya başlamayan kişilerin deneyimini temsil etmeyebilir. Kimlerin dinlendiğini ve kimlerin eksik kaldığını izlemek gerekir.
Keşif ve geliştirme birbirini besleyebilir. Uygulama sırasında fark edilen bir bağımlılık yeni soru doğurabilir; kullanıcı gözlemi küçük bir kapsam değişikliğini gerektirebilir. Her yeni bilgi için bütün planı yeniden yapmak yerine, bulgunun hangi kararı etkilediği değerlendirilmelidir.
Gerçek vaka: Voxy’de küçük bir keşif denemesiyle başlamak
Product Talk’un 7 Haziran 2023 tarihli yazısı, Voxy’de kıdemli ürün yöneticisi Bianca Starling’in sürekli keşif alışkanlıklarını başlatma deneyimini aktarıyor. Voxy, kurumsal dil öğrenimi hizmeti sunuyor. Starling, ürün ekibinde tutarlı bir keşif süreci oluşturmak için sınırlı bir deneme başlatmış.
Teknik lider ve ürün tasarımcısıyla birlikte çalışan ekip, kullanıcı görüşmeleri için ürün içindeki Pendo aracından randevu bağlantısı paylaşmış. Görüşmelerde biri konuşmayı yürütürken diğerleri not almış; roller dönüşümlü uygulanmış. Öğrenilen ihtiyaçlar, çözüm seçenekleri ve deneyler hedeflenen kullanıcı katılımıyla ilişkilendirilmiş.
Yazıda, grup dersine katılmaya çekinen kullanıcıların öğretmenin konuştuğu dilleri görmesi gibi varsayımların incelendiği anlatılıyor. Burada dile getirilen katılma isteği, gerçekleşmiş ders katılımıyla aynı değildir. Bu ayrım, araştırma bulgusunun hangi iddiayı desteklediğini anlamak için önemlidir.
Vaka, uygulamada yer alan kişinin röportajına dayanıyor; kontrollü bir etki araştırması sunmuyor. Doğrulanabilen ders, bütün kurumu aynı anda değiştirmek yerine sınırlı bir çalışmayla görüşme, ortak değerlendirme ve deney alışkanlıklarını denemektir. Bu süreçte üretilen bilgi, sonraki yaygınlaştırma kararını desteklemiş.
Varsayımsal örnek: İlk raporu paylaşmayı kolaylaştırmak
Bir kurumsal raporlama ürünü, yeni kullanıcıların ilk raporlarını ekip arkadaşlarıyla paylaşmasını kolaylaştırmak istiyor. Ürün sahibi, tasarımcı ve geliştirici, düzenli kullanıcı temasını bu amaca bağlayarak çalışmaya başlıyor.
Görüşmelerde kullanıcılardan son rapor hazırlama deneyimlerini anlatmaları isteniyor. Hangi veriyi seçtikleri, paylaşmadan önce kimden onay aldıkları ve hangi adımda başka araca geçtikleri konuşuluyor. Ekip doğrudan “Yeni paylaşım düğmesi ister misiniz?” sorusuyla başlamıyor; mevcut işin nasıl yürüdüğünü anlamaya çalışıyor.
Bazı kullanıcılar yanlış kişilere erişim vermekten çekiniyor. Bazıları ise raporun karşı tarafta nasıl görüneceğini bilemediği için dosya indirip e-posta gönderiyor. Bu ihtiyaçlar ayrı kaydediliyor. Paylaşımı artıracak tek çözümün daha büyük bir düğme olduğu varsayılmıyor.
Tasarımcı, erişecek kişileri ve görüntülenecek içeriği açıklayan bir prototip hazırlıyor. Prototip, çözümün belirli yönlerini denemek için kullanılan temsildir. Kullanıcının kimin ne göreceğini doğru yorumlayıp yorumlamadığı inceleniyor. Geliştirici, mevcut yetki sisteminin önerilen davranışı destekleyip desteklemediğini değerlendiriyor.
Öğrenilenlere göre ilk kapsam, paylaşım öncesi erişim bilgisini netleştirmek olarak seçilebilir. Product Backlog, yani ürün için gereken işlerin sıralı listesi, bu kararla güncelleniyor. Başka bir ihtiyaç için düşünülen geniş kapsamlı çalışma sonraki değerlendirmeye bırakılıyor.
Değişiklik kullanıma açıldıktan sonra paylaşım davranışı ve kullanıcıların yaşadığı güçlükler izleniyor. Sonraki görüşmeler, paylaşımı tamamlayanların yanında tamamlayamayanları da kapsıyor. Yeni bulgular, ilk çözümün yeterli olup olmadığını ve sıradaki ihtiyacın ne olduğunu değerlendirmeye yardımcı oluyor.
Yaygın üç hata
- Görüşme takvimini başarı ölçüsü saymak
Düzenli temas değerlidir; fakat kararlarla bağlantısı kurulmalıdır. Her çalışmanın hangi soruya cevap aradığını ve bulgunun neyi değiştirdiğini kaydedin. Görüşme sayısını ürün etkisinin yerine koymayın.
- Geri bildirimi doğrudan özellik talimatına çevirmek
Kullanıcının önerdiği çözümün arkasındaki ihtiyacı araştırın. Aynı güçlük farklı yollarla giderilebilir. Tek bir talebe bağlanmadan önce kullanım bağlamını ve diğer seçenekleri değerlendirin.
- Yalnızca araştırma yapmak, varsayımı sınamamak
Problemi anlamakla çözümün çalışacağını göstermek farklıdır. Görüşmelerden sonra çözümün hangi varsayıma dayandığını açıklayın. O varsayımı değerlendirecek küçük ve uygun çalışmayı belirleyin.
Mini uygulama / şablon
Yaklaşan ürün kararı için aşağıdaki alanları doldurun.
- Amaçlanan kullanıcı veya iş sonucu
- —
- Öğrenmek istediğimiz soru
- —
- Görüşülecek kullanıcı grubu
- —
- Eksik kalan kullanıcı grupları
- —
- İncelenecek yakın tarihli deneyim
- —
- Gözlenen ihtiyaç ve kanıt
- —
- Düşünülen çözüm seçenekleri
- —
- Kritik varsayım
- —
- Varsayımı sınama yöntemi
- —
- Öğrenilenlerin değiştirdiği karar
- —
- Açık kalan sorular
- —
- Sonraki temas ve değerlendirme zamanı
- —
Sonra bir önceki çalışmanın bulgusunu seçin. Bu bulgu kapsamı, sıralamayı veya çözümü etkiledi mi? Etkilemediyse gerekçeyi açıklayın. Her görüşme planı değiştirmek zorunda değildir; fakat bilgiyle karar arasındaki bağ görünür olmalıdır. Kayıtları kısa tutun ve ekibin sonraki kararında kullanabileceği şekilde güncelleyin.
İlgili terimler
Product Discovery, Product Trio, Customer Interview, Outcome ve Output, Opportunity Solution Tree, Hypothesis, Assumption Testing, Prototype, Usability Testing, Product Backlog, Product Goal, Dört Büyük Ürün Riski, Product Owner, Product Manager