SaaS MVP'niz Lansmanda Neleri İçermeli — ve Neleri İçermemeli

Minimum uygulanabilir üründeki "minimum" kelimesi, herkesin görmezden geldiği kısımdır. Kurucular küçük başlama fikrine onaylarcasına başlarını sallar, sonra size kırk ekranlı, üç kullanıcı rollü, bir faturalandırma motoru, bir analiz panosu ve "ha, bir de her şeyle entegre olmalı" diyen bir spesifikasyon uzatır. Bu bir MVP değildir. Bu, iyimserliği sonuna kadar açılmış tam bir üründür. Ve ilk lansmanların geç, bütçe aşımıyla ve bir şekilde hâlâ müşterilerin gerçekten istediği o tek şeyden yoksun gelmesinin en yaygın tek sebebidir.

Epey küçük şirkete ve tek başına çalışan kurucuya ilk yazılım ürünlerini piyasaya çıkarmalarında yardım ettim. İnsanları tökezleten nadiren teknik kısımdır. Zor olan kısım — istisnasız her seferinde — henüz neyi yapmamaya karar vermektir. Bir MVP, hayalinizdeki ürünün rastgele özellikleri törpülenmiş daha küçük bir sürümü değildir. Bilinçli bir bahistir: temel fikrin daha fazla paranıza ve zamanınıza değer olduğunu kanıtlayacak, gerçek kullanıcıların önüne koyabileceğiniz en küçük şey.

İşte bu yüzden, daha çok kurucunun spesifikasyonunu yazmadan önce okumasını dilediğim rehber bu. Jargon yok, "hızlı hareket et ve bir şeyleri kır" gösterisi yok. Sadece ilk sürümünüze ait olanla bekleyebilecek — ve beklemesi gereken — şey arasındaki sınırı çizmenin pratik bir yolu.

Bir MVP gerçekte nedir (ve ne değildir)

Tanımı netleştirelim, çünkü kafa karışıklığının çoğu burada başlar. Bir MVP, gerçek bir kişinin ürününüzün vaat ettiği o tek değerli şeyi yapmasına olanak tanıyan — ve onu tekrar yapmak için geri gelip gelmeyeceğini öğrenmenizi sağlayan — ürününüzün en küçük, en basit sürümüdür. Hepsi bu. Bu, tamamlanmış ürünün soyulmuş bir lansmanı değil, çalışan yazılımdan oluşan bir öğrenme aracıdır.

Kritik kelime uygulanabilir'dir. Yaygın bir hata, "minimum" kelimesini okuyup kullanıcıyı utandıracak kadar çıplak bir şey yayına almaktır — çöken yarım bir akış, boş bir ekrana götüren bir kayıt. Bu minimum-uygulanabilir değil, minimum-bozuktur. Diğer başarısızlık tam tersidir: o kadar "eksiksiz" bir ürün ki yapması bir yıl sürer, o noktaya geldiğinizde de sermayenizi sekiz haftada test edebileceğiniz bir tahmini kanıtlamaya harcamışsınızdır.

İşte kullandığım zihinsel test. Listedeki her özellik için sorun: bunu kaldırsak, bir kullanıcı yine de ürünün var olma sebebi olan o tek temel sonucu elde edebilir mi? Cevap evetse, neredeyse kesinlikle MVP değildir. Tek başına bu soru çoğu spesifikasyonu yarıya indirir — ve kestiği yarı, sizi geciktirecek olan yarıdır.

Ürününüzün yaptığı tek işi bulun

Ne yapacağınıza karar vermeden önce, ürününüzün biri için yaptığı tek iş konusunda acımasızca net olmalısınız. Vizyon değil. Yol haritası değil. İşe yararsa bir kişinin gününü iyileştiren ve onu ödeme yapmaya istekli kılan o tek tekrarlanabilir eylem. Sıkıntılı spesifikasyonların çoğu tam burada belirsizdir — bir işi değil, bir platformu tanımlarlar.

Şu cümleyi sesli olarak tamamlamayı deneyin: "Bir kullanıcı ürünüme ______ için gelir ve ______ olarak ayrılır." Bir planlama aracı: bir yönetici gelecek haftanın çizelgesini yayınlamaya gelir ve her vardiya dolu, ekip bilgilendirilmiş olarak ayrılır. Bir faturalandırma uygulaması: bir serbest çalışan bir müşteriye fatura kesmeye gelir ve gönderilmiş, izlenebilir bir faturayla ayrılır. Bu cümleyi temiz bir şekilde dolduramıyorsanız, kapsam belirlemeye hazır değilsiniz — hâlâ düşünmeye hazırsınız.

Her SaaS MVP'nin gerçekten ihtiyaç duyduğu şeyler

Bazı şeyler en yalın ilk sürümde bile pazarlık konusu değildir — heyecan verici oldukları için değil, onlar olmadan ürünün ya kullanılamayacağı ya da size hiçbir şey öğretemeyeceği için. Bunları tavan değil, zemin olarak düşünün. Basit yapın, ama düzgün yapın.

• Oturum açmanın bir yolu. Tek bir e-posta ve parola girişi bile yeterlidir — ama gerçek ve güvenli olanı, çünkü diğer her şey kullanıcının kim olduğunu bilmeye bağlıdır.
• Baştan sona temel iş akışı. Tek iş, kullanıcının ilk tıklamasından değerli sonucu aldığı ana kadar — kritik yolda çıkmaz sokak yok, "yakında" düğmeleri yok.
• Verinin gerçekten yaşadığı bir yer. Tek seferlik bir prototip değil, gerçek depolama; böylece kullanıcının çalışması bir yenilemeden sağ çıkar ve yarın geri dönebilir.
• Neler olduğunu görmenizin bir yolu. Temel günlük kaydı veya basit bir yönetici görünümü; böylece bir şey bozulduğunda — ki bozulacaktır — nedenini tahmin etmeden bulabilirsiniz.
• Kullanıcıların size ulaşmasının bir yolu. Sadece bir e-posta bağlantısı bile. İlk kullanıcılar öngörmediğiniz sınırlara çarpacak; size söylemelerini istiyorsunuz, sessizce ayrılmalarını değil.
• Asgari güven düzeyi: bir gizlilik notu, makul veri işleme ve insanların bilgileriyle pervasız bir şey yapmamak.

O listede olmayanlara dikkat edin: faturalandırma, gösterişli kullanıcı tanıtımı, ayarlar sayfaları, mobil uygulamalar, entegrasyonlar. Birazdan neden olduğuna geleceğiz. Zeminin amacı, bitirilebilecek kadar küçük ve öğrenilebilecek kadar sağlam olmasıdır. Çalışan bir giriş, sonuç veren tek bir iş akışı, gerçek veri ve kullanıcıları izleyip onlarla konuşmanın bir yolu. Bu uygulanabilir bir üründür.

v1'den bilinçli olarak neyi dışarıda bırakmalı

Bu, kurucuların direndiği bölüm, o yüzden açık olayım: ilk lansmanınız için elzem gibi hissettiren şeylerin çoğu değildir. Elzem gibi hissettiriyorlar çünkü "gerçek bir üründe" bunlar vardır — ama siz henüz gerçek bir ürün yapmıyorsunuz, bir soru inşa ediyorsunuz. Bunları dışarıda bırakmak köşe kesmek değildir. Bir MVP'nin disiplininin ta kendisidir.

Otomatik faturalandırma ve karmaşık fiyatlandırma

İlk sürümde neredeyse kesinlikle self-servis bir faturalandırma motoruna, kademeli planlara, oransal hesaplamaya ve tahsilat takip mantığına ihtiyacınız yok. İlk kullanıcılar ödeme yapmak isterse, paralarını elle alabilirsiniz — bir fatura, bir ödeme bağlantısı, hızlı bir telefon görüşmesi. İlk on müşteriniz için elle faturalandırma, otomatik faturalandırmanın söyleyemeyeceği bir şeyi söyler: biri gerçekten ödeyecek mi. Tahsil edilecek para olduğunu kanıtladıktan sonra makineyi inşa edin.

Ayrıntılı roller ve izinler

Çok rollü izin sistemleri — yöneticiler, müdürler, görüntüleyiciler, ayrıntılı erişim kuralları — gerçek bir mühendislik bataklığıdır ve test yüzeyini muazzam ölçüde çoğaltır. İlk sürüm için tek bir kullanıcı türü neredeyse her zaman yeterlidir. Gerçek izin ihtiyaçlarını, gerçek ekiplerin şeyi kullanışını izleyerek öğreneceksiniz ve bu ihtiyaçlar nadiren kâğıt üzerinde tahmin edeceğiniz şeylerdir.

Entegrasyonlar, yerel mobil uygulamalar ve pano

"Her şeyle entegre olması gerekiyor", zaman çizelgelerini sessizce ikiye katlayan ifadedir. En fazla bir entegrasyon seçin ve yalnızca temel işin parçasıysa. Yerel iOS ve Android uygulamaları neredeyse her zaman bekleyebilir — duyarlı bir web uygulaması bugün bir telefonda çalışır. Peki herkesin istediği analiz panosu? Kullanıcılar henüz oluşturmadıkları veriyi analiz edemez. Önce veriyi oluşturan şeyi yayına alın; gösterilecek bir şey olduğunda görselleştirin.

Sınırı çizmek için basit bir yöntem

İlkeyi bilmek bir şeydir; her özelliğin kendi yavrunuz gibi hissettiren kendi spesifikasyonunuza uygulamak daha zordur. İşte işe yarayan bir yöntem, çünkü her şeyin "elzem"e sürüklenmesine izin vermek yerine her öğe için bir karar dayatır.

1. 1
   Hayal ettiğiniz her özelliği listeleyin

   Hepsini dökün — henüz filtreleme yok. Tam dilek listesini masaya koyun ki hiçbir şey söylenmeden gizlenip inşa ortasında bir sürpriz olarak yeniden ortaya çıkmasın.
2. 2
   Her birini temel işe karşı işaretleyin

   Her özellik için sorun: bir kullanıcı tek temel işi baştan sona tamamlamak için buna ihtiyaç duyuyor mu? 'Temel', 'yararlı' veya 'bir gün' olarak işaretleyin. Dürüst olun — çoğu son ikisine düşer.
3. 3
   v1 için yalnızca 'temel'i tutun

   MVP'niz 'temel' yığınıdır ve başka hiçbir şey değil. 'Yararlı' ve 'bir gün' yığınları reddedilmiş değil — onlar yol haritanız, ait oldukları yere park edilmiş.
4. 4
   Kesintiyi mantık kontrolünden geçirin

   Geriye kalana bakın ve sorun: gerçek bir kullanıcı yalnızca bundan gerçek değer elde edebilir mi? Evetse, bir MVP'nin kapsamını belirlediniz. Bir şey temel akışı gerçekten bozuyorsa, yalnızca o tek öğeyi geri çekin — başka hiçbir şeyi değil.

Disiplin dördüncü adımdadır. Her zaman "sadece bir şeyi daha geri çekme" cazibesi vardır, sonra bir tane daha, ta ki tam ürünü sessizce yeniden inşa edene kadar. Yalnızca temel akışı gerçekten bozan öğeleri kurtarmaya izin verin — onu sadece daha hoş yapacak olanları değil. Daha hoş, ikinci sürümün işidir.

Uygulanabilir, yine de gerçek hissettirmesi gerektiği anlamına gelir

Sınırın diğer tarafında bir başarısızlık biçimi var ve onu adlandırmaya değer. Küçük yayına alma telaşında bazı kurucular derme çatma bir şey yayına alır — ve buna MVP der. Çalışmanızı kaybeden bir temel akış, 404 veren bir kayıt, yer tutucu metinle dolu içerik. Bu fikrinizi adil bir şekilde test etmez; kullanıcıların bozuk bir deneyimi tolere edip etmeyeceğini test eder ve cevap her zaman hayırdır. Gerçekte uygulama başarısız olmuşken fikrin başarısız olduğu sonucuna varırsınız.

"Minimum" kapsama uygulanır, asla tuttuğunuz kısmın kalitesine değil. Daha az özellik, her biri sağlam. Yayına aldığınız tek iş akışı bitmiş hissettirmeli — hızlı, net ve güvenilir — ürünün yaptığı tek şey olsa bile. İyi yapılmış dar bir ürün, kötü yapılmış geniş bir ürünü her seferinde yener, özellikle yabancılardan işlerini size emanet etmelerini istiyorsanız.

MVP bitiş çizgisi değildir — ilk okumadır

İşte her şeyi yeniden çerçeveleyen kısım: lansman hedef değildir. Hedef, sonraki haftalarda öğrendiğinizdir. Yayına alınan ve size "kullanıcılar temeli seviyor ama sürekli X istiyor" diyen bir MVP, gümbür gümbür bir başarıdır — X bir ay daha çalışma anlamına gelse bile. Sessizliğe yayına alınan, kimsenin geri dönmediği bir MVP de işini yapmıştır: sizi diğer otuz özelliği kimsenin istemediği bir temele inşa etmekten kurtarmıştır.

O yüzden ilk haftaları inşa kadar bilinçli planlayın. İnsanların anketlerde söylediklerini değil, gerçekte ne yaptıklarını izleyin. Geri dönenlerle ve dönmeyenlerle konuşun. İkinci sürüme neyin gireceğine orijinal spesifikasyonunuzun değil, gerçek kullanımın karar vermesine izin verin. Daha önce park ettiğiniz yol haritası bir söz değil; bir hipotezdir ve kullanıcılarınız onu notlandırmak üzere.

Sık sorulan sorular