Minimum Uygulanabilir Ürün — Minimum Viable Product, MVP

30 sn özet

Minimum Uygulanabilir Ürün, İngilizce Minimum Viable Product ifadesinin karşılığıdır ve MVP olarak kısaltılır. Temel amacı, önemli bir ürün varsayımını gerçek kullanıcı tepkisiyle sınayarak sonraki yatırım kararını aydınlatmaktır. Kapsam, öğrenilmek istenen soruya göre belirlenir. Dar bir yazılım, elle yürütülen hizmet veya değer önerisini gösteren bir deney bu amaca hizmet edebilir. Ancak her küçük çalışma MVP sayılmaz. Kullanıcının ne yapacağı, hangi kanıtın toplanacağı ve sonuçlara göre nasıl karar verileceği açık olmalıdır. Az özellik geliştirmek, tek başına doğru öğrenmeyi sağlamaz.

Neden önemli?

Bir ürün fikri, ekip içinde güçlü destek bulabilir. Müşteri probleminin önemli olduğu, önerilen çözümün kullanılacağı ve müşterinin bedel ödeyeceği düşünülebilir. Bu kabuller sınanmadan kapsamlı geliştirmeye geçildiğinde şirket aynı anda birçok belirsizliğe yatırım yapmış olur.

MVP, en kritik belirsizliği erken ele almaya yardımcı olur. Ürünün bütününü kurmadan önce hangi bilginin kararımızı değiştireceğini sorarız. Kullanıcı çözümü anlayabiliyor mu? Mevcut yöntemini değiştirmeye istekli mi? Sunulan faydayı gerçekten elde edebiliyor mu? Bu soruların her biri farklı bir deney gerektirebilir.

Yönetici açısından değer, yatırımın aşamalı yapılabilmesidir. İlk çalışma, daha büyük bütçe talebinin dayanağını güçlendirebilir veya yaklaşımın değiştirilmesini gerektirebilir. Başlangıç fikrinin desteklenmemesi de karar için yararlı bir sonuçtur. Önemli olan öğrenilen bilginin sonraki tercihe nasıl yansıdığıdır.

Junior bir iş analisti veya ürün sahibi açısından MVP, kapsam tartışmasına amaç kazandırır. “Bu özellik ilk sürümde olsun mu?” sorusundan önce “Bu özellik olmadan hangi soruya cevap veremeyiz?” sorusu gelir. Böylece kapsamın gerekli parçalarıyla ertelenebilecek parçaları daha açık gerekçelerle değerlendirilir.

Terim nedir?

MVP, ürün geliştirmede doğrulanmış öğrenme elde etmeye yönelik bir yaklaşımdır. Doğrulanmış öğrenme, ürün fikrine ilişkin kabulün kullanıcı davranışı veya başka uygun kanıtlarla sınanması sonucunda edinilen bilgidir. Burada “minimum”, öğrenme için gerekli kapsamı; “uygulanabilir” ise deneye katılan kişinin önerilen değeri anlamlı biçimde deneyimleyebilmesini ifade eder.

Bir varsayım, yeterince doğrulanmamış fakat kararın dayandığı kabuldür. “Mağaza yöneticileri iade taleplerini daha hızlı değerlendirmek için bu hizmeti kullanır” bir varsayımdır. “İade panelini geliştireceğiz” ise yapılacak iştir. MVP planı, yapılacak işi hangi varsayımı sınadığıyla ilişkilendirmelidir.

Çalışmanın biçimi soruya göre değişir. Talebin varlığı araştırılıyorsa hizmeti anlatan bir sayfa ve anlamlı bir başvuru davranışı bilgi sağlayabilir. Kullanıcının çözümü kullanabilmesi araştırılıyorsa bir prototip veya dar bir çalışan akış gerekebilir. Operasyon yükü inceleniyorsa hizmetin gerçek koşullarda elle yürütülmesi daha açıklayıcı olabilir.

Bu çalışmaların kanıt gücü farklıdır. Bir videoyu beğenmek, ürünü düzenli kullanmakla aynı davranış değildir. Başvuru yapmak da ödeme yapmak veya sözleşme yenilemekle eşdeğer tutulamaz. Deneyin neyi gösterdiği kadar hangi soruyu yanıtlamadığı da belirtilmelidir.

MVP ile ilk ticari sürümün amaçları örtüşebilir, fakat kapsam kararlarının gerekçesi açık tutulmalıdır. İlk sürüm belirli müşterilere güvenilir bir hizmet sunmayı hedeflerken MVP çalışması belirli bir kabulü sınamaya odaklanabilir. Kullanıcıya sunulan deneyim her durumda anlaşılır ve verilen vaatle tutarlı olmalıdır.

Minimum kapsam, temel kalite gereksinimlerini keyfî biçimde kaldırma gerekçesi değildir. Gerçek müşteri verisi işleniyorsa verinin korunması, iade kararı öneriliyorsa kararın kontrolü deneyin parçasıdır. Hangi işlemin otomatik, hangisinin insan tarafından yürütüldüğü kullanıcıya doğru aktarılmalıdır. Aksi durumda toplanan tepki, gerçekte sunulamayacak bir hizmete dayanabilir.

Gerçek vaka: Dropbox’ın demo videosuyla topladığı ilgi

WIRED’ın 22 Aralık 2011 tarihli incelemesi, Dropbox’ın Mart 2008’de Digg üzerinde yayımladığı demo videosunun bir gecede yaklaşık 70.000 kayıt getirdiğini aktarır. Video, dosyaların farklı bilgisayarlarda eşitlenmesi deneyimini görünür kılmıştır. Bu, hizmete yönelik ilginin ölçülebilir bir işaretidir.

Drew Houston’ın Dropbox blogundaki 11 Eylül 2008 tarihli lansman yazısı da şirketin o tarihte herkese açık kullanıma geçtiğini ve öncesinde kullanıcıların beta sürecine katıldığını doğrular. Beta, ürünün genel kullanıma açılmadan önce belirli kullanıcılarla denendiği aşamadır.

Bu iki kaynak, videonun çalışan ürün geliştirme süreciyle birlikte değerlendirilmesi gerektiğini gösterir. Vakayı tamamen hayalî bir ürün videosu olarak anlatmak doğru olmaz. Videodan gelen kayıtlar da dosya eşitlemenin bütün koşullarda güvenilir çalıştığını veya kayıt olanların ödeme yapacağını tek başına kanıtlamaz.

MVP açısından çıkarılabilecek ders, erken kanıtın kapsamını doğru okumaktır. Demo, değer önerisine ilgi hakkında bilgi verir. Teknik güvenilirlik, devam eden kullanım ve ticari sonuçlar için başka deneyler ve gözlemler gerekir.

Kaynaklar: WIRED, “With Sync Solved, Dropbox Squares Off With Apple's iCloud”, 22 Aralık 2011.
Dropbox Blog, Drew Houston, “Dropbox launches to the public!”, 11 Eylül 2008.

Varsayımsal örnek: İade değerlendirme hizmeti

Bir girişim, çevrim içi mağazaların iade taleplerini değerlendirmesine yardımcı olmak istiyor olsun. Ekip kapsamlı entegrasyonlar ve otomatik karar sistemi planlıyor. Ancak önce mağaza yöneticilerinin dışarıdan gelen değerlendirmeyi kendi operasyonlarında kullanıp kullanmayacağını öğrenmek gerekiyor.

Varsayım şöyle yazılabilir: “Mağaza yöneticileri, gerekçesi açık ve kendi politikalarıyla uyumlu bir iade önerisini karar sürecinde kullanır.” İlk çalışma, basit bir talep formu ve değerlendirme hizmeti olabilir. İncelemeyi ekip üyeleri elle yapar; bu durum mağazaya açıklanır. Nihai karar mağaza yöneticisinde kalır.

Deney sırasında yöneticinin öneriyi kullanıp kullanmadığı, ek bilgi ihtiyacı, değerlendirme süresi ve öneriye itiraz nedeni kaydedilir. Yalnızca hizmetin beğenilip beğenilmediği sorulmaz. Kullanıcıların gerçek iş akışındaki davranışları incelenir.

Öneriler kullanılmıyorsa nedeni araştırılır. Mağaza politikası yeterince açık olmayabilir, gerekli bilgi eksik olabilir veya yönetici karar sorumluluğunu devretmek istemeyebilir. Bu nedenler aynı çözümü gerektirmez. Daha fazla otomasyon geliştirmeden önce hangi engelin önemli olduğu anlaşılmalıdır.

Sonuçlar kullanımın değerli olduğunu gösterirse bir sonraki yatırım belirli bir adımı otomatikleştirebilir. Ancak elle sunulan hizmetin başarısı, otomatik sistemin aynı kaliteyi sağlayacağını kanıtlamaz. Teknik doğruluk ve hizmet ekonomisi ayrıca sınanır. Bu örnek için herhangi bir başarı oranı veya maliyet tasarrufu varsayılmamıştır.

Yaygın 3 hata

MVP’yi özellik sayısını azaltma çalışmasına çevirmek

Kapsam küçülebilir, fakat karar sorusu belirsiz kalabilir. Önce kritik varsayımı yazın. Deneyin hangi kullanıcı davranışından bilgi üreteceğini belirleyin.

İlgi göstergesini kesin talep kanıtı saymak

Video izleme, başvuru, ödeme ve tekrar kullanım farklı kanıtlardır. Sonucun hangi kabulü desteklediğini açıkça belirtin. Daha güçlü bir yatırım kararı için eksik kalan kanıtı araştırın.

Sonuç görüldükten sonra başarı ölçütünü değiştirmek

Beklenen davranış oluşmadığında başka bir göstergeyi öne çıkarmak öğrenmeyi zayıflatır. Karar ölçütünü baştan belirleyin; beklenmedik bulguları da ayrı değerlendirin. Sonuçları başlangıç beklentisiyle birlikte yorumlayın.

Mini uygulama/şablon

Bir MVP çalışması için şu alanları doldurun:

Karar: Deney hangi yatırım tercihini aydınlatacak?
Kritik varsayım: Yanlış çıkarsa planımızı değiştirecek kabul nedir?
Hedef kullanıcı: Hangi grubun hangi ihtiyacına odaklanıyoruz?
Deney: Kullanıcıya hangi dar deneyimi sunacağız?
Gerekli kapsam: Soruyu yanıtlamak için neler bulunmalı?
Kanıt: Hangi davranışı veya sonucu kaydedeceğiz?
Karar ölçütü: Hangi bulguda devam edecek, değiştirecek veya duracağız?
Sınırlar: Deney hangi soruları yanıtlamayacak?
Temel kalite: Verilen vaadi yerine getirmek için hangi koşullar korunmalı?
Sonraki adım: Öğrenilen bilgi hangi yeni çalışmayı gerektiriyor?

Deney sonunda yalnızca çıktıları listelemeyin. Başlangıçtaki kabulün nasıl değiştiğini ve sonraki yatırımın neden gerekli olduğunu yazın. Kapsamı bu öğrenmeye göre yeniden belirleyin.

İlgili terimler

Ürün Keşfi, Problem Keşfi, Varsayım Haritalama, Prototip, Kullanılabilirlik Testi, Ürün-Pazar Uyumu, Aktivasyon, Değer Önerisi, Deney Tasarımı, Önceliklendirme