Lean Startup 0’dan MVP’ye

Ben Aydan uzun süredir bir yazılım şirketinde ürün geliştirme süreçlerinde yer alıyorum ve her gün şu üç soruyla masaya oturuyorum: Ne yapacağız, kimin için yapacağız, sağlayacağımız fayda nedir? Zaman içinde öğrendiğim en net gerçek şu: Başarı, tek bir “büyük fikir”in değil; küçük ama isabetli kararların ritminin sonucu.

Bu yüzden biz Yalın Girişim yaklaşımını çalışma kültürümüzün merkezine yerleştirdik. Yalın; israfı azaltan, öğrenmeyi hızlandıran ve bizi sürekli kanıt üretmeye zorlayan bir düşünme biçimi. Aşağıda, 0’dan Asgari Uygulanabilir Ürün’e (MVP), oradan sürdürülebilir büyümeye giden yolu benim deneyimlerim ile , sade ve uygulanabilir bir dille anlatıyorum.

Problemin Tanımlanması

Her şey çözülmeye değer bir problem belirlemekle başladı. Lean Startup (Yalın Girişim) yaklaşımının da öğütlediği gibi, ilk adım olarak neyin gerçekten sorun olduğunu netleştirmeye odaklandık. Birçok girişimci, kafasındaki ürüne aşık olup aylarca müşteriyle konuşmadan ürün geliştiriyor ve sonuçta kimsenin istemediği bir şey ortaya çıkarabiliyor. Ben bu tuzağa düşmemek için kendi kendime söz verdim: Problemi doğrulamadan kod yazmaya başlamayacağız. Nitekim araştırmalara göre startup’ların başarısız olma nedenlerinin başında, %42 oranıyla “piyasada ihtiyaç olmayan bir ürün geliştirmek” geliyor. Bu çarpıcı oran, doğru problem seçiminin ve ihtiyaç doğrulamasının önemini bana bir kez daha gösterdi.

Peki net bir problem tanımı yapmak bize ne kazandırdı?

• Kaynaklarımızı boşa harcamaktan kaçındık. En başta doğru sorunu hedefleyerek, kısıtlı zaman ve bütçemizi yanlış yere akıtma riskini azalttık.
  
• Ürünün gerçekten bir ihtiyacı karşıladığından emin olduk. “Kim için, hangi sorunu çözüyoruz?” sorusunun yanıtını netleştirerek, ortaya atılan fikrin gerçek dünyada bir karşılığı olmasını sağladık.
  
• Kendi ön yargılarımızdan arındık. Çözüm düşüncesini bir kenara bırakıp sadece problem üzerine düşünmek, bilinçaltımızdaki “sevdiğimiz fikri haklı çıkarma” eğilimini engelledi. Bu sayede müşteri gözünden geniş bir perspektif kazanabildik.
  

Problemi tanımlama aşamasında bol bol araştırma yaptık. Potansiyel kullanıcılarla sohbetler, sektörel okumalar ve mini anketler sayesinde ortada gerçekten bir “karşılanmamış ihtiyaç” olup olmadığını anlamaya çalıştık. Her girişimin kanıtlaması gereken iki şey vardır: 1) müşteri tarafında çözülmemiş bir ihtiyaç var mı ve 2) bu ihtiyaç yeterince yaygın mı? İşe koyulmadan önce bu sorulara yanıt aradık. Tecrübeler gösteriyor ki problemleri derinlemesine inceleyip hedef kitlesini iyi tanıyan ekipler, çok daha isabetli çözümler üretiyor. Ben de bunu bizzat deneyimledim: Problemi tanımlamak için harcadığımız ekstra zaman, ekibimi daha sonra yaşayabileceğimiz aylara mal olabilecek yanlış yönlerden kurtardı.

Müşteri Segmentasyonu: Kimin İçin?

Problemi netleştirdikten sonra sıradaki kritik soru “Bu çözümü kimin için geliştiriyoruz?” oldu. Başlangıçta aklımızda tek bir kullanıcı profili vardı; çoğu girişimci gibi biz de biraz kendimize benzeyen “ideal müşteri”yi düşünmüştük. Ancak Lean Startup prensiplerini uygularken açık fikirli olmak gerekiyor. Keşif sürecinde öğrendiğimiz bir ders şuydu: Hayalimizdeki müşteri profili yerine gerçek verilerle konuştuğumuz kullanıcılar bize bambaşka içgörüler sunabilir. Nitekim öyle de oldu; ideal kullanıcı tanımımızı, gelen geri bildirimler ışığında birkaç kez revize ettik.

Hedef kitleyi belirlemek için müşteri segmentasyonu çalışması yaptık. Birkaç farklı kullanıcı personası oluşturarak bu kişilerin demografik özelliklerini, ihtiyaçlarını yazdık. Empati kurmak adına, her bir persona için şu soruların yanıtlarını bulmaya çalıştık:

• Bu kullanıcı şu an problemi nasıl çözüyor? Mevcut bir çözüm veya yöntem kullanıyor mu?
  
• Mevcut çözümlerden neden memnun değil? Onları tam olarak hangi noktada tatmin etmiyor?
  
• Bu kullanıcıyı ne motive eder, kararı ne etkiler? Fiyat mı, kullanım kolaylığı mı, prestij mi vs.?
  

Bu sorular sayesinde, hedeflediğimiz kullanıcıların günlük hayatta gerçekten neyle mücadele ettiğini anlamaya başladık. Örneğin, kullanıcılarımızdan biri sorunu kendi geliştirdiği bir Excel makrosuyla çözdüğünü ama bunun da sık sık hata verdiğini belirtti. Bu tür içgörüler bize iki şeyi gösterdi: Birincisi, piyasa boşluğu gerçekten var; ikincisi, rakip veya alternatif çözümlerin nerede yetersiz kaldığı netleşiyor.

Ekip olarak şunu fark ettik: “Herkes için bir ürün” yapmaya kalkmak yerine, küçük bir kullanıcı grubunun derdine derman olmaya odaklanmak çok daha değerli. İlk müşterilerimiz kimler olacak, nerede bulunurlar, problemleri karşısında duyguları nedir – bunları öğrenmek çözüm geliştirme sürecimizin pusulası oldu. Julia Austin’in de vurguladığı gibi, keşif sürecinde ideal kullanıcının en başta hayal ettiğimizden farklı olabileceğini kabul etmek önemli. Biz de önyargılarımızdan sıyrılıp gerçek kullanıcıların beklentilerine kulak verdik. Bu sayede çözmeye çalıştığımız problemin hangi insanlar için gerçekten anlam ifade ettiğini, somut kanıtlarla görmüş olduk.

Çözüm Hipotezinin Oluşturulması

Problemimiz tanımlandı, hedef kitlemiz netleşti. Sırada bu ikisini buluşturacak çözüm fikrini ortaya koymak vardı. Ancak burada kritik olan, çözümümüzü bir varsayım olarak ele almak. Yani “Şu özelliklere sahip bir ürün geliştirirsek, hedef kullanıcılarımızın X problemini çözebiliriz” şeklinde bir hipotez kurduk. Bu bizim çözüm hipotezimizdi.

Lean Startup felsefesi gereği, problem aşamasında bilinçli olarak çözümden bahsetmemiştik. Önce derdi anlamaya çalıştık, şimdi dermanı tarif etmeye başladık. Çözüm hipotezimizi oluştururken tüm ekipçe beyaz tahtanın karşısına geçip beyin fırtınası yaptığımız anı hatırlıyorum. Hepimizin aklında parlak fikirler vardı, fakat öğrendiğimiz bir şey varsa o da şu: Her fikir bir varsayımdır, ta ki test edilip doğrulanana kadar. Bu yüzden en mantıklı görünen fikri bile “bizce” diye ifade ederek yazdık. Örneğin, “Bizce kullanıcılar işlemlerini otomatikleştiren basit bir web aracı istiyor” gibi bir cümleyle çözümümüzü tanımladık.

Burada benim açımdan zor ama önemli bir adım, sadelik oldu. Aklımızda uçsuz bucaksız özellik listeleri belirse de kendimize sürekli şunu hatırlattık: İlk çözümümüz minimum olmalı. Çünkü bu sadece ilk hipotezimiz; zamanla değişebilir, gelişebilir. Lean Startup terminolojisinde buna değer varsayımı da diyebiliriz: Ürünümüzün müşteriye gerçekten değer sunup sunmayacağına dair ilk tahmin. Biz de çözüm hipotezimizi bu şekilde netleştirdikten sonra, artık onu gerçek dünyada sınama safhasına geçebiliriz.

Build (İnşa Et) Aşaması: MVP Geliştirme Süreci

Yukarıdaki diyagram, Lean Startup metodolojisinin belkemiği olan Build-Measure-Learn (İnşa Et – Ölç – Öğren) döngüsünü görselleştiriyor. Bu döngüde fikirler hızlıca ürüne dönüştürülür, ardından kullanıcı tepkileri ölçülür ve elde edilen verilerle öğrenilir, yani fikir doğrulanır veya gerekiyorsa yön değiştirilir. Başarılı startup ekipleri, bu döngüyü olabildiğince hızlı ve verimli döndürerek rakiplerine avantaj sağlar. Biz de şu anda bu döngünün ilk aşamasındayız: Çözüm hipotezimizi çalışan bir ürüne dönüştürme, yani Build (İnşa) aşamasında.

Çözüm hipotezimizi test etmek için bir Minimum Viable Product (MVP – Asgari Uygulanabilir Ürün) geliştirmeye giriştik. MVP, ürünümüzün sadece temel özelliklerini barındıran, hızlıca ortaya konulmuş ilk versiyonudur. Eric Ries bu kavramın amacını şöyle açıklar: “Bir ekibin, müşteriler hakkında en az çabayla maksimum miktarda doğrulanmış öğrenmeyi toplamasına olanak tanıyan yeni bir ürünün sürümüdür.” Yani MVP, bize en kısa zamanda en çok öğrenmeyi sağlayacak kadar işlevsel bir üründür. Bu tanım kulağa teorik gelebilir ancak bana yol gösteren ilke çok basitti: MVP mükemmel değil, işe yarar olmalı.

MVP’yi planlarken ekip arkadaşlarım ile birlikte ürünümüzün kullanıcı için en kritik işlevini belirledik. Tüm “olsa güzel olur” özellikleri liste dışı bıraktık ve gerçekten çözümü deneyimletmek için gereken minimum şeyi inşa etmeye odaklandık. Bu sayede haftalar sürecek geliştirme işini günlere indirdik. Örneğin, ilk prototipimiz arka planda bazı işlemleri manuel yapmamızı gerektirse bile, kullanıcıya temel faydayı sunacak basitlikte tutuldu. Hızlı öğrenmek için buna ihtiyacımız vardı. Nitekim MVP’nin değerini, Dropbox veya Zappos gibi örneklerden biliyorduk: Basit bir video demosuyla binlerce kullanıcıyı bekleme listesine alan Dropbox ya da ayakkabı mağazalarından ürün alıp çevrimiçi satan Zappos örneği, MVP’nin yaratıcı kullanımına dair klasik hikayelerdendir. Bizim ürünümüz de belki bu kadar yenilikçi değildi, ama ortak noktası şuydu: MVP, sürecin sonu değil başlangıcı.

Eric Ries der ki: “MVP’nin hedefi öğrenme sürecini başlatmaktır, bitirmek değil.” Bu söz kulağıma küpe oldu. İlk MVP’mizin kullanıcılar tarafından tamamen mükemmel bulunmasını beklemiyoruz. Hatta belki bazı kullanıcılar beğenmeyecek veya eksik bulacak. Ancak bu bile bizim için değerli, çünkü bize neyin çalışıp neyin çalışmadığını öğretecek. Önemli olan, “küçük de olsa gerçek bir ürün” ile piyasaya çıkmak ve ondan öğrenecek pozisyonda olmak.

Teknik tarafta da Yalın olmayı sürdürdük: MVP’yi geliştirirken mevcut kütüphaneleri ve servisleri olabildiğince kullandık, sıfırdan her şeyi kodlama yoluna gitmedik. Amaç, hızlıca denemek olduğu için, kaliteyi değil ama kapsamı minimum tuttuk. Bir takım olarak “önce çalışır hale getirelim, sonra geliştiririz” mottosuyla hareket ettik. Bu yaklaşım başlangıçta içimize sinmeyen, mükemmeliyetçiliğimizi törpüleyen bir şeydi. Fakat günün sonunda elde ettiğimiz ürün, hedef kullanıcı senaryosunu uçtan uca gerçekleştirebiliyor muydu? Evet, gerçekleştiriyordu. İşte bu bizim için yeterliydi.

Önemle belirtmeliyim ki MVP’miz henüz gerçek kullanıcılarla buluşmadı. Yani Lean Startup döngümüzün Measure (Ölç) ve Learn (Öğren) aşamalarına daha geçemedik. Şu ana kadarki kararlarımız hala varsayımlara ve ön araştırmalara dayanıyor. Henüz hiçbir metrikte veri yok, elimizde sadece yaptığımız ön görüşmelerden aldığımız nitel geri bildirimler var. Veriye dayalı kararlar almaya başlamadığımızın bilincindeyiz ve bu normal. Çünkü önce bir ürünü sunmak, sonra veriyi toplamak gerekiyor. Bu noktada sabırlı olmayı öğrendim; bir ürün geliştiricisi olarak içgüdüsel olarak sayılar, grafikler görmek istesem de henüz kullanıcıya açılmadan bunların hiçbirine sahip olamayız. Önemli olan, bunun farkında olarak beklentileri yönetmek ve aceleyle yanlış çıkarımlar yapmaktan kaçınmak.

Ölçüm, Öğrenme ve Yolculuğun Devamı

Önümüzde heyecan verici bir dönemeç var: MVP’mizi küçük de olsa gerçek bir kullanıcı grubunun kullanımına açacağız. İşte o zaman Lean Startup döngüsünün ikinci aşaması olan Measure (Ölç) adımına geçebileceğiz. Gerçek kullanıcı verilerini ölçerek, hipotezlerimizi sınamaya başlayacağız. Kullanıcılar ürünümüzü kullanırken hangi özellikleri benimsiyor, hangi noktada takılıyor, bunu izleyeceğiz. Bu verilerle de üçüncü adım olan Learn (Öğren) aşamasına geçmiş olacağız. Yani, elimizdeki veriye bakarak ya hipotezimizi doğrulayacağız ya da yanlışladığımız noktaları tespit edeceğiz. Lean Startup’a göre bir girişimin ilerlemesi, ürettiği fonksiyon sayısıyla değil elde ettiği doğrulanmış öğrenme (validated learning) miktarıyla ölçülür. Biz de MVP sonrası aşamada işte bu doğrulanmış öğrenmeyi maksimize etmeye çalışacağız.

Elbette işler her zaman plana göre gitmeyebilir. Ölçüm sonuçları beklediğimizden farklı olursa, belki de temel varsayımlarımızdan biri yanlış demektir. Bu durumda Lean Startup’ın ünlü Pivot (yön değiştirme) hamlesi gündeme gelecek demektir. Pivot, ürünün veya stratejinin belirli bir yönünü köklü biçimde değiştirmek anlamına gelir. Örneğin, kullanıcılar beklediğimiz değeri görmezse farklı bir çözüme yönelebilir veya bambaşka bir müşteri segmentine odaklanabiliriz. Ancak bunlar şu an için ilerideki kararlar. Pivot kararı verebilmek için elimizde ölçülebilir sonuçlar olması ve bunların analiz edilmesi gerekiyor. İşte bu noktada innovation accounting (inovasyon muhasebesi) ve doğru metrics (metrikler) belirleme devreye girecek. Hangi rakamlara bakacağız, başarıyı neye göre tanımlayacağız, bunlar hep ürün lansmanından sonra gündemimize gelecek konular. Şu an için bu kavramlara girmiyoruz, çünkü önce MVP’mizi kullanıcıyla buluşturmamız şart.

Özetle, bu içeriğimde Lean Startup yolculuğumuzun fikir aşamasından Build (İnşa et) aşamasına kadarki kısmını, kendi deneyimlerimle aktardım. Problemi tanımladık, müşteri segmentimizi belirledik, çözüm hipotezimizi oluşturduk ve bu hipotezi test etmek üzere ilk MVP’mizi inşa ettik. Bundan sonraki adım, MVP’yi gerçek kullanıcılarla buluşturup ölçüm ve öğrenme safhalarına geçmek olacak. Pivot ihtiyacı, kalıcı başarı metrikleri, sürdürülebilir büyüme gibi konular ise ürün lansmanımız sonrası ortaya çıkacak ve bunları ayrı bir yazıda paylaşacağım.

Şu an için yolculuğun başındayız, fakat Lean Startup kültürü sayesinde elimizde bir rota ve metodoloji var. Küçük adımlarla, hızlı deneylerle ilerliyoruz. Unutmayalım, başarı bir gecede gelecek mucizevi bir fikirden ziyade, sürekli öğrenme ve uyum sağlama yeteneğimizde gizli. Ben kendi adıma, her gün masaya otururken sorduğum o üç soruya artık bir dördüncüsünü ekledim: “Bugün ne öğrenebiliriz?” Lean yaklaşımının bana kattığı en önemli değer belki de bu zihniyet oldu. Bundan sonraki durakta, gerçek kullanıcı verileriyle öğrenecek çok şeyimiz var – ve ben bu yolculuğu bizzat yaşamaya devam ediyorum.