MVP’nin M’si

Bence bu zamana kadar yazdığım yaklaşık 40 bin kelimelik içeriğin en önemlilerinden birini yazmak üzereyim. En azından ben öyle hissediyorum. MVP kavramına haddinden fazla önem verdiğimi düşünen birçok kişi var. Fakat neden bu kadar önem verdiğimi kendi örneklerim ve diğer vakalarla açıklamaya çalıştığımda, bana hak vereceğinizi düşünüyorum. Hatta şöyle diyeyim, “az bile önemsiyorum”.

MVP konusunu üç yazılık bir seri olarak hazırlayacağım.

İlk yazıda MVP’nin M’sini ele alacağız ve tanım ile başlayıp, nedensellik ilişkileriyle avantajlarını sıralayacağız. Sonunda da MVP nasıl planlanır kısmını inceleyeceğiz.

İkinci yazıda MVP’nin V’sini inceleyeceğiz ve MVP ile pazara çıktıktan sonraki süreci ele alacağız.

Üçüncü yazıda da MVP’nin P’si ile ilgileneceğiz ve ürün yol haritamıza göre gelecekteki özellikleri nasıl ekleyeceğiz, hangi metrikleri takip edeceğiz gibi kısımları ele alacağız.

MVP Nedir?

Usulen tanım ile başlayalım. MVP; Minimum Viable Product‘ın baş harflerinden oluşan ve Türkçe’ye (biraz zorlama da olsa) Minimum Geçerli Ürün olarak çevrilen, problemin temel çözümünü sağlayan, karmaşık olmayan, geliştirmeye açık ürüne verilen addır.

Yani MVP, pazardan hızlı geri bildirim almanızı ve çözümünüzün pazarda atfedileceği değeri anlamanızı sağlayacak, basit fakat fonksiyonel üründür.

MVP Ne Değildir?

MVP Planladığınız Tüm Özelliklerden Birazını İçeren Bir Ürün Değildir!

MVP’deki amaç odaklandığınız temel problemin çözümünün pazardaki değerini ölçmektir. Pazarın, ürününüzün hangi özelliğini kabul ettiğini, hangisini etmediğini ölçümleyeceğiniz bir süreç değildir. Temel amaç, en kısa ve “masrafsız” yoldan temel değer önerinizi test etmektir.

Bir örnekle ilerleyelim:

Diyelim ki bir pastaneniz var ve hiç alışık olmayan bir hedef kitleye donut satmayı planlıyorsunuz. İşte bu durumda donutın önce tadı, şekli, yeme kolaylığı, fiyatı gibi önemli detaylarının müşteri tarafında test edilmesi gerekir. Bu testin de en basit donut ile yapılması önemlidir. Çünkü müşterinin bu noktada kafasının karışmaması ve temel ürün dışında başka bir şeyle meşgul olmaması gerekir. Eğer pazar, donutları beğenir ve siz de çeşitli satış rakamları ve geri bildirimlerle bunu ispatlarsanız, işte o zaman donut çeşitlerini üretmeye ve rafa koymaya başlarsınız.

MVP Yarım Bir Ürün Değildir!

Burada birçok kişinin yanılgıya düştüğüne defalarca şahit oldum. MVP yarım yamalak bir ürünü pazarda test etmek değildir. Amacı tekrar hatırlayalım; temel çözüm fonksiyonlarının pazarda bulacağı değeri tespit etmek. Bu yüzden, geri kalan her şey tam olmasa bile çözüm tam olmalıdır.

Burayı da bir örnekle açıklayalım:

Aynı pastanede bu sefer de çikolatalı bir artizan ekmek yapmayı planladığınızı düşünelim. Bu ekmeği onlarca üretip stoklamaktansa MVP olarak bir veya iki tane ekmek yapıp, küçük dilimler halinde pazarın nabzını ölçmek doğru yoldur. Fakat müşterinize yarı pişmiş bir ürünü servis ederseniz, tam ürünün minimal ölçeğini değil, tam ürünle hiç alakası olmayan bir ürün çıkarmış olursunuz. Evet MVP hız demektir, doğru! Fakat bu hızlılık tamamlanmamış ürünü sunmak değildir.

MVP Geliştirmeye Kapalı Olan Bir Ürün Değildir!

MVP süreklilik arz eden bir süreçtir. Bu, her sürümde ürüne değer katmaya devam edeceğiniz anlamına gelir. MVP sadece bir temeldir, inşa etme süreci devam etmelidir.

MVP İle Başlamanın Avantajları

Bu başlığı birkaç açıdan ele alalım ve ilk olarak maliyet ve bütçe kısmına odaklanalım.

Karşılığında parasal olarak bir kazanç elde etmek istiyorsanız, ürününüzün bir problemi çözmesi gerekir. Fakat bu problem pazarda karşılığını bulana kadar sadece bir hipotezdir. İşte bu hipotezi doğrulamak için MVP’ye ihtiyacınız vardır. Çünkü sizin problem olarak tanımladığınız durum, pazar için bir problem olmayabilir. Ya da önerdiğiniz çözüm pazar tarafından reddedilebilir. Bu ihtimalleri ölçerken minimum bir bütçe ile yola çıkmak gerekir. Spotify örneğiyle bunu açıklayalım:

2008 yılında, Daniel Ek ve Martin Lorentzon, insanların şarkıları indirmekten ve bu şarkıları düzenlemekten bıktıklarıyla ilgili bir hipotez geliştirdiler. Özellikle iPod gibi akıllı cihazların yükselişi göz önüne alındığında, bu hipotezin pazarda karşılığını bulması çok büyük bir fırsat gibi görünüyordu. Ancak bu hipotezi doğrulamadan pazara giremeyeceklerini biliyorlardı. İnsanların indirme yapmadan sadece “müzik akışı” fikriyle ilgilenip ilgilenmediklerini test etmek için bir lo-fi masaüstü uygulaması oluşturdular ve kapalı beta testi yaptılar. İşte bu MVP, freemium modeliyle tam olarak insanların istediği şey olduğunu kanıtladı. Listeler yapmak, podcast yayınları yüklemek ya da dinlemek, premium üyelik özellikleri gibi tüm ek özellikler zaman içerisinde ve kullanıcıların ihtiyaçları doğrultusunda eklendi. Eğer Spotify bu ilave özellikleri (2008’deki teknoloji ile dahi) MVP’lerine ekleselerdi, pazarın temelde canını sıkan problem olan “dinlemek istedikleri şarkıya ulaşmadaki çetrefilli süreç ve bunu cihazlarına indirme zaruretini” yine çetrefilli bir yolla çözmeye kalkışmış olacaklardı. Bu da belki de pazar tarafından kabul görmemelerine neden olacaktı. İyi ihtimalle Daniel ve Martin, temel problemin çözümü dışındaki özellikleri uygulamadan çıkarıp tekrar deneyebilirlerdi. O zaman da 2x israf yapılmış olacaktı: Kabul görmeyen özelliklerin uygulamaya eklenmesi için harcanan zaman, emek ve para ve bu özelliklerin tekrar uygulamadan çıkarılması için harcanan zaman, emek ve para.

İkinci konu ise yatırım. Büyük projeler büyük bütçeler gerektirir. Bu da günün sonunda kendinizi bir yatırımcı karşısında bulmanızın kaçınılmaz olduğu demektir. Bir ürün fikri ne kadar büyük bir potansiyele sahip olursa olsun, yatırımcıları bu potansiyele inanmaları konusunda ikna etmek kolay bir süreç değildir.

‘Buy-in’ olarak adlandırılan, piyasa tarafından kabul edilen bir MVP, yatırımcıya fikrinizin potansiyelinin kanıtını gösterir. Bu durumda tamamen teorilerden ibaret bir fikir yerine, kapalı bir beta sürümü dahi olsa pazarca onaylanmış ve çözümü kabul görmüş bir MVP, yatırımcının ilk adımı atma kararında yardımcı olabilir.

MVP Nasıl Planlanır?

Geldik işin en zor kısmına. Bu kadar teorik bilgiden sonra bir MVP nasıl olmalı ve nasıl planlanmalı sorusunun cevabını aramadan olmaz. Bunun için 4 basamaklı bir süreci takip edebiliriz.

1-Pazar İhtiyaçlarını Anlayın

İlk adım, ürününüze piyasada bir ihtiyaç olup olmadığını belirlemektir. Bu, kurumsal bir ihtiyaç veya mevcut bir boşluğu ele alan bir müşteri ihtiyacı olabilir. Rakiplerinizin ne yaptığını analiz etmek ve ürününüzü nasıl öne çıkarabileceğinizi belirlemek de önemlidir. Bu, başarılı olmak için ne tür bir ürüne ihtiyacınız olduğunu belirlemenize yardımcı olacaktır.

Ürününüze ihtiyaç olduğunu belirledikten sonra, uzun vadeli hedefler belirlemeniz gerçekten önemlidir: Neyi başarmayı planlıyorsunuz? Ardından, ürününüzün başarısını neyle ölçeceğinizi belirleyebilirsiniz. Tüm bunlar için bir yalın kanvas hazırlayabilirsiniz.

2-Müşteri Satın Alma Yolculuğunu Anlayın

Ürününüzü kullanıcılarınızı düşünerek tasarlamanız önemlidir. Bunun için de yukarıda belirlediğiniz problemin çözümüne ulaşmada kullanıcıların satın alma yolculuklarının haritasını çıkarmak iyi bir yoldur. Bu yolculuğu anlamak, kullanıcıların ürününüzle karşılaşma anından satın alma gibi nihai bir hedefe ulaşana kadar hangi süreçlerden geçtiğini onların gözünden görmenizi sağlar. Böylece ürününüzü kullanıcılar için uygun bir şekilde nasıl tasarlayabileceğiniz konusunda birçok fikir edinirsiniz. Ayrıca, satın alma yolculuğunu tanımlamak ve bir nihai hedefi tamamlamak için kullanıcıların yapması gereken aksiyonları ele almak, kullanıcı memnuniyetini göz önünde bulundurarak hiçbir şeyi gözden kaçırmamanızı sağlar.

3-Fayda – Maliyet Analizi Yapın

Fayda – maliyet analizi, kullanıcının problematik noktalarını ve her bir problem için önerilen çözümleri elde ettiğindeki kazanımları belirlemenize olanak tanır. Bu analiz, potansiyel olarak en fazla değer katabileceğiniz alanı belirlemenize çok önemli katkılar sağlar. Bu sayede MVP’nizi bu alanlara odaklayabilir ve daha az etkili olacağını düşündüklerinizi gelecekteki sürümler için ürün yol haritanıza ekleyebilirsiniz.

4-Özellikleri Planlayın

Bu aşamada, hangi özellikleri MVP’nize, hangi daha düşük öncelikli özellikleri ise ileriki sürümlere ekleyeceğinizi ayırt edebilirsiniz. MVP’nizi başarılı kılmak için hangi özelliklerin gerekli olduğuna karar vermek için kullanabileceğiniz bazı araçlar bulunmaktadır. Kullanıcının ne istediği ve kullanıcının neye ihtiyacı olduğu sorusunu sormak, özellikleri belirlemeye ve öncelik sırasına koymaya yardımcı olabilir. Kullanıcı tarafından istenen çok sayıda özelliğin erken aşamada uygulanmasının kullanıcı deneyimine zarar verebileceğini ve ürünün genel amacından uzaklaşabileceğini unutmayın. Eklemeniz gereken tek özellik, ürününüzün odaklandığı problemin temel çözümüne bağlı olmalıdır.

Burada, benim de çok sık kullandığım, önceliklendirme matrisinden faydalanabilirsiniz. Bu matrisle, hangi özelliğin en fazla etkiyi nerede yapabileceğinizi belirleyebilirsiniz. Böylece MVP’nize kesinlikle nelerin dahil edilmesi gerektiğine ve sonraki sürümlere hangi özelliklerin dahil edilebileceğine dair kararı görselleştirmiş olursunuz.

Bir başka yöntem ise MoSCoW Önceliklendirmesi yöntemidir. Bu metoda göre özellikler 4 başlık altında toplanır. Bunlar;

• Must Have (Kesinlikle Olmalı)
• Should Have (Olmalı)
• Could Have (Olabilir)
• Won’t Have (Olmamalı)

Buraya kadar MVP’nin M’sini ele aldık. Serinin ikinci yazısında MVP’nin V’sini ele alacağız ve MVP ile pazara çıktıktan sonraki süreci inceleyeceğiz.

Sevgiler