Kapsam Kayması Tuzağı: Kulağa İyi Gelen Ama Aslında Öyle Olmayan Özelliklere Nasıl Hayır Denir

Bir uygulama yayınladın. Kullanıcılar geldi. Ve şimdi gelen kutun, hepsi iyi fikir gibi görünen özellik talepleriyle dolu.

“Excel’e dışa aktarma ekleyebilir miyiz?” Makul. “Faturalar otomatik gönderilebilir mi?” Mantıklı. “Stripe ile entegre olabilir miyiz?” İşte gerçek paranın olduğu yer. “Bir mobil uygulama ekleyebilir misin?” Herkes onu ister. “Bunu kendi müşterilerimiz için white-label yapabilir miyiz?” Aa, işte şimdi bir iş modeli çıktı.

Her talep tek tek akıllıca geliyor. Bir araya geldiğinde, kulağa beş farklı ürün geliştiriyormuşsun gibi geliyor.

İşte bu kapsam kayması ve küçük, yapay zekayla geliştirilen uygulamaları teknik sorunların öldürebileceğinden daha fazla öldürüyor. Özellikleri geliştirdiğin için değil — onları geliştirmeye çalışırken zamanın, paran ya da aklın bittiği için.

Kapsam kayması çalışan bir uygulamayı nasıl öldürür

İşte olan şu. İlk üç talebe makul göründükleri için evet diyorsun. Yapay zeka oluşturucundan onları eklemesini istiyorsun. Her yeni özellik mevcut koda çarptığı için bir hafta yerine iki hafta sürüyor. Şimdi beş şey yapan bir uygulaman var ve bunların üçünü iyi, ikisini idare eder şekilde yapıyor.

Sonra dördüncü talep geliyor: “Farklı izin seviyelerimiz olabilir mi?” Birden her ekranda kimin neyi görebileceğini yeniden düşünmen gerekiyor. Bu bir özellik değil; bir mimari değişikliği. Yapay zeka oluşturucundan bunu yapmasını istiyorsun. Her şeye dokunuyor. İki hafta üç oluyor. Her görünüme mantık eklediğin için uygulama yavaşlıyor.

Sekizinci talebe geldiğinde, özgün kullanıcıların için yeni şeyler yayınlamayı bıraktın çünkü özellik-talebi makinesini döndürmekle çok meşgulsün. Uygulamayı üç ay önce seven insanlar hayal kırıklığına uğradı çünkü istedikleri hiçbir şey bitmiyor. Yeni talepler gönderenler hayal kırıklığına uğradı çünkü özellikler bir türlü gelmiyor.

Çalışan bir şey geliştirdin. Her şey olmaya çalışarak onu bozdun.

Karar çerçevesi

Bir kapıya ihtiyacın var. Her özellik talebi üç sorudan geçer:

Soru 1: Bu, bu uygulamaya mı ait, yoksa farklı bir uygulama mı?

İlk uygulaman bir işi gerçekten iyi yapar. Bir randevu uygulaması randevu ayarlar. Bir faturalama uygulaması fatura keser. Bunlar farklı uygulamalardır. Biri randevu uygulamandan fatura kesmesini istiyorsa, bir özellik eklemiyorsun — bir randevu uygulamasından muhasebe yapmasını istiyorsun. Bu farklı bir ürün.

İyi bir test: “Bu özelliği alıp tek başına yayınlasam, insanlar onu satın almak ister miydi?” Cevap evetse, muhtemelen farklı bir uygulamaya aittir. Cevap “hayır, sadece daha büyük şeyin parçası olarak mantıklı” ise, doğru kapsamı geliştiriyorsun demektir.

“CRM’imizle entegre ol” gibi talepler alacaksın. Bunun gerçek anlamı “kendi CRM’in ol.” Bu farklı bir uygulama. Sonra bir CRM ile entegre olabilirsin. Bir CRM dolusu özelliği, bir CRM’e dönüşmeden ekleyemezsin.

Soru 2: Bu, kullanıcılarının çoğu için mi yoksa sadece bu biri için mi bir sorunu çözüyor?

Bir müşteri uygulamana bayılıyor ve bir özellik fikri var. Yaşadığı gerçek bir sorun. Aynı zamanda sadece onun yaşadığı gerçek bir sorun.

Yirmi kullanıcın varsa ve biri bir şey istiyorsa, kontrol et: diğer on dokuzu da bunu mu bekliyor, yoksa bu kişi aklına geldiği için mi istedi? Onlara doğrudan sorabilirsin: “Senden önce, buna ihtiyacı olan başka biri var mı diye sormayı düşündün mü?” Genellikle cevap hayırdır.

Bu tehlikeli soru çünkü isteyen tek müşteri en önemli müşterin olabilir. Onu mutlu tutman gerekebilir. Bu bir iş kararı, ürün kararı değil. Ama gözlerin açık gir: bir müşteri için bir şey geliştirirsen, uygulamanı büyütmüyorsun, bir danışmanlık pratiği kuruyorsun.

Soru 3: Bunun maliyeti ne ve özgün fikre maliyeti ne?

Her şeyin bir maliyeti var. Excel’e dışa aktarmak sana mühendislik zamanına mal olur. Uygulamana karmaşıklığa mal olur. Odağa mal olur. Bunu, kullanıcılarının her gün şikâyet ettiği bir performans iyileştirmesi yerine geliştir, bir tercih yapmış olursun.

Somut sor: “Bunu geliştirirsem, neyi geliştir_me_yeceğim?” Cevap “hiçbir şey, sonsuz zamanımız var” ise, dürüst olmuyorsun. Yok. Zaman sınırlı.

Özgün fikre olan maliyet genellikle görünmezdir. Özellik taleplerinin içine gömüldüğünde, insanların seninle ilgili sevdiği o çekirdek şeyi sürdürmeyi bırakırsın. Çekirdek yavaşlar. Çekirdek daha hatalı hale gelir. Çekirdek ihmal edilmiş hisseder. Ve sonunda insanlar ayrılır çünkü harika çalışan o uygulama artık idare eder şekilde çalışıyor ve asla yapılmak üzere tasarlanmadığı şeyleri yapıyor.

Gerçek bir örnek: kabul formu

Biri basit bir müşteri kabul formu geliştirdi. Müşteriler doldurur, koç inceler, randevu ayarlarlar. Uygulama bu.

Talep bir: “Acil kabulleri işaretleyebilir miyim?” Evet, bu çekirdek iş akışının bir varyasyonu. Geliştir.

Talep iki: “Kayıtlarım için kabulleri Excel’e aktarabilir miyim?” Bu bir belge özelliği. Uygulamanın işi değil. Kabuller uygulamada yaşıyor. Excel istiyorlarsa, kopyala-yapıştır yapabilirler. Ama tamam, dışa aktarma bir kolaylık olarak mantıklı olabilir. Geliştir.

Talep üç: “Kabuller otomatik olarak takvim etkinlikleri oluşturabilir mi?” Şimdi randevu işi yapıyorsun. Uygulama kabul içindi, randevu için değil. Biri ikisini de istiyorsa, muhtemelen üstüne yamanmış bir kestirme değil, gerçek bir randevu sistemi istiyordur. Nazikçe reddet.

Talep dört: “Koçlar kabul takiplerini SMS ile gönderebilir mi?” Şimdi bir iletişim sistemisin. Hayır.

Talep üçte, sınıra çarptın. Uygulama kabul. Geri kalan her şey farklı bir uygulama. Sonra o uygulamalarla entegre olabilirsin. Onlar olmadan, o uygulamalara dönüşmeden onları ekleyemezsin.

Nasıl hayır denir

En zor kısmı aslında onu söylemek. Kullanıcılarını hayal kırıklığına uğratmak istemezsin.

Dürüst ol: “Bu harika bir fikir ama burada geliştirdiğimiz şeyden farklı bir ürün. Bizim geliştirdiğimiz şey [tek işin]. Randevu, faturalama ya da CRM işleri yapmaya çalışırsak, hepsinde idare eder, hiçbirinde harika olmayız.”

Çoğu zaman müşteri anlayacaktır. İstediler çünkü fikir akıllarına geldi, seni test ettikleri için değil.

Bazen direnirler. “Ama ikisine de ihtiyacım var.” İşte o zaman önerirsin: gerçek randevu uygulamasını kullan. Gerçek faturalama uygulamasını kullan. Gerçek CRM’i kullan. Sonra bu uygulamayı iyi yaptığı şey için kullan. İşte dürüst cevap bu.

Her şey olma cazibesi

Küçük bir ürün geliştirmenin en zor kısmı hayır demek. Hayır, masada para bırakmak gibi hissettiriyor. Ya o müşteri gerçekten ikisi için de ödeme yapacak olsaydı? Ya o özellik seni on kat daha büyük yapacak olsaydı?

Belki. Ama onu yayınlamazsan on kat daha büyük bir ürün değilsin. Beş şeyi kötü yapan, yarım kalmış bir ürünsün. Çekirdeği sevenler hayal kırıklığına uğradı. Yeni özellikleri isteyenler hayal kırıklığına uğradı. Ve kendini, yeni bir şey eklemenin önce beş eski şeyi yeniden düzenlemek anlamına geldiği bir köşeye sıkıştırdın.

Büyüyen ürünler, bir işi gerçekten iyi yapan ve sonra dikkatlice ekleyenlerdir. İlk günden Salesforce olmaya çalışmazlar. O tek şeyi yapman gerektiğinde uzandığın uygulamadır onlar ve yaptığında hızlı ve güvenilir olacağına güvendiğin uygulamadır.

Hayır de. Çekirdeği koru. Bunu yap, insanların gerçekten kullanmak isteyeceği bir şey geliştirirsin.