İşe yarayan bir MVP özeti tasarım başlamadan önce üç karar verir: ürünün kimin için olduğu, birinci sürümün bilinçli olarak neleri dışarıda bırakacağı ve hangi kullanıcı kanıtının sonraki yatırımı haklı çıkaracağı. Bu yüzden özet evrak işi değildir. İlk ürün kararıdır.
Kurucular çoğu zaman aslında fikrin açıklaması olan bir özetle gelir: pazar hakkında birkaç paragraf, bir özellik listesi ve ürünün bir gün nereye gidebileceğine dair bir cümle. Sohbet başlatmaya yeter, ancak üzerine ürün çıkarmaya yetmez. Bir geliştirme ekibinin, hedefi test edilebilir seçimler dizisine dönüştüren daha küçük ve daha keskin bir belgeye ihtiyacı vardır.
İşe yarayan bir özet üç iş görür
1. Sorunu olan kişiyi tanımlar
“Küçük işletmeler” bir pazardır; ilk kullanıcı değildir. İyi bir özet kişiyi, içinde bulunduğu anı ve bugün kullandığı geçici çözümü tanımlar. Yarınki iptalleri doldurmaya çalışan bir klinik yöneticisinin sorunu, ikisi de sağlık sektöründe olsa bile yeni randevu arayan bir hastanın sorunundan farklıdır. İlk kullanıcı ne kadar özgülse, ürünün sonra ne yapması gerektiğine karar vermek o kadar kolaylaşır.
2. Birinci sürümün çevresine bir çizgi çeker
Özellik listesi size hayal edileni söyler. Kapsam çizgisi ise neyin inşa edileceğini söyler. Temel döngüyü tek cümleyle yazın; ardından o döngüyü güvenilir kılan işleri sıralayın: ana ekran, tek anlamlı eylem, arkasındaki veriler ve kullanıcıya çalıştığını söyleyen geri bildirim. Geri kalan her şey daha sonrası için adaydır; lansman için sessiz bir gereklilik değildir.
3. Sonraki kanıtı tanımlar
“Yayına alıp ne olduğuna bakmak” bir öğrenme planı değildir. İlk birkaç haftada ne gözlemlemeyi beklediğinize karar verin: tamamlanmış bir iş akışı, tekrar eden bir eylem, ücretli dönüşüm veya belirli bir kullanıcı türüyle kurucunun yaptığı görüşme. Ölçütün karmaşık olması gerekmez. Bir sonraki ürün kararını değiştirebilmesi için kullanıcının davranışına yeterince yakın olması gerekir.
Bir ekran öncesinde ne yazılmalı
- İlk kullanıcı: tek rol, tek durum ve can yakan tek geçici çözüm
- Temel döngü: değer yaratan ve tekrar tekrar gerçekleşebilen en küçük eylem
- Lansman sınırı: birinci sürüm için açıkça kapsam dışı olanlar
- Güven gereksinimi: kullanıcının harekete geçmeden önce görmesi, kontrol etmesi veya anlaması gerekenler
- Sonraki kanıt noktası: başka bir geliştirme turunu hak eden davranış veya konuşma
Kullandığımız kapsam testi
Önerilen her özelliği ele alın ve tek soru sorun: Bu, temel döngünün ilk kullanıcı için başarılı olma olasılığını artırıyor mu? Yanıt hayırsa onu ilk sürümden çıkarın. Yanıt belkiyse, koruduğu varsayımı yazın ve o varsayımı test etmenin daha ucuz yolunu bulun. Bu, faydalı bir özelliğin ürünü geciktirmek için kalıcı bir mazerete dönüşmesini engeller.
Bir özetin amacı, inşa edebileceğiniz her şeyi kaydetmek değildir. Sonraki geliştirme kararını açık kılmaktır.
— ürün başlangıçlarında kullandığımız bir kural
Sık sorulan sorular
MVP özeti ne kadar uzun olmalı?
Tek oturuşta okunacak kadar kısa, ödünleşimleri belirleyecek kadar özgül olmalıdır. İlk kullanıcıyı, temel döngüyü, lansman sınırını, güven gereksinimlerini ve sonraki kanıt noktasını tanımladığında bir ila iki sayfa genellikle yeterlidir.
Özette tam bir özellik listesi olmalı mı?
Temel döngünün işlemesini sağlayan özellikleri ekleyin; kalanını sonraki fikirler bölümünde tutun. Ayrı bir bekleme listesi, iyi fikirleri sessizce lansman gereksinimine dönüşmelerine izin vermeden korur.
Hedef kullanıcı hâlâ belirsizse ne olur?
En güçlü iki adayı ve onları ayıracak kanıtı yazın. Belirsizlik açık olduğunda faydalıdır; geniş bir ürün kapsamının içinde saklandığında pahalılaşır.
Tasarım başlamadan önce özet bitmiş olmalı mı?
İlk tasarım turuna yön verecek kadar net olmalı, sonsuza dek donmuş olmamalıdır. Tasarım daha iyi bir soruyu ortaya çıkarabilir; ancak her değişiklik kapsamı ve toplamaya çalıştığınız kanıtı güncellemelidir.