Daha önce B2B teknoloji startup’larının iş modeli doğrulama ve iş geliştirme yolculuklarını detaylıca yazdık. Hap niteliğinde makaleler olduğu için kendimizi tekrar etmeyeceğiz.
Bu yazıda, PoC (proof of concept, kavram doğrulama) projelerinin detaylarını startup bakış açısından anlatacağız.
PoC projesi bizim için çok değerli bir kavram. Yeni hizmet modelimizin adını “PoC labs” koymamızın sebebi bu olabilir mi acaba? Bizim gördüğümüz, prototipini tamamlamış ve gerçek müşteri deneyimi edinmeye hazır startup’ların tek yaptıkları ve yapmaları gereken PoC projeleri. Basit görünüyor ancak maalesef PoC etkileşimlerinin çoğu ölü doğabiliyor.
Aşağıda neler yapıp, nelerden kaçınılması gerektiğini anlatan özet bir tablo bulabilirsiniz. Onun altında da her madde için özet açıklamalar var.
PoC MVP değildir. MVP’nin gerçek dünyada uygulanması ve daha fazlasıdır.
Her şeyi test ediyorsunuz: problemi, potansiyel müşterilere vereceğiniz ilk mesajı, kurumsal kullanıcı davranışını, satın alan ve karar verenlerin kimler olduğunu vb. Yani PoC sürecinin kendisi bir deneydir. PoC projesinin ücretli olmasını hedeflemelisiniz evet, ancak işinizle ilgili en riskli varsayımlarınızı doğrulamak her zaman birincil önceliğiniz olmalı. Eğer nasıl deney tasarlanacağı konusunda emin değilsiniz, size aşağıda bazı başlangıç noktası kaynaklar veriyoruz:
DİKKAT
Bu deneyde öncelik işi anlamak, ürünü satmak değil. Bu yüzden MVP veya prototipinizin yapabileceklerinden çok, işiniz ile ilgili varsayımlarınızı doğrulamayı hedeflemelisiniz.
Bir deney tasarladığınızda, hedef müşterinizin sahip olması gereken özellikleri de bilmelisiniz. Eğer PoC müşteriniz hedef müşteri tanımına uymuyorsa, deney başarısız olur. Evet, eski şirketinizsw, arkadaşınızın şirketinde veya bir mentorünüzün tanıdığı bir şirkette PoC projesi yapma ihtimaliniz daha yüksek olabilir. Ancak bu şirket, hedef müşteri tanımınıza uymuyorsa, sadece değerli zaman ve enerjinizi harcamanıza neden olur.
DİKKAT
Balinalardan, havalı görünen, yüksek risk algılı, startup'larla uyumsuz ve dünyadaki bütün zamana sahip şirketlerden, uzak durun. Evet eğer hiç bitmeyen PoC projesinden sağ çıkabilseydiniz, belki referanslar sayfanızda çok güzel durabilirlerdi. PoC projeleri müşterilerinizin inovasyon riskini en aza indirebilmesi için en iyi yöntem olmasına rağmen, bazı şirketler değişmez. Bütün büyük şirketler balina değildir. Yavaş, yüksek bürokrasiye sahip ve ana işi optimize etmeye odaklanmaktan yeniyi görme yetisini kaybetmiş şirketlerden bahsediyoruz. Olası balinalardan zarar görmemek için, PoC 'nin tasarımından uygulamasına tüm süreçlerde zaman kısıtmaları koyun. Mantıklı zaman kısıtlamalarına uymayıp, kendi şartlarını dikte etmeye başlarsa, bir balina ile karşı karşıya olabilirsiniz.
PoC projesinin "tüm" dertlere deva olmayacağını hem siz hem de müşteriniz bilmeli. Proje çıktısı hemen canlıdaki sistemlerin yerine geçmeyecek. PoC etkileşimi, çözümün işe yaradığını, beklentileri karşıladığını ve yaklaşıma daha fazla yatırım yapılması gerektiğini doğrulamak için var. O zaman kapsam, gerçek dünya senaryolarının bir simülasyon ile kısıtlı olmalıdır. Hedefler de anlamlı ve net olmalıdır. Bunu sağlamak startup’ın sorumluluğundadır.
DİKKAT
Müşterinizin dertlerinizi en iyi şekilde anlamadan önce başarmak istediğiniz çözüme hemen atlamak kulağa hoş gelebilir. Ancak bu ölümcül olabilir. Müşteriniz ile birlikte, çözümünüzü onların sorunları ile uyumlandırmak için sürekli güncellemeniz gerekir. Sonra da bu çözümü en iyi şekilde gösterecek kapsam ve hedefi belirleyebilirsiniz.
PoC etkileşimine girerken, başarı tanımını sizin ve müşterinizin gözünden nortaklaştırmalısınız. Müşterinizin ve siz, çıktıları sayısal verilerle nasıl ölçeceğinizi bilmeniz gerekir. PoC sürecindeki herşey gibi, başarı tanımı da ortak olmalıdır. PoC tamamlandığında, sonuçların olumlu yanlarını nicel göstergeler kullanarak savunmak durumunda kalmak istemezsiniz.
Bonus tüyo: PoC başarısına bağlı olarak PoC sonrası atılacak adımların (hizmet satınalma, yatırım vs.) neler olacağına baştan anlaşabilirsiniz.
DİKKAT
Sakın fazla söz verip eksik teslim etmeyin. Sizin ve çözümünüzün yapabilecekleri konusunda ilk andan itibaren tamamen dürüst olun ve gerçekçi beklentiler oluşturun. PoC etkileşiminde yapılacak işler tahmin edilebilir ve yönetilebilir olmalıdır. Tek değişken ölçülebilir PoC sonuçlarıdır.
PoC etkileşimi boyunca takip edilecek bir planınız olmalı. Tabi ki bu plandan sapmalar olacaktır, ancak sağlıklı planlamayla haftalık veya 2 haftalık sprintlerle biraraya gelmenizi öneririz. Gelişimi takip etmek ve ilgili paydaşlara sık güncellemeler göndermek startup’ın sorumluluğudur. Bu güncellemelerin önemli bir kısmı projedeki risk veya gecikmeler ve bunların ne zaman/nasıl/kiminle paylaşıldığıdır. Bildirme ve belgelendirmenin 2 önemli faydası var. Her şeyden önce öngörülemez durumlar etkileşimin tamamlamasını engelleyecek olursa bir dayanağınız olur. Ayrıca etkileşim sona erdiğinde geriye dönüp analiz edebileceğiniz kayıtlara sahip olursunuz.
DİKKAT
Bildirme ve belgelendirme işini katma değersiz bir idari aktiviteye dönüştürmeyin. Her güncellemeyi incelediğinize ve ondan öğrendiğinize emin olun. Bu güncellemelerden bir şeyler öğrenmezseniz, gerekli iterasyonları yapamaz veya tavsiye edemezseniz, etkileşimin ipi elinizden kaçar.
Burada iki seviyede postmortem değerlendirmeden bahsediyoruz. Birincisi tamamladığınız her PoC projesinden sonra yapacağınız tekil değerlendirme, ikincisi ise ürün Pazar uyumunu bulma yolculuğunuzda yaptığınız tüm PoC projelerini ele aldığınız, portfolyo değerlendirmesidir. Bu değerlendirmelerin tipik gündem maddeleri; neler iyi gitti, neler kötü gitti, ne öğrendik ve neleri geliştirebiliriz sorularıdır. Pivot etme veya devam etme kararı da sıkça yapılan bir tartışmadır.
Bu postmortem değerlendirmelerin en önemli faydası, ürün pazar uyumuna ne kadar yaklaştığınızı görmenizi sağlaması ve yakınlaştıysanız, ürünün ne olması gerektiğini göstermesidir. Bu da bu yazının devamının konusu.
DİKKAT
Sadece kendi veri ve içgörülerinize güvenmeyin. Öz değerlendirme içinde sizi yanlış yönlendirebilecek önyargılar içerebilir. Varsayımları yeterli kanıt olmadan doğrulamanıza sebep olabilir. Her zaman girişim dışından da veri ve geri bildirim toplayın.
Problem çözüm aşamasında yapılan tüm PoC etkileşimlerinin amacı, girişimin tekrar edilebilir bir şekilde pazarlanabilecek ve hedef müşteri segmentine satılabilecek, ölçeklenebilir bir ürün konsepti geliştirmesi için gerekli ve yeterli delili toplamasıdır. O zaman ürün tanımı yapmak gerekir.
Hayal edelim:
PoC’ler boyunca anlamanız ve doğrulamanız gereken bazı konular:
Şimdi ürün pazar uyumunu doğrulama vakti.
Prototip geliştirmiş, kurumsal PoC süreçleriyle ürünleşme, pazar uyumu ve yatırım arayan B2B startup'lar, sizi tanımak istiyoruz. Workinlot PoC Labs