Kazanimlar:
- MVP (minimum uygulanabilir ürün) kavramını ve 'en küçük öğrenme birimi' mantığını kavrayıp yapay zeka ile kapsam belirleyebilme
- Özellik önceliklendirmeyi (MoSCoW, etki-efor) ve yapay zeka destekli hızlı prototip/landing page üretimini uygulayabilme
- MVP'nin amacının satmak değil öğrenmek olduğunu, aşırı mühendisliğin (over-engineering) girişimin en pahalı hatası olduğunu kavrayabilme
Kurucuların en pahalı hatası, kimsenin istediğinden emin olmadıkları bir ürünü aylarca mükemmelleştirmektir. Piyasaya çıktıklarında öğrenirler ki ya problem yanlıştı ya çözüm. Bu felaketi önlemenin yolu MVP'dir: minimum uygulanabilir ürün (Minimum Viable Product — en az çabayla en çok öğrenmeyi sağlayacak en küçük ürün sürümü). Bu ünitede YZ'yi (yapay zeka) MVP kapsamını belirlemek, özellikleri önceliklendirmek ve hızlı prototip/tanıtım sayfası üretmek için kullanacağız. En kritik cümle: MVP'nin amacı satmak değil öğrenmektir; en pahalı hata, doğrulanmamış varsayımlara aşırı mühendislik yapmaktır.
MVP nedir, ne değildir?
MVP yanlış anlaşılan bir kavramdır. MVP, "yarım yamalak, bozuk bir ürün" değildir; belirli bir varsayımı test etmek için gereken en küçük tam deneyimtir. Anahtar kelime "öğrenme"dir. Kendinize sorun: "Hangi soruyu cevaplamaya çalışıyorum?" MVP, o soruyu cevaplayacak kadar — ne eksik ne fazla — özellik içerir. Bir MVP bazen çalışan bir uygulama bile olmayabilir: bir tanıtım sayfası (landing page), bir video, elle yapılan bir hizmet (arkada insan çalışırken önde otomatikmiş gibi görünen "sihirbaz arkası" yöntemi) de MVP olabilir.
MVP'nin karşıtı aşırı mühendislik (over-engineering — henüz gerekli olmayan özellik, ölçek ve mükemmellik için harcanan emek) ve altın kaplama (gold-plating — kimsenin istemediği detayları cilalamak) tir. Bunlar girişimin en sinsi para ve zaman katilleridir; çünkü "çalışıyormuş" gibi hissettirirler ama öğrenmeyi geciktirirler.
İpucu: Bir özelliği eklemeden önce sorun: "Bu özellik olmadan test etmek istediğim şeyi öğrenebilir miyim?" Cevap "evet" ise, o özellik MVP'ye girmez. MVP'yi büyüten her "ama şu da lazım" cümlesi, öğrenmeyi geciktiren bir maliyettir.
Özellik önceliklendirme
Sınırsız zaman ve para olmadığı için hangi özelliğin önce yapılacağına karar vermek gerekir. İki pratik yöntem:
MoSCoW: Özellikleri dörde ayırır — Must (olmazsa olmaz), Should (olmalı ama şart değil), Could (olsa iyi), Won't (şimdilik yok). MVP yalnızca "Must" kümesidir.
Etki-Efor matrisi: Her özelliği "müşteriye etkisi" ve "yapma eforu" ekseninde yerleştirir. Yüksek etki-düşük efor olanlar önce yapılır; düşük etki-yüksek efor olanlar terk edilir. YZ, bir özellik listesini bu matrise hızlıca yerleştirmede iyi bir yardımcıdır — ama "etki" tahminini gerçek müşteri sinyaliyle düzeltmek gerekir.
Adım adım: YZ ile MVP tasarımı
- Öğrenme sorusunu yaz. "Bu MVP hangi tek varsayımı test edecek?"
- Aday özellikleri listele. Aklınızdaki her şeyi dökün.
- YZ ile önceliklendir. MoSCoW veya etki-efor ile ayıklatın; "Must" kümesini bulun.
- En hafif formu seç. Kod mu gerekli, yoksa landing page/video/elle hizmet yeter mi?
- Prototipi/sayfayı üret. YZ'den tanıtım sayfası metni, akış veya sözde kod taslağı isteyin.
- Başarı ölçütünü önceden tanımla. "Şu sonucu görürsem varsayım doğrulanır."
- Yayınla ve öğren. Gerçek davranışı ölç; kararı kurucu verir.
Üç mini vaka
Vaka 1 — Kod yazmadan MVP. Bir kurucu, ev yemekleri satan komşuları müşterilerle buluşturan bir uygulama düşünüyordu. Aylarca kod yazmak yerine, tek bir tanıtım sayfası ve bir WhatsApp hattıyla başladı; siparişleri elle eşleştirdi ("sihirbaz arkası" yöntemi). İki haftada 40 gerçek sipariş aldı ve asıl darboğazın teslimat lojistiği olduğunu öğrendi. Kod yazsaydı bunu aylar sonra öğrenecekti. MVP, öğrenmeyi öne çekti.
Vaka 2 — Aşırı mühendislik tuzağı. Bir ekip, henüz tek müşterisi yokken "milyonlarca kullanıcıya ölçeklenecek" bir altyapıya 4 ay harcadı. Ürün çıktığında kimse istemedi; problem yanlıştı. Harcanan emeğin neredeyse tamamı boşa gitti. Ders: ölçek problemi, çekiş (traction) sorununu çözdükten sonraki bir lükstür; önce kimsenin istediğini kanıtlayın.
Vaka 3 — Önceliklendirmenin gücü. Bir kurucunun 30 özelliklik bir listesi vardı. YZ'ye etki-efor matrisi yaptırdı ve gerçek müşteri görüşmelerinden gelen sinyalle "etki" sütununu düzeltti. 30 özellikten sadece 4'ünün "Must" olduğu ortaya çıktı. MVP'yi 6 ay yerine 3 haftada çıkardı; kalan 26 özelliğin çoğuna müşteri hiç ihtiyaç duymadığını gösterdi.
Dört kopyalanabilir şablon
1) Öğrenme sorusu + MVP kapsamı:
Rolün: yalın ürün koçu. Test etmek istediğim varsayım:[örn. "esnaflar tahsilat için aylık ödeme yapar"].(1) Bu varsayımı doğrulamak için gereken EN KÜÇÜK ürünü tarif et,(2) bunun kod gerektirmeyen bir versiyonu (landing page, video,elle hizmet) mümkün mü, göster, (3) MVP'ye girmemesi gereken"cazip ama gereksiz" özellikleri uyar.
2) MoSCoW önceliklendirme:
Aşağıdaki özellik listesini MoSCoW'a ayır: Must / Should / Could /Won't. Sadece "test etmek istediğim varsayım için ZORUNLU" olanlarMust olsun. Her özelliğin neden o kümede olduğunu tek cümleyle yaz.Liste: [özellikler].
3) Etki-efor matrisi:
Şu özellikleri "müşteriye etki (1-5)" ve "yapma eforu (1-5)"eksenlerinde puanla ve 4 çeyreğe yerleştir. Yüksek etki-düşük eforolanları "önce yap", düşük etki-yüksek efor olanları "yapma" diyeişaretle. Etki puanlarının benim gerçek müşteri verimledoğrulanması gerektiğini hatırlat. Liste: [özellikler].
4) Landing page metni:
MVP'm için bir tanıtım sayfası metni yaz. Bölümler: (1) müşterinindiliyle başlık (değer önermesi), (2) problem-çözüm kısa anlatı,(3) 3 fayda maddesi, (4) net bir çağrı (ön kayıt / bekleme listesi).Abartılı vaat kullanma; sadece doğrulayabileceğim iddialar olsun.Türkçe, sade, samimi.
Zayıf prompt / Güçlü prompt
Zayıf prompt:
Ürünüm için tüm özellikleri listele.
Bu istem MVP mantığına aykırıdır; öğrenmeyi geciktiren, aşırı mühendisliğe davet eden uzun bir dilek listesi üretir.
Güçlü prompt:
Test etmek istediğim tek varsayım: [x]. Bu varsayımı doğrulayacakEN KÜÇÜK MVP'yi tarif et, kod gerektirmeyen bir versiyonu öner,özellikleri MoSCoW ile ayır ve sadece Must kümesini bırak.Başarı ölçütümü (hangi sonuç varsayımı doğrular) önceden yazmamayardım et.
Yaklaşım
Öğrenme hızı
Maliyet
Risk
Tam ürünü baştan yapmak
Çok yavaş
Yüksek
Yanlış şeye para gömme
Aşırı mühendislik/altın kaplama
Yavaş
Çok yüksek
En pahalı hata
Sadece Must özellikli MVP
Hızlı
Düşük
Yönetilebilir
Kodsuz MVP (landing/elle)
En hızlı
En düşük
Erken öğrenme
Sık yapılan hatalar
- MVP'yi tam ürün sanmak. MVP en küçük öğrenme birimidir, cilalı final değil.
- Aşırı mühendislik. Müşteri yokken ölçek/mükemmellik için ay harcamak; en pahalı hata.
- Öğrenme sorusu tanımlamamak. Neyi test ettiğini bilmeyen MVP, yönsüz bir harcamadır.
- Başarı ölçütünü sonradan koymak. Ölçüt önceden yazılmazsa her sonuç "başarı" gibi yorumlanır.
- Kodsuz seçenekleri atlamak. Landing page/video/elle hizmetle test etmek varken kod yazmak.
Dikkat: YZ, bir prototip veya kod taslağı üretebilir ama üretilen kodun güvenliği, doğruluğu ve yasal uygunluğu sizin sorumluluğunuzdadır. Özellikle ödeme, kişisel veri veya güvenlik içeren MVP'lerde YZ çıktısı bir başlangıç taslağıdır; canlıya almadan önce yetkin bir geliştiricinin/uzmanın gözden geçirmesi şarttır.
Özetle
MVP, en az çabayla en çok öğrenmeyi sağlayan en küçük üründür; amacı satmak değil, bir varsayımı test etmektir. En pahalı hata, kimsenin istediği kanıtlanmamış bir ürüne aşırı mühendislik ve altın kaplama yapmaktır. Her MVP bir öğrenme sorusuyla başlar; özellikler MoSCoW veya etki-efor ile ayıklanır ve yalnızca "Must" kümesi yapılır. Çoğu zaman en iyi MVP koddan bile önce gelir: landing page, video veya elle hizmet. YZ, kapsam belirleme, önceliklendirme ve prototip/sayfa taslağı üretmede güçlü bir hızlandırıcıdır; ama "etki" tahminleri gerçek müşteri sinyaliyle düzeltilmeli ve teknik/yasal-kritik çıktılar uzmanca gözden geçirilmelidir.
Uygulama görevi
Bir varsayım seçin ("Öğrenme sorusu" şablonu). YZ'den bu varsayımı test edecek en küçük MVP'yi ve mümkünse kodsuz bir versiyonunu isteyin. Aday özelliklerinizi "MoSCoW" şablonuyla ayırıp yalnızca Must kümesini bırakın. Son olarak "Landing page metni" şablonuyla abartısız bir tanıtım sayfası taslağı üretin ve yayınlamadan önce başarı ölçütünüzü (ör. 20 ziyaretçiden en az 5 ön kayıt) yazın.
Kontrol listesi
- [ ] MVP'min test ettiği tek öğrenme sorusunu net yazdım mı?
- [ ] Kodsuz bir MVP versiyonunu değerlendirdim mi?
- [ ] Özellikleri önceliklendirip yalnızca "Must" kümesini mi bıraktım?
- [ ] Başarı ölçütünü yayından önce tanımladım mı?
- [ ] Teknik/yasal-kritik çıktıyı uzman gözden geçirmesine bıraktım mı?