Output Değil Outcome: Problem Tanımı, Hipotez ve Jobs to Be Done

Sürüm notu: Bu yazı kavramsaldır; outcome tanımı için Joshua Seiden'ın "Outcomes Over Output" (2019) kitabı, Jobs to Be Done için Clayton Christensen'ın çalışmaları esas alınmıştır.

Önce Tahmin Et

Bookstore'un analytics ekranında bir sayı var: son dört haftada sepete kitap ekleyen ziyaretçilerin %66,7'si siparişi tamamlamadan çıkmış. Genel müdür toplantıda çözümü hemen söylüyor: "Tek tıkla ödeme yapalım. Amazon'da var, bizde neden yok?" Ekip bir sonraki çeyreğin planına "One-click checkout" diye bir epic yazıyor.

Üç soru: Tek tıkla ödeme sepet terk oranını düşürür mü? Bunu bilmek için şu an elimizde hangi bilgi var? Bir de şunu düşün: sepete kitap ekleyip çıkan bu ziyaretçilerin kaçı zaten kayıtlı ve kartı kayıtlı bir müşteri? Eğer çoğu ilk kez gelen misafir kullanıcıysa, "tek tık" onlara ne ifade eder?

Output, Outcome, Impact

Bu yazının merkezindeki ayrım üç kelimeden oluşuyor ve biri diğerinin sonucu:

Output ekibin ürettiği şeydir: bir feature, bir ekran, bir endpoint. "Guest checkout production'da" bir output'tur ve ekibin kontrolündedir; istersen yarın teslim edebilirsin. Outcome, bu output'un sonucunda insanların davranışının değişmesidir. Joshua Seiden "Outcomes Over Output" kitabında outcome'u iş sonuçlarını hareket ettiren insan davranışı değişikliği olarak tanımlar. "Sepet terk oranı %66,7'den %60'a indi" bir outcome'dur; ekip bunu etkileyebilir ama doğrudan kontrol edemez, çünkü sonuçta müşteri karar verir. Impact ise outcome'un iş üzerindeki etkisidir: gelir, kâr, pazar payı. Aylık online gelirin artması bir impact'tir ve kampanyalardan döviz kuruna kadar ekibin dışındaki birçok etkenden etkilenir.

Bir ekibe hedef verirken hangi seviyeyi seçtiğin, ekibin nasıl çalışacağını belirler. Output hedefi ("ilk çeyrekte one-click checkout'u teslim et") ekibi teslim etmeye odaklar ve teslimden sonra kimse sonuca bakmaz; bu, önceki yazıdaki feature factory'nin tarifidir. Impact hedefi ("online geliri %10 artır") ise ekibin günlük kararlarıyla bağlantısı kurulamayacak kadar uzaktır. Outcome seviyesi ikisinin arasında, ekibin hem etkileyebileceği hem de ölçebileceği yerdedir.

Output'u Hedeflemek Neden Bu Kadar Cazip?

Çünkü output kolay görünür, kolay ölçülür ve kolay kutlanır. "One-click checkout'u teslim ettik" bir sprint review'da gösterilebilir; "sepet terk oranı üç puan düştü" ise haftalarca veri bekler ve belki hiç gerçekleşmez. Yöneticiler de çoğu zaman çözüm söylemeye alışkındır: bir problemi tarif etmek yerine aklındaki çözümü talep etmek, daha net bir talimat gibi gelir.

Bunun bedeli, yanlış çözümü doğru şekilde inşa etmektir. One-click checkout kart bilgisi kayıtlı müşteriler için tasarlanmış bir çözümdür. Eğer sepeti terk edenlerin çoğu ilk kez gelen misafirlerse ve asıl dertleri son adımda gördükleri kargo ücretiyse, ekip bir çeyrek boyunca güzel bir feature inşa eder ve sepet terk oranı yerinden kıpırdamaz. Daha kötüsü, kimse bunu fark etmez; çünkü hedef output'tu ve output teslim edildi.

İyi Bir Problem Tanımı

Outcome'a odaklanmanın ilk adımı problemi çözümden ayırmaktır. İyi bir problem tanımı dört şey söyler ve hiçbir çözüm içermez: kim (hangi kullanıcı segmenti), hangi durumda, ne oluyor (gözlemlenen davranış ve kanıtı) ve bunun bedeli ne.

Kötü örnek: "Müşterilerimiz tek tıkla ödeme yapamıyor." Bu aslında bir problem değil, bir çözümün yokluğudur; içinde çözüm saklıdır. İyi örnek: "Sepete kitap ekleyen ziyaretçilerin %66,7'si son dört haftada siparişi tamamlamadan çıktı. Terk oranı misafir kullanıcılarda %72,1, kayıtlı müşterilerde %56,3; terklerin yaklaşık %60'ı daha ödeme adımına geçmeden, sepette oluyor. Her üç puanlık iyileşme, mevcut trafikle dört haftada yaklaşık 155 ek sipariş demek."

İkinci tanım hiçbir çözüm söylemiyor, ama çözüm alanını daraltıyor: sorun misafirlerde daha büyük ve çoğu kişi ödeme adımını görmeden vazgeçiyor. Son cümle problemin neden önemli olduğunu sayıyla söylüyor; prioritization yazısında bu tür sayıların nasıl kullanılacağını göreceğiz. Bu cümlelerdeki sayılar (son dört haftanın sepet ve sipariş sayıları) 07. yazıda event verisinden SQL (Structured Query Language) ile hesaplayacağımız funnel'ın çıktısı; o zamana kadar onları ekibin analytics ekranından okunmuş kabul et.

Hipotez Formatı

Problem tanımlandıktan sonra her çözüm fikri bir hipotez olarak yazılır. Yaygın bir format şöyledir: "[Bu değişikliği] yaparsak, [bu kullanıcılar] için [bu metric'in] [bu yönde, bu kadar] değişeceğine inanıyoruz; bunu [bu ölçümle], [bu süre içinde] doğrulayacağız."

Bookstore için bir örnek: "Kargo ücretini ürün sayfasında ve sepette, ödeme adımından önce gösterirsek, misafir kullanıcılar için sepet terk oranının en az üç puan düşeceğine inanıyoruz; bunu sepete ekleme ile sipariş arasındaki funnel'la, dört hafta içinde ve ortalama sepet tutarının düşmediğini kontrol ederek doğrulayacağız."

Bu cümlenin her parçasının bir işi var. "İnanıyoruz" kelimesi bunun bir bilgi değil, bir tahmin olduğunu kabul eder. Kullanıcı segmenti, sonucu kimde arayacağını söyler. Metric ve büyüklük, hipotezi yanlışlanabilir kılar: üç puan düşmezse hipotez çürümüştür. Süre, sonsuza kadar beklemeyi engeller. Son kısım ise bir guardrail'dir: sepet terkini düşürürken ortalama sepet tutarını düşürmek istemiyoruz. Guardrail metric'lerini 06. yazıda açacağız.

Aynı problem için birden fazla hipotez yazmak iyi bir alışkanlıktır: "zorunlu üyelik adımını kaldırırsak", "kayıtlı müşteriler için kart bilgisini saklarsak". Genel müdürün one-click checkout fikri de bu listede bir hipotez olarak yer alır; tek fark, artık diğerleriyle aynı kurallarla değerlendirilecek olmasıdır.

Jobs to Be Done

Problemi doğru tanımlamanın bir yolu, müşterinin neyi satın aldığını değil, neyi başarmaya çalıştığını sormaktır. Clayton Christensen'ın Jobs to Be Done (JTBD) fikri bunu söyler: insanlar ürünleri belirli bir durumda belirli bir ilerleme kaydetmek için "işe alır". Christensen'ın en bilinen örneğinde sabah işe giderken milkshake alan insanlar aslında bir içecek değil, uzun ve sıkıcı bir araba yolculuğunu doyurucu ve tek elle yapılabilir bir şeyle geçirmeyi satın alıyordu; milkshake'in rakibi başka bir milkshake değil, muz ve simitti.

Bookstore'da kitap satın alan biri her zaman "kitap" satın almıyor. Bir kısmı yarın doğum günü olan bir arkadaşına hediye arıyor, bir kısmı üniversitenin ders listesindeki kitapları dönem başlamadan tamamlamaya çalışıyor, bir kısmı da okuma listesindeki bir sonraki romanı. Aynı ödeme adımı, bu üç iş için çok farklı şeyler ifade eder. Hediye arayan için asıl soru teslim tarihidir; ders kitabı arayan için toplam maliyet ve kargo.

Job Story ve User Story

JTBD fikrini backlog'a taşımanın bir yolu job story formatıdır: "When [durum], I want to [motivasyon], so I can [beklenen sonuç]." Türkçe karşılığıyla: "Arkadaşımın doğum günü yarın olduğunu son anda hatırladığımda, bir kitabı teslim tarihini görerek hızlıca sipariş etmek istiyorum, böylece hediyem zamanında ulaşır."

Klasik user story ise genellikle "[Rol] olarak, [bir şey] istiyorum, böylece [fayda]" biçimindedir: "Müşteri olarak hızlı ödeme yapmak istiyorum, böylece zaman kazanırım." İki format arasındaki fark durumdadır. User story bir rolden başlar ve rol çoğu zaman "müşteri" kadar geniştir; job story ise bir durumdan başlar ve durum, çözümü en çok şekillendiren bilgidir. Yukarıdaki job story'yi okuyan bir ekip "teslim tarihini ödeme adımından önce göster" fikrine kendiliğinden gelir; user story'yi okuyan ekip ise one-click checkout'a.

Bu bir format savaşı değil. Birçok ekip ikisini birlikte kullanır: job story'ler discovery'de problemi anlamak için, user story'ler delivery'de backlog item'ı yazmak için. User story, use case ve acceptance criteria'nın ayrıntısı ilerideki Requirements Analysis serisinin konusu; bu seri oraya girmiyor.

Sepet Terk Problemini Çerçevelemek

Şimdi baştaki toplantıya geri dönelim ve problemi çözüme atlamadan çerçeveleyelim. Ekibin elindeki bilgi şu: terk oranı %66,7; misafirlerde %72,1, kayıtlı müşterilerde %56,3; terklerin yaklaşık %60'ı ödeme adımından önce. Elinde olmayan bilgi ise neden olduğu. Bu yüzden ilk iş bir çözüm seçmek değil, "neden?" sorusuna cevap aramak.

Ekip üç kaynağa bakmaya karar veriyor. Birincisi veri: funnel'ı kullanıcı segmentine (misafir, kayıtlı) ve terkin gerçekleştiği adıma göre bölmek. İkincisi destek talepleri: "sipariş veremiyorum" ve "kargo ücreti" geçen son üç ayın kayıtları. Üçüncüsü müşteriler: önümüzdeki iki hafta içinde, son ay sepetini terk etmiş altı müşteriyle kısa görüşmeler. Bu üç kaynaktan çıkan her "neden", sonraki yazıda Opportunity Solution Tree'nin bir dalı olacak.

One-click checkout fikri çöpe gitmedi; hipotezler listesinde duruyor. Ama artık ekip onu "genel müdür istedi" diye değil, kanıtla değerlendirecek. Ve ilk bakışta, sepet terkinin çoğu misafirlerde olduğuna göre, kayıtlı ve kart bilgisi saklı müşterilere hitap eden bir çözümün listenin başında olmayacağı görülüyor.

Üretimde Dikkat

Outcome'u ölçemiyorsan, onu hedef olarak koyamazsın. "Sepet terk oranını düşür" hedefinin anlamlı olması için önce bugünkü değerin güvenilir biçimde hesaplanması gerekir: hangi event'ler, hangi zaman penceresi, misafir ve kayıtlı kullanıcı nasıl ayrılıyor. Bu tanımı yazmadan hedef koymak, sonra "bizim hesabımıza göre düştü" tartışmasına davetiye çıkarır.

Outcome'lar yavaş hareket eder. Bir output'u teslim ettiğin gün outcome değişmez; haftalarca veri gerekir. Bu yüzden hipotezde süreyi baştan yaz ve o süre dolmadan sonuç ilan etme. Deneyle karar vermeyi 08. yazıda, istatistiksel tuzaklarıyla birlikte konuşacağız.

Outcome hedefi tek başına bırakılırsa yan etki üretir. Sepet terkini düşürmenin en kolay yolu, sepete eklemeyi zorlaştırmaktır: daha az kişi sepete ekler, ekleyenler zaten almaya kararlıdır, oran düzelir. Bu yüzden her outcome hedefinin yanında en az bir guardrail metric olmalı.

Sık Düşülen Tuzaklar

İlk tuzak çözümü problem diye yazmak. "Kullanıcılar arama sonuçlarını filtreleyemiyor" cümlesi bir problem gibi görünür ama içinde filtre çözümü saklıdır. Gerçek problem belki "kullanıcılar aradıkları kitabı ilk sayfada bulamıyor"dur ve çözümü filtre değil, daha iyi bir sıralamadır.

İkinci tuzak outcome yerine aktivite saymak. "Kargo ücretini gösteren banner 40.000 kez görüntülendi" bir outcome değildir; kimsenin davranışının değiştiğini söylemez. Görüntülenme, tıklama, açılma gibi sayılar outcome'a giden yolda ara sinyallerdir.

Üçüncüsü hipotezi yanlışlanamaz yazmak. "Kargo ücretini göstermek kullanıcı deneyimini iyileştirecek" cümlesi asla yanlış çıkmaz, çünkü neyin, ne kadar değişeceğini söylemez. Bir hipotez, gerçekleşmezse onu çürütecek bir sayı içermeli.

Dördüncüsü JTBD'yi persona ile karıştırmak. "35 yaşında, İstanbul'da yaşayan, polisiye seven Ayşe" bir personadır; JTBD ise Ayşe'nin bu akşam neyi başarmaya çalıştığıyla ilgilenir. Aynı kişi bir gün hediye, bir gün ders kitabı alır; işi değişir, kişi değişmez.

Küçük Bir Deneme

★☆☆ Ekibinin backlog'undaki ilk beş item'ı oku ve her birinin bir output mu yoksa bir outcome mu tarif ettiğini işaretle. Output olanlardan biri için arkasındaki outcome'u bir cümleyle yaz.

★★☆ Ürünündeki bir problem için bu yazıdaki dört parçalı problem tanımını yaz: kim, hangi durumda, ne oluyor (sayıyla), bedeli ne. İçinde çözüm kalmadığından emin ol; bir arkadaşına okut ve hangi çözümü ima ettiğini sor.

★★★ Aynı problem için üç farklı hipotez yaz, her biri bu yazıdaki formatta: değişiklik, segment, metric ve büyüklük, ölçüm ve süre, guardrail. Hangisinin en ucuz test edilebilir olduğunu tartış.

Problemi çözümden ayırdık ve hipotez yazmayı öğrendik. Bir sonraki yazıda "neden?" sorusunun cevabını aramaya çıkıyoruz: continuous discovery'yi, iyi bir müşteri görüşmesinin nasıl yapıldığını ve sepet terk problemini Opportunity Solution Tree ile nasıl haritalandıracağımızı göreceğiz.