Bu yazı yatırım almanın yolunu anlatmıyor. Yatırımcıların beklentisi aşamaya, sektöre ve kişiye göre değişir; tek bir doğru hazırlık düzeyi yoktur. Anlatabileceğimiz şey, ürün tarafında hangi parçaların açık olması gerektiği ve hangi eksiklerin görüşmede soru doğurabileceğidir. Aşağıdaki sekiz başlık bir kontrol listesi olarak okunabilir.
1. Çözülen problemin açıklığı #
Ürünün hangi problemi çözdüğü tek bir cümleyle söylenebilmelidir: kim, hangi durumda, neyi yapamıyor ya da zor yapıyor. Cümle özellik listesine dönüyorsa problem henüz net değildir.
Kontrol etmenin yolu basittir. Cümleyi ürünü bilmeyen birine söyleyin ve kendi sözleriyle geri anlatmasını isteyin. Geri gelen cümle farklıysa sorun anlatımda değil, problem tanımındadır. Ürünün ilk ekranı da aynı cümleyi söylemelidir.
2. Hedef kullanıcı ve kullanım senaryosu #
"Herkes kullanabilir" bir hedef kullanıcı tanımı değildir. Ürünün ilk kullanıcısı kimdir, ürünü hangi anda açar, işi bitirdiğinde elinde ne olur? Bu soruların cevabı tek bir senaryoda birleşmelidir.
Bir ana senaryonun baştan sona eksiksiz çalışması, on senaryonun yarım çalışmasından daha fazla şey anlatır. Görüşmede gösterilecek akış bu senaryodur ve ürünün geri kalanı onun etrafında kurulur.
3. Demo ile gerçek ürün arasındaki sınır #
Demo, belirli bir yolu göstermek için hazırlanmış bir sahnedir. Çalışan ürün ise beklenmeyen girdiyle, boş veriyle ve hatayla da baş eder. İkisini karıştırmak riskli bir hazırlık hatasıdır, çünkü beklenmedik bir soru farkı hemen ortaya çıkarabilir.
Neyin gerçek, neyin sahne olduğunu ekibin kendisi net bilmeli ve sorulduğunda açıkça söylemelidir. "Bu ekran çalışıyor, şu bölüm örnek veriyle gösteriliyor, şu özellik tasarım aşamasında" demek, her şeyi çalışıyormuş gibi sunmaktan daha güvenlidir.
4. Prototipin rolü #
Kod yazılmadan önce tıklanabilir bir prototip iki işe yarar. Birincisi, ürün fikrini anlatmak yerine göstermeyi sağlar. İkincisi ve daha önemlisi, gerçek kullanıcılarla denenebilir. Görüşmeye "kullanıcılara gösterdik, şurada takıldılar, şunu değiştirdik" diyebilmek, prototipin kendisinden daha değerlidir.
Prototipin sınırı da bellidir: teknik uygulanabilirliği ve gerçek veriyle davranışı kanıtlamaz. Bu yüzden prototip, çalışan ürünün yerine değil, yanında durur. Hangi aşamada hangi aracın uygun olduğunu prototipleme araçları yazısında anlattık.
5. Ölçülebilir varsayımlar #
Erken aşamada elde kesin veri yoktur ve olması da beklenmez. Olması gereken, varsayımların yazılı ve sınanabilir olmasıdır. "Kullanıcılar bunu sever" bir varsayım değildir. "İlk kullanımda şu işi yardım almadan tamamlarlar" bir varsayımdır, çünkü sınanabilir.
Her varsayımın yanına nasıl ölçüleceği ve hangi sonucun fikri değiştireceği yazılır. Elde veri varsa olduğu gibi, kapsamı ve sınırlarıyla birlikte gösterilir. Az sayıda kullanıcıdan gelen gözlem, genel bir sonuç gibi sunulmamalıdır.
6. Teknik uygulanabilirlik #
Ürünün en riskli teknik parçası hangisidir ve bu parça denenmiş midir? Bir entegrasyon, bir veri kaynağı, bir yapay zekâ işlevi ya da bir ölçek sorusu olabilir. Arayüzü tamamlanmış ama en riskli parçası hiç sınanmamış bir ürün, göründüğünden daha az hazırdır.
Bu yüzden ilk sürümde ekran sayısını azaltmak ama altyapı kararlarını ertelememek gerekir. Kapsamı bu ayrımla daraltmanın yolunu MVP kapsamını daraltmanın üç sorusu yazısında anlattık. Tasarım ve yazılım kararları ayrı ekiplerde ve ayrı zamanlarda verildiğinde bu risk genellikle geç fark edilir.
7. Yol haritası ve bilinmeyenlerin açıkça gösterilmesi #
İyi bir yol haritası üç şeyi ayırır: yapılmış olan, sırada olan ve henüz bilinmeyen. Üçüncü sütun çoğu sunumda yoktur, oysa sorular çoğu zaman oradan gelir.
Bilinmeyenleri yazmak zayıflık göstermez. Her bilinmeyenin yanında onu neyin cevaplayacağı durur: bir kullanıcı testi, bir pilot müşteri, bir teknik deneme. Bu, ekibin önündeki riski gördüğünü ve sırayla ele aldığını gösterir. Her şeyin planlı ve kesin göründüğü bir yol haritası ise inandırıcılığını kaybeder.
8. Marka ve sunum tutarlılığı #
Sunum, web sitesi, demo ve ürünün kendisi aynı şeyi aynı dille söylemelidir. Sunumda başka bir ad, sitede başka bir vaat, üründe başka bir görsel dil varsa dinleyen kişi hangisinin doğru olduğunu sormak zorunda kalır.
Tutarlılık pahalı bir marka çalışması gerektirmez. Bir ad, bir cümlelik değer önerisi, sınırlı bir renk ve tipografi seti ve bunların sunumda, sitede ve üründe aynı biçimde kullanılması yeterlidir. Sunumun kendisi de bir üründür: her slayt tek bir şey söylemeli, ekran görüntüleri gerçek ürünü göstermelidir.
Hazırlığı nereden başlatmalı #
Sekiz başlığın hepsi aynı anda tamamlanmaz. Sıra genellikle şöyle işler: önce problem ve senaryo netleşir, sonra o senaryoyu gösteren prototip ya da çalışan akış hazırlanır, en son anlatı ve sunum bunların üstüne kurulur. Tersinden başlandığında, yani önce sunum yazıldığında, ürün sunumdaki vaade yetişmeye çalışır.
Girişimlerle çalışırken anlatıyı, demo deneyimini, web sitesini ve satış materyallerini aynı hikâyede toplamaya çalışıyoruz. Bu çalışmanın nasıl kurgulandığı Startuplar İçin sayfasında yer alıyor. Akışların ve prototipin tasarımı UI/UX tasarım, ilk sürümün geliştirilmesi SaaS ve iş yazılımları, sunum ve tanıtım dosyaları ise Satış ve Kurumsal Materyaller hizmetlerinin konusudur.
