Ürün Geliştirmedeki En Büyük 4 Efsane ve Bunlardan Nasıl Kaçınılır

Programın gerisinde neden kaldık? Ürün tasarımını ne zaman bitireceksiniz? Bu sözleri daha önce duyduysanız yalnız değilsiniz.

Birçok şirket ürün geliştirmenin nasıl işlediğini anlamıyor. Bunu, fazladan kaynak eklemenin her şeyi sihirli bir şekilde düzelteceği doğrusal bir süreç olarak görüyorlar. Gerçekte ise süreç bundan çok daha sezgiye aykırı ve karmaşıktır.

Kariyerim boyunca yaygın ürün geliştirme mitlerinden bazılarını çürütmek konusunda üzerime düşeni yaptım. Bir girişim ortamında bu süreç oldukça kaotik olabilir, ancak aynı zamanda ödüllendiricidir. Şöyle düşünün: Bir şey ivme kazanmadan önce onu düzeltmek daha kolaydır. 

Ancak asıl zorluk, hasar oluşmadan önce herkesi aynı noktada buluşturmaktır. İş yerinizde devam eden bir çekişme olmasını isteyeceğiniz son şey budur. Kontrol altına alınmazsa, kolay kolay sönmeyecek başka bir yangına dönüşür.

Ürün geliştirmeyle ilgileniyor ve nerede yanlış yaptığınızı merak ediyorsanız bu yaygın ürün geliştirme mitlerine göz atın. Oyununuzu en üst seviyede tutmanıza yardımcı olacaktır. 

• Daha fazla kaynak, daha iyi performans demektir
• Büyük partiler hâlinde çalışmak geliştirme sürecini iyileştirir
• Ürünü özelliklerle doldurun, müşteriler bayılacaktır.
• Ne pahasına olursa olsun plana bağlı kalın

Şimdi de Bazı Profesyonel Mitleri Çürüteceğiz

Şunu açıklığa kavuşturalım: Ürün geliştirme, üretimden tamamen farklı bir alandır. Üretimde maliyetleri kontrol edebilir ve verimliliği geleneksel yöntemlerle artırabilirsiniz. Ancak bunu ürün geliştirmede yaparsanız, faydadan çok zarar verirsiniz. 

Neden mi? Çünkü üretim öngörülebilirdir. Görevler, bir makinedeki dişliler gibi tekrarlıdır. Buna karşılık ürün geliştirme dinamik ve sürekli değişkendir. Bunu yapmanın tek bir doğru yolu yoktur; ilerledikçe öğrenirsiniz. Bu da bizi ilk ürün geliştirme mitimize getiriyor.

Mit 1: Daha fazla kaynak, daha iyi performans demektir

Daha fazla girdi, daha fazla çıktıya eşittir düşüncesi kulağa son derece mantıklı geliyor, ancak bu mantık ürün geliştirmede tehlikeli ve yanıltıcıdır. 

Anketlere göre çoğu ürün geliştirme yöneticisi kapasite kullanımını yüzde 98'in üzerinde tutuyor. Bir ekip ne kadar çok çalışırsa ortaya çıkaracağı çıktının da o kadar fazla olması mantıklı görünüyor.

Uygulamada ise işler böyle yürümez. Yüksek kaynak kullanımı, ekip performansının düşmesine ve çıktının azalmasına yol açar. Ne kadar iyi bir yönetici olursanız olun, bu durumun etrafından dolaşamazsınız. Ancak birçok yönetici bunu iki temel nedenden dolayı görmezden geliyor:

1. Ürün geliştirmenin ne kadar öngörülemez olduğunu hafife alırlar. Bir proje her an masanıza gelebilir. Projenin ne tür bir proje olacağını, ne tür bir uzmanlığa ihtiyaç duyacağınızı ve ne kadar süreceğini önceden tahmin edemezsiniz.

Ürün geliştirme doğrusal olmaktan çok uzaktır. Buna yüksek kaynak kullanımını da eklemek daha fazla gecikmeye, aksaklığa ve kuyruklara yol açar. Bunun nedeni, bir ekip sürekli olarak yüzde 100 kapasiteyle çalışıyorsa yeni projelerin kapasite tamponu bulunmadığı için sıraya alınmak zorunda kalmasıdır.

2. Ürün yöneticileri bir konuyu düzenli olarak hafife alır: Kuyrukların performans için ne kadar kötü olabileceğini. Bir ürün geliştirme ekibi maksimum kapasitede çalışıp aynı anda birkaç projeyi birden yürüttüğünde, onay ve doğrulama süreçlerinde takılı kalan projeleri beklemeye alması kaçınılmazdır.

Diyelim ki bir ürün tasarlıyorsunuz ve sürecin ortasında ilerleyemiyorsunuz, çünkü mühendislik departmanından onay almanız gerekiyor. Bu onayın üç hafta sürdüğünü varsayalım. Ne yaparsınız? Üç hafta boyunca oturup bekler misiniz, yoksa bu süre içinde yeni bir projeye mi başlarsınız? Çoğu ürün geliştirici, kendilerini yalnızca bir felakete hazırladıklarının farkında olmadan ikinci seçeneği tercih eder.

Onayı aldığınızda farklı bir proje üzerinde çalışıyor olacaksınız ve projeyi yeniden üstlenmek için yeterli kapasiteniz kalmayacak. Sonuç olarak, kaldığınız yerden devam edebilmek için bir miktar kapasite boşaltmadığınız sürece ilk proje kuyrukta kalır. Bununla birlikte, pazar trendleri değişirse atıl durumdaki projenin geçerliliğini yitirme riski vardır.

Bu da yine yüksek kaynak kullanımının bir sonucudur. Maksimum kapasitede çalışmak daha uzun kuyruklar oluşturur. Bu kısır döngü, siz ya iş listesini temizleyene ya da yeni bir ekip kurarak çalışma kapasitenizi artırana kadar devam eder. Başka bir deyişle, kuyruklar:

• Gecikme maliyetlerini, süreç maliyetlerini ve çevrim sürelerini artırır.
• Projeleri beklemeye alır. Projeleri ne kadar uzun süre bekletirseniz, pazar değişikliklerine karşı o kadar savunmasız hâle gelirler.
• Ürün geliştirmeyi daha da değişken hâle getirir.

İşte bu kaynak tahsisi çıkmazını şu şekilde çözebilirsiniz:

1. Aktif projelerin sayısını sınırlayın. Bu, kullanım oranınızı azaltır, bir miktar kapasiteyi serbest bırakır ve daha az kuyruk oluşmasını sağlar. Dahası, ekip yürütülen görevlere daha fazla odaklanır.
2. Devam eden iş (WIP) envanterini daha görünür hâle getirin. Ürün geliştirmede WIP görünmezdir ve kaynakları etkili bir şekilde tahsis etmenin bu kadar zor olmasının nedeni de budur. Güncel kalmak için ürün geliştirme yazılımındaki görsel kontrol panolarını her zaman çok yararlı bulmuşumdur. Her gün 10 dakikalık toplantılar yapabilir veya çok sayıda yapışkan not kullanabilirsiniz. Amaç, herkesin kilometre taşları hakkında mümkün olduğunca açık bir şekilde iletişim kurmasıdır.
3. Departman hedeflerini uyumlu hâle getirin. Onay almak için üç hafta beklemeniz gereken o örneği tekrar düşünün. Ya bunun yerine yalnızca birkaç saat sürseydi? Bunun için yönetim kontrol sistemlerini değiştirerek departmanların hedeflerini eşleştirmeniz gerekir. Çoğu yönetici, operasyonları değiştirip verimli hâle getirerek kapasitenin büyük bir bölümünü açığa çıkarabileceklerinin farkına varmadan kapasiteyi artırmak ister.

Efsane 2: Büyük partiler hâlinde çalışmak geliştirme sürecini iyileştirir

Büyük partiler hâlinde çalışmak üretimde iyi sonuç verir, ancak ürün geliştirmede verimli değildir. Büyük partiler daha fazla kuyruk anlamına gelir ve daha fazla kuyruk, devam eden iş miktarının artmasına ve çevrim sürelerinin uzamasına yol açar.

Bir ekibin bir makinenin 300 bileşenini üretmesi gerektiğini varsayalım. Ekip tüm parçaları birlikte üretebilir veya 20'şer parçalık partiler hâlinde çalışabilir. Tüm parçaları birlikte üretmeye karar verirse:

• Kuyruklar daha uzun olur
• Çevrim süreleri daha uzun olur 
• Geri bildirim asgari düzeyde olur

Bir ürün geliştirme planı tamamen planlandığı gibi ilerlemeyebilir. Teknik özelliklerde veya ürünün başka bir niteliğinde değişiklik yapmanız gerekebilir. Bu öğrenme eğrisini aşmanın tek yolu geri bildirim almaktır.

Geri bildirim, ürünü test ederken ve nasıl performans gösterdiğini gözlemlerken edindiğiniz bilgidir. Geliştirme sürecinde teknik faktörlere dayalı olarak herhangi bir değişiklik gerekip gerekmediğini belirlemek için gereklidir. Daha az geri bildirim, daha uzun çevrim sürelerine yol açar. Çevrim süresi, tasarımın tamamlanması ile üretim arasındaki süredir. Bunu Little Yasası'nı kullanarak ölçebilirsiniz.

İkinci durumda parti boyutu yüzde 90 daha küçüktür. 

• Çok az veya hiç devam eden iş yoktur 
• Kuyruk yoktur 
• Hızlı geri bildirim alınır
• Daha iyi kalite ve verimlilik sağlanır, çevrim süreleri azalır

Birçok ürün geliştirici, büyük partiler hâlinde çalışmanın ölçek ekonomisi sağladığını düşünerek ilk yolu seçer. Ancak bu, gerçeğin çok uzağındadır. En uygun parti boyutuna ulaşmak, işlem maliyetleri ile elde bulundurma maliyetleri arasında denge kurmaya bağlıdır. 

Bugün bir yıllık yumurta ihtiyacınızı stoklarsanız bunun için iyi bir fiyat alabilirsiniz, ancak yumurtaların çoğu bozulur. Başka bir deyişle, işlem maliyetiniz düşük, ancak elde bulundurma maliyetiniz yüksektir. Her iki dünyanın da en iyi yönlerinden yararlanmanın püf noktası doğru dengeyi bulmaktır.

En uygun parti boyutuna ulaşmak hiç de kolay değildir. Bu boyut işletmeden işletmeye değişir. Örneğin bir bakkalınız varsa elde bulundurma maliyetleriniz çelik üreticilerinin maliyetlerinden çok daha yüksek olacaktır. Sonuç olarak, yeni darboğazlar oluşturmayacak ve size en düşük maliyete mal olacak parti boyutunu seçin.

İlgili Okuma: Ürün Ekipleri İçin Etkili Bir Müşteri Geri Bildirim Döngüsü Nasıl Oluşturulur?

Efsane 3: Ürünü özelliklerle doldurun, müşteriler ona bayılacaktır.

Ürün geliştiriciler, bir ürüne ne kadar çok özellik eklerlerse müşterilerin ürünü o kadar beğeneceğini düzenli olarak varsayar. Bu, gerçeğin çok uzağındadır ve çoğu zaman özellik sürünmesine yol açar. Bir ürünü kaç kez elinize alıp kullanmasının çok karmaşık olduğunu gördünüz?

Bu her zaman olur. Tipik kulaklıkların yan tarafında çok fazla düğme bulunur, televizyon kumandalarının kullanımı zordur, LCD ekranların kurulumu zahmetlidir ve kablosuz şarj hâlâ bir hayaldir. Yine de bir ürün geliştiriciyi ürünü basit tutmaya ikna etmek zordur ve bunun başlıca iki nedeni vardır:

1. Ürün geliştiriciler, fikirleri daraltmadan çok fazla fikir üzerinde beyin fırtınası yapma eğilimindedir. Genellikle bir filtre eksikliği olduğunu fark ettim. Bu, bir işkolik kişinin gününde boş bir zaman dilimi görmeye dayanamamasına benzer. O zamanı üretken bir şeyle doldurması gerekir.

Aynı şekilde, ürün geliştiricileri de tüketicinin bunları kullanıp kullanmayacağına bakmaksızın, bir ürüne daha fazla özellik ekleyebilecekleri boş bir alan bulduklarında bunu bir fırsat olarak görürler.

Apple Inc. bunun tam tersine harika bir örnektir. Her zaman sadeliği ve zarafeti ön planda tutar. Ürün geliştirme, son kullanıcıdan başlar ve teknolojiye doğru ilerler. Başka bir deyişle, teknolojiyi tüketici yönlendirir; tersi değil. Hatta bir ürün piyasaya sürülmeden önce son sözü Apple’ın tasarım ekibi söyler.

Bir ürüne gereksiz özellikler yığmak müşteriye değer katmaz. McKinsey’nin raporuna göre, çoğu şirket “müşterilerin ürün performansından memnuniyetini izliyor [ve] yalnızca yüzde 44’ü, müşterilerin aldıkları değer karşılığında ödedikleri fiyattan memnuniyetini ölçüyor.”

İkinci ölçüte daha fazla önem veren şirketler, hem kısa hem de uzun vadeli kâr artışı ve istikrar açısından daha iyi sonuçlar elde etti. Buna karşılık yalnızca ürün performansına odaklananlar, uzun vadeli büyüme fırsatlarını kaçırdı.

2. Ürün geliştiricileri uzmanlıklarını sergilemeye bayılır. Öyle ki bazen işin teknik ayrıntılardan çok müşteri deneyimiyle ilgili olduğunu unuturlar. Tüm tüketicilerin istediği, sorunsuz bir kullanıcı deneyimi ve zahmetsizce çalışan bir çözümdür.

Bunu gerçekleştirmek için ürün geliştiricilerinin neleri dışarıda bırakacaklarını bilmeleri gerekir. Kendinizi tüketicilerin yerine koyun. Yerleşik ses sistemine sahip bir buzdolabı satın almak ister miydiniz? İlk bakışta kulağa hoş geliyor, ancak buzdolabında şarkı dinlemek yalnızca kullanışsızdır.

Listenizi daraltın. Seçtiğiniz ürün özellikleri ya temel nitelikte olmalı ya da ürünü öne çıkarmalıdır. Bir ürünün, daha fazla özellik ekleyemediğinizde değil, bir özelliği çıkarmanın ürünü daha iyi değil daha kötü hâle getireceği noktada tamamlandığını unutmayın. 

Perakendeciler için basit ve kullanımı kolay bir uygulama geliştirmek üzere UX/UI tasarımcılarıyla çalışırken kullandığım sürece bir örnek:

1. Fikir üretme sürecine katılın; bu, temelde doğru soruları sormak ve “nasıl” sorularını yanıtlamak anlamına gelir. Ekibinizle fikir alışverişi yaparak bariz olanın ötesine geçmek ve yenilikçi çözümler aramak için bir fırsattır. Bu sürecin kontrolden çıkmaması için bir zaman sınırı da belirleriz. Yaratıcılığı zaman ve verimlilik uğruna feda etmek istemezsiniz.
   
2. Nihai ürüne ilişkin vizyonunuzu daralttıktan sonra, çoğu geliştiricinin gözden kaçırdığı en önemli adımın sondan başlamak ve geriye doğru tersine mühendislik yapmak olduğunu düşünüyorum. Bu, nihai ürününüze ulaşmak için gereken tüm adımları belirlemenize yardımcı olur. Çoğu geliştirici en baştan başlar ve sonunda başlangıçta planladığı şeyi gözden kaçırır.
   
3. Daha önce belirtildiği gibi, ürün geliştirme planı değişebilir ve değişir de. Tüm adımlar uygulanırken beyin fırtınası devam eder; ancak artık teknik ayrıntılara odaklanmıştır. Bunu, başlangıçta tasarladığınız fikri ince ayarlamak ve onu bir sonraki seviyeye taşımak gibi düşünün.

4. Efsane: Ne pahasına olursa olsun plana bağlı kalın

Bir atasözünde dendiği gibi, “insanların ve farelerin en iyi hazırlanmış planları bile çoğu zaman ters gider.” Bundan daha doğru bir ifade olamaz. Ürün geliştirme, baştan sona deneme ve yanılmadan ibarettir. Deney yapmak, daha önce gözden kaçırdığınız boşlukları fark etmenizi sağlar.

Bir MIT araştırması, ürün geliştirmenin dinamik doğasını ortaya koyuyor. Bir alt sistem üzerinde çalışan havacılık ve uzay mühendisleri, en iyi tasarımı seçmeden önce birden fazla tasarımı değerlendirdi. Ancak mühendislik süreci boyunca tercihleri, test sonuçlarına bağlı olarak değişti.

Ürün geliştirme tamamen yenilikle ilgilidir. Ürünün ilk taslağıyla başlar ve ilerledikçe üzerinde değişiklikler yaparsınız. Belki telefonun cam arka yüzü fazla ısınıyordur ya da kavisli kenarlar GPS anteninin sığmasına izin vermiyordur. Bu içgörüleri ancak test etmeye ve deney yapmaya başladığınızda elde edebilirsiniz.

Daha önce ele alındığı gibi, ürün geliştirme teknolojiyle değil, müşteriyle başlar. Peki müşterinin neye ihtiyaç duyduğunu nasıl ölçersiniz? Memnun olmayan müşterilerin çoğu bir ürün hakkında şikâyet etmez; yalnızca ayrılır. Daha da kötüsü, gelişen pazar eğilimleri nedeniyle müşterilerin tercihleri geliştirme süreci boyunca değişirse ne olur?

Tüm bu soruların yanıtı, geliştirme planınızı değiştirmenizdir. Bu, planlamanın boşuna olduğu anlamına gelmez; son ayrıntısına kadar titiz olmanız gerektiği anlamına gelir. Planınızı bir yasa yerine bir hipotez gibi ele alın; çünkü günün sonunda kusursuz bir plan değil, kusursuz bir ürün istersiniz.

Ürün geliştirme planınızı daha esnek tutmak için yapabileceğiniz bazı şeyler şunlardır:

1. Kapsamlı bir plan geliştirin. Bunu, geliştirme sürecinize yön verecek bir iskelet, temel bir yapı gibi düşünün. Ayrıntıları dışarıda bırakın; çünkü zamanla kendiliğinden yerli yerine oturacaklardır. Hatta ürününüz için kesinlikle gerekli olan bazı ayrıntılara yer açmak üzere temel yapıyı değiştirmeniz bile gerekebilir.
   
2. Planınızdaki kusurları bekleyin. Her şeyi önceden görmeniz mümkün değil. Bu nedenle planınız, gerektiğinde başvurabileceğiniz yeterli bir esnekliğe sahip olmalıdır. Daha önce oluşturduğunuz temel yapıya alternatifler geliştirin.

İlgili Yazı: En İyi Ürün Planlama Yazılımları

Son Düşünceler

Ürün geliştiricilerinin gezegendeki en zor işlerden bazılarını üstlendiğine şüphe yok. Yenilik için zaman ve bolca deneme gerekir. Buna, imalat veya üretim gibi sıradan bir süreçmiş gibi yaklaşamazsınız. Ben de bir ürün geliştirici olarak, çoğu yöneticinin bunu anlamadığını söyleyebilirim. Bu mitlerin içinde yaşıyorlar ve birilerinin bu balonu patlatması gerekiyor.

Ürün geliştirme ne kadar heyecan verici olsa da ister her iş için bir çalışanınız olsun ister eksiksiz bir ekip olmadan ürünleri yönetin, aynı ölçüde sinir bozucu ve tüketici olabilir. Oyunun zirvesinde kalmanın anahtarı, yukarıdaki mitleri ortadan kaldırmaktır. Yeni bir ürün yöneticisiyseniz, sizi sayısız baş ağrısından ve anlamsız toplantıdan kurtardık. Deneyimli bir profesyonelseniz, aşağıdaki yorumlar bölümünde başka ürün yönetimi mitlerini paylaşmaktan çekinmeyin.

Alan uzmanlarının görüşlerini içeren, sizi gelişmelerin önünde tutacak daha bilgilendirici ürün yönetimi makaleleri ve ipuçları için The CPO Club'ın bültenine abone olun.

Ya da şu podcast'lerimizden birini dinleyin: İvme Kazanmak (Bain Public'den Paul Ortchanian ile)