"Bu fikir tutar mı?" Uygulama fikriyle bize gelen girişimcilerin neredeyse hepsi bu soruyu soruyor ve çoğu zaman cevabı yazılımdan bekliyor. Oysa bir fikrin tutup tutmayacağını anlamanın en ucuz yolu, uygulamayı yazmadan önce sorunun gerçekten var olduğunu, insanların bunun için zaman ya da para ayırdığını ve sizin onlara ulaşabildiğinizi kanıtlamaktır. MVP (Minimum Viable Product, minimum uygulanabilir ürün) bu kanıtı toplamak için çıkarılan en küçük ürün sürümüdür; amacı satmaktan çok öğrenmektir. Bu rehberde bir mobil uygulama fikrini problem görüşmelerinden ilk ölçümlere kadar dokuz adımda nasıl doğrulayacağınızı anlatıyoruz.
MVP nedir, ne değildir?
MVP, kapsamı daraltılmış ama gerçek kullanıcıya gerçek değer sunan bir üründür. "Yarım yapılmış uygulama" ya da "ucuz sürüm" değildir. Bir yemek tarifi uygulaması düşünün: MVP, yüzlerce özelliğin kötü bir kopyası değil; tek bir işi, örneğin "evdeki malzemelerle 20 dakikada yapılacak tarif önerisini" iyi yapan bir sürümdür. Kullanıcı bu tek işin işine yarayıp yaramadığını size davranışıyla söyler.
MVP ile karıştırılan üç kavramı ayırmak işinizi kolaylaştırır:
- Prototip: Tıklanabilir ekranlardan oluşur, arkasında çalışan bir sistem yoktur. Kullanılabilirliği ve akışı test eder.
- Kavram kanıtı (PoC): Teknik bir sorunun çözülebildiğini gösterir; örneğin bir sensör verisinin telefona istenen hızda aktarılabildiğini. Kullanıcı ihtiyacını test etmez.
- MVP: Gerçek kullanıcıların gerçek koşullarda kullandığı, davranışlarının ölçüldüğü ilk üründür.
Doğru sıra genellikle problemi doğrulamak, prototiple çözümü denemek ve ancak ondan sonra MVP'yi geliştirmektir.
Adım adım fikir doğrulama
Problemi tek cümleyle yazın. Neden: Belirsiz bir problem, belirsiz bir ürün doğurur. Nasıl: "[Kim], [hangi durumda], [ne sorun] yaşıyor ve bugün bunu [nasıl] çözüyor" kalıbını doldurun. Örnek: "İzmir'de iki üç şubeli kafe işletmecileri, haftalık vardiya planını WhatsApp grubunda yapıyor ve son dakika değişikliklerinde kimin geleceğini takip edemiyor." Bu cümleyi yazamıyorsanız henüz bir probleminiz değil, bir çözüm fikriniz var demektir.
Varsayımları listeleyin ve en riskli olanı seçin. Neden: Her fikir birkaç varsayımın üzerinde durur ve biri yanlışsa diğerleri önemini yitirir. Nasıl: Varsayımları dört başlıkta toplayın: problem gerçekten var mı, insanlar çözüm için ödeme yapar ya da alışkanlık değiştirir mi, onlara makul bir maliyetle ulaşabilir misiniz, teknik olarak yapılabilir mi? Her birini "ne kadar eminim" ve "yanlışsa ne kadar zarar eder" diye puanlayın. En az emin olduğunuz ve en çok zarar verecek varsayım ilk test edeceğiniz şeydir.
Problem görüşmeleri yapın. Neden: Anketler insanların ne düşündüğünü değil, ne düşündüklerini sandıklarını ölçer; görüşme ise geçmiş davranışa iner. Nasıl: Hedef kitleden kişilerle yarım saatlik görüşmeler planlayın ve fikrinizi anlatmadan dinleyin. "Böyle bir uygulama kullanır mıydınız?" yerine "Bu sorunu en son ne zaman yaşadınız, o gün ne yaptınız, bunun için şu an ne kullanıyorsunuz, ne kadar zaman ya da para harcıyorsunuz?" diye sorun. İnsanlar nazik oldukları için fikirlere "güzel" der; ama sorunu çözmek için bugün zaten bir şey yapıyorlarsa, örneğin Excel tutuyor, birine para ödüyor ya da başka bir uygulamayla boğuşuyorlarsa bu çok daha güçlü bir sinyaldir. Görüşme notlarını aynı şablonla tutun ki sonradan karşılaştırabilesiniz.
Talebi küçük bir deneyle ölçün. Neden: Görüşmeler problemi doğrular, ama insanların harekete geçip geçmeyeceğini göstermez. Nasıl: Ürünü anlatan tek sayfalık bir açılış sayfası hazırlayın, bekleme listesi formu ekleyin ve hedef kitleye küçük bir bütçeyle ulaşın. Ziyaretçinin ne kadarının e-posta bıraktığı, hatta ön sipariş ya da kapora verip vermediği değerli bir veridir. Reklamla trafik getirecekseniz Meta reklamları başlangıç rehberimiz kurulumu anlatıyor; insanların problemi arama motorunda ne sıklıkla ve hangi kelimelerle aradığını görmek için de anahtar kelime araştırması iyi bir başlangıçtır.
Tıklanabilir prototiple çözümü deneyin. Neden: Tasarım aşamasında akışı değiştirmek, kodlanmış bir ekranı değiştirmekten çok daha ucuzdur. Nasıl: Figma gibi bir araçla ana akışın ekranlarını çizin ve birbirine bağlayın. Katılımcıya bir görev verin ("Yarınki vardiyada eksik kişiyi bulun ve ona haber verin") ve sessizce izleyin; nerede durakladığını, neyi aradığını not edin. Nielsen Norman Group'un yaygın olarak bilinen tavsiyesine göre her test turunda beş kullanıcıyla deneme yapmak kullanılabilirlik sorunlarının büyük kısmını ortaya çıkarmaya yeter; tek büyük test yerine küçük ve tekrarlanan turlar daha verimlidir.
MVP kapsamını daraltın. Neden: Kapsam büyüdükçe öğrenme gecikir, maliyet artar ve sonuçları yorumlamak zorlaşır. Nasıl: Kullanıcının uygulamaya geldiği tek ana işi seçin ve o işe hizmet etmeyen her şeyi "sonra" listesine yazın. Aşağıdaki sorular kapsamı netleştirir: Bu özellik olmadan ana iş yapılabiliyor mu? Bu özellik hangi varsayımı test ediyor? Elle ya da hazır bir araçla geçici olarak çözülebilir mi? Profil fotoğrafı, karanlık mod, çoklu dil, sosyal giriş seçenekleri ve gelişmiş raporlar çoğu zaman ilk sürüme girmek zorunda değildir.
Başarı ölçütlerini geliştirmeden önce yazın. Neden: Sonuçlar geldikten sonra hedef belirlerseniz her sonucu başarı gibi okumaya meyilli olursunuz. Nasıl: Üç tür ölçüt belirleyin. Aktivasyon: Kayıt olan kullanıcının ne kadarı ana işi ilk kez yaptı? Elde tutma: Kullanıcılar birinci gün, yedinci gün ve otuzuncu gün geri geliyor mu? Değer: Ana iş haftada kaç kez yapılıyor, ücretli plana geçen var mı? Ardından bir olay planı çıkarın:
kayit_tamamlandi,ilk_vardiya_olusturuldu,degisiklik_bildirimi_gonderildigibi olay adlarını ve hangi ekranda tetikleneceklerini önceden yazın. Firebase için Google Analytics gibi bir araç bu olayları kurulumdan itibaren toplar.Küçük ve tanıdık bir grupla yayına çıkın. Neden: İlk kullanıcılarla doğrudan konuşabilmek, rakamların nedenini anlamanızı sağlar. Nasıl: Herkese açık bir lansman yerine görüşme yaptığınız kişilerden ve bekleme listesinden seçtiğiniz bir grupla başlayın. iOS'ta TestFlight, Android'de kapalı test kanalı bu iş için uygundur; mağazaya çıkış adımlarını App Store ve Google Play yayınlama rehberimizde anlattık. Kullanıcılara uygulama içinden kolayca geri bildirim gönderebilecekleri bir yol açın ve ilk haftalarda birkaç kişiyle yeniden görüşün.
Karar verin: devam, yön değişikliği ya da durdurma. Neden: Doğrulamanın amacı bir karara varmaktır; sonuçsuz biten bir MVP, belirsizliği yalnızca ertelemiş olur. Nasıl: Yedinci adımda yazdığınız ölçütlere bakın. Kullanıcılar ana işi düzenli yapıyor ve geri dönüyorsa kapsamı genişletme zamanıdır. İlgi var ama kullanım düşükse çözümün biçimini (yön değişikliği) sorgulayın. Problem görüşmelerinde bile güçlü bir sinyal yoksa durmak, aylar sonra durmaktan çok daha ucuzdur.
Hangi MVP türü sizin için uygun?
MVP her zaman bir mobil uygulama olmak zorunda değildir. Test etmek istediğiniz varsayıma göre çok daha hafif biçimler de işe yarar:
| MVP türü | Nasıl çalışır? | Neyi test eder? | Emek |
|---|---|---|---|
| Açılış sayfası | Ürünü anlatan sayfa ve bekleme listesi | Talep ve mesajın çekiciliği | Çok düşük |
| Concierge | Hizmeti elle, kişisel olarak sunarsınız | Değer önerisi ve ödeme isteği | Düşük yazılım, yüksek zaman |
| Wizard of Oz | Arayüz otomatik görünür, arkada işi insan yapar | Kullanıcı deneyimi ve akış | Orta |
| Web uygulaması | Tarayıcıda çalışan sade bir sürüm | Ana işin kullanımı ve elde tutma | Orta |
| Tek özellikli mobil uygulama | Yalnızca ana akışı içeren uygulama | Mobil kullanım alışkanlığı, bildirim etkisi | Orta-yüksek |
Ürününüzün değeri bildirim, konum, kamera ya da çevrimdışı kullanım gibi telefona özgü yeteneklere dayanıyorsa MVP'yi doğrudan mobil yapmak mantıklıdır. Değer bir hizmette ya da eşleştirmedeyse, önce concierge veya web sürümüyle öğrenip mobil uygulamaya sonra geçmek bütçeyi korur. Mobil yapmaya karar verdiğinizde Flutter gibi tek kod tabanlı bir yaklaşım, iOS ve Android'i aynı anda test etmenizi sağlar; teknoloji seçimini native ve cross-platform karşılaştırmamızda ele aldık.
Örnek senaryo: vardiya planlama uygulaması
Yukarıdaki kafe örneğini sürdürelim; bu senaryo tamamen örnek amaçlıdır. Girişimci, problem görüşmelerinde işletmecilerin çoğunun vardiyayı WhatsApp ve kâğıt çizelgeyle yönettiğini, en çok son dakika değişikliklerinden yakındığını öğrenir. Fikrin ilk hâlinde maaş hesabı, izin takibi, stok sayımı ve müşteri sadakat modülü de vardır.
Varsayım puanlamasında en riskli madde şu çıkar: "İşletmeciler, çalışanlarını yeni bir uygulamaya geçirmeye ikna edebilir mi?" Bu yüzden MVP yalnızca üç ekrana iner: haftalık plan, değişiklik talebi ve anlık bildirim. Maaş ve stok modülleri listeden çıkarılır. Başarı ölçütü önceden yazılır: ilk ay sonunda pilot işletmelerin planlarını uygulama üzerinden yapmaya devam etmesi ve çalışanların bildirimleri açık tutması. Sonuçlar olumlu gelirse ikinci aşamada izin takibi eklenir; olumsuz gelirse ekip, çalışanları uygulamaya taşımak yerine işletmecinin WhatsApp'a otomatik mesaj attığı daha hafif bir modeli dener.
Bu yaklaşımda yazılım bütçesinin büyük kısmı öğrenme sonrasına kalır. Kapsamın maliyete etkisini merak ediyorsanız mobil uygulama bütçe rehberimizde kalem kalem anlattık.
Sık yapılan hatalar
- Yakın çevreyi hedef kitle sanmak: Arkadaş ve aile görüşleri iyi niyetlidir ama ödeme davranışını yansıtmaz.
- Özellik isteklerini doğrudan yol haritasına yazmak: Kullanıcı istediği çözümü söyler; sizin işiniz arkasındaki problemi anlamaktır.
- İndirme sayısına bakmak: İndirme, ilk izlenimi ölçer. Asıl sinyal, kullanıcının ana işi tekrar tekrar yapmasıdır.
- Ölçümü sonraya bırakmak: Olay takibi kurulmadan yayına çıkan bir MVP, en değerli ilk haftaların verisini kaybeder.
- Mükemmel tasarım için beklemek: İlk sürümün temiz ve anlaşılır olması yeterlidir; cila, değer kanıtlandıktan sonra gelir.
- Arka ucu baştan büyük ölçeğe göre kurmak: Binlerce eş zamanlı kullanıcıya hazırlanmak, henüz on kullanıcınız yokken zaman kaybıdır. Yine de veri modelini ve güvenliği gelişigüzel bırakmayın.
Sık Sorulan Sorular
MVP geliştirmek ne kadar sürer?
Kapsama göre değişir. Açılış sayfası ve görüşmelerle yapılan doğrulama birkaç hafta sürebilir; tek ana akışlı bir mobil MVP ise genellikle birkaç aylık bir iştir. Süreyi belirleyen asıl etken özellik sayısı ve arka uç gereksinimleridir.
Fikrimi anlatırsam çalınır mı?
Fikirler nadiren çalınır; zor olan onları uygulamaktır. Problem görüşmelerinde zaten çözümünüzü değil, kullanıcının yaşadığı sorunu konuşursunuz. Yine de teknik detayları paylaşacağınız iş ortaklarıyla gizlilik sözleşmesi imzalamak makul bir önlemdir.
Kaç kişiyle görüşmem yeterli?
Kesin bir sayı yoktur. Pratikte yeni görüşmeler artık yeni bir şey söylemediğinde, yani cevaplar tekrar etmeye başladığında yeterli noktaya yaklaşmışsınızdır. Farklı alt grupları (küçük ve büyük işletme gibi) ayrı ayrı dinlemek önemlidir.
MVP'yi kodsuz (no-code) araçlarla yapabilir miyim?
Evet, özellikle web tabanlı MVP'ler ve iç araçlar için iyi bir seçenektir. Sınırlar genellikle performans, cihaz özelliklerine erişim ve veri sahipliğinde ortaya çıkar. Kodsuz araçla değeri kanıtlayıp sonra kalıcı bir altyapıya geçmek sık kullanılan bir yoldur.
Aynı işi yapan bir rakip varsa fikrim değersiz mi?
Hayır; rakip olması çoğu zaman pazarın var olduğunu gösterir. Asıl soru, rakibin hangi kullanıcı grubunu iyi hizmet veremediği ya da hangi işi zahmetli bıraktığıdır. Problem görüşmelerinde rakip ürünü kullananlara neyi sevmediklerini ve neden hâlâ başka yöntemlerle desteklediklerini sorun. Mağaza yorumlarındaki tekrar eden şikâyetler de iyi bir başlangıç verisidir. Farkınız "daha çok özellik" değil, belirli bir kitle için daha iyi çözülmüş tek bir iş olduğunda MVP'nin sınaması gereken şey de tam olarak bu farktır.
MVP'den sonra kodu baştan yazmak gerekir mi?
Her zaman değil. MVP'yi temiz bir mimariyle ve doğru teknolojiyle geliştirdiyseniz üzerine inşa etmeye devam edebilirsiniz. Hız için bilinçli kısayollar aldıysanız, bunları not edip ölçeklenme öncesinde temizlemek gerekir.
Fikrinizi birlikte sınayalım
İyi bir MVP, en az kaynakla en net cevabı alan üründür: problem doğrulanmış, kapsam daraltılmış, ölçütler önceden yazılmış ve karar noktası belli. Fikrinizi bu adımlarla netleştirmek, prototip hazırlamak ya da ilk sürümü Flutter ile geliştirmek isterseniz mobil uygulama hizmetimize göz atabilir veya bize yazarak bir ön görüşme planlayabilirsiniz.
