30 sn özet

Ürün keşfi, hangi müşteri probleminin çözülmeye değer olduğunu ve hangi çözümün anlamlı sonuç üretebileceğini araştırma sürecidir. İngilizce karşılığı Product Discovery’dir. Kullanıcının ihtiyacını anlamakla başlar; çözümün değerini, kullanılabilirliğini, teknik yapılabilirliğini ve şirket açısından uygunluğunu sınamaya uzanır. Görüşme, gözlem, veri analizi, prototip ve küçük deneyler farklı sorulara cevap verir. Amaç, geliştirme yatırımının dayandığı belirsizlikleri azaltmaktır. Keşif ürün kullanıma sunulduktan sonra da sürer; gerçek kullanım bulguları sonraki kararları şekillendirir.

Neden önemli?

Bir ekip planlanan özellikleri zamanında yayımlayabilir; buna rağmen müşteri beklediği faydayı alamayabilir. Sorun, ürünün yanlış uygulanması kadar yanlış ihtiyaca odaklanılması veya uygun olmayan bir çözüm seçilmesi de olabilir. Ürün keşfi bu olasılıkları geliştirme kararına taşır.

Örneğin teklif hazırlamakta zorlanan satış ekibi, otomatik metin yazımı isteyebilir. Araştırmada asıl gecikmenin fiyat onayını beklemekten kaynaklandığı görülürse metin üretimini hızlandırmak toplam süreyi yeterince değiştirmeyebilir. Talebi anlamak, süreci incelemek ve alternatifleri sınamak yatırımın yönünü değiştirebilir.

Yönetici açısından keşfin değeri, seçenekler arasındaki kararın dayanağını güçlendirmesidir. Bütçe talebinde yalnızca yapılacak işler değil; çözülmek istenen problem, bulunan kanıtlar ve açık kalan sorular da görünür olur. Böylece hangi yatırımı neden şimdi yapacağımızı daha açık tartışabiliriz.

Junior bir iş analisti veya ürün sahibi için keşif, gereksinimlerin gerekçesini anlamayı sağlar. Kullanıcının çalışma biçimini bilen bir analist, ekranda görünmeyen süreç bağımlılıklarını fark edebilir. Ürün sahibi ise geliştirme önceliklerini müşteri faydasıyla ilişkilendirebilir. Bu katkılar, ürün yöneticisinin ve diğer uzmanların kararlarını besler.

Terim nedir?

Ürün keşfi, ürün kararları için bilgi üretmeye yönelik çalışmaların bütünüdür. Problem keşfi kullanıcının hangi durumda neyi başaramadığını anlamaya odaklanır. Ürün keşfi bu bilgiyi çözüm seçeneklerinin değerlendirilmesine taşır. Önemli bir problemin bulunması, akla gelen ilk çözümün uygun olduğunu tek başına göstermez.

Marty Cagan’ın Silicon Valley Product Group’ta anlattığı dört risk çerçevesi bu değerlendirmeyi düzenlemek için kullanılabilir. Değer riski, müşterinin çözümü seçip seçmeyeceğiyle ilgilidir. Kullanılabilirlik riski, kullanıcının çözümü anlayıp kullanabilmesidir. Teknik yapılabilirlik riski, mevcut zaman, teknoloji ve yetkinlikle çözümün üretilebilmesidir. İşletme açısından uygunluk riski ise çözümün şirketin ticari ve diğer gereksinimleriyle uyumunu kapsar.

Bu sorular birbirini tamamlar. Kolay kullanılan bir çözüm yeterince önemli bir ihtiyaca karşılık vermeyebilir. Kullanıcının istediği çözüm de şirketin kaynaklarıyla sürdürülemeyebilir. Bu nedenle araştırmada ürün, tasarım ve mühendislik katkıları birlikte değerlendirilmeli; ilgili işletme uzmanları kararın koşullarına göre sürece katılmalıdır.

Keşfin yöntemi, yanıtlanacak soruya göre seçilir. Kullanım bağlamı için gözlem yapılabilir. Bir akışın anlaşılabilirliği tıklanabilir prototiple incelenebilir. Prototip, çözümün belirli yönlerini denemek için hazırlanan temsilidir. Teknik belirsizlik için sınırlı bir uygulama denemesi gerekebilir. Gerçek operasyon etkisi ise dar kapsamlı bir pilotla araştırılabilir; pilot, çözümün sınırlı kullanıcı veya koşullarda uygulanmasıdır.

Her yöntem aynı tür kanıt üretmez. Prototipi tamamlayan kullanıcının ürüne ödeme yapacağı sonucu çıkarılamaz. Teknik denemenin çalışması da bütün müşterilerde aynı performansın oluşacağını kanıtlamaz. Bulguların hangi kararı desteklediği ve hangi soruyu açık bıraktığı belirtilmelidir.

Keşif ile geliştirme birbirini besler. Bir çözüm için yeterli kanıt oluştuğunda gerekli kapsam geliştirilir. Uygulama sırasında ortaya çıkan teknik kısıtlar veya kullanım sonrası bulgular, çözüm yaklaşımının yeniden ele alınmasını gerektirebilir. Böylece keşif, başlangıçta tamamlanıp rafa kaldırılan bir rapora dönüşmez.

Gerçek vaka: Airbnb’nin kullanıcılarla doğrudan çalışması

Paul Graham, Temmuz 2013 tarihli “Do Things that Don’t Scale” yazısında Airbnb’nin erken döneminde kurucuların New York’ta kullanıcılarla doğrudan çalışmasını anlatır. Yeni kullanıcılar kazanmak ve mevcut kullanıcıların ilanlarını iyileştirmek için sahaya gitmişlerdir. Graham, Brian Chesky ve Joe Gebbia’nın ilk ev sahiplerinin dairelerinin fotoğraflarını çektiğini de belirtir.

Bu uygulama, ürün keşfi açısından kullanıcı deneyimine yakından temas etme örneği olarak değerlendirilebilir. Ekibin ilan hazırlama sürecine katılması, hizmetin kullanılma koşullarını ve kullanıcıların ihtiyaçlarını yerinde anlamasına alan açmıştır. Bu, kaynaktaki davranışın keşif açısından yorumlanmasıdır.

Kaynak, fotoğraf müdahalesini kontrollü bir deneyin tasarımı ve sonuçlarıyla sunmaz. Dolayısıyla belirli bir rezervasyon artışının yalnızca bu çalışmadan kaynaklandığını burada iddia edemeyiz. Doğrulanabilen uygulama, kurucuların kullanıcılarla doğrudan çalışması ve ilanların iyileştirilmesine bizzat katkıda bulunmasıdır.

Vakadan çıkarılabilecek ders, öğrenmenin yalnızca uzaktan veri incelemeye dayanmak zorunda olmadığıdır. Bir hizmeti kullanıcıyla birlikte yürütmek, araştırılacak sorunları görünür kılabilir. Böyle bir müdahalenin kalıcı hizmet modeline dönüşüp dönüşmeyeceği ise maliyet, kapasite ve müşteri sonuçlarıyla ayrıca değerlendirilmelidir.

Kaynak: Paul Graham, “Do Things that Don’t Scale”, Temmuz 2013.

Varsayımsal örnek: Teklif sürecindeki gecikme

Şirketlere teklif hazırlama yazılımı sunan bir ekip düşünelim. Müşteriler tekliflerin geç gönderildiğini söylüyor ve otomatik metin oluşturma istiyor. Ürün ekibi, önce son yaşanan gecikmelerin adımlarını inceliyor. Görüşmeler ve çalışma sırasında gözlem, fiyat onayı beklemenin önemli bir engel olduğunu göstersin.

Ekip problem tanımını şu şekilde kuruyor: “Satış temsilcisi, müşteri görüşmesinden sonra fiyat onayını zamanında alamadığı için teklifi beklenen sürede gönderemiyor.” Bu varsayımsal bulgu üzerine farklı çözüm adayları değerlendiriliyor. Onay durumunun görünür olması, belirli koşullarda önceden tanımlı yetki verilmesi veya onay isteğinin doğru kişiye yönlendirilmesi seçenekler arasında bulunuyor.

Tasarımcı bir onay akışı prototipi hazırlıyor. Kullanıcı testinde temsilcinin onay durumunu anlayıp sonraki adımı bulabilmesi inceleniyor. Mühendis, mevcut sistemin yetki ve fiyat bilgisiyle bağlantısını değerlendiriyor. Ticari ekipler ve ilgili süreç sahipleri, önerilen yetki değişiminin işletme koşullarına uygunluğunu tartışıyor.

Bu çalışmalar olumlu sonuçlanırsa sınırlı bir pilot uygulanabilir. Onay bekleme süresi, teklifin gönderilmesi ve düzeltme ihtiyacı izlenir. Kullanıcıların farklı dosyalara veya mesajlaşma araçlarına dönmesi de araştırılır. Böylece çözümün gerçek sürece katkısı değerlendirilir.

Teklifin satışa dönüşmesi daha geniş bir sonuçtur; fiyat, rakipler ve müşteri bütçesi de bu sonucu etkiler. Bu nedenle pilotun etkisi yorumlanırken diğer açıklamalar dikkate alınır. Örnekte sayısal bir iyileşme veya kazanma oranı varsayılmamıştır.

Yaygın 3 hata

  1. Keşfi özellik talepleri toplamakla sınırlamak

Talepler araştırmaya başlangıç olabilir. Kullanıcının son deneyimini, mevcut alternatiflerini ve yaşadığı engeli inceleyin. Ardından çözüm adaylarını karşılaştırın.

  1. Kullanılabilirliği değerle eşitlemek

Kullanıcının prototipi tamamlaması önemli bir bilgidir. Ancak çözümün onun için yeterince değerli olduğunu tek başına göstermez. Kullanma gerekçesini ve mevcut yöntemini değiştirme isteğini ayrıca araştırın.

  1. Araştırmayı karar vermeden sürdürmek

Görüşmeler ve raporlar çoğalırken yatırım tercihi belirsiz kalabilir. Her çalışmanın hangi kararı aydınlatacağını yazın. Yeni bilgi aynı sonucu tekrar ediyorsa sonraki adımı değerlendirin; farklı bulgular varsa nedenlerini araştırın.

Mini uygulama/şablon

Bir ürün kararı için şu alanları doldurun:

Beklenen sonuç
Müşteri ve işletme açısından ne değişsin istiyoruz?
Problem
Kim, hangi durumda, hangi engelle karşılaşıyor?
Mevcut kanıt
Bunu hangi davranış veya olay destekliyor?
Çözüm adayları
Hangi farklı yaklaşımlar değerlendirilebilir?
Kritik belirsizlik
Hangi kabul yanlış çıkarsa yatırım değişir?
Yöntem
Bu belirsizliği hangi çalışmayla araştıracağız?
Karar ölçütü
Hangi bulgu hangi tercihi destekleyecek?
Sınır
Çalışma hangi koşulları kapsamayacak?
Sonraki adım
Devam etmek, değiştirmek veya durmak için ne öğrendik?

Bulguları ürün, tasarım ve mühendislik ekibiyle birlikte değerlendirin. Geliştirme kapsamını öğrenilenlere bağlayın. Kullanım sonrası gözlemleri bir sonraki keşif sorusuna dönüştürün.

Kavramsal kaynak: Silicon Valley Product Group, Marty Cagan, “The Four Big Risks”.

İlgili terimler

Problem Keşfi, Ürün Stratejisi, Varsayım Haritalama, Prototip, Kullanılabilirlik Testi, Minimum Uygulanabilir Ürün, Deney Tasarımı, Teknik Yapılabilirlik, Değer Önerisi, Önceliklendirme