Özellik Yığınından Çekirdeğe: Ürünü Ayakta Tutan Şey

Yeni bir üründe en zor iş özellik eklemek değil, eklememeye karar vermek. Piyasadan silinen ürünlerin çoğu eksik oldukları için değil, ne işe yaradıkları anlaşılmadığı için siliniyor. Sorulacak soru da bu yüzden başka ne ekleyelim değil: kullanıcı bu ürünü hatırladığında aklına gelen tek iş ne?

Özellik eklemek neden bu kadar kolay geliyor

Bir sorun görürsün, çözümü bellidir, ekip iki haftada yapar. Yol haritasına satır eklemek görünür bir iş, satır silmek görünmez. Toplantıda bunu da ekleyelim diyen kişi katkı yapmış sayılır, bunu yapmayalım diyen kişi engel çıkarmış sayılır. Kurumsal ürünlerdeki özellik yığılmasının asıl kaynağı kullanıcı talebi değil, bu asimetri.

Finans uygulamaları bunun en görünür örneği. Ekranların çoğu müşteri bir işi bitirsin diye değil, şirket içindeki departmanlar kendini gösterebilsin diye orada. Ortaya çıkan şey de ürün olmuyor, organizasyon şemasının ekrana yansıması oluyor.

Asıl maliyet arayüzde değil

Özellik yığmanın bedeli genelde arayüz karmaşıklaşır diye anlatılır. Bu, maliyetin küçük tarafı. Kullanıcının açıp kapatabildiği her bağımsız ayar, ürünün içinde bulunabileceği durum sayısını ikiye katlar. On tane böyle ayar 1024 kombinasyon demek, on beş tane 32 binden fazla. Kimse bu kombinasyonların tamamını test etmiyor, edemez de. Test edilen birkaç yaygın yolun dışında kalan her şey, bir kullanıcı şikayet edene kadar bozuk kalıyor.

O yüzden ekleyelim, sevmezlerse kaldırırız cümlesi pratikte pek işlemiyor. Ekleme maliyeti bir defalık, taşıma maliyeti sürekli. Kaldırma ise en pahalısı, çünkü o özelliği kullanan az sayıda insan bu kez haklı olarak kızıyor.

Temel taş metaforu tek başına karar verdirmez

Temel taş, ürünün kullanıcı için gerçekten değerli olan çekirdek parçası diye tanımlanır. Kulağa doğru geliyor ama bu haliyle hiçbir tartışmayı bitirmiyor: her ekip kendi sevdiği özelliğin çekirdek olduğunu düşünür. Metaforu işe yarar hale getiren şey, sınanabilir bir soruya çevrilmesi.

Ürünün çekirdeği, kaldırdığında kullanıcının ürünü kullanmayı bıraktığı şey. Gerisi destek. Bu soruyu ekipteki herkese ayrı ayrı sor, cevapları yan yana koy. Üç farklı cevap çıkıyorsa henüz bir çekirdeğin yok, birbirine yapıştırılmış üç ürünün var.

MVP küçültülmüş ürün değildir

MVP çoğu yerde aynı ürünün az özellikli hali diye anlaşılıyor. Daha işe yarar tanımı şu: kullanıcının o işi gerçekten yapmak isteyip istemediğini ölçen en ucuz kurulum. Ölçüm yoksa elde MVP yok, yarım ürün var.

Ölçmek için gereken şeyler zaten mütevazı. Hangi ekran kaç kez açılmış, iş kaç adımda bitiyor, kaçı yarıda bırakılmış. Bir özelliği savunmadan ya da silmeden önce üç soruya bak:

• Son üç ayda kaç farklı kullanıcı bu özelliğe dokundu?
• Dokunmayanlar ürünü bırakıyor mu, yoksa varlığından haberleri bile yok mu?
• Kaldırırsak hangi destek talebi artar, hangisi azalır?

Kayıtlara bakmadan yapılan özellik tartışmaları uzuyor, çünkü herkes kendi sezgisini savunuyor. Sayı masaya gelince tartışma genelde beş dakikada bitiyor.

Kısa vadeden vazgeçmenin gerçek bedeli

Çekirdeğe odaklanmak, kısa vadeli büyümenin bir kısmından vazgeçmek demek. Özellik listesi uzun olan rakip demoda daha iyi görünür, ihale tablosunda daha çok kutucuk işaretler. Bu gerçek bir kayıp ve uzun vadede kazanırsın demek tek başına yeterli bir cevap değil.

Ayrımı şuraya koyuyorum: eklenen özelliğin bakım yükünü kim taşıyor. Satışın istediği ama bir daha kimsenin açmadığı ekran, her sürümde regresyon testine, her kütüphane güncellemesinde tamire, her yeni geliştiriciye anlatılmaya devam ediyor. Bu yükü taşıyan ekip ile o özelliği isteyen ekip aynı değilse, ürün büyümez, sadece şişer.