Yazılım ekiplerinin üretmekte çok iyi olduğu belirli bir yoğunluk türü var. Kapatılan ticketlar, tamamlanan sprintler, zamanında çıkan sürümler. Hız metrikleri sağlıklı görünüyor. Mühendislik çalışması gerçekten sağlam. Ve bir şekilde, çeyrek çeyrek, ürün olması gerektiği gibi büyümüyor. Kullanıcılar daha fazla ilgi göstermiyor. Tutundurma iyileşmedi. Satış ekibi hâlâ bir yıl önce duyduğu itirazları duyuyor.

Suçlu, çoğu ekibin kabul etmek istediğinden daha sık, gerçekte kimsenin inşa edilmesine ihtiyaç duymadığı özelliklerle dolu bir yol haritası.

Bu Akıllı Ekiplere Nasıl Oluyor

Gereksiz özellikler hakkındaki rahatsız edici gerçek, nadiren birinin dikkatsiz ya da tembel olması yüzünden inşa edilmeleri. Her bireysel adımda tamamen makul görünen bir karar alma sürecinin sonucunda inşa ediliyorlar. Bir paydaş bir endişe dile getiriyor. Bir rakip benzer bir şey gönderiyor. Sesli bir kullanıcı sert dilli bir destek bileti gönderiyor. Strateji toplantısındaki biri, bu yeteneğin yeni bir pazar segmentinin kilidini açacağına dair ikna edici bir argüman ortaya koyuyor. Bu girdilerin her biri meşru geliyor ve bunlara yanıt vermek işi iyi yapıyor gibi hissettiriyor.

Problem herhangi bir girdi değil. Ekibi girdinin gerçek, yaygın bir kullanıcı ihtiyacını temsil edip etmediğini ya da yakınlık ve aciliyet tarafından güçlendirilmiş gürültü olup olmadığını doğrulamaya zorlayan yeterince güçlü bir filtrenin yokluğu. Bu filtre olmadan, odadaki en sesli sesler yol haritasını belirliyor ve en sesli sesler nadiren en temsili olanlar.

Niş bir yapılandırma seçeneği isteyen sesli bir güç kullanıcısı, kendini temsil ediyor, ek karmaşıklıktan kafası karışacak ya da bunalacak sessiz kullanıcı çoğunluğunu değil. Belirli bir uyumluluk özelliği olmadan imzalamayacak bir kurumsal aday, hizmet etmeye değer gerçek bir pazar segmentini temsil edebilir ya da eninde sonunda elde edilecek getiriye orantısız mühendislik kaynakları tüketecek tek bir uç durumu temsil edebilir. Farkı ayırt etmek iyi niyetten fazlasını gerektiriyor. Gerçek bir doğrulama süreci gerektiriyor ve çoğu ekip bunu atlıyor, çünkü doğrulama sadece inşa etmekten daha yavaş hissettiriyor.

Gerçek Maliyet İlk Anda Görünmez

Kimsenin kullanmadığı özellikler, ürünün içinde zararsızca yer kaplayan ekran alanı olarak oturmaz. Birikirken hafife alınması kolay ve biriştikten sonra görmezden gelinmesi çok pahalı maliyetler biriktirirler.

Bir ürüne eklenen her özellik, başka bir şey değiştiğinde test edilmesi gereken yüzey alanını artırıyor. Bir sonraki özelliği inşa ederken göz önünde bulundurulması gereken uç durumlar ekliyor. Ürünün ne yaptığını ve önce ne yapmaları gerektiğini anlamaya çalışan her yeni kullanıcı için biraz daha karmaşık hale gelen bir arayüze katkıda bulunuyor. Bu maliyetler izole halde görünmez, çünkü her bir özelliğin katkısı marjinal görünüyor. Basit başlayan bir ürünün yeni kullanıcı onboarding’inin iki saatlik bir sürece dönüştüğü ve mühendislik ekibinin yeni bir şey göndermekten çok mevcut davranışı sürdürmek için zaman harcadığı kadar yeterli karmaşıklık biriktirdiğinde görünür hale geliyorlar.

Kullanılmayan özelliklerden kaynaklanan teknik borç, kötü uygulama kararlarından kaynaklanan teknik borçtan kaldırmayı haklı çıkarmak da daha zor. Kötü yazılmış bir fonksiyon, birinin zamanı olduğunda yeniden düzenlenebilir. Kullanıcı tabanının büyük çoğunluğu hiç dokunmamış olsa bile üç kullanıcının güvendiği bir özellik, siyasi açıdan zor ve yönetimi zaman alıcı bir kaldırma konuşması yaratıyor. Özellikler eklemekten çıkarmak çok daha zor, bu da yanlış şeyi inşa etmenin maliyetinin onu çalışmayı bırakmaya karar verdiğinizde ortadan kalkmadığı anlamına geliyor.

Bu Problemi Yaratan Keşif Kısayolları

Yol haritalarında sonuçlanan gereksiz özelliklerin büyük kısmı, gerçek araştırma gibi hissettiren ama olmayan bir avuç keşif kısayolundan birine izlenebilir.

Yanlış insanlarla görüşmek. Kullanıcı görüşmeleri değerli, ama yalnızca görüşülen kişiler ürünün başarısı için gerçekten önemli olan davranışların kullanıcılarını temsil ediyorsa. Ekipler sıklıkla güç kullanıcılarını, kurumsal müşterileri ve görüşme taleplerine yanıt verecek kadar proaktif olan kişileri fazla önemseme eğiliminde, ki bunların tümü ürünün hizmet etmesi gereken ortalama kullanıcıdan sistematik olarak farklı. Bu görüşmelerden gelen içgörüler belirli ve güvenilir hissettiriyor, bu da gerçekte genelleştirilemez olduklarında tehlikeli kılıyor.

Özellik isteklerini temel ihtiyaçlarla karıştırmak. Kullanıcılar belirli bir özellik istediklerinde, yaşadıkları bir probleme çözüm öneriyorlar. Önerdikleri çözüm, kendi zihinsel modelleri ve teknik açıdan mümkün olanlar üzerinden süzülüyor, bu da altta yatan problem gerçek olsa bile çoğu zaman en iyi çözüm olmadığı anlamına geliyor. İstenen özelliği altta yatan problemi araştırmadan inşa eden ekipler çoğu zaman özelliğin kullanıcının ihtiyaç duyduğunu gerçekten çözmediğini buluyor, çünkü kullanıcı problemini yanlış soyutlama seviyesinde çözüyordu.

İç görüşleri kullanıcı verisi olarak ele almak. Şirket içinde herhangi bir özellik için en sesli savunucular genellikle ürünle her gün çalışan insanlar, bu da normal kullanıcılara genelleştirmeyen ürün hakkında sezgiler geliştirdikleri anlamına geliyor. Ürün tartışmaları, kullanıcı olarak ne istediklerini tartışan iç ekip üyelerince domine edildiğinde, sonuç ürün aşinalığında son derece alışılmadık insanların tercihlerini yansıtma eğiliminde, ilk kez karşılaşanların tercihlerini değil.

Doğrulama Gerçekte Nasıl Görünüyor

“Biri bunu önerdi”den “bunu inşa ediyoruz”a giden yolu yavaşlatmak, ayrıntılı araştırma programları ya da aylarca süren keşif çalışması gerektirmiyor. Herhangi bir özellik aktif geliştirmeye geçmeden önce ekibin cevaplamayı taahhüt ettiği küçük bir soru seti gerektiriyor.

Bu problemi spesifik olarak kim yaşıyor ve ne sıklıkla karşılaşıyorlar? Kullanıcıların yüzde yirmisinin her gün yaşadığı bir problemi çözen özellik, yüzde ikisinin ayda bir yaşadığı bir problemi çözen özellikten çok farklı bir yatırımı hak ediyor. İkisi de izole halde ele alınmaya değer görünebilir, ama sıklık ve erişim varsayılan değil açık olduğunda önceliklendirme tamamen farklı görünüyor.

Bu kullanıcılar şu anda bu problemi çözmek için ne yapıyorlar? Kullanıcılar etkili geçici çözümler geliştirmişse, inşa edilmiş bir çözümün aciliyeti göründüğünden daha düşük. Problemi yaşadıklarında ürünü tamamen terk ediyorlarsa, aciliyet çok daha yüksek. Geçici çözüm davranışı, herhangi bir öz bildirimli şiddet derecelendirmesinden gerçek acı seviyesi hakkında size daha fazla şey söylüyor.

Buna yer açmak için ne inşa etmeyi durduracağız ya da erteleyeceğiz? Diğer çalışmalarla açıkça takas yapmayan yol haritası önceliklendirmesi gerçek önceliklendirme değil. Bir dilek listesi. Yol haritasına eklenen her özellik başka bir şeyin yerini almalı ve ekibi neyin önceliğinin düşürüldüğünü isimlendirmeye zorlamak, yeni özelliğin gerçek maliyetini görünmez değil görünür hale getiriyor.

Kazanan Ürünler Çoğunlukla Daha Az İnşa Edenler

Güçlü, dayanıklı kullanıcı tabanları geliştirmiş yazılım ürünleri genelinde görünür bir kalıp var ve bu, daha fazla özelliğin daha fazla değer anlamına geldiği içgüdüsünün tersini çalıştırıyor. Kendi kategorilerinde kazanan ürünler, belirli bir çekirdek kullanım durumu belirleme, bu kullanım durumunu son derece iyi çalıştırma ve çekirdeği gerçekten mükemmel olana kadar kapsam genişletme baskısına direnme eğiliminde olanlar.

Rekabetçi baskıya yanıt olarak özellik ekleme cazibesinin gerçek ve anlaşılır, ama çoğunlukla geri tepme eğiliminde. Rakibini özellik özellik eşleştirmeye çalışan bir ürün genellikle karşılaştırmayı kaybeder, çünkü rakibin her özelliği geliştirmek için daha fazla zamanı vardı ve meydan okuyan mühendislik kaynaklarını daha geniş bir yüzey üzerinde yayıyor. Köklü oyunculara karşı etkili biçimde rekabet eden ürünler bunu genellikle her şeyde geniş çapta karşılaştırılabilir olmak yerine belirli bir konuda dramatik biçimde daha iyi olarak yapıyorlar.

Bu, ilerleme göstermek, kullanıcı taleplerine yanıt vermek ve satış ekibini yeni konuşma noktalarıyla mutlu tutmak için baskı olduğunda sürdürmesi gerçekten zor belirli bir disiplin gerektiriyor. Çalışmanın kanıtı olarak göstermenin en kolay şeyi gönderilen özellikler, bu da düşünme yerine inşa etmeyi ve doğrulama yerine açıklamayı ödüllendiren bir teşvik yapısı yaratıyor.

Hayır Demek Bir Ürün Becerisi

Çoğu ürün ekibi girdi toplamakta makul ölçüde iyi hale geliyor. Çok daha azı bunun arkasından gelmesi gereken filtrelemede iyi hale geliyor. Bir özellik isteğine hayır demek, kullanıcıdan gelse de, bir paydaştan gelse de, ikna edici bir iç savunucudan gelse de, ürün vizyonuna güven ve ürünün kim için olduğu ve onlar için hangi problemi çözdüğü hakkında gerçek bir netlik gerektiren bir beceri.

Bu netlik, hayırın engel değil ürün liderliği gibi hissettiren şey. Bir kararın ardındaki gerekçe “hizmet ettiğimiz kullanıcılar için odaklandığımız problem türü bu değil” olduğunda, “hayır çünkü meşgulüz”den çok farklı bir konuşma. Birincisi stratejik. İkincisi sadece sürtünme.

Bu beceriyi inşa eden ekipler, net gerekçe ve gerçek inanç ile hayır demeyi pratik edenler, dağınık ve odaksız değil tutarlı ve amaçlı hissettiren ürünler üretme eğiliminde. Bu ürünlerin kullanıcıları, başka biri için olabilecek özelliklerden oluşan bir labirenti dolaşmak zorunda kalmıyor. İhtiyaç duydukları şeyi buluyorlar, bekledikleri gibi çalışıyor ve bu deneyim gerçekten önemli olan tutundurma sayılarını yönlendiren güven türünü inşa ediyor.

Projelerimi ve çalışmalarımı incelemek isterseniz: https://hub.barisgunduz.com/