30 saniyelik özet

Problem–solution fit, yani problem–çözüm uyumu, belirli bir müşteri grubunun önemli bir problemini önerilen çözümün anlamlı biçimde azaltabildiğine ilişkin kanıttır. Problemin varlığıyla çözümün işe yaraması ayrı ayrı araştırılmalıdır. Olumlu yorum, kullanılabilir ekran veya tamamlanan geliştirme bu ilişkiyi tek başına göstermez. Müşterinin mevcut yöntemine kıyasla hangi sonucu elde ettiği, bunun hangi koşullarda gerçekleştiği ve sonuç için hangi yükü üstlendiği değerlendirilir. Bu aşamadaki kanıt, bütün pazarda sürdürülebilir büyüme sağlanacağını garanti etmez; daha büyük taahhütlerden önce çözüm yönünü değerlendirmeye yardımcı olur.

Neden önemli?

Bir satış ekibi teklif hazırlamakta zorlandığını söylüyor olsun. Ürün ekibi bunu metin yazma problemi olarak yorumlayıp otomatik teklif oluşturma özelliği geliştirebilir. Ancak asıl engel, fiyatın kim tarafından onaylanacağının belirsizliği veya geçerli ürün koşullarının bulunamaması olabilir. Daha hızlı yazılan teklif, yine onay bekleyebilir.

Bu durumda ekip geliştirmeyi tamamlamış ama önemli iş sonucunu değiştirememiştir. Çözümün kalitesi ile doğru probleme yönelmesi farklı değerlendirmelerdir. Kullanıcının ekrana olumlu yorum yapması, teklifin daha doğru veya daha hızlı müşteriye ulaştığını göstermez.

Yönetici açısından problem–çözüm uyumu, yatırımın dayandığı temel ilişkiyi sınar. Hangi grubun hangi sıkıntısı azalacak? Bunu göstermek için ne gözlenecek? Sonuç zayıfsa daha fazla özellik eklemek yerine problem tanımı veya çözüm yaklaşımı yeniden ele alınabilir. Bu değerlendirme erken yapıldığında, kaynaklar doğrulanmamış bir yönü büyütmek için kullanılmayabilir.

Terim nedir?

Problem–çözüm uyumu tek bir resmi eşikle ölçülen evrensel bir durum değildir. Ekipler, kendi iş bağlamlarına uygun kanıt ve karar koşulları belirlemelidir. Temel ilişki, hedef kullanıcı, önemli problem ve çözümün ürettiği sonuç arasında kurulur. Kullanıcı grubu veya kullanım koşulu değişirse önceki kanıtın geçerliliği yeniden değerlendirilir.

Problem kanıtı; somut olaylar, mevcut geçici çözümler, harcanan emek ve oluşan iş etkisinden gelebilir. Çözüm kanıtı ise gerçek görev denemeleri, kullanım, sonuç karşılaştırmaları veya belirli koşullardaki müşteri taahhütleriyle güçlenebilir. Kanıt türleri farklı sorulara cevap verir. Ödeme isteği ticari ilgi hakkında bilgi verirken çözümün problemi azaltabildiği ayrıca incelenmelidir.

Prototype, yani prototip, çözümün belirli özelliklerini veya davranışlarını sınamak için hazırlanan temsildir. Bir görevde anlaşılabilirliği değerlendirebilir, fakat gerçek veriyle çalışmıyorsa operasyon sonucunu kanıtlayamaz. Pilot ise sınırlı kapsamlı gerçek kullanım denemesidir. Pilotun kapsamı ve destek koşulları açık olmalıdır; yoğun el emeğiyle sağlanan başarı, otomatik hizmetin aynı sonucu vereceğini göstermez.

Product–market fit, yani ürün–pazar uyumu, daha geniş biçimde ürünün belirli bir pazarda güçlü ve sürdürülebilir karşılık bulmasıyla ilgilidir. Problem–çözüm uyumu bunun için önemli bir araştırma alanıdır; ancak yeterli pazar büyüklüğü, erişim ve ekonomik sürdürülebilirlik gibi sorular açık kalabilir. Birkaç müşteriye değer sağlamak, ölçeklenebilir ticari modelin bütün unsurlarını doğrulamaz.

Kullanımın devam etmesi de bağlamıyla yorumlanmalıdır. Kullanıcı çözümü zorunlu olduğu için, alternatif bulunmadığı için veya gerçekten fayda gördüğü için kullanıyor olabilir. Tersine, eski yönteme dönmesi sorunun önemsizliğini değil, veri aktarımı veya eğitim engelini gösterebilir. Davranış gözlendikten sonra nedenleri araştırılmalı; tek olaydan kesin sonuç çıkarılmamalıdır.

Gerçek vaka: Airbnb’nin fotoğrafları yerinde iyileştirmesi

Y Combinator’ın 2017 yılında yayımladığı sayfa, Airbnb kurucusu Joe Gebbia ile Reid Hoffman’ın ürünün büyümesi üzerine görüşmesini özetliyor. Anlatılan erken uygulamalardan biri, ev sahiplerinin bulunduğu yerlere giderek daha iyi fotoğraflar çekmek. Sayfa, bu adımı başlangıçta ölçeklenemeyen işleri yapma yaklaşımıyla ilişkilendiriyor.

Kaynak ayrıca müşterilerin yaşam alanlarında deneyimlerini araştırmayı ve güven sağlayan tasarımı konuşmanın konuları arasında sayıyor. Buradan çıkarılabilecek analiz dersi, çözümün değerini yalnızca web sitesinin özelliklerinde aramamaktır. Kullanıcının kararını etkileyen sunum ve güven koşulları da araştırılabilir.

Fotoğraf müdahalesi, büyük bir otomasyon yatırımı olmadan belirli bir deneyim unsurunu ele almanın örneğidir. Ancak bu kısa kaynak, fotoğrafların bağımsız etkisini gösteren kontrollü deney sunmuyor. Dolayısıyla belirli bir rezervasyon artışı veya kesin neden–sonuç ilişkisi ileri sürülmüyor. Vaka, bütün pazarın doğrulandığını değil, erken çözüm öğrenmesinin nasıl somutlaştırılabileceğini düşünmek için kullanılıyor.

Kaynak: Y Combinator, Scaling Product at Airbnb with Joe Gebbia and Reid Hoffman, 6 Haziran 2017.

Varsayımsal örnek: Teklif hazırlama yükünü azaltmak

Bir yazılım ekibi satış ajanslarına teklif hazırlama aracı sunmayı düşünüyor. İlk varsayım, teklif metninin yazılmasının fazla zaman aldığı. Müşteri keşfinde son teklifler incelendiğinde ekiplerin geçerli örneği bulmakta ve eski koşulları yeni belgeye taşımamakta zorlandığı anlaşılsın. Bu bulgu, tam otomatik metin üretimi yerine doğrulanmış içerik parçalarını bulma yaklaşımını gündeme getiriyor.

Hedef görev açık yazılıyor: Satış uzmanı, güncel ticari koşullara uygun bir teklif taslağı hazırlayıp gerekli onaya gönderecek. Çözüm, onay sürecini değiştirmiyorsa bu sınır korunuyor. Toplam teklif süresi iyileşmediğinde hangi adımın etkilenmediği görülebiliyor.

İlk denemede ekip, geçerli örnekleri düzenleyip yeniden kullanılabilir içerik parçaları sunuyor. Bazı işlemler elle yapılıyorsa bu emek ayrıca kaydediliyor. Kullanıcıdan yalnızca arayüzü değerlendirmesi istenmiyor; gerçek bir teklif görevini tamamlaması bekleniyor.

Deneme öncesinde mevcut yöntemde hazırlama süresi, düzeltme ihtiyacı ve eski koşul kullanma sorunları inceleniyor. Yeni yaklaşımla karşılaştırmada tekliflerin karmaşıklığı ve kullanıcının deneyimi dikkate alınıyor. Daha basit bir teklifin hızlı tamamlanması, çözümün etkisi olarak doğrudan sunulmuyor.

Başarı koşulları iş kullanıcılarıyla önceden kararlaştırılıyor. Hedef, hızlı fakat yanlış teklif üretmek değil; uygun taslağı daha az gereksiz arama ve düzeltmeyle hazırlamak. Karar eşiği için yeterli veri yoksa oran veya süre uydurulmuyor; önce başlangıç durumu ölçülüyor.

Kullanıcılar tekrar kullanmak istiyor ve iş sonucu iyileşiyorsa belirli koşullarda uyuma ilişkin kanıt güçleniyor. Buna rağmen hizmetin sunum maliyeti ve başka ajanslardaki uygulanabilirlik açık kalabilir. Ekip, sonraki yatırımı bu sınırlar üzerinden değerlendiriyor; sınırlı başarıyı bütün pazara genellemiyor.

Yaygın üç hata

  1. Beğeniyi sonuç yerine kullanmak

“Mükemmel fikir” yorumu ilişki kurmak için olumlu olabilir, fakat problemi azaltma kanıtı değildir. Kullanıcının görevini, elde ettiği sonucu ve mevcut yönteme göre farkı inceleyin. Nezaket yorumlarını kullanım davranışıyla aynı düzeyde değerlendirmeyin.

  1. Birden fazla şeyi değiştirip tek etki iddia etmek

Yeni araçla birlikte eğitim, süreç ve veri düzeni de değişebilir. Sonucu hangi müdahalelerin etkileyebileceğini kaydedin. Etkileri ayıramıyorsanız bunu belirtin. Birleşik hizmet değer üretse bile yazılımın tek başına aynı sonucu sağlayacağını varsaymayın.

  1. İlk olumlu denemeyi geniş yatırım onayı saymak

Kısıtlı gruptaki başarı, farklı müşterilerin veya daha büyük kullanımın koşullarını göstermeyebilir. Sonraki denemede hangi belirsizliğin araştırılacağını belirleyin. Müşteri değerini, işletim maliyetini ve pazara erişimi ayrı sorular olarak izleyin.

Mini uygulama / şablon

Bir çözüm fikri seçin. Önce ilişkiyi tek cümlede kurun: Belirli kullanıcı, belirli durumda, bu yaklaşımla hangi ilerlemeyi elde edecek?

Hedef kullanıcı ve kullanım koşulu
—
Önemli problem ve somut kanıt
—
Mevcut yöntem veya alternatif
—
Önerilen çözüm ve kapsam sınırı
—
Beklenen iş sonucu
—
Sınanacak kritik varsayım
—
Denemenin türü ve görevleri
—
Başlangıç ölçümü
—
Karşılaştırma koşulları
—
Başarı ve durdurma ölçütleri
—
Sonucu koruyacak kalite kontrolleri
—
Elle yapılan işler ve sunum maliyeti
—
Gözlenen sonuç ve sınırlamalar
—
Sonraki karar ve karar sahibi
—

İnceleme sonunda “uyum var” etiketinin yanına kanıtın geçerli olduğu koşulları yazın. Hangi kullanıcılar, hangi görevler ve hangi destekle sonuç aldı? Açık kalan soruları koruyun. Böylece erken öğrenme, belirsiz bir başarı ilanı yerine bir sonraki taahhüdün gerekçesine dönüşür.

İlgili terimler

Müşteri Keşfi, İdeal Müşteri Profili, Problem Statement, Değer Önerisi, Prototype ve MVP, Product–Market Fit, Business Case, Feasibility Study, KPI ve Metrics, Voice of Customer