30 günde çıkacak kadar küçük bir kapsam nasıl seçilir?

Fikrini doğruladın, birkaç kişiyle konuştun, "evet, bu derdim var" cevabını aldın. Şimdi asıl tuzak başlıyor. Kafandaki ürün; panel, bildirim, raporlar, ekip hesapları ve mobil uygulamayla birlikte büyüdükçe büyüyor. Mesai sonrası akşamları ve hafta sonlarıyla bunu bitirmek aylar sürer. O aylarda tek bir kullanıcıdan bile ses almazsın.

Bu yazı tek bir soruya odaklanıyor: 30 gün içinde gerçek bir insanın kullanabileceği kadar küçük bir sürümü nasıl seçersin? Cevabı Paul Graham, Y Combinator'dan Michael Seibel, Marc Lou ve Pieter Levels gibi isimlerin anlattıklarından ve Hacker News'te fazla inşa edip duvara toslayan kurucuların tartışmalarından derledim.

Neden 30 gün ve neden bu kadar küçük?

Paul Graham, girişimlerin en sık yaptığı hatalar listesinde "yavaş yayına çıkmak" maddesine ayrı yer veriyor. Ona göre yazılım hiçbir zaman tam bitmez, o yüzden yayına çıkmak bilinçli bir çaba ister. Gecikmenin arkasında çoğu zaman tanıdık şeyler var: yavaş çalışmak, problemi tam anlamamak, kullanıcıdan ve yargılanmaktan korkmak, aynı anda çok iş yürütmek, mükemmeliyetçilik. Graham'a göre erken çıkmak bunların hepsine birden ilaç oluyor. Aynı yazıda erken çıkmanın da itibar riski olduğunu kabul ediyor ama yavaş kalmanın çok daha fazla girişimi öldürdüğünü söylüyor.

Michael Seibel, YC Startup School'daki MVP dersinde aynı noktaya pratik taraftan bakıyor. Önerisi kötü bir şeyi hızlıca çıkarmak, onu ilk hedef kullanıcının önüne koymak ve gerçekten bir değer sunup sunmadığını görmek.

30 günlük süre buna iyi bir çerçeve sağlıyor. Hem bir şeyi gerçekten bitirmeye yetecek kadar uzun hem de "bir özellik daha" diyerek kaybolmana izin vermeyecek kadar kısa.

Önce tek cümlelik sözünü yaz

Kapsamı daraltmaya özelliklerden değil, vaatten başla. Şu kalıbı doldur:

"[Kim], [hangi durumda], [ne yapabilsin] diye bu ürünü kullanır."

Örnekler:

• "Serbest çalışan çevirmenler, müşteriden gelen dosyanın kelime sayısına göre teklifi iki dakikada çıkarabilsin."
• "Küçük bir yoga stüdyosu, haftalık ders programını ve kontenjanı WhatsApp'a link atarak paylaşabilsin."
• "Bir oto servis ustası, aracı teslim alırken çektiği fotoğrafları müşteriye tek linkle gönderebilsin."

Bu cümleye girmeyen her şey ilk sürümün dışında kalır. Seibel'in derste vurguladığı ayrım da burada işe yarıyor. Müşteriyi ve problemi sıkı tut, çözümü gevşek tut. Yani "kime ve hangi derde" sorusunun cevabı sabit kalsın, "nasıl" sorusunun cevabı ise kolayca değişebilsin.

Tek çekirdek eylemi bul

Marc Lou, haber bülteninde minimum bir ürün için listeyi üç maddeye indiriyor: bir başlık, bir satın alma düğmesi ve tek bir özellik. Başlığı ilk sıraya koyuyor çünkü ziyaretçi birkaç saniyede okumaya devam edip etmeyeceğine karar veriyor. Tek özellik de müşterinin en acı veren problemini çözmeli. Bu özellik birkaç küçük parçaya ihtiyaç duyuyorsa sorun yok, ama fazla düşünmemeni öneriyor.

Lou'nun en akılda kalan cümlesi şu: "Every startup has a 24-hour version." (Her girişimin 24 saatlik bir sürümü vardır.) Önerdiği yol, bir günde yayına alınabilecek hali bulmak ve sonra sadece gerçekten gereken parçaları birkaç gün içinde eklemek.

Çevirmen örneğine dönelim. Çekirdek eylem "dosyayı yükle, kelime sayısını ve fiyatı gör, teklifi PDF olarak al" olabilir. Müşteri listesi, fatura takibi, çoklu dil çifti ayarları, ekip hesabı… Hepsi mantıklı, hepsi sonra.

Hacker News'teki eski ama hâlâ öğretici bir "en iyi MVP örnekleri" başlığında bir yorumcu güzel bir ayrım yapıyor. Ona göre MVP, birinin para vereceği en küçük şeyi kurmak demek değil. Pareto'nun önemsiz yüzde 20'lik dilimine düşebilecek her parçayı kesmek demek. Bir de yarı yarıya kararsız kaldığın her konuda birini seçip yoluna devam etmek.

Kesme listesi: 30 günde neleri ertelersin?

Marc Lou'nun "atla" dediği şeyler özellikle teknik kurucular için acı verici ama işe yarıyor. Müşterinin görmediği işler bunlardan biri: test yazmak, git dallanma düzeni kurmak, yeni bir framework öğrenmek. Doğrudan müşteri değeri üretmeyen özellikler de öyle: şifre sıfırlama, karanlık mod, cilalı bir logo.

Pieter Levels'ın 2014'te "12 ayda 12 girişim" denemesi sırasında yazdığı MVP yazısı da aynı ruhu taşıyor. Levels kendini "hızlı ve kaba" çalışan biri olarak tarif ediyor. O dönem projelerinde jQuery dışında framework kullanmadığını, veritabanı yerine JSON dosyalarıyla başladığını yazıyor. Gerekçesi şu: en başta veritabanı şeması tasarlamak ona yavaş ve ters geliyor. Aynı stili kopyalaman gerekmiyor. Asıl ders, ilk sürümde altyapı kararlarının seni yavaşlatmasına izin vermemek.

Pratik bir kesme listesi:

• Ertelenir: Yönetim paneli, rol ve yetki sistemi, çoklu dil, mobil uygulama, ayrıntılı raporlar, entegrasyonlar, bildirim tercihleri, tema seçenekleri.
• Elle yapılır: Hesap açma onayı, fatura kesme, veri girişi, kullanıcıya hatırlatma.
• Kalır: Başlık, tek çekirdek eylem, kayıt veya iletişim yolu, ödeme ya da ödeme niyeti.

Kapsamı yaz ve zaman kutusuna koy

Seibel'in önerisi çok net. Bir süre belirle, örneğin üç hafta, ve sadece o sürede bitebilecek özellikleri listeye al. Bu listeyi yazılı tut. Yazılı bir kapsam olmazsa iş sessizce büyür ve üç haftalık plan üç aya dönüşür. Geride kalırsan önce açıkça önemsiz olanı kes. Önemsiz bir şey kalmadıysa önemli olanlardan da kesmeye hazır ol, çünkü bir şeyi dışarı çıkarmak her şeyden önemli.

Bunun için süslü bir araca ihtiyacın yok. Tek sayfalık bir not yeter:

1. Tek cümlelik söz
2. Çekirdek eylem (tek bir akış)
3. "Bu dönemde var" listesi (en fazla 5 madde)
4. "Sonra" listesi (sınırsız)
5. Yayın tarihi

"Sonra" listesi sihirli bir rahatlama sağlar. Aklına gelen her güzel fikri silmiyorsun, sadece park ediyorsun. Hacker News'teki aynı MVP başlığında bir kurucu, ürününü iki haftada yayına çıkarmak için minimumu kurduğunu, ama sonrası için çok uzun bir özellik listesi tuttuğunu anlatıyor. Dengeyi de bu kuruyor: fikirler gitmiyor ama sırasını bekliyor.

Elle yapılabilecek her şeyi elle yap

Paul Graham'ın "Ölçeklenmeyen şeyleri yap" yazısı burada en büyük yardımcın. Graham, ürün eksik olsa bile ilk kullanıcı deneyiminin elle tamamlanabileceğini anlatıyor. Örneklerden biri Stripe. Kurucular ilk kullanıcıları perde arkasında elle geleneksel üye işyeri hesaplarına kaydettirmiş, kullanıcıya ise hesap anında açılmış gibi görünmüş. Bir diğeri Wufoo; yeni kullanıcılara elle yazılmış teşekkür notları gönderiyormuş. Graham'a göre amaç, ne kurman gerektiğini öğrendikten sonra bu adımları otomatikleştirmek.

Aynı Hacker News başlığında anılan CD Baby örneği de benzer. Bir yorumcunun hatırladığına göre platform albüm satın alma linkleriyle başlamış, siparişleri kurucu elle karşılayıp gönderiyormuş.

Senin için anlamı şu. Yoga stüdyosu ürününde ödeme otomatik olmak zorunda değil. İlk on stüdyoya hesap açmayı sen yapabilirsin. Emlak ofisleri için bir ilan aracı yapıyorsan ilk ilanları onlarla birlikte girebilirsin. Her elle iş, 30 günden birkaç günü geri kazandırır.

Fazla inşa etmenin bedeli

Hacker News'te bir geliştirici, aylarca bir uygulama yapıp ardından nasıl kullanıcı bulacağını bilemediğini anlatıyor. Yazının başında kendisi de itiraf ediyor: "Kullanıcılarla erken konuş" tavsiyesini duymuş ama dinlememiş. Uygulama, insanların topluluklarına hizmet sunarak para toplamasını sağlayan oldukça kapsamlı bir platform. Yorumların çoğu aynı soruda birleşiyor: bu, GoFundMe ya da TaskRabbit gibi oturmuş platformlardan neden farklı? Bir yorumcu, ortaya çıkanın iki taraflı bir pazar yeri olduğuna dikkat çekiyor. Böyle bir yapı, tek bir çekirdek eylemle test edilebilecek bir fikirden çok daha ağır.

Ders şu: kapsam büyüdükçe "bu kimin hangi derdini çözüyor" sorusunun cevabı bulanıklaşıyor. Küçük kapsam, o soruyu cevaplamaya seni zorluyor.

Başka bir Hacker News tartışması da cilanın yan etkisini anlatıyor. Bir kurucu, açılış sayfalarını güzelleştirdikçe daha sert eleştiri aldığını fark etmiş. Yorumculardan biri bunu şöyle açıklıyor: ürün cilalı göründükçe bitmiş gibi algılanıyor, bitmiş görünen şey de daha çok eleştiriliyor. Bir başkası parlak ana sayfaların çoğunda şirketin ne yaptığını anlayamadığını söylüyor. Yani ilk 30 günde tasarıma harcadığın emek, fikrin netliğinden çalabilir.

Örnek bir 30 gün

Mesai sonrası haftada 10–12 saat ayırabilen biri için kaba bir plan:

• 1. hafta: Tek cümlelik söz, kapsam notu, başlık ve açılış sayfası. Hedeflediğin 5–10 kişiyle konuşup çekirdek eylemi teyit et.
• 2. hafta: Çekirdek akışı uçtan uca çalışır hale getir. Çirkin olabilir, sadece çalışsın.
• 3. hafta: Kayıt, ödeme ya da ödeme niyeti, geri bildirim yolu. Elle yapılacak işleri belirle.
• 4. hafta: İlk kullanıcıları içeri al, yanlarında otur ya da ekran paylaş, kırılanı düzelt ve yayına çık.

Geride kalırsan Seibel'in kuralını uygula: tarih sabit, kapsam esnek.

Bu hafta yapılacak

1. Tek cümlelik sözünü "[Kim], [hangi durumda], [ne yapabilsin]" kalıbıyla yaz ve iki potansiyel kullanıcıya okut.
2. Ürünün çekirdek eylemini tek bir akış olarak çiz: giriş noktası, tek adım, sonuç.
3. Kafandaki tüm özellikleri listele, sonra her birini "var", "elle" ya da "sonra" diye etiketle. "Var" listesi 5 maddeyi geçmesin.
4. Yayın tarihini takvimine yaz ve bir arkadaşına ya da Tershane'deki dönem grubuna söyle.
5. Ürünün 24 saatlik halini düşün: Bir günde neyi yayına alabilirdin? Oradan geriye doğru kapsam kur.

Sık sorulanlar

Bu kadar küçük bir ürün itibarımı zedelemez mi?

Paul Graham da bu riski kabul ediyor ama erken kullanıcıların oldukça hoşgörülü olduğunu, işe yarar bir şey yapmasının yeterli olduğunu söylüyor. Ürünü erken kullanıcılara "erken sürüm" diye açıkça sun.

Tek özellik yeterli değilse, rakipler daha fazlasını sunuyorsa?

Rakiple özellik sayısında yarışma. Tek bir dar kitlenin tek bir derdini rakipten daha iyi çözmeye odaklan. Gerisi "sonra" listesinde.

30 gün yetmezse ne yaparım?

Tarihi değil kapsamı değiştir. Seibel'in önerdiği gibi önce açıkça önemsiz olanı, gerekirse önemli olanı da kes. Tarihi sürekli ertelersen 30 gün kolayca üç aya dönüşür.

Kod kalitesini tamamen boşveriyor muyum?

Hayır. Pieter Levels bile bir proje tutarsa kodun başkaları tarafından okunup büyütülebilmesini istediğini yazıyor. Amaç gereksiz altyapıyı ertelemek, çalışmayan bir şey çıkarmak değil.

Dayanak

• The 18 Mistakes That Kill Startups — Paul Graham: yavaş yayına çıkmanın nedenleri ve erken çıkmanın riski
• Do Things That Don't Scale — Paul Graham: Stripe ve Wufoo örnekleriyle elle onboarding
• Startup School Week 2 Recap: Michael Seibel — Y Combinator: zaman kutusu, yazılı kapsam, özellik kesme, müşteriyi sıkı çözümü gevşek tutma
• How to build a startup in 24 hours — Marc Lou: başlık, satın alma düğmesi, tek özellik ve atlanacaklar listesi
• How I build my minimum viable products — Pieter Levels: hızlı ve kaba çalışma, framework ve veritabanı olmadan başlama
• Ask HN: What are some great examples of a Minimum Viable Product? — Hacker News: MVP ve "satılabilir en küçük ürün" ayrımı, CD Baby, iki haftada çıkan ürün
• Ask HN: I spent months building an app and now I don't know how to get users — Hacker News: aylarca inşa edip kullanıcı bulamama hikâyesi
• Ask HN: Is there an "uncanny valley" effect with startup MVPs? — Hacker News: cilalı MVP'nin daha sert eleştirilmesi