Mükemmel ürün diye bir şey yoktur: ekleme, çıkar

Bir kurucuya "ürününü nasıl daha iyi yaparsın" diye sor; cevabı neredeyse her zaman bir liste olur: "Şu özelliği ekleyeceğim, bir de şunu, bir de rakipte olan şu var ya, onu da." İyileştirmek, kafamızda otomatik olarak "eklemek" demektir.

Bu yazıda bunun tam tersini savunacağım. Çünkü tecrübemde gördüğüm en sağlam ürün dersi şu: çoğu zaman ürünü iyileştirmenin yolu bir şey eklemek değil, bir şey çıkarmaktır. Ve "mükemmel ürün" diye bir hedef varsa, o hedef ekleyecek bir şey kalmadığında değil, çıkarılacak bir şey kalmadığında ortaya çıkar.

Antoine de Saint-Exupéry'nin çok alıntılanan bir sözü vardır: "Mükemmellik, eklenecek bir şey kalmadığında değil, çıkarılacak bir şey kalmadığında ulaşılan şeydir." Bu cümle uçaklar için yazılmıştı ama yazılım ürünleri için bundan daha doğru bir şey duymadım.

Neden hep eklemek isteriz?

Çıkarmanın neden zor olduğunu anlamak için, önce eklemenin neden bu kadar cazip olduğuna bakmak gerekir. Birkaç güçlü sebep var:

• Ekleme görünür bir emektir. Yeni bir özellik çıkardığında "çalıştığını" gösterirsin: değişiklik notları dolar, ekran görüntüsü paylaşırsın, ekip "ilerliyoruz" hisseder. Bir özelliği silmek ise dışarıdan tembellik gibi görünür, oysa çoğu zaman daha zor ve daha cesur bir karardır.
• "Müşteri istedi" demek kolaydır. Bir talep geldiğinde "hayır" demek çatışma yaratır; "tamam, ekleriz" demek anı kurtarır. Ekleme, kısa vadede herkesi memnun eden kolay yoldur.
• Rakipte var. Rakibin listesinde bir şey gördüğünde, eksik kalma korkusuyla onu da eklemek istersin. Böylece iki ürün de birbirini taklit ederek şişer.
• Eklemek somut, çıkarmak soyut hisseder. Yeni özelliğin getireceği fayda gözünde canlanır; ama o özelliğin yıllar boyunca yükleyeceği karmaşıklık ve bakım maliyeti görünmezdir. Görünür faydayı, görünmez maliyete tercih ederiz.

Bu sebeplerin hepsi insani ve anlaşılır. Sorun şu ki, her biri seni aynı yöne iter: sürekli büyüyen, sürekli karmaşıklaşan bir ürüne.

Her özelliğin gizli bir bedeli vardır

Bir özelliğin maliyeti, onu yapmak için harcadığın zamanla bitmez. Asıl bedel, o özellik üründe kaldığı sürece ödenir:

• Karmaşıklık. Her yeni özellik, ürünü öğrenmeyi ve kullanmayı biraz daha zorlaştırır. Tek tek hiçbiri büyük görünmez ama toplamları, yeni bir kullanıcının ürünü anlamasını imkânsız hale getirir. Bu doğrudan onboarding ve aktivasyonu vurur: çok seçenek, karar felci demektir.
• Sonsuz bakım yükü. Eklediğin her özellik artık sonsuza dek senindir. Bozulduğunda tamir edersin, başka bir şeyi değiştirdiğinde onu da düşünürsün, dokümanını güncellersin. On özellikli bir ürünün bakımı, beş özellikli bir ürünün iki katı değil, çok daha fazlasıdır.
• Dikkat dağılımı. Kullanıcı ürününe bir iş yapmak için gelir. Önüne ne kadar çok seçenek, buton, menü koyarsan, o asıl işi yapması o kadar zorlaşır. Her ekstra özellik, çekirdek değerin önüne çekilmiş bir perdedir.
• Odak kaybı. Bu en sinsisi. Ekip enerjisi sınırlıdır; her yeni özellik, çekirdeği daha iyi yapmaya gidebilecek zamanı ve dikkati başka yöne çeker. SaaS geliştirirken dikkat edilmesi gerekenleri yazarken de değindiğim gibi, dağılan odak, sessizce en pahalı şeydir.

Eklediğin bir özelliğin maliyetini bir kez ödemezsin; o üründe kaldığı her gün yeniden ödersin.

"Müşteri istedi" tuzağı

Burada en çok yanılınan noktaya gelelim. "Ama müşteri bu özelliği istiyor" cümlesi, en kötü ürün kararlarının arkasındaki en masum gerekçedir.

Gerçek şu: müşteri özellik istemez, problemini çözmek ister. İstediği özellik, o anda aklına gelen, çoğu zaman yanlış ya da geçici bir çözümdür. Eğer müşterinin söylediği özelliği aynen eklersen, yüzeydeki isteği karşılarsın ama altındaki derdi ıskalarsın.

Klasik örnek: müşteriler "daha hızlı at istiyoruz" der; oysa istedikleri hız, ulaşmaktır — ve doğru cevap daha hızlı at değil, otomobildir. İşin daha da inceltici tarafı şu: on farklı müşteri sana on farklı özellik talebiyle gelir, ama altlarını kazdığında çoğunun aynı tek problemi yaşadığını görürsün. Senin işin o on özelliği eklemek değil; hepsinin altındaki tek derdi sade biçimde çözmektir.

Bu yüzden bir özellik talebi geldiğinde tek bir soru her şeyi değiştirir: "Bu sana ne kazandıracak?" Cevap, eklemen gereken özelliği değil, çözmen gereken problemi gösterir. (Bu konuyu bir sonraki yazıda derinleştireceğim: insanların istediğini söylediği şeyle gerçekten yaptığı şey çoğu zaman bambaşkadır.)

Çıkararak iyileştirmek

Peki "çıkarmak" pratikte ne demek? Birkaç somut alışkanlık:

Az ama iyi yapılmış bir çekirdek. MVP'nin temel mantığı buydu: tek bir işi gerçekten iyi yapmak. Ama bu disiplin MVP'den sonra kaybolur; ürün büyüdükçe çekirdek, eklenen onlarca özelliğin altında boğulur. İyi ürün, MVP'den sonra da o çekirdeği korumayı bilir. Bir işi herkesten iyi yapmak, on işi vasat yapmaktan her zaman güçlüdür.

Kullanılmayanı bul ve kaldır. Çoğu üründe özelliklerin küçük bir kısmı kullanımın büyük kısmını taşır; gerisi sadece yer kaplar. Veriye bakıp gerçekten kullanılmayanı tespit etmek ve onu kaldıracak cesareti göstermek, bir ürünü hafifletmenin en doğrudan yoludur.

"Hayır" demeyi bir strateji olarak gör. Her "evet", ürünün gelecekteki karmaşıklığına atılmış bir imzadır. İyi kurucular ekleyebilecekleri yüzlerce şeye hayır der ki, gerçekten önemli olan birkaç şeyi mükemmel yapabilsinler. Hayır demek, ne yaptığını bilmenin işaretidir.

Basitliği bir özellik olarak gör. Sadelik kendiliğinden gelmez; ona ulaşmak için aktif olarak çalışmak gerekir. Bir ürünü basit tutmak, ona on özellik eklemekten çok daha zordur — ve kullanıcının gerçekte değer verdiği şey çoğu zaman tam da budur.

Neyi çıkaracağına nasıl karar verirsin?

Çıkarmak cesaret ister ama kör cesaret değil. Üç süzgeç işini kolaylaştırır:

1. Kullanım süzgeci. Veriye bak. Bir özellik gerçekten kullanılıyor mu, yoksa sadece menüde mi duruyor? Hislere değil, sayılara güven.
2. Çekirdek değer süzgeci. "Bu özellik olmadan ürün asıl işini hâlâ yapar mı?" Cevap evetse, o özellik çekirdek değil, çevredir — ve çevre, çıkarmaya en uygun yerdir.
3. Savunma süzgeci. Her özelliği, kalması için aktif olarak savunmaya zorla. Güçlü bir gerekçe bulamıyorsan, "olsa iyi olur"dan öteye geçemiyorsan, o özellik muhtemelen gitmeli.

Tabii çıkarmak da dikkat ister: birkaç kullanıcının bağlı olduğu bir özelliği kaldırırken etkisini ölç, kullananları önceden uyar, mümkünse bir alternatif bırak. Amaç pervasızca silmek değil; ürünü herkes için sade tutmanın, birkaç kişiyi her ayrıntıda memnun etmekten daha değerli olduğunu kabul etmek.

"Mükemmel ürün" miti

Son olarak en baştaki iddiaya dönelim. "Mükemmel ürün" diye bir varış noktası yoktur; çünkü ürün hiçbir zaman bitmez. Ama ilginç olan şu: kullanıcıya "tamamlanmış", "oturmuş", "rahat" hissettiren ürünler, en çok özellik ekleyenler değil, gereksiz olan her şeyi cesaretle çıkarmış olanlardır.

Mükemmelliğe ekleyerek değil, eleyerek yaklaşırsın. Çünkü ekleyecek şey her zaman vardır — liste sonsuzdur. Asıl ustalık, o sonsuz listeye hayır deyip, geriye sadece gerçekten önemli olanı bırakabilmektir.

Toparlarsak

Ürünü iyileştirmek, çoğu kurucunun sandığının tersine, eklemekle değil çıkarmakla ilgilidir:

1. Hep eklemek isteriz — çünkü ekleme görünür, kolay ve cazip; çıkarma ise zor ve cesaret ister.
2. Her özelliğin gizli bedeli vardır — karmaşıklık, sonsuz bakım, dikkat dağılımı ve odak kaybı.
3. "Müşteri istedi" bir tuzaktır — müşteri özellik değil problem çözümü ister; talebin altındaki gerçek derdi çöz.
4. Çıkararak iyileştir — az ama iyi bir çekirdek, kullanılmayanı kaldırma, strateji olarak "hayır", özellik olarak basitlik.
5. Mükemmellik elemekle gelir — ekleyecek bir şey kalmadığında değil, çıkarılacak bir şey kalmadığında.

Kendi işlerimde defalarca gördüm: bir ürünü kurtaran şey çoğu zaman eklediğim son özellik değil, sonunda silmeye cesaret ettiğim üç özellik oldu. Eklemek kolaydır, herkes yapar. Çıkarmak zordur — ve tam da bu yüzden değerlidir.

Ürünün giderek şişti ve "neyi çıkarmam, neye odaklanmam gerektiğini" netleştirmek istiyorsan, bana ulaşabilirsin — birlikte ürününü sadeleştirelim. Sunduğum hizmetlere de göz atabilirsin.