Bir ürün başarısız olduğunda genelde bu müşterilerin o ürünü kullanmak / almak istememesinden olur. Ürün geliştirme süreçlerinin yegane amacı da başarılı ürünler üreten bir makine oluşturmaktır. Dolayısıyla, ürün geliştirme yöntemleri, ürün geliştirmede sebepsellik oluşturmaya çalışır ki devamlı başarılı ürünler üretebilsin ya da mevcut ürünleri daha başarılı yapabilsin. [1] Önce mevcut ürün geliştirme süreçlerini basitçe analiz edip sonrasında da nerenin eksik olduğunu ve eksik olan kısmı nasıl doldurabileceğimizden bahsedeceğim.
Ürün geliştirici, ürün geliştirirken genelde şu üç aşamadan geçer:
Aşama 1: Bir Fikrim Var
Bu aşamada, ürün geliştirici (girişimci, product manager, …) aklına gelen fikri hayata geçirmeye çalışarak bir ürün ortaya çıkartır. Bu çalışma izlediği yönteme göre (MVP, lean, …) uzun veya daha az uzun bir süre ofiste oturup bir şey build etmek anlamına gelir. Sürecin sonucunda genelde ürün geliştirici müşterilerin yaptıkları ürünü kullanmadıklarını farkeder.
Aşama 2: Müşterilerle Konuşayım
Ürün geliştirici, kullanılmayan ürünüyle ilgili nereyi ıskaladığını anlamak için müşterilerle konuşmak ister. Bir kaç tane müşteriyi bulur ve onlara gidip “niye kullanmıyorsunuz? şu feature’ı eklesem kullanır mısınız, bu feature’ı hızlandırsam para öder misiniz, UX kötü ondan mı kullanmıyorsunuz, bir sonraki versiyonda hangi feature’ları koyayım” falan gibi sorular sorar. Müşteriyle yapılan bu görüşmenin içeriği genelde üründen, ürünün özelliklerinden ve fiyatından bahseder ve hipotetik sorularla biter:
Ürün Geliştirici: ürüne şu özelliği koysam kullanır mıydın?
Müşteri: Tabi, hatta raporlama da koy ve daha hızlı yap o zaman kullanırım.
Ürün geliştirici aydınlandığını düşünerek ofise döner ve bir sonraki versiyon üzerinde çalışmaya başlar.
Aşama 3: Bir Sonraki Versiyon
Bir sonraki versiyonu launch eden ürün geliştirici son derece umutlu bir şekilde beklemeye başlar. Ancak ürün yine kullanılmaz ve bu sefer ciddi bir umutsuzluğa kapılır. Bu aşamalar genelde ürün başarılı veya başarısız olana kadar tekrar edip iteratif olarak devam eder.
Tanı
Hem Silikon Vadisi hem Avrupa’da ürün geliştirme süreçlerinin hemen hepsi yukarıdakine benzer akışlar izliyor, yani Dünya inovasyonu böyle yapıyor. Büyük küçük teknoloji (ve diğer) şirketlerinin ağzından bir türlü eksik etmediği, büyük bütçeler (ve zaman) ayırılan inovasyon projelerinin %70'i başarısızlıkla sonuçlanıyor. [2]
Tecrübeli girişimci ve yatırımcılar bu kadar yüksek olan başarısızlık oranını çoktan kabullenmiş durumda: temel ekonomik ve yatırım prensibine göre zaten high-return olan projelerin high-risk olmasını bekliyorlar.[3] Bence bu kabul fazla pesimist. Return’ü sabit tutarak, bu 3 aşamayı iyileştirerek başarı oranını bir kaç kat arttırmanın mümkün olduğunu düşünüyorum.
Başarısızlık oranının bu kadar yüksek olmasının sebebi:
1. Eğer kendi kendinizin müşterisi olacağınız bir ürün geliştirmiyorsanız, müşterinin ne istediğini tahmin etmeniz neredeyse imkansız.
2. Müşteriler size ne yapacağınızı söyleme konusunda çok kötüler. Buna şaşırmamak lazım. Çünkü müşterilerin işi bu değil. Ayrıca, bir de burada sürüyle sosyal katman devreye giriyor: müşterinin sizi kırmak istememesi, eğer B2B ise patronunun size vereceği feedback ile ilgili ne düşüneceği gibi.
“Customers don’t know what they want.” (Steve Jobs)
3. Deneme yanılma methodolojileri (MVP, lean, customer development,…) bu problemi bir ölçüde adreslese de, problem yüzeyi geniş olduğundan bu methodolojiler brute-force kalıyor ve günün sonunda ürün geliştirici 3–4 iterasyon yapmış ve hala product/market fit bulamamış veya local optimum’a takılıp kalmış olabiliyor. Eğer ürün başarılı olduysa da çoğunlukla sebepsellikten değil rastlantısallıktan ötürü oluyor.
Jobs-To-Be-Done Framework
JTBD, Rewired Group (Bob Moesta, Chris Spiek), Strategyn ve Clay Christensen tarafından geliştirilen, yıllarca fiziksel ürünler için uygulanmış ve Intercom sayesinde şimdilerde statup dünyasında popülerleşen bir araç. Farklı insanlar farklı şekillerde uyguluyor, son bir kaç aydır Chris Spiek ve Ervin Fowlkes ile bu birebir çalışma imkanı buldum o yüzden benim anlatacağım yöntem Rewired’ın yöntemi.
JTBD framework’e göre, insanlar aslında bir ürünü satın almıyor, o ürünü bir işi yapması için işe alıyorlar. Dolayısıyla eğer iş’in ne olduğunu çıkartabilirsek, hem geliştirdiğimiz ürünün rakiplerini daha iyi anlayabilir, hem de ürün başarısında sebepselliği yakalayabiliriz.
İş (Job) Nedir?
Teknoloji devamlı ilerleyip çözümler gelişse de esasında iş’ler çok daha az sıklıkla değişiyor. Aşağıdaki örneğe göz atalım. [4]
Üstteki fotoğrafı hatırlarsınız, önceden bir otelde konaklamak üzere olan müşteriler için önemli şeylerden bir tanesiydi.
Otelde konaklayanların oteli değerlendirererek yorum yazdığı kitaplar yerine üstteki ürün kullanılmaya başlandı. Bu iki ürün aslında aynı iş’i yapıyor. Muhtemelen 5–10 sene içerisinde üstteki ürün de kaybolup aynı iş başka bir şekilde yapılıyor olacak.
JTBD Nasıl Uygulanıyor?
Eğer iş’i anlamanın neden önemli olduğuna ikna olduysanız, biraz uygulamadan bahsedelim. Uygulamada JTBD’yi hem yeni ürün geliştirmede hem de mevcut ürünleri iyileştirmede kullanabiliriz.
Temel olarak, ilgilendiğiniz alan her neyse, bununla eşlenik hayatında son bir kaç ay içerisinde değişiklik yapmış bir kaç tane insan bulmaya çalışıyorsunuz. (switch arıyoruz)
Örneğin diyelim ki Anadolu’da yaşayan insanlar için bir dating uygulaması geliştirmeyi planlıyoruz. O halde mesela son 3 ay içerisinde Esra Erol’a katılmış insanları bulup onlarla konuşmaya çalışabiliriz.
Kimle konuşacağımızı belirledikten sonra, bu insanlara yaklaşık 40–45 dakika boyunca özel bir teknik uygulayarak bir takım sorular soruyor ve switch hikayelerini anlamaya çalışıyoruz. [5]
Genelde yaklaşık 10 interview sonrasında elimizde yeteri kadar veri oluşuyor. Sonrasında detaylı bir analiz süreci için kapanıyoruz ve interviewlardaki farklı iş’lerin neler olduğunu çıkartıyoruz.
Genelde işler şuna benziyor:
“İlk eşimden boşandıktan sonra uzun süre yalnız kaldım. Bana birisini bulmama yardım et ki hayatıma yalnız olmadan devam edebileyim” [6]
iş’i spesifik olarak tanımladıktan sonra, etrafında üreteceğiniz çözüm çok daha basitleşiyor ve MVP’niz için hangi featureların önemli olup olmadığı çok daha net bir şekilde belli oluyor.
Notlar
- Ürünlerin rastlantısal olarak başarılı olması da söz konusu olabilir. Ama konumuz bu değil.
- Harvard Business School’un yakın zamanda yaptığı bir araştırma’ya göre, inovasyon projelerinin en az %70 ila %90'ı müşteri bulamıyor. G.Cooper’un yaptığı bir çalışmaya göre yeni ürünlerin yalnızca %25'i başarılı oluyor.
- Buna bir ölçüde katılıyorum, risk ve reward bağımsız değişken değil ve aralarında doğru orantıya benzer bir bağıntı var ancak bence o fonksiyon sandığımızdan çok daha az lineer.
- Bu örnek Des Traynor’un yazdığı ve JTBD konusunda gördüğüm en sağlam giriş yazısından alıntıdır.
- Bu interviewları detaylı teknik çalışma ve pratik istiyor. Apayrı bir yazı dizisi ile anlatmayı planlıyorum.
- Esra Erol örneği için uydurmadır. Normalde iş’leri bu şekilde kafamızdan tanımlamıyoruz, interviewlar yaparak ilerliyoruz.
