Dört Büyük Ürün Riski

30 saniyelik özet

Bir ürün fikrinin önünde farklı belirsizlikler bulunur: İnsanlar çözümü tercih edecek mi, kullanabilecek mi, ekip geliştirebilecek mi ve çözüm şirket açısından çalışacak mı? Dört Büyük Ürün Riski, bu soruları ayrı değerlendirmeye yardımcı olur. Kullanıcının fikri beğenmesi, ödeme yapacağını göstermez. Çalışan bir gösterim de gerçek kullanım koşullarında güvenilir hizmet verileceğini kanıtlamaz. Product Owner, yani ürün sahibi, hangi varsayımın yatırım kararını etkilediğini belirlemeli ve ilgili uzmanlıklarla birlikte uygun kanıtı aramalıdır. Böylece geliştirme kapsamı, yalnızca talebin cazibesine değil, bilinmeyenlerin nasıl ele alınacağına da dayanır.

Neden önemli?

Bir şirket, müşterilerin satın alma tekliflerini otomatik karşılaştırmasını sağlayacak özellik düşünüyor. Satış ekibi olumlu geri bildirim almış, tasarımcı anlaşılır bir ekran hazırlamış, geliştiriciler örnek dosyalarla çalışan bir gösterim üretmiş. Yönetim, fikrin hazır olduğunu düşünebilir.

Oysa müşteriler farklı dosya biçimleri kullanıyor olabilir. Kullanıcı, rapordaki eksik bilgiyi fark etmeyebilir. Her karşılaştırmanın insan tarafından kontrol edilmesi gerekiyorsa hizmetin maliyeti değişebilir. Olumlu görünen ilk bulgular, bu soruları kendiliğinden cevaplamaz.

Buradaki sorun araştırma yapılmamış olması değildir; araştırmadan çıkarılan sonucun fazla geniş olmasıdır. “Müşteriler sevdi” ifadesi hangi müşteri grubunu ve hangi davranışı anlatıyor? “Teknik olarak çalışıyor” hangi veriyle, hangi koşullarda söyleniyor? Kararın dayandığı kanıtın sınırları belirtilmelidir.

Yönetici açısından yaklaşım, kaynakları en önemli bilinmeyene yönlendirmeyi sağlar. İhtiyaç henüz açık değilse ayrıntılı ekran tasarımını genişletmek erken olabilir. İhtiyaç açık fakat gerekli veri sağlanamıyorsa önce bu bağımlılık araştırılmalıdır. En kolay test edilebilen soruyla en önemli sorunun aynı olması gerekmez.

İş analisti, tasarımcı, mühendis ve ürün sorumlusu farklı bilgi getirir. Bunların ayrı raporlarda kalması yerine aynı karar üzerinde konuşulması önemlidir. Mühendisliğin fark ettiği bir sınır çözüm kapsamını değiştirebilir; kullanıcı gözlemi teknik önceliği yeniden belirleyebilir. İş birliği, bütün risklerin tek kişi tarafından değerlendirilmesini beklemekten daha güçlü bir karar zemini oluşturur.

Terim nedir?

Marty Cagan, Silicon Valley Product Group’un The Four Big Risks yazısında dört risk türünü tanımlar.

Value Risk, yani değer riski: Müşteri çözümü satın alacak mı veya kullanıcı kullanmayı seçecek mi?

Usability Risk, yani kullanılabilirlik riski: Kullanıcı çözümü anlayıp kullanabilecek mi?

Feasibility Risk, yani teknik yapılabilirlik riski: Mühendisler gereken çözümü mevcut süre, yetkinlik ve teknolojiyle geliştirebilecek mi?

Business Viability Risk, yani iş açısından uygulanabilirlik riski: Çözüm şirketin satış, maliyet, sözleşme ve diğer iş koşullarıyla birlikte çalışacak mı?

Cagan’ın yaklaşımında ürün yöneticisi değer ve iş uygulanabilirliğini, tasarımcı kullanılabilirliği, baş mühendis teknik yapılabilirliği ele alır. Bu sorumluluk dağılımı onun ürün takımı modelidir; her kurumda aynı unvanların bulunması gerektiği anlamına gelmez.

Çerçeve kaynağı: Marty Cagan, The Four Big Risks, Silicon Valley Product Group, 4 Aralık 2017.

Product Discovery, yani ürün keşfi, ürün kararları için araştırma ve sınamalarla kanıt üretme çalışmasıdır. Burada yöntem, cevaplanacak soruya göre seçilir. Görüşme kullanım bağlamını anlamaya, prototip ise çözümün belirli yönlerini denemeye yardımcı olabilir. Her yöntemin ürettiği kanıt farklıdır.

Örneğin prototipte görevi tamamlamak, kullanıcının mevcut aracını bırakacağını göstermez. Ücretli seçeneğe tıklamak, gerçekleşmiş ödeme değildir. Bu ayrımlar yöntemi değersiz kılmaz; bulgunun hangi iddiaya destek verdiğini doğru yorumlamayı sağlar.

Riskler birbirini etkileyebilir. Kullanıcıya güven veren bir açıklama, teknik olarak üretilmesi zor bilgiler gerektirebilir. Maliyet sınırı, sunulabilecek kapsamı daraltabilir. Bu nedenle değerlendirme, dört ayrı çalışmanın sırayla tamamlandığı bir onay zinciri gibi uygulanmamalıdır.

Gerçek vaka: Buffer’da ürün öncesi ilgi testi

Buffer’ın kurucusu Joel Gascoigne, 16 Şubat 2011 tarihli yazısında sosyal medya gönderilerini zamanlama fikrini nasıl sınadığını anlatır. Çalışan ürünü geliştirmeden önce fikri açıklayan basit sayfalar hazırlamış ve ilgilenen ziyaretçilerin e-posta adreslerini toplamış.

Sonraki adımda akışa fiyatlandırma sayfası eklemiş. Böylece ziyaretçilerin hangi planları seçtiğini de gözlemlemiş. Bazı kişilerin ücretli planlara tıklaması, geliştirmeye devam etme kararını destekleyen bir işaret olmuş. İlk çalışan ürünün yayımlanması ve ödeme yapan müşteri edinilmesi ise daha sonraki aşamada gerçekleşmiş.

Bu vaka, ilgi ifadesiyle ücretli seçeneğe yönelik davranışın ayrı ele alınmasını gösterir. Ancak fiyatlandırma sayfasına tıklamak, düzenli ödeme veya sürdürülebilir kullanım kanıtı değildir. Kaynak, dört risk yaklaşımının sistematik uygulandığını da söylemez.

Vakayı bu çerçeveyle yorumladığımızda değer varsayımına ilişkin erken bilgi üretildiğini söyleyebiliriz. Kullanılabilirlik, teknik ölçeklenebilirlik ve hizmet maliyeti için aynı testten sonuç çıkaramayız. Yöntemin katkısı, bütün ürünü kanıtlamak yerine belirli bir soruya daha az yatırımla yaklaşmaktır.

Kaynak: Joel Gascoigne, Idea to Paying Customers in 7 Weeks: How We Did It, Buffer, 16 Şubat 2011.

Varsayımsal örnek: Otomatik teklif karşılaştırması

Bir kurumsal yazılım ekibi, satın alma uzmanlarının tedarikçi tekliflerini karşılaştırmasını kolaylaştırmak istiyor. Ürün sahibi, “Dosyaları yükle, en iyi teklifi göster” fikrini doğrudan geliştirme talimatına çevirmiyor. Önce kararın dayandığı varsayımları ekiple birlikte yazıyor.

Değer tarafında, uzmanların yakın tarihli satın alma işlemleri inceleniyor. Karşılaştırmaya ne kadar emek harcadıkları, hangi bilgileri başka kişilerden istedikleri ve mevcut yöntemden neden memnun olmadıkları araştırılıyor. Sorunun bulunması, önerilen otomatik çözümün tercih edileceğini henüz kanıtlamıyor.

Tasarımcı, örnek bir karşılaştırma üzerinden kullanıcıdan karar gerekçesini anlatmasını istiyor. Kullanıcının eksik teslimat koşulunu fark edip etmediği gözleniyor. Ekranda kolay ilerlemekle doğru yorum yapmak ayrı ele alınıyor. Kullanıcı yanlış bir öneriye güveniyorsa yalnızca görev tamamlama sonucu yeterli sayılmıyor.

Geliştiriciler, uygun izinlerle edinilen gerçekçi dosyalar üzerinde teknik inceleme yapıyor. Farklı biçimler ve eksik alanlar değerlendiriliyor. Başarılı tek bir örneğin bütün müşteri belgelerini temsil ettiği varsayılmıyor.

İş tarafında, karşılaştırmalar için insan kontrolü gerekip gerekmediği ve bunun operasyonu nasıl etkilediği konuşuluyor. Sunulacak fiyat, destek yükü ve müşterinin veri paylaşma koşulları ilgili kişilerle ele alınıyor. Henüz veri yokken doğruluk, gelir veya tasarruf oranı yazılmıyor.

İlk kapsam yalnızca belirli teklif türlerine daraltılabilir. Kullanıcıya hangi bilgilerin eksik olduğu açıkça gösterilebilir. Bu karar bütün risklerin ortadan kalktığı anlamına gelmez. Kullanım sonrasında yeni belge türleri veya müşteri ihtiyaçları ortaya çıktığında kanıt yeniden değerlendirilir.

Yaygın üç hata

1. Tek olumlu bulguyla bütün fikri doğrulanmış saymak

Beğeni, kullanım ve ödeme farklı davranışlardır. Test sonucunun hangi iddiayı desteklediğini yazın. Bir alandaki olumlu bulguyu diğer risklere gerekçesiz taşımayın.

1. Teknik gösterimi gerçek hizmetle eşitlemek

Gösterimde veri çeşitliliği, beklenmedik durumlar ve işletim koşulları sınırlı olabilir. Denenen koşulları açıkça kaydedin. Gerçek kullanım için kalan soruların nasıl ele alınacağını belirleyin.

1. İş koşullarını son toplantıya bırakmak

Destek emeği, veri sağlama ve fiyatlandırma çözümü değiştirebilir. İlgili uzmanlıkları karar için gerekli zamanda dahil edin. Önemli bir sınırın ancak geliştirme tamamlandığında ortaya çıkmasını beklemeyin.

Mini uygulama / şablon

Bir çözüm fikri için aşağıdaki alanları doldurun.

Hedef kullanıcı ve problem

—

Önerilen çözüm

—

Değerle ilgili kritik varsayım

—

Kullanılabilirlikle ilgili kritik varsayım

—

Teknik yapılabilirlikle ilgili kritik varsayım

—

İş açısından uygulanabilirlikle ilgili kritik varsayım

—

Mevcut kanıtlar

—

Kararı en fazla değiştirecek bilinmeyen

—

Sınama yöntemi ve katılımcılar

—

İlerleme, değiştirme veya durdurma koşulu

—

Kanıtın sınırları

—

Sonraki değerlendirme zamanı

—

Ardından her varsayımı sınanabilir bir cümleyle ifade edin. “Kullanıcılar sever” yerine hangi kullanıcı grubunda hangi davranışı aradığınızı açıklayın. Görüşleri, gözlemleri ve gerçekleşmiş sonuçları ayrı kaydedin. Yönetim görüşmesinde araştırma sayısını değil, bulguların kararı nasıl değiştirdiğini ve hangi soruların açık kaldığını anlatın.

İlgili terimler

Product Discovery, Value Risk, Usability Risk, Feasibility Risk, Business Viability Risk, Customer Interview, Usability Testing, Prototype, Hypothesis, Assumption Mapping, Minimum Viable Product, Pricing, Unit Economics, Product Owner, Product Manager