MVP için Hangi Özellikler Seçilmeli? Kapsamı Doğru Belirlemek için Kurucu Rehberi

MVP için hangi özelliklerin seçileceği, erken aşama kurucuların önünde en çok yığılan sorulardan biri. Elinizde bir fikir var, işe yarayabileceğini biliyorsunuz; ama önünüzde elli maddelik bir özellik listesi var ve neyi kesmeniz gerektiğine dair net bir ilkeniz yok. Her özellik önemli görünüyor, her biri için mantıklı bir gerekçe var. Bu rehber, bütçeniz bitmeden önce — geliştirme başlamadan — o kararları kararlılıkla verebilmeniz için somut bir çerçeve sunuyor.

##MVP Kapsam Hatası: Neden Çoğu İlk Sürüm Fazla Büyük Başlıyor

En yaygın MVP hatası az göndermek değil, çok fazla göndermek. Çoğu kurucu özellik listesini bir pazarlık olarak ele alıyor: 'Bunu keseriz ama bunu kesemeyiz.' Sonuç, sekiz şeyi yeterince yapan ama hiçbirini birisini ödemeye ikna edecek kadar iyi yapmayan bir ürün oluyor. MVP'nin amacı etkilemek değil; belirli bir pazar varsayımını mümkün olan en düşük maliyet ve süreyle test etmek. Bunu test etmeye hizmet etmeyen her şey — ileride ne kadar faydalı olursa olsun — fazladan yüktür. Ve bu yük, zaman ve para olarak geri döner.

Kapsam kayması çoğunlukla erken aşamada başlar: 'Şimdi ekleyelim, sonradan zor olur' mantığı. Bu düşünce kalıbı, tek başına yüzlerce saatlik geliştirme süresini gereksiz yere artırır. Kullanıcıların hiçbir zaman doğrudan geri bildirim vermediği özellikler için vakit ve bütçe harcanır; asıl ürün gecikmesinin nedeni bu sıkıştırılmış kapsamdır.

##MVP için Hangi Özellikler Seçilmeli: Adım Adım Bir Çerçeve

• ▸MVP'nizin müşteri için yaptığı işi tek bir cümleyle yazın. Eğer tek cümleyle yazamıyorsanız odağınız henüz yeterince netleşmemiş demektir. Bu cümle, herhangi bir özellik ekleme tartışmasında başlangıç noktanız olmalı.
• ▸Düşündüğünüz tüm özellikleri listeleyin. Her biri için iki soru sorun: Hangi müşteri sorununu çözüyor? Bu özellik olmadan kullanıcı çekirdek değere ulaşabilir mi? İkinci soruya 'evet' cevabı verebiliyorsanız özellik ikinci sürüme aittir.
• ▸En riskli varsayımınızı belirleyin — yanlış çıkması durumunda tüm fikrinizi çökertecek tek şeyi. Her MVP özelliği bu varsayımı doğrulamalı ya da doğrudan test edilmesini desteklemeli. Bu varsayıma dokunmayan özellikler kesilmelidir.
• ▸'Şimdi gerekli / sonraya bırakılabilir' filtresini uygulayın. Kullanıcı bir özellik olmadan da çekirdek akışı tamamlayıp değer alabiliyorsa, o özelliği ikinci sürüme bırakın. Yapacak şeyler bitmeyecek — hepsini aynı anda yapmaya çalışırken zaman ve bütçe bitecek.
• ▸Her özelliği üç katmana atayın: olmazsa olmaz (kullanıcı çekirdek değere bu olmadan ulaşamaz), olursa iyi (deneyimi önemli ölçüde artırır), güzel olurdu (geri kalan her şey). Yalnızca olmazsa olmazları gönderin; diğerlerine gerçek kullanıcı geri bildirimi aldıktan sonra bakın.
• ▸Geliştirme başlamadan önce kapsamı yazılı olarak dondurun. Ekibiniz veya geliştiricinizle bir özellik dondurma tarihi üzerinde anlaşın ve buna uyun. Kapsam kayması neredeyse hiçbir zaman teknik bir sorun değildir — iletişim ve taahhüt sorunudur.

##Özellikleri Keserken Ne Aranmalı

Kesilmesi en zor özellikler genellikle inşa etmekten en çok gurur duyduklarınızdır — karmaşık algoritmalar, özenle tasarlanmış ayarlar ekranları, yönetici panelleri, gelişmiş filtreler. Bunlar nadiren bir kullanıcının kalıp kalmamasına karar verendir. Karar veren şey, çekirdek döngünün işleyip işlemediği ve kullanıcının ilk 90 saniye içinde ne yapması gerektiğini anlayıp anlamadığıdır.

Müşterilerle MVP kapsamı belirlerken her özellik için şu soruyu sorarım: 'Kullanıcı bu özellik olmadan ürün için para ödemez mi, yoksa siz sadece onsuz göndermekten mi korkuyorsunuz?' Bu iki neden arasında büyük bir fark var. Birinci, ürün kararıdır. İkincisi, güven sorunudur — ve güven sorununu özellik ekleyerek çözemezsiniz.

##Gerçek Hayattan Bir Örnek

Yakın zamanda bir müşterim şu 'birinci aşama' MVP planıyla geldi: kullanıcı kimlik doğrulama, ekip yönetimi, rol tabanlı izinler, beş grafik türüyle bir kontrol paneli, CSV dışa aktarma, e-posta bildirimleri, geri bildirim widget'ı ve Stripe entegrasyonu. Her biri mantıklı görünüyordu; hiçbiri tartışmalı değildi. Ancak hepsini birden inşa etmek dört ila altı ay demekti.

Birlikte kapsamı şuna indirdik: Google ile giriş, kullanıcıların gerçekten yanıtlaması gereken soruyu yanıtlayan tek bir grafik ve Stripe'ta tek bir ödeme katmanı. Bu sürüm üç haftada yayına girdi. Altı hafta içinde kullanıcılar hangi kesilen özelliklerin gerçekten önemli olduğunu söyledi — ve hiçbiri başta bağlı oldukları özellikler değildi. Ekip yönetimi ve CSV dışa aktarma değil, belirli bir konuya odaklanmış ikinci grafik türü ve Slack bildirimleri istendi.

##Sık Sorulan Sorular

>Bir MVP'de kaç özellik olmalı?

Evrensel bir sayı yok, ancak iyi kapsamlandırılmış bir SaaS MVP için 5–12 özellik tipik bir aralık. Sayıdan daha önemli olan, her özelliğin çekirdek kullanıcı akışı için gerçekten gerekli olup olmadığı. Üç şeyi mükemmel yapan bir MVP, on beş şeyi yeterince yapan birinden çok daha test edilebilir — ve yatırım alabilir. Yatırımcılar keskin odağı dağınık kapsama tercih eder.

>Paydaşlar ya da yatırımcılar daha fazla özellik isterse ne yapmalıyım?

Bu bir ürün sorunu değil, önceliklendirme ve iletişim sorunudur. Her özellik talebini test ettiğiniz hipoteze bağlamak doğru yanıt. Bir paydaş X özelliğini istiyorsa şunu sorun: 'Bu özellik birinci sürümde hangi varsayımı doğrulamamıza yardımcı oluyor?' Yanıt 'hiçbirini, ama olursa iyi olur' ise bu tanım gereği MVP sonrası bir özellik. Ürün geliştirmeyi anlayan yatırımcılar şişirilmiş bir MVP'ye değil, keskin ve öğrenme odaklı bir MVP'ye değer verir.

>Çok fazla özellik kestim mi? Bunu nasıl anlarım?

Kalan özellikler eksiksiz bir kullanıcı akışı oluşturmuyorsa çok fazla kesmişsiniz demektir — kullanıcı giriş yapamıyor, çekirdek eylemi gerçekleştiremiyor veya bir çıkmazla karşılaşıyorsa. Bu tabandır. Bu tabanın üstünde, hemen hemen her kurucu az değil fazla kapsam belirliyor. MVP'niz kullanıcının değer önerinizde vaat ettiğiniz tek şeyi yapmasına izin veriyorsa, göndermek ve öğrenmek için yeterli. Öğrenme olmadan eklediğiniz her özellik tahmindir, geri bildirim değil.

MVP için doğru özellikleri seçmek yaratıcı bir egzersizden çok bir disiplin meselesi. Amaç her istediğinizi inşa etmek değil; ne inşa ettiğinizin gerçekten inşa etmeye değer olup olmadığını mümkün olan en kısa sürede öğrenmek. Geliştirme başlamadan MVP'nizi kapsamlandırmanıza yardımcı olmamı istiyorsanız, iletişim sayfasından ulaşabilirsiniz.