30 saniyelik özet
Opportunity Solution Tree, hedeflenen sonuç ile müşteri ihtiyaçlarını, çözüm seçeneklerini ve varsayım testlerini ilişkilendiren fırsat–çözüm ağacıdır. Ekibin düşüncesini görünür hale getirir: Neyi değiştirmek istiyoruz, müşterinin hangi ihtiyacı buna bağlanıyor, hangi seçenekleri değerlendiriyoruz ve hangi belirsizliği önce sınayacağız? Product Owner, yani ürünün değerini artırmaktan sorumlu rol, bu bağlantıları ekiple birlikte sorgulayarak geliştirme önceliklerini gerekçelendirebilir. Ağacın değeri kutuların sayısında değil, kararın dayandığı kanıtı ve alternatifleri açıklayabilmesindedir.
Neden önemli?
Bir ürün toplantısında satış ekibi yeni bir entegrasyon, destek ekibi ekran değişikliği, yönetici ise rakipte gördüğü bir özelliği isteyebilir. Her talep kendi bağlamında anlamlıdır. Ancak bunları doğrudan geliştirme listesine eklemek, hangi müşteri ihtiyacının öncelikli olduğunu açık bırakır. Ekip çok iş teslim ederken hedeflenen davranış değişmeyebilir.
Fırsat–çözüm ağacı, bu taleplerin arkasındaki gerekçeyi konuşmak için ortak zemin sağlar. Bir entegrasyon talebi, müşterinin aynı bilgiyi farklı sistemlere tekrar girmesiyle ilgili olabilir. Ekran değişikliği talebi de aynı işin başka bir aşamasındaki karışıklığı yansıtabilir. İhtiyaç görünür olduğunda çözüm seçenekleri genişler; talebi yerine getirmek ile müşterinin işini kolaylaştırmak arasındaki ilişki daha iyi değerlendirilir.
Yöneticiler açısından bu ayrım kaynak tahsisini kolaylaştırır. Bir fikrin ertelenmesi, onu öneren kişinin görüşünün değersiz olduğu anlamına gelmez. Ekibin başka bir ihtiyacı hedeflemesi veya mevcut kanıtı yetersiz bulması söz konusu olabilir. Gerekçenin görünür olması, tartışmayı kişisel iknadan çıkarıp kararın dayanaklarına taşır.
Bununla birlikte ağaç, bütçe veya kapasite kararını kendiliğinden vermez. Bağımlılıklar, operasyon yükü ve stratejik zorunluluklar ayrıca değerlendirilir. Araç, bu kararların yerine geçmeden hangi müşteri faydasını beklediğimizi ve neden o seçeneğe yatırım düşündüğümüzü açıklamaya yardımcı olur. Junior bir analist için de önemli katkı, hazır talebi yazmanın ötesine geçerek talebin hangi deneyimden doğduğunu araştırabilmektir.
Terim nedir?
Teresa Torres’in geliştirdiği yöntemde ağacın üstünde outcome bulunur. Outcome, teslim edilen özellikten farklı olarak ulaşılmak istenen sonuçtur. Bunun altında müşterinin karşılanmamış ihtiyaçları, yaşadığı güçlükler veya istekleri yer alır; bunlar fırsatları oluşturur. Fırsatların altında çözüm seçenekleri, onların altında ise seçeneklerin dayandığı varsayımları sınayan testler gösterilir.
Örneğin bir düğme eklemek çözümdür; kullanıcının bir işlemin tamamlanıp tamamlanmadığını anlayamaması fırsat olabilir. Ayrım, aynı ihtiyacın farklı yollarla karşılanmasını düşünmeye alan açar. Yöntem, müşteri anlatılarıyla beslenen ve öğrenildikçe güncellenen ortak bir çalışma aracıdır.
Ağaç bir yol haritası değildir. Yol haritası ürünün yönünü ve planlanan ilerlemeyi anlatırken ağaç, hedefe ulaşmak için değerlendirilen seçenekleri ve öğrenme ihtiyacını görünür kılar. Bir seçeneğin ağaçta bulunması, geliştirme taahhüdü verildiği anlamına gelmez.
Kavramsal kaynak: Teresa Torres, Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes, Product Talk, 6 Aralık 2023.
Gerçek vaka: CarMax’ın müşteri ihtiyaçlarını ortak bir ağaca taşıması
Product Talk’ın 12 Eylül 2018 tarihli vaka yazısı, CarMax’ın dijital araç tanıtım deneyimi üzerinde çalışan ekibiyle yapılan görüşmeye dayanır. Görüşmeye ürün yöneticisi Victoria Lawson, tasarımcı Jake Mitchell ve teknik lider Sri Arcot katılır.
Ekip, müşteri görüşmeleri ve deneylerle zaten çalıştığını, ancak elde ettiği bilgileri ve çözüm seçeneklerini daha düzenli ilişkilendirmeye ihtiyaç duyduğunu anlatır. Mitchell, ağacın ekibin odağını ve değerlendirdiği fırsatları ortak bir görselde topladığını belirtir. Lawson, bir sonraki fırsatı seçerken ağacı kullandıklarını aktarır.
Arcot’un anlattığı değişim özellikle önemlidir: Mühendislik bakış açısıyla çözüme hızla geçme eğilimi yerine, önce fırsatları belirleyip tartışmaya daha fazla dikkat edilir. Görüşmede deneylerin tek tek varsayımları sınayacak biçimde tasarlanması da ele alınır.
Bu anlatıdan çıkarılabilecek ders, müşteriyle konuşmanın tek başına önceliklendirme sorununu çözmediğidir. Toplanan bilginin karar sürecinde nasıl kullanılacağı da tasarlanmalıdır. Vaka, ekip üyelerinin deneyimlerini aktarır; ağacın tek başına yarattığı sayısal bir ticari etkiyi ölçen çalışma olarak okunmamalıdır.
Varsayımsal örnek: Tedarikçi seçiminin kolaylaştırılması
Kurumsal satın alma taleplerini yöneten bir platformun ekibi, teklif alan şirketlerin uygun tedarikçiyi seçerek süreci tamamlamasını kolaylaştırmak ister. Yönetim toplantısında otomatik teklif karşılaştırması önerilir. Ürün sahibi bu fikri kaydeder ve satın alma uzmanlarının yakın zamanda tamamladıkları veya yarım bıraktıkları seçim süreçlerini araştırır.
Görüşmelerde farklı güçlükler ortaya çıkar: Bazı teklifler teslimat koşullarını açık yazmaz, bazı teklifler aynı kapsamı içermez, bazı kararlar ise şirket içindeki onay sorumlusuna ulaşamaz. Ekip bunları ayrı fırsatlar olarak ele alır. Otomatik karşılaştırma, bütün güçlükleri aynı anda çözecek hazır cevap kabul edilmez.
İlk odak, teklif kapsamlarının anlaşılmamasıdır. Bu fırsat için standart teklif formu, eksik kapsamı işaretleyen kontrol ve teklif hazırlarken verilen açıklayıcı rehber değerlendirilir. Her seçeneğin dayandığı varsayım farklıdır. Standart formun işe yaraması, tedarikçilerin gerekli bilgiyi doğru alanlara girebilmesine bağlıdır. Kontrolün işe yaraması ise eksikliğin güvenilir biçimde saptanabilmesini gerektirir.
Ekip, standart formun basit bir taslağını tedarikçilere kullandırır; hangi alanların yanlış anlaşıldığını gözlemler. Satın alma uzmanlarından da hazırlanan tekliflerle seçim görevini tamamlamalarını ister. Formun doldurulabilmesi ve tekliflerin karşılaştırılabilmesi ayrı gözlemler olarak kaydedilir. Bir tarafın rahat kullanması, diğer tarafın karar verebildiğini göstermeyebilir.
Öğrenme, otomatik karşılaştırmaya yatırım yapmadan önce veri toplama biçiminin değiştirilmesi gerektiğini gösterebilir. Sonraki karar buna göre güncellenir. Ürün sahibi geliştirme işini, formu yayımlamakla sınırlı tanımlamaz; hangi kapsam belirsizliğinin azalmasını beklediklerini ve bunu nasıl izleyeceklerini de açıklar. Teslim edilen çözümden sonra gerçek seçim davranışı izlenerek ağacın başlangıcındaki hedefe dönülür.
Yaygın üç hata
- İhtiyaç yerine özellik adı yazmak
“Karşılaştırma ekranı yok” ifadesi ekibi belirli bir çözüme bağlar. Kullanıcının son kararında neyi anlayamadığını araştırmak daha açıklayıcıdır. Özellik talebi görüşme için başlangıç olabilir; arkasındaki ihtiyaç araştırılmadan ağaca fırsat olarak yerleştirilmemelidir.
- Çizimi kanıt yerine koymak
Dalların düzenli görünmesi, aralarındaki ilişkinin doğrulandığını göstermez. Bir müşteri anlatısı ihtiyacı anlamaya yardımcı olur; bütün müşteri grubundaki yaygınlığını tek başına açıklamaz. Görüşme, kullanım verisi ve ekip yorumu birbirinden ayırt edilmelidir. Belirsiz bir ilişki, kesinleşmiş bilgi gibi sunulmamalıdır.
- Her dalı geliştirme sözüne dönüştürmek
Ağaçtaki bütün çözümleri iş listesine taşımak, alternatif üretmenin amacını zayıflatır. Bir seçenek öğrenmek için tutulabilir, bir diğeri yeni kanıtla elenebilir. Paydaşlara hangi dalın araştırıldığını, hangisinin geliştirme kararı aldığını ve hangisinin beklediğini açıkça anlatmak gerekir.
Mini uygulama / şablon
- Hedeflenen sonuç ve ölçüm tanımı
- —
- İlgili müşteri veya kullanıcı grubu
- —
- Araştırılan deneyim aşaması
- —
- Müşterinin yaşadığı ihtiyaç veya güçlük
- —
- Bu ihtiyacı destekleyen gözlem ve kaynağı
- —
- Hedefle ilişkisinin gerekçesi
- —
- Henüz bilinmeyen noktalar
- —
- Değerlendirilen çözüm seçenekleri
- —
- Her seçenek için kritik varsayım
- —
- Varsayımı sınayacak görev veya gözlem
- —
- Kararı değiştirecek bulgu
- —
- Geliştirme kararı ve gerekçesi
- —
- Teslimat sonrası izlenecek davranış
- —
- Son güncelleme ve sorumlu
- —
Şablonu doldururken önce tek bir müşteri deneyimine odaklanın. Çözüm seçeneklerini aynı ihtiyaca bağlayıp karşılaştırın. Ardından kararı en fazla etkileyen belirsizliği seçin ve bunu öğrenmek için gereken en küçük çalışmayı planlayın. Toplantı sonunda yalnızca tercih edilen fikri değil, neden seçildiğini ve hangi kanıt geldiğinde yeniden değerlendirileceğini de kaydedin. Böylece sonraki görüşme önceki kararı savunmaya değil, yeni bilgiyle güncellemeye hizmet eder.
İlgili terimler
Outcome, Product Discovery, Continuous Discovery, Customer Interview, Opportunity Mapping, Assumption Testing, Product Backlog, Roadmap, Product Goal, Prioritization