Product Discovery: Continuous Discovery, Kullanıcı Görüşmesi ve Opportunity Solution Tree

Sürüm notu: Bu yazı kavramsaldır; Opportunity Solution Tree ve continuous discovery için Teresa Torres'in Product Talk yazıları (Aralık 2023 güncellemesi) ve "Continuous Discovery Habits" (2021) kitabı esas alınmıştır.

Önce Tahmin Et

Bookstore ekibi sepet terk problemini anlamak için, son ay sepetini terk etmiş altı müşteriyle görüşmeye karar verdi. Ekipten bir geliştirici görüşme sorularını hazırladı:

• Tek tıkla ödeme olsaydı alışverişi tamamlar mıydınız?
• Sitemizi beğeniyor musunuz, nelerin iyileşmesini istersiniz?
• Kargo ücreti sizin için önemli mi?
• Kitap aldığınız son siteden en son ne zaman, ne aldınız? Bize o alışverişi baştan anlatır mısınız?

Bu dört sorudan hangisi gerçekten işe yarar bilgi üretir? Hangisinin cevabını görüşmeden önce zaten tahmin edebilirsin? Bir de şunu düşün: altı görüşmenin dördünde "kargo ücreti çok yüksek" cevabı gelirse, bu, kargo ücretini düşürmemiz gerektiği anlamına mı gelir?

Continuous Discovery

Product discovery, neyi inşa etmemiz gerektiğine karar verme işidir; delivery ise o şeyi inşa edip müşteriye ulaştırma işi. Birçok ekipte discovery bir projenin başında yapılan bir "analiz fazı"dır: birkaç hafta araştırma, bir doküman, sonra aylarca delivery. Teresa Torres "Continuous Discovery Habits" kitabında bunun yerine sürekli bir pratik önerir: ürünü inşa eden ekip, ulaşmak istediği bir outcome doğrultusunda müşterileriyle en az haftada bir temas kurar ve küçük araştırma aktiviteleri yapar.

Haftada bir temas kulağa çok gelebilir, ama küçük bir şeyden bahsediyoruz: 30 dakikalık bir görüşme, bir prototipin beş müşteriyle denenmesi, bir destek kaydı okuma oturumu. Önemli olan ritim: discovery bir faz olmaktan çıkar ve delivery'nin yanında her hafta akan bir iş hâline gelir. Torres ayrıca görüşmeleri ürün ekibinin kendisinin yapmasını, yani bulguların bir araştırma ekibinden rapor olarak gelmemesini vurgular; product manager, designer ve en az bir mühendis.

İyi Görüşme Soruları: Geçmişi Sor, Geleceği İsteme

Baştaki dört sorudan yalnız sonuncusu gerçekten işe yarar. İlk üçünün ortak sorunu, müşteriden bir tahmin ya da bir görüş istemeleri. "Tek tıkla ödeme olsaydı alışverişi tamamlar mıydınız?" sorusuna çoğu insan nazikçe "evet" der; ama insanlar gelecekteki davranışlarını tahmin etmekte kötüdür ve görüşmeciyi memnun etmeye eğilimlidir. "Kargo ücreti sizin için önemli mi?" sorusunun cevabı da önceden bellidir: kimse "hayır, kargo ücretine hiç bakmam" demez.

Rob Fitzpatrick'in 2013 tarihli "The Mom Test" kitabı bu tuzağı iyi anlatır: annene iş fikrini sorarsan sana yalan söylemez ama seni kırmamak için fikrini beğenir. Çözüm, fikir ya da görüş yerine geçmişteki somut davranışı sormaktır. Torres de buna story-based interviewing der: "En son ... zamanı anlat" diye başlayan, müşteriyi gerçek bir anı baştan sona anlatmaya davet eden sorular.

Bookstore görüşmesi için daha iyi bir akış şöyle olur: "En son internetten kitap aldığınız zamanı anlatır mısınız? Kimin içindi? Nereden aradınız? Sepete ekledikten sonra ne oldu?" Ardından müşterinin anlattığı hikâyenin içinden takip soruları: "O anda kargo ücretini gördüğünüzde ne düşündünüz? Sonra ne yaptınız?" Bu sorular bir çözümü ima etmez, müşterinin aklına bir cevap koymaz ve gerçekte ne olduğunu anlatır.

Görüşmeyi kayda alacaksan önceden izin iste ve kaydı kimin, ne kadar süre saklayacağını söyle. Görüşme notlarında müşterinin adı, e-postası, sipariş numarası gibi kişisel verileri tutma; özet bir hikâye ve bir müşteri kodu yeterli.

Opportunity Solution Tree

Görüşmelerden, destek kayıtlarından ve veriden gelen bulgular bir yerde toplanmalı ki ekip hangisine odaklanacağına karar verebilsin. Torres'in Opportunity Solution Tree'si (OST) bunun için bir görselleştirmedir ve dört seviyeden oluşur:

Ağacın kökü outcome'dur ve discovery'nin kapsamını belirler. Torres burada bir ayrım yapar: business outcome'lar (gelir, churn) şirketin sağlığını ölçer ama ekip onları doğrudan hareket ettiremez; product outcome'lar ise müşterinin ürün içindeki davranışını ölçer ve genel kural olarak ağacın kökü için daha uygundur. Bookstore'un kökü bir product outcome: sepet terk oranını %66,7'den %60'a indirmek.

İkinci seviye opportunity'lerdir: müşterinin karşılanmamış bir ihtiyacı, bir acısı ya da bir arzusu. Opportunity bir çözüm değildir. Torres'in basit testi şudur: "Bu opportunity'yi karşılamanın birden fazla yolu var mı?" "Kargo ücretini son adımda görüp vazgeçiyorum" bir opportunity'dir, çünkü onu birçok farklı çözümle karşılayabilirsin. "Ürün sayfasında kargo ücretini göster" ise bir çözümdür. Opportunity'ler ekibin kafasından değil, görüşmelerden gelmelidir; Torres her üç dört görüşmede bir opportunity alanını yeniden gözden geçirmeyi önerir.

Üçüncü seviye solution'lardır, ama yalnız seçilen hedef opportunity için. Ekip ağaçtaki her opportunity için çözüm üretmez; birini seçer ve onun için birkaç alternatif çözüm düşünür. Torres en az üç çözümü karşılaştırmayı önerir; tek bir çözüme âşık olmak discovery'nin en yaygın hatasıdır.

Dördüncü seviye assumption testleridir. Her çözüm bir dizi varsayıma dayanır ve ekip çözümün tamamını inşa etmek yerine en riskli varsayımı ucuza test eder. Sonuçlar bir sonraki kararı yönlendirir: fikri bırakmak, birini delivery için geliştirmek ya da yeni bir hedef opportunity seçmek.

Bookstore'un Ağacı

Altı görüşme, son üç ayın destek kayıtları ve segmentlere bölünmüş funnel'dan üç opportunity çıktı. Birincisi kargo ücretinin sürpriz olması: görüşülen altı kişinin dördü, sepete ekledikten sonra kargo ücretini görünce vazgeçtiği bir anı anlattı. İkincisi zorunlu üyelik: tek bir kitap için hesap açmak istemeyen misafirler; funnel'da misafirlerin terk oranı %72,1, kayıtlı müşterilerin %56,3. Üçüncüsü kart bilgilerini her seferinde girmek; bu yalnız kayıtlı müşterilerden geldi ve genel müdürün one-click checkout fikrinin karşılık geldiği opportunity tam olarak bu.

Ekip hedef opportunity olarak kargo ücreti sürprizini seçti, çünkü hem görüşmelerde en sık geçti hem de misafir ve kayıtlı kullanıcıların ikisini birden etkiliyor. Bu opportunity için üç çözüm düşündü: ürün sayfasında kargo ücretini göstermek, sepette "X TL daha ekle, kargo bedava" diye bir ücretsiz kargo eşiği göstergesi, ve posta koduna göre kargo hesabı. Dikkat et, "kargo ücretini düşürmek" de bir çözüm olabilirdi; ama bu bir viability kararıdır ve product discovery'nin ötesinde bir maliyet konuşması gerektirir.

Baştaki sorunun cevabı da burada: altı görüşmenin dördünde kargo ücreti geçmesi, ücreti düşürmemiz gerektiği anlamına gelmez. Müşterilerin hikâyesine dikkat edince dertlerinin ücretin kendisinden çok, ücreti son adımda görmek olduğu ortaya çıktı. Opportunity'yi doğru adlandırmak, çözüm alanını tamamen değiştiriyor.

Assumption Testing Türleri

"Ürün sayfasında kargo ücreti" çözümünün arkasında birkaç varsayım var: müşteriler kargo ücretini erken görmek istiyor (desirability), ücreti ürün sayfasında doğru hesaplayabiliriz (feasibility), ücreti erken gören müşteri sepete daha az ekleyip toplam siparişi düşürmez (viability). Bunları test etmenin birkaç ucuz yolu var.

Veri analizi en ucuzudur: terklerin ne kadarının sepette, ne kadarının ödeme adımında olduğu zaten funnel'da duruyor. Fake door testinde gerçek feature'ı inşa etmeden onun kapısını koyarsın: ürün sayfasına bir "kargo ücretini gör" linki eklersin ve kaç kişinin tıkladığını ölçersin; tıklayana dürüstçe "bu özellik yakında geliyor" dersin. Concierge testinde feature'ı otomatikleştirmek yerine bir insan elle yapar: birkaç hafta boyunca destek ekibi, isteyen müşteriye canlı destekten kargo ücretini söyler. Prototip testinde ise tıklanabilir bir tasarımı beş müşteriye kullandırır ve ne yaptıklarını izlersin.

Hangisini seçeceğin, test ettiğin varsayıma bağlıdır. Fake door talebi ölçer ama kullanılabilirliği ölçmez; prototip testi kullanılabilirliği ölçer ama talebi ölçmez. Hiçbiri gerçek feature'ın gerçek trafikteki etkisini ölçmez; onun için 08. yazıdaki deneye ihtiyaç var.

Dual-Track ve Geliştiricinin Yeri

Discovery ile delivery'nin aynı ekip içinde paralel aktığı çalışma biçimine dual-track denir; Jeff Patton ve Marty Cagan'ın yazılarıyla yaygınlaştı. Bir track bu hafta neyin inşa edileceğini öğrenir, diğeri geçen haftalarda öğrenilenleri production kalitesinde inşa eder. İki track ayrı ekipler değildir; aynı insanlar, haftanın farklı saatlerinde, iki işi birden yapar.

Geliştiricinin discovery'deki yeri üç yerde belirginleşir. Birincisi feasibility spike: "ürün sayfasında kargo ücretini hesaplayabilir miyiz?" sorusunu cevaplamak için kargo firmasının fiyat API'sini (Application Programming Interface) bir iki gün kurcalamak, gecikmesini ölçmek, cache'lenebilir olup olmadığına bakmak. İkincisi throwaway prototip: fake door linkini ya da prototip testinin arkasındaki sahte veriyi hızlıca kurmak, ve bunu bilerek "atılacak kod" olarak yazmak. Üçüncüsü görüşmelere katılmak: müşterinin hikâyesini birinci elden dinleyen geliştirici, aylar sonra bir edge case'e karar verirken o hikâyeyi hatırlar.

Üretimde Dikkat

Fake door testi bir etik sınır taşır. Kullanıcıyı olmayan bir özelliğe tıklatıp boş bir sayfaya göndermek güveni zedeler; tıklayana dürüst bir mesaj göster, testi kısa tut (bir iki hafta) ve trafiğin küçük bir kısmıyla yap. Ödeme gibi hassas akışlarda fake door kullanma.

Prototipin production'a sızmasını engelle. "Şimdilik böyle kalsın" diye bırakılan fake door linkleri ve prototip endpoint'leri yıllarca yaşar. Discovery için yazılan kodu ayrı bir branch'te ya da açıkça adlandırılmış bir feature flag'in arkasında tut ve testin bitiş tarihini backlog'a bir silme item'ı olarak yaz.

Discovery bulgularını kaydet ama kişisel veriyi kaydetme. Görüşme notları, OST'nin kendisi ve assumption testlerinin sonuçları ekibin ortak hafızasıdır; üç ay sonra "bunu neden yapmamaya karar vermiştik?" sorusunun cevabı orada olmalı.

Sık Düşülen Tuzaklar

İlk tuzak yönlendirici soru. "Kargo ücretinin yüksek olması sizi rahatsız ediyor mu?" sorusu cevabı müşterinin ağzına koyar. Soruyu bir hikâye istemeye çevir: "Son alışverişinizde kargo ücretini ne zaman gördünüz, o anda ne yaptınız?"

İkinci tuzak tek görüşmeden genelleme. Çok etkileyici anlatılan tek bir hikâye, ekibin bütün önceliklerini değiştirebilir. Opportunity'yi ancak birkaç görüşmede ve mümkünse veride de gördüğünde ağaca güçlü bir dal olarak ekle.

Üçüncüsü tek çözüme âşık olmak. Ekip "ürün sayfasında kargo ücreti" fikrine baştan karar vermişse, assumption testleri yalnız o fikri doğrulamak için tasarlanır. En az üç çözümü yan yana koymak bu önyargıyı kırar.

Dördüncüsü discovery'yi bir faza çevirmek. "Bu çeyrek discovery yapıyoruz, sonraki çeyrek delivery" ayrımı continuous discovery'nin tam tersidir. Haftalık ritim kaybolduğunda, ekip ilk delivery haftasından itibaren yeniden tahminle karar vermeye başlar.

Küçük Bir Deneme

★☆☆ Ekibinde bir sonraki müşteri görüşmesi için üç soru yaz ve her birini "geçmiş davranış mı, gelecek tahmini mi, görüş mü?" diye etiketle. Geçmiş davranış sormayan soruları "en son ... zamanı anlatır mısınız?" biçimine çevir.

★★☆ Ürününün bir outcome'u için küçük bir OST çiz: kök outcome, elindeki kanıta dayanan en az üç opportunity, birini hedef seç ve onun için üç çözüm yaz. Hangi opportunity'nin kanıtı zayıf, onu nasıl güçlendirirsin?

★★★ Seçtiğin çözümün en riskli varsayımını bul ve onu bir haftadan kısa sürede test edecek bir assumption testi tasarla: hangi test türü, kaç kullanıcı, hangi sonuç seni fikirden vazgeçirir? Geliştirici olarak bu testte senin payına düşen iş ne?

Ağaçta hedef opportunity'yi seçtik, ama çoğu zaman masada birden fazla iyi fikir, birden fazla ekip talebi ve sınırlı kapasite olur. Bir sonraki yazıda RICE (Reach, Impact, Confidence, Effort), MoSCoW, Kano ve Cost of Delay ile önceliklendirmeyi konuşacağız ve TypeScript ile aynı backlog'u iki farklı yöntemle sıralayacağız.