Product Thinking: Özellik Listesinden Probleme Dönmek
Product thinking, bir ürünü özellik listesiyle değil çözdüğü problemle tanımlama alışkanlığıdır. Fark küçük görünür ama masadaki soruyu değiştirir: “bu ekrana filtre koyalım mı” yerine “kullanıcı burada neyi bulamıyor” sorulur. Ekiplerin çoğu ikinci soruyu atlayıp doğrudan birincisine geçtiği için ürünler şişer, kimsenin açmadığı menüler birikir.
Önce problem, sonra ürün
Bir ürünün var olma sebebi, birinin işini yaparken takıldığı yerdir. O yüzden ilk soru “ne yapalım” değil, “kim, ne yaparken, neden takılıyor” olmalı. Bu cevap yoksa geliştirilen her özellik tahmine dayanır.
İyi bir problem tanımı üç şeyi netleştirir: kim yaşıyor, ne sıklıkta yaşıyor, şu an bunu nasıl idare ediyor. Üçüncüsü hem en çok atlanan hem de en çok bilgi taşıyan kısım. İnsanların soruna karşı geliştirdiği geçici çözüm, yani elle güncellenen bir Excel dosyası, WhatsApp grubuna atılan not, iki sistem arasında kopyala yapıştır, size hem problemin gerçekten yaşandığını hem de çözümünüzün ne kadar iyi olması gerektiğini söyler. Kimse kendi kurduğu düzeni daha kötüsü için bırakmaz.
Çıktı ile sonuç karıştığında
Ürün odaklı düşünmeyi anlatan metinlerin çoğu şöyle bir sıra verir: problemi anla, hedef kitleyi tanımla, değer önerisini yaz, stratejiyi kur, hedeflenen çıktıları belirle. Son adım sessizce ilk cümleyi çürütür. Sürecin sonunda yine bir fonksiyon ve ekran listesi duruyorsa özellik odaklılıktan çıkılmış olmuyor, sadece o listeye varmadan önce dört slayt daha ekleniyor.
Ayrımı taşıyan şey sürecin son adımıdır. Çıktı, ekibin ürettiği şeydir: ekran, uç nokta, rapor. Sonuç, kullanıcının davranışında ölçülen değişimdir: destek talebi açan kullanıcı oranı, ilk siparişe kadar geçen süre, ikinci kez giriş yapma oranı. Sona çıktı yazarsanız ekip teslim ettiği gün kutlar. Sona sonuç yazarsanız teslimattan iki hafta sonra sayıya bakmak zorunda kalır, ki asıl öğrenme oradadır.
Özellik isteği geldiğinde
İstekler genelde problem olarak değil, çözüm kılığında gelir: “şuraya toplu dışa aktarma ekleyin”. Bir özellik isteğini doğrudan backlog'a yazmam, önce o isteğin arkasındaki işi sorarım. Toplu dışa aktarma isteyen kişi çoğu zaman veriyi dışarı almak istemiyor, ayda bir muhasebeye gönderdiği tabloyu hazırlamak istiyor. Aradaki fark iki haftalık bir dışa aktarma modülüyle iki günlük hazır bir rapor arasındaki farktır, üstelik ikincisi kullanıcının işini birincisinden daha iyi bitirir.
Her iş ürün problemi değil
Bu yaklaşımın abartıldığı bir yer var: bazı işler gerçekten sadece iştir. Rakipte olan bir entegrasyon sizde yoksa, bunun derin kullanıcı araştırmasıyla açıklanacak tarafı yok. Mevzuat gereği eklenen alanlar da kimsenin hayatını kolaylaştırmaz, sadece ürünü satılabilir tutar. Bunları da problem hikâyesine çevirmeye çalışmak süreci tiyatroya döndürür.
Çizgi şuradan çekilebilir: eklemezseniz ürünün satılamayacağı şeyler zorunludur, geri kalan her şey tartışmaya açıktır. Tartışmaya açık kısımda arkasında problem olmayan özelliğe hayır diyebilmek, product thinking'in günlük hayattaki tek somut karşılığıdır.