Neredeyse hepinizin MVP kavramını duyduğunuzdan oldukça eminim. Ancak aranızdaki çoğunluğun MVP'leri gerçek dünyada nadiren pratik kullanım alanı bulmuş, son derece teorik bir şey olarak görme ihtimali de yüksek. Gerçek şu ki minimum uygulanabilir ürün örnekleri çevremizde her yerde ve dünyaca ünlü yazılım ürünlerinin birçoğu MVP olarak başladı.
MVP'ler oluşturma konusunda deneyimli kıdemli bir ürün yöneticisi olarak, küçük bir startup girişimcisiyseniz bu kavramın ne kadar değerli olduğunu göstermek için birkaç başarı hikâyesini paylaşmak istiyorum.
MVP Nedir?
Minimum uygulanabilir ürün, Eric Ries'in ürün oluşturma metodolojisi olan Yalın Girişim'in temel unsurlarından biridir.
Yalın Girişim ve MVP'nin ardındaki temel fikir, startup'ların sürekli başarısız olması ve bu riski azaltmak için önce ürününüzün temel özelliklerini içeren çok küçük bir sürümünü oluşturmanız, müşterilerin bunu isteyip istemediğini doğrulamanız ve son ürünü geliştirmeye başlamadan önce iş fikrinizin işe yaradığını teyit etmeniz gerektiğidir.
Şimdi, en başarılı MVP örneklerinden bazılarının hikâyelerine göz atalım.
Örnek #1: Dropbox'ın MVP Geliştirme Konusundaki Alışılmadık Formatı
Muhtemelen çoğumuzun önemli belgelerin dijital kopyalarını depolamak veya ekibinizin birlikte üzerinde çalıştığı her şey için şirket depolama alanı olarak kullandığı bir platformla başlayalım.
Bulut depolama hayatımızın ayrılmaz bir parçası hâline geldi ve artık hem kişisel hem de profesyonel kullanım alanları için sıradan bir hizmet konumunda. Ancak Drew Houston'ın Dropbox'ı başlatmaya karar verdiği 2007 yılında durum böyle değildi.
Dropbox o dönemde piyasadaki ilk bulut depolama hizmeti olmasa da (böyle bir hizmet sunan Box ve Amazon S3 zaten vardı), dosyalarınızı bulutla senkronize etmek için kesintisiz bir deneyim sunan hizmetti.
Drew, bulut depolama için ilginç bir çözüm geliştirdi. Dropbox, dosyaları manuel olarak yükleyip indirmenizi sağlamak yerine bilgisayarınızda, içeriğini bulutla senkronize hâlde tutan bir klasör oluşturacaktı. Yani tek yapmanız gereken bu klasöre dosya eklemek veya klasörden dosya çıkarmaktı; geri kalan her şey Dropbox'ın sorunuydu.
Tüm bunlar bugün bize sıradan geliyor, ancak o zamanlar hayranlık uyandıran bir şeydi.
Ancak böylesine kesintisiz bir deneyim oluşturmak, Drew'un ekibinin birden fazla işletim sistemi için masaüstü uygulamaları geliştirmesi ve arka planda her şeyi sizin için yönetecek karmaşık bir dosya senkronizasyon mekanizması oluşturması gerektiği anlamına geliyordu.
Bu da Drew'un Dropbox'ın MVP sürümünü bir uygulama olarak geliştiremeyeceği anlamına geliyordu; çünkü en küçük özellik kapsamına sahip bir uygulama bile tamamen işlevsel bir sunucu altyapısı gerektirecek ve ekibinin oluşturması uzun zaman alacaktı.
Ancak hem kullanıcılardan hem de yatırımcılardan erken geri bildirim almak istiyordu; bu, maliyetli uygulama geliştirme süreci hataları yapmaktan kaçınmasına ve pazarın beğeneceği bir şey oluşturmasına yardımcı olacaktı.
Bu nedenle oldukça alışılmadık bir yaklaşım benimsedi. MVP'si bir tanıtım videosuydu. Evet, doğru; Dropbox ile dosyaları senkronize etmenin kesintisiz deneyimini gösterdiği, ürününü açıklayan bir video hazırladı.
Drew bu videoyu hedef kitlesine göstermeye başladığında, aldığı tepki beklediğinden çok daha iyiydi. Dropbox'ın web sitesi trafiği birkaç yüz bine yükseldi ve beta sürümünü denemek için bekleme listesine 75.000 kişi kaydoldu.
Dropbox'tan Çıkarılan Dersler
Drew ve ekibinin hikâyesinden çıkardığımız muhtemelen bir numaralı ders, yazılım startup'ları dünyasında kalıpların dışında düşünmeniz ve teknik kısıtlamaların kendinizi sınırlamasına izin vermemeniz gerektiğidir.
Drew, kullanıcıların ihtiyaçlarını öğrenmeden ilerlemenin felaketle sonuçlanacağını biliyordu. Bu nedenle tamamen işlevsel bir MVP'ye alternatif bir çözüm bulması gerekiyordu.
MVP'nizin ne olduğu gerçekten önemli değildir. Bir mobil uygulamanın maketi veya tel kafes modeli ya da WordPress üzerine kurulmuş sahte bir web sitesi olabilir. Seçtiğiniz MVP türü geri bildirim almanıza ve varsayımlarınızı test etmenize yardımcı olduğu sürece doğru yoldasınız.
Bizim için ikinci çıkarım ise öğrenme aşamasını atlamak ve ürününüz üzerinde yineleme yapmamak için hiçbir mazeret olmadığıdır.
Have an account? Log In
Örnek #2: Amazon'un Var Olmayan Arka Ucu
Dev bir yazılım şirketine dönüşmeden önce Amazon, ünlü bir şekilde çevrim içi bir kitapçı olarak başladı.
Amazon'un kuruluş hikâyesinin ilginç kısmı, Jeff Bezos'un Amazon vizyonunun yalnızca çevrim içi kitap satmakla ilgili olmamasıydı. Hedefleri, dünyanın en büyük çevrim içi kitapçısı olmaktan çok daha büyüktü (Amazon'un bugünkü büyüklüğünden de görebileceğimiz gibi).
Kitaplarla başlamayı seçmesinin nedeni oldukça pragmatikti—kitapları bulmak kolaydı ve dünya genelinde gönderimleri ucuzdu.
Shopify, WooCommerce ve kullanıma hazır birçok diğer araç sayesinde bugün çevrim içi mağaza oluşturmak son derece kolay. Ancak Bezos'un Amazon'u başlattığı 1994 yılında, hem ön yüz hem de arka yüz dahil olmak üzere mağazanın tamamını sıfırdan geliştirmesi gerekiyordu.
Jeff'in baştan sona bir çevrim içi mağaza oluşturmak için yatırım yapma imkânı yoktu. Bu nedenle girişimleri yönetmek için “Oz Büyücüsü” yaklaşımını benimsedi. Ön yüzü hazırdı—insanların kitaplara göz atabildiği, kitapları sepetlerine ekleyebildiği ve sipariş verebildiği bir çevrim içi mağaza.
Ancak bir arka yüz ve bu siparişlerin otomatik olarak işlenmesini sağlayan bir sistem yoktu. Amazon'da biri kitap satın aldığında Jeff kitabı bizzat fiziksel bir kitabevinden alıyor ve kamu posta hizmetini kullanarak müşterisine gönderiyordu.
Bu yaklaşım, Jeff'in büyük bir başlangıç yatırımı yapmadan bir iş kurmasına olanak tanımasının yanı sıra, hem yönettiği web sitesi hem de ürünleri çevrim içi satma sürecinin tamamı hakkında erkenden kullanıcı geri bildirimi almasını sağladı.
Jeff, kullanıcı geri bildirimlerini sürekli olarak hizmetine dâhil etti ve 1999 yılına gelindiğinde Amazon, bugün bize daha tanıdık gelen bir yapıya dönüşmüştü.
Jeff, kullanıcı geri bildirimlerini hayata geçirmenin yanı sıra web sitesine yeni ürün kategorileri ekleyerek daha büyük hedefinin peşinden gitmeye başladı. 1999'da Amazon; müzik, videolar, elektronik ürünler, oyuncaklar ve diğer ürün türlerini zaten satıyordu.
Amazon'dan Çıkarılan Dersler
Jeff, şirketlerini “annelerinin garajında” kuran eski usul girişimcilerden biri. Tam kapsamlı bir web sitesini karşılayamadığı için “Oz Büyücüsü” yaklaşımını kullanmış olsa da sonunda ürünü geliştirmeden önce iş modelinin işe yarayıp yaramadığını kontrol etme yönündeki en iyi uygulamayı izledi.
Örnek #3: Zappos'un Nakit Açığı Veren MVP'si
Şimdi e-ticaretin öncülerine devam edelim ve on binlerce ürün sunan, milyarlarca dolarlık gelir elde etmiş, giyim ve hazır giyim konusunda uzmanlaşmış dev bir çevrim içi mağaza olan Zappos'tan bahsedelim.
Zappos'un hikâyesi, kurucusu Nick Swinmurn'ün 1999 yılında yakındaki alışveriş merkezinde istediği belirli bir çift ayakkabıyı bulmak için uzun süre uğraşması ancak bulamamasıyla başlar. Fiziksel mağazalardaki sorunu hızla fark etti—her zaman sınırlı sayıda ayakkabı modeli bulunduruyorlardı, çünkü geniş bir ürün seçkisini stoklamak her bir mağazanın depolama ve ambar maliyetlerini artırıyordu.
Bu nedenle ayakkabı markaları, işlettikleri orta büyüklükteki ve küçük mağazaların çoğunda genellikle yalnızca en popüler ve yaygın modelleri sergilemeyi ve satmayı, daha niş modelleri ise sadece en büyük mağazalarında bulundurmayı tercih ediyordu.
Bu, ana akım olmayan bir şey istediğinizde onu yerel alışveriş merkezinizde bulamayacağınız ve favori markanızı satan en yakın mağazaya gitmek için uzun bir mesafe katetmeniz gerektiği anlamına geliyordu.
Öte yandan bir çevrim içi mağaza, küçük bir alışveriş merkezine sahip küçük bir kasabada ya da dev mağazaların bulunduğu büyük bir metropol alanında yaşayan kullanıcılar fark etmeksizin, teorik olarak sınırsız sayıda ürünü herkese sergileyebilir.
Tıpkı Amazon'daki Jeff gibi Nick'in de baştan sona bir çevrim içi mağaza oluşturacak maddi gücü yoktu. Teorik olarak yatırımcılardan bu fonları isteyebilirdi, ancak çevrim içi mağazasının başarısız olması ve sonunda yatırımcıların parasını kaybetmesi riskini gerçekten almak istemiyordu.
Bu nedenle Amazon'la aynı yolu izledi ve bir “Oz Büyücüsü” web sitesi başlattı. Nick yerel alışveriş merkezlerine gitti, orada bulunan tüm ayakkabıların fotoğraflarını çekti ve bu fotoğrafları MVP web sitesinde satılık ürünler olarak yayımladı.
Bir kullanıcı Zappos.com'da sipariş verdiğinde Nick yerel alışveriş merkezinde o modeli satan mağazaya gidiyor, ürünü satın alıyor ve posta yoluyla müşteriye gönderiyordu. Tahmin edebileceğiniz gibi Nick, mağazayı yürüttüğü “Oz Büyücüsü” yöntemiyle kâr etmiyordu. Aslında para kaybediyordu.
Ancak Nick'in bu noktada en çok önem verdiği şey kâr-zarar dengesi değildi. İki şeyi elde etmek istiyordu—müşterilerden geri bildirim almak ve iş modelini doğrulamak.
Zappos.com'un satış gelirlerinden ve sunduğu ürün sayısından görebildiğimiz gibi Nick'in iş modeli işe yarıyordu ve bu, büyük bir başarıya yol açtı.
Zappos'tan Çıkarılan Dersler
Zappos ve Nick'in şirketin concierge MVP sürümünü işletme şekli, girişimler hakkında çok önemli bir şey öğretiyor: para kaybetmek sorun değildir.
Bir dakika, bunu açıklığa kavuşturalım. Genel olarak bir işletmenin para kaybetmesi sorun değildir diyemeyiz. Ancak bir işletme MVP aşamasındaysa zararına faaliyet göstermek kabul edilebilir; çünkü MVP ürünlerinin size para kazandırması amaçlanmaz. Bunun yerine amaçları, müşterilerinizden geri bildirim almak ve girişim fikrinizi doğrulamaktır.
Örnek #4: Buffer'ın Geliştirme Öncesi Açılış Sayfası
Biz ürün yöneticileri Jira veya Monday.com'u araç setimizde vazgeçilmez araçlar olarak gördüğümüz gibi, sosyal medya yöneticileri de Buffer'ı günlük işlerinin vazgeçilmez bir parçası olarak görür.
Ancak tam teşekküllü bir sosyal ağ yönetim platformu olmadan önce Buffer, tek bir özellik içeren bir uygulama olarak başladı.
Söz konusu özellik, kullanıcıların Twitter'da birden fazla gönderiyi planlayabilmesiydi. Bu özelliğe sahip Twitter istemcileri zaten vardı; ancak Buffer'ın kurucu ortağı ve CEO'su Joel Gascoigne, planlama sürecinin etrafında kusursuz ve kullanımı kolay bir kullanıcı deneyimi oluşturarak planlamayı keyifli hâle getirmek istiyordu.
Özellikle, kullanıcıların her tweet için ayrı ayrı yapmak yerine çok sayıda tweet'i aynı anda planlayabilmesini sağlayacak bir kullanıcı deneyimi tasarlamıştı (özellik, daha önce bahsedilen Twitter istemcilerinde bu şekilde çalışıyordu).
Joel, fikrinin kolayca başarısız olabileceğini biliyordu; bu nedenle hayal edilebilecek en yalın değerli ürünü oluşturmaya yöneldi. Bu, çalışan bir uygulama değil, basit bir açılış sayfasıydı.
Açılış sayfasını ziyaret eden kişiler Buffer'ın özellikleri hakkında bilgi okuyup kaydolmak için tıklıyordu. Ancak Buffer kullanıcıları uygulamaya erişmek yerine ürünün henüz hazır olmadığını belirten bir mesaj ve Buffer ekibinin ürün kullanıma hazır olduğunda kendilerine bildirim gönderebilmesi için e-posta adreslerini bırakmalarını isteyen bir istem görüyordu.
Buffer'a erişmek için e-posta adreslerini bırakan kullanıcıların sayısı (bu sayı oldukça fazlaydı), Joel'e bu ürünü geliştirmek için zaman ve para harcamanın değerli olduğuna dair bir sinyal verdi.
Joel, ürüne olan ilgi düzeyini belirlemenin yanı sıra topladığı e-posta listesini kullanıcılarla iletişime geçmek, onlarla konuşmak, planlama aracını nasıl kullanmayı planladıkları hakkında daha fazla bilgi edinmek ve diğer uygulamalarda yaşadıkları sorunları daha derinlemesine anlamak için de kullandı.
Buffer'dan Çıkarılan Dersler
Ürününüzle ilgilenen kişilerden oluşan bir liste elde etmeyi hiç başardınız mı? Elde edeceğiniz 1 numaralı fayda, öğrenme fırsatıdır. Katılıyorum, bu kişiler aynı zamanda gelecekteki erken benimseyenlerinizdir; ancak size kazandıracakları para büyük olasılıkla önemsiz bir miktar olacaktır. Buna karşılık öğreneceğiniz dersler paha biçilmezdir.
Örnek #5: Spotify'ın Beta Sürümü
Muhtemelen şu anda dizüstü bilgisayarınızın arka planında lo-fi çalışma listesi çalan yayın hizmeti, Daniel Ek ve Martin Lorentzon'un o dönemde müzik sektöründe var olan ilginç bir sorunu ele almaya karar verdiği 2008 yılında başladı.
Sorun şuydu: Bir şarkıyı dinlemek istiyorsanız onu satın almanız gerekiyordu (2009'da fiyatı 1-2 dolar arasındaydı). Bu da ya sevdiğiniz her şeyi içeren kapsamlı bir çalma listesi oluşturmak için yüzlerce veya binlerce dolar harcamanız ya da satın almaya gücünüzün yettiği birkaç şarkıyla yetinmeniz gerektiği anlamına geliyordu.
Daniel ve Martin'in bu sorunu çözecek devrim niteliğinde bir fikri vardı: Aylık abonelik ücreti ödeyip istediğiniz kadar şarkı dinleyebileceğiniz, “sınırsız açık büfe” gibi çalışan bir yayın hizmeti.
Önceki birçok MVP örneğinden farklı olarak Spotify'ın arkasındaki ekip, gerçekten de tamamen çalışan bir yazılım prototipi geliştirdi ve bunu beta testi için müzik blog yazarları arasında dağıttı.
Kaynak: Prototypr
Spotify mühendisleri yalnızca temel işlevlerini içeren bir ürün sürümü oluşturmakla kalmadı; Spotify'dan yayın yapmanın, kullanıcıların cihazlarının sabit diskinde depolanan bir şarkıyı çalmak gibi hissettirmesi için altyapılarını geliştirmek ve gecikmeyi azaltmak üzere aylar harcadılar.
Dağıttıkları beta sürümü büyük bir başarı elde etti ve kısa süre içinde binlerce kullanıcı müzik dinlemenin bu yeni ve devrim niteliğindeki yolunu denemek için akın etmeye başladı.
Spotify'dan Çıkarılan Dersler
Spotify, bir MVP'deki V'yi unutmamanın harika bir örneğidir. Önemli olan, ürünün mini sürümünün pazarda uygulanabilir ve dolayısıyla değerli olmasıdır.
Ayrıca, yokluğunun ürününüzün potansiyel kullanıcılarınız için sunduğu temel değer önerisine zarar vereceğini düşünüyorsanız, tek bir özelliği uygulamak için aylar harcamanızda sakınca yoktur.
More Articles
Örnek #6: Airbnb'nin Konsiyerj Testi
Başarılı MVP'lerle ilgili son örnek olay incelememiz, seyahat ve konaklama platformu Airbnb hakkındadır.
Hikâyeleri, kurucu ortaklar Brian Chesky ve Joe Gebbia'nın San Francisco'daki dairelerinin kirasını ödeyecek yeterli paraları olmadığını fark ettikleri 2007 yılında başlar.
Kira masraflarını karşılamak için kısa süre içinde, o sırada şehirde gerçekleşmekte olan bir tasarım konferansına katılanlara uyuma alanı olarak dairelerindeki yatakları kiralamaya karar verdiler.
Bunun üzerine dairelerinin fotoğraflarını çekip, “konaklama hizmetleri” için oluşturdukları küçük bir web sayfasına yüklediler. Fikir işe yaradı ve Airbnb ekibi, web sitelerinin insanların başkasının evinde konaklama bulup rezervasyon yapacağı platform olarak hizmet verdiği bir iş kurmak ve bunu ölçeklendirmek üzere karar aldı.
Amazon ve Zappos gibi onlar da, web sitelerinde sundukları ilk konaklama kendi daireleri olduğu için Oz Büyücüsü MVP yaklaşımını benimsediler.
Bundan sonra, ürün fikirlerini genel olarak ve özellikle de insanların dairelerini para karşılığında başkalarına kiralamaya istekli olacakları hipotezini doğrulamak için kullandıkları MVP'lerinin (rezervasyon için çalışan bir mekanizmaya sahip işlevsel bir web sitesiydi) giderek daha gelişmiş sürümlerini oluşturmaya devam ettiler.
Airbnb'den Çıkarılan Dersler
Bazen MVP'niz tek seferlik bir çalışma değildir ve ürününüzün ve iş modelinizin farklı yönleri hakkında müşteri geri bildirimleri ve içgörüler toplamak için kullandığınız MVP'nizin farklı sürümlerini (her seferinde yeni özellikler ekleyerek) oluşturmaya devam edersiniz.
Her şey, iş modelinizi düşük maliyetle test etmekle ilgilidir.
Yukarıdaki başarı öykülerinden gördüğümüz üzere MVP, ürün yönetimi ders kitaplarındaki başka bir kavramdan ibaret değildir. Bu gerçek bir şeydir ve MVP'ler oluşturmak, birçok ünlü dijital ürünün, kurucuları ve ürün geliştirme ekibi onları geliştirmek için aylar sürecek yoğun bir çalışmaya başlamadan önce doğrulanmasına yardımcı olmuştur.
Bunun gibi daha fazla içgörü için bültenimize abone olmayı unutmayın!
