Ne zaman ürün odaklı startup kurucuları ile minimum düzeyde uygulanabilir ürünlerden bahsetsem, çoğu zaman kendimi sinir bozucu bir sohbetin içinde buluyorum. MVP terimi çok büyük bir yanlış isimdir; iyi bir MVP uygulanabilir değildir ve kesinlikle bir ürün değildir. Muhtemelen, olmasını istediğiniz kadar da az değildir, bir düşünün.

Yalın girişimler dünyasında, kurucuların mümkün olduğunca çabuk nasıl başarısız olunacağını bulmaya aşırı odaklanmaları gerekir. İdeal olarak, başarısız olursunuz, bu da işleyen bir işletmeye sahip olduğunuz anlamına gelir. “Başarısız olmaya çalışmak” yaklaşımlarının çoğu, iş fırsatlarınıza bakmayı ve işinizin gelecekte nerede başarısız olabileceğini düşünmeyi içerir. O zaman git ve o kısmı çöz.

Tüm müşteri tabanı zaten eBay’i kullanmaktan memnunsa ve ürününüz üstün olsa bile vazgeçmiyorsa, Bere Babies satmak için dünyanın en iyi platformunu oluşturmak iyi değildir. Scooter şirketlerinin, scooterların çalınmasını umursamadığı ortaya çıkarsa, özellikle ortak kullanımlı scooterlar için harika bir kilit oluşturmak iyi değildir. Tek bir kod satırı yazmadan önce herhangi birinin ürününüzü satın alıp almayacağını anlamanın bir yolu olsaydı harika olurdu.

Peki MVP’ler nerede devreye giriyor? Başlangıç ​​olarak bir hipoteziniz var; MVP, hipotezinizi doğrulamak veya çürütmek için yapabileceğiniz en küçük çalışma miktarıdır.. Eric Ries – evet, “The Lean Startup”ı yazan adam – ünlü bir örnek olarak Dropbox’ın MVP’sini kullanıyor. Tam teşekküllü, özelliklerle dolu bir ürün değildi. Pek çok özelliğinden sıyrılmış bir ürün değildi. Bir ürünün nasıl çalışabileceğini gösteren bir videoydu. Bu videoya verilen yanıt, şirketin ihtiyaç duyduğu onaydı: Bunu yaparlarsa, henüz oluşturulmamış ürünü için bir müşteri tabanı bulabilecekler. Demek yaptıkları buydu: Ürünü oluşturdular ve büyük bir başarı elde ettiler.

İyi bir MVP tasarlamak

İyi bir MVP tasarlamak, kutunun dışında düşünmek demektir. Ne kadar az kod yazabilirsiniz? Tasarım yapmadan kurtulabilir misin? En büyük sorunuz, mantıklı bir müşteri edinme maliyeti karşılığında müşterileri çekip çekemeyeceğiniz ise, yalnızca bir reklam kampanyası ve bir ödeme sayfası çalıştırıp, ardından sipariş verene para iadesi yapabilir misiniz? Kulağa eğlenceli geliyorsa ancak marka riski konusunda endişeleniyorsanız, sahte bir marka oluşturup ürününüze bir yanıt alabilir misiniz?

İşin püf noktası, hipotez hakkında dikkatlice düşünmektir – ürününüz, pazar, girdiğiniz sorun alanı, çekmeyi umduğunuz müşteriler ve rekabet ortamı hakkında neyin doğru olması gerekir? Varsayımlarınızın doğruluğundan ne kadar eminsiniz? İyi bir MVP tasarlamak bir sanattır, ancak gerçekten iyi bir soruyla başlar. İşte birkaç örnek:

  • Dört saatlik manuel muhasebe görevlerini üç dakikada çalıştırılabilen bir komut dosyasına indirgememiz mümkün mü? Bu teknik bir MVP’dir – manuel görevleri güvenilir bir şekilde otomatikleştirip otomatikleştiremeyeceğinizi görmek için muhtemelen bazı kodları bir araya getirmeniz gerekir.
  • Bu görevi otomatikleştirmek için para ödemeye hazır birini bulabilir miyiz? Bazı durumlarda, cevap “hayır” olacaktır – evet, genç bir muhasebeciye biraz zaman kazandırabilirsiniz, ancak bazı endüstrilerde insanlar, genç personelin manuel görevleri yapmak için ne kadar zaman harcadıklarını umursamıyor. Bu durumda, bunun için ödeme yapmaya istekli 20-30 müşteri bulup bulamayacağınızı belirlemeniz gerekir. “Ah, bu iyi bir fikir gibi geliyor” diyen birinin, cebine uzanıp elini uzatmaktan farklı olduğunu unutmayın. aslında sana para ödüyor.
  • Bu ürün için tasarım önemli mi? Bir çok B2B yazılımı korkunç derecede çirkin. Bunun nedeni iyi tasarımcıların olmaması değil, sadece bir öncelik olmamasıdır; ürünü kullanmak zorunda olanlar daha iyi bir tasarımı veya daha kolay bir UX’i tercih edebilir, ancak karar vericiler umursamıyor ve kullanıcılar söz sahibi olmuyor. Başka bir deyişle: Bir iş gerekçesi bulamıyorsanız, geliştirme bütçenizin yarısını kullanımı daha kolay hale getirmek için harcamayın. Özellikle bu süreçte istemeden yanlış özellik setini geliştirdiğiniz ortaya çıkarsa.
  • Görevdeki biri bizi kopyalayıp yok edecek mi? Alanınızda çok sayıda görevli varsa, biraz araştırma yapın ve diğer girişimlere nasıl tepki verdiklerini görün. Onları elde etme eğilimindeyseler, harika. Özelliklerini ve yeniliklerini kopyalamaya ve sonra onları ezmeye meyilliyseler, daha az harika. Biraz Googling (ve tabii ki sektörünüz için TechCrunch’ı okumak) gelecekte sizi birçok baş ağrısından kurtarabilir. Görevliler rutin olarak yenilikleri çalıyorsa, patentlere daha fazla yatırım yapın ve avukatlar için bir miktar para ayırın.
  • Bu özellik müşterilerimiz için bir anlam ifade ediyor mu? Aynı özelliği isteyen müşterilerinizden çok yüksek sesle bir azınlık elde edebilirsiniz, ancak yalnızca toplu bir omuz silkme ile karşılanmak üzere yeni bir özelliği büyük hayran kitlesine sunan ilk şirket olmayacaksınız. Gürültülü müşteriler tüm müşteri tabanınız adına konuşmazlar, bu nedenle birikmiş iş listenizi nasıl düzelttiğiniz konusunda mantıklı olun – bir özellik şirketinizin genel iş hedeflerine önemli bir değer katmıyorsa, bunu yapanlara göre öncelik vermeyin. Bunun etrafında bir MVP tasarlamanın bir yolu, kullanıcı arayüzünüze bir düğme eklemek ve kaç kişinin tıkladığını izlemektir. Bir “yakında geliyor!” örneğin tıklandığında mesaj. Evet, kullanıcıları rahatsız ediyor, ancak neredeyse hiç kimsenin kullanmayacağı bir özellik ekleyerek birkaç geliştirme döngüsü harcamaktan çok daha “ucuz”.

Özetle, anahtar, sorunun ne olduğu hakkında çok dikkatli düşünmek ve ardından bu soruyu sormanın zarif, alçakgönüllü yollarını bulmaktır. Gönderim kodu yerine bir anket işe yarayabilir mi? Bir video demosu size ihtiyacınız olan yanıtları verebilir mi? 50 müşteriyi arayabilir ve onlara ihtiyatlı sorular sorabilir ve düşündüğünüz özelliği soruna olası bir çözüm olarak önerip önermediklerini görebilir misiniz? Sizi iki şekilde şaşırtabilirler: Müşterileriniz, önerdiğiniz şeyi ezici bir şekilde isteyebilir (harika!), nefret edebilir (ayrıca harika – bu, onların yapmadıkları bir şeyi geliştirmek için zaman ve para harcamanıza gerek olmadığı anlamına gelir) istiyorum) ya da sorunu çözmek için tatlı noktaya ulaşan, geliştirmesi daha ucuz olan ve sürecinizle ilgili hissetmelerine yardımcı olan tamamen farklı bir yolu olabilir.

MVP için daha iyi bir isim için bir önerim yok, sadece onu bir ürün, uygulanabilir veya mutlaka küçük, basit veya kolay olarak düşünme tuzağına düşmeyin. Bazı MVP’ler karmaşıktır. Ancak fikir, değerli kaynaklarınızın mümkün olduğu kadar azını sorularınıza yanıt almak için harcamaktır.



genel-24