Kendi ürününü kullanmak neden bir kalite aracıdır?
Bir ekip, her gün kullandığı bir aracın eksiğini birkaç saat içinde fark eder; kullanmadığı bir aracın eksiğini ise ancak müşteri şikâyet ettiğinde öğrenir. Aradaki fark haftalar, bazen aylardır — ve o süre boyunca eksik, ürünü satın almış herkesin gününü küçük küçük bozar. Kendi ürününü kullanmanın kalite üzerindeki etkisi bu kadar basit bir mekanizmadan geliyor: geri bildirim döngüsünün kısalması.
İkinci etkisi önceliklendirmededir. Uzaktan bakıldığında bütün eksikler eşit görünür ve liste, en yüksek sesle istenen maddeye göre sıralanır. Ürünü kullanan bir ekipte ise sıralama kendiliğinden oluşur: gün içinde en çok canınızı sıkan şey, listenin başına çıkar. Bu, kullanıcıların da en çok canını sıkan şey olma eğilimindedir; çünkü aynı ekranlarda aynı işi yapıyorsunuzdur.
Bunun bir sınırı olduğunu da söyleyelim: siz tipik kullanıcı değilsiniz. Ürünü yazan kişi, ekranı gözü kapalı kullanır ve yeni bir kullanıcının nerede duraksadığını göremez. Kendi kullanımınız 'ne bozuk' sorusunu iyi cevaplar, 'ne anlaşılmıyor' sorusunu ise cevaplayamaz. İkincisi için gerçek kullanıcıyı izlemek gerekir; ikisi birbirinin yerine geçmez.
Biz bunu nasıl uyguluyoruz?
İçerik platformumuzun kendi tanıtım sitesi, o platformun üzerinde bir kiracı olarak yaşıyor. Yani ürünün pazarlama sayfası, ürünle yönetiliyor. Bu, dışarıdan bakınca hoş bir ayrıntı gibi görünür; içeriden bakınca en sert kalite denetimidir. Panelde bir alanı bulmak zorlaşırsa bunu ilk biz yaşarız, çünkü kendi metinlerimizi orada düzenliyoruz.
İş takip aracımız için de aynısı geçerli: kendi işlerimizi, hatalarımızı ve sürümlerimizi orada yönetiyoruz. Bu yüzden yol haritası bir toplantı odasında değil, günlük kullanımın içinde şekilleniyor. 'Şu ekranda üç tık fazla var' cümlesi, bir müşteri talebinden daha hızlı iş emrine dönüşüyor — çünkü o üç tık, o hafta hepimizin canını sıkıyor.
Kurumsal sitemizde de aynı ilkeyi izliyoruz: halka açık yüz bir çatıyla, yönetim paneli başka bir çatıyla yazıldı ve ikisi aynı arayüzü konuşuyor. Müşterilere önerdiğimiz ayrımı önce kendimize uyguladık; böylece 'bu ikili neden mantıklı' sorusuna teorik değil, üzerinde gezdiğiniz siteyi göstererek cevap verebiliyoruz.
Bedeli: kendi ürününüzü kullanmak sizi yavaşlatır
Bu yaklaşımın romantik anlatılmaması gerekir; gerçek bir bedeli var. Kendi ürününüzü kullanmak, olgunlaşmamış bir aracı iş akışınıza sokmak demektir. Eksik bir özellik yüzünden geçici çözüm üretirsiniz, bir hata yüzünden bir işi ikinci kez yaparsınız, bazen de ürünü düzeltmek için asıl işinizi bırakırsınız. Hazır ve olgun bir araç kullanmak, ilk yıl neredeyse her zaman daha hızlıdır.
İkinci bedel, körlüktür. Aynı ekranı her gün gören ekip, o ekranın tuhaflıklarına alışır ve bir süre sonra fark etmez olur. Bunu dengelemenin tek yolu, düzenli aralıklarla dışarıdan göz getirmektir: ürünü hiç kullanmamış birine bir işi yaptırıp izlemek. Kendi kullanımınız körlüğü yaratır, kullanıcı testi onu dağıtır.
Kendi ürününü kullanmak, ekibi beta testçi yapmak değildir
İki şey sık karıştırılıyor: ürünü gerçek işinizde kullanmak ile ekibi yarım kalmış özellikleri denemeye zorlamak. Birincisi, ürünün gerçek bir iş yükü altında nasıl davrandığını gösterir; ikincisi, ekibin zamanını çalar ve bir süre sonra 'zaten bozuktur' alışkanlığı yaratır. Ayrımın ölçüsü basit: iç kullanım, gerçek bir işi gerçekten yürütmelidir. Yürütmüyorsa o kullanım değil, testtir.
Bu ayrımı korumak için iç kullanımın da bir kalite eşiği olması gerekir. Bir özellik iç kullanıma açılıyorsa, en azından temel akışı çalışmalı ve veri kaybı riski taşımamalı. Bizde kural şu: iç kullanıma açılan şey, müşteriye açılacak kadar olgun olmasa bile, güvenilir olmak zorunda. Denenecek yer test ortamıdır; iş yürütülen yer değil.
Kendi ürününü kullanan ekipte hata kaydı kültürü
Kendi ürününü kullanan bir ekipte en büyük risk, hataların kayda geçmemesidir. Herkes kodu bildiği için sorunu ya kendi başına düzeltir ya da 'ben biliyorum, oradan gitme' diye etrafından dolaşır. Sonuç, ekibin bildiği ama sistemin hiç görmediği bir hatalar listesidir — ve o liste müşteride bir gün mutlaka ortaya çıkar.
Bunu engellemenin tek yolu, kaydın ucuz olmasıdır. Hata kaydı açmak üç tıktan uzunsa kimse açmaz; şablon istiyorsa, zorunlu alanları çoksa ya da hangi projeye açılacağı belirsizse hiç açılmaz. Biz kendi takip aracımızda bu yüzden kayıt açmayı bilinçli olarak hafif tuttuk: tip, başlık ve tek cümle yeterli; gerisi sonra doldurulabilir.
İkinci alışkanlık, 'ben hallederim' cümlesini kayda dönüştürmektir. Bir geliştirici hatayı beş dakikada düzeltebilir, ama kaydı açmadan düzelttiğinde iki bilgi kaybolur: bu hatanın var olduğu ve hangi değişiklikle geldiği. Bu iki bilgi, aynı hata altı ay sonra geri geldiğinde en çok ihtiyaç duyacağınız şeydir.
İç ihtiyaç ile müşteri ihtiyacı çatıştığında
Kendi ürününü kullanmanın gölge tarafı, yol haritasının iç ihtiyaca göre eğilmesidir. Sizi rahatsız eden şey listenin başına çıkar; oysa müşterinin ihtiyacı başka bir yerde olabilir. Bizim işimiz onlarca ürünü aynı anda yürütmek olduğu için, iç ihtiyaçlarımız çoğu müşteriden daha karmaşık — bu, kolayca 'kimsenin istemediği bir özelliği mükemmelleştirme' tuzağına dönüşebilir.
Bunu dengelemek için basit bir kural kullanıyoruz: iç kullanımdan doğan bir talebin yol haritasına girmesi için, en az bir dış kullanım senaryosuna karşılık gelmesi gerekir. Yalnız bize özgü bir ihtiyaçsa, çözümü ürüne değil kendi yapılandırmamıza koyarız. Ürünün genel kalması, en az iç verimliliğimiz kadar önemli.
Uydurma rakam yok: sitemizde neden yüzde ve müşteri sayısı görmüyorsunuz?
Sitemizde 'müşteri memnuniyeti %98', 'verimliliği 3 kat artırdık' ya da uydurulmuş müşteri alıntıları yok. Bunun sebebi alçakgönüllülük değil, kural: yayımladığımız her sayının arkasında ölçülebilir bir kaynak olmalı. Bu kuralı içerik üretirken herkese açıkça söylüyoruz — istatistik bandına yalnız gerçek sayılar girer, gerisi girmez.
Bu kuralın en görünür sonucu, bazı bölümlerin daha 'zayıf' görünmesidir. Ürün sayfalarımızda modül sayısı, ekran sayısı, dil sayısı gibi sayılabilir şeyler var; ciro etkisi ya da memnuniyet oranı yok. Rozet bandı da yok, çünkü henüz gerçek bir rozetimiz yok — birileri koydu diye yer tutucu logo dizmek, ilk bakışta iyi ikinci bakışta kötü görünüyor.
Aynı dürüstlük görsellerde de geçerli. Sitedeki bazı videolar şu an telifsiz yer tutucu ve bunu içeride açıkça böyle işaretliyoruz; yerlerine kendi ürün görüntülerimiz konacak. Bir müşteri 'bu ekran görüntüsü gerçek mi' diye sorduğunda cevabın tereddütsüz olması, uzun vadede her tasarım hilesinden değerli.
Eksiğini söylemek satışı bozar mı?
Kısa vadede bozar, uzun vadede kurtarır. Ürün sayfalarımızda henüz yapılmamış özellikleri açıkça işaretliyoruz ve bu, karşılaştırmalı bakan birinde 'şunlar eksik' izlenimi bırakabiliyor. Buna karşılık, satış görüşmesinde hiçbir sürprizle karşılaşmayan bir müşteri, teslimden sonra da aynı güvenle konuşuyor. Beklentiyi doğru kurmak, sonradan yönetmekten kolaydır.
Bir de şu var: eksiğini söyleyen bir liste, söylediklerini de inandırıcı kılar. Her maddesi işaretsiz duran bir özellik listesi, okuyanı 'bunların hepsi gerçekten var mı' diye düşündürür. Yanında dürüstçe 'bu yok' yazan bir liste ise geri kalanın gerçekten var olduğunu ima eder. Dürüstlük burada etik bir tercih olduğu kadar iletişimsel bir avantaj.
Referans ve vaka anlatımı: izin olmadan müşteri adı yazılmaz
Dürüstlük kuralının en somut hâli referans sayfasıdır. Bir müşterinin adını, logosunu ya da projesinin ayrıntısını yayımlamak izne bağlıdır; izin sözlü verilmiş olsa bile yazılı teyit almak gerekir. Bu, hukuki bir tedbir olduğu kadar mesleki bir görgü kuralı: müşterinin iç süreçlerini pazarlama malzemesine çevirmek, ona sormadan yapılacak bir şey değil.
İzin alınamadığında iki yol var: projeyi hiç anlatmamak ya da anonimleştirerek anlatmak. İkincisi sanıldığından zordur — sektör, şehir ve ölçek birlikte verildiğinde çoğu proje tanınır hâle gelir. Anonim vaka yazarken sorulacak soru şu: bu metni müşterinin rakibi okusa, kimden bahsedildiğini anlar mı? Anlıyorsa yeterince anonim değildir.
Bizim tercihimiz, gerçek izin gelene kadar boş bırakmak oldu. Referans bölümümüzde uydurma logo dizmiyoruz ve olmayan bir vaka anlatmıyoruz. Bu, sayfayı bugün daha zayıf gösteriyor; ama bir müşteri 'sizin şu projeniz' diye sorduğunda anlatacak gerçek bir hikâyemiz oluyor. Kısa vadeli görüntü ile uzun vadeli güven arasında seçim yapmak gerektiğinde ikincisini seçiyoruz.
Kendi ürününü kullanmak her zaman mümkün mü?
Hayır, ve bunu kabul etmek gerekiyor. Bir klinik yönetim yazılımı yazıyorsanız klinik işletmiyorsunuzdur; bir uçuş operasyonu ürününde kendi uçağınız yoktur. Bu alanlarda kendi kullanımın yerini alan şey, işi yapan kişiyle kurulan yakın ilişkidir: ekranın başında oturup izlemek, günün nasıl aktığını görmek, kendi varsayımlarınızı orada test etmek.
İkinci telafi yöntemi, kendi işinizin o ürüne benzeyen parçasını bulmaktır. Bir randevu ürününde kendi toplantı düzeninizi, bir belge yönetim ürününde kendi sözleşme akışınızı o araçla yürütebilirsiniz. Tam kullanım değildir ama 'hiç kullanmamak'tan çok daha iyidir; en azından temel akışın günlük hayatta nasıl hissettirdiğini öğrenirsiniz.
Kendi kullanımınız müşteriyi ne kadar temsil ediyor?
Kendi kullanımınızın değeri, müşterininkine ne kadar benzediğiyle sınırlıdır. Biz aynı anda onlarca ürün yürüten bir ekibiz; bir müşteri ise tek bir işletmeyi yürütür. Bizim için 'çok proje arasında geçiş' günlük bir ihtiyaç, çoğu müşteri için hiç karşılaşılmayan bir durum. Bu farkı bilmeden kendi deneyiminizi genelleştirmek, ürünü kendinize göre eğmenin en kolay yoludur.
Bunu dengelemek için iki şey yapıyoruz. Birincisi, kendi kullanımımızdan doğan her talebi 'bu tek kullanıcılı bir işletmede de gerekir mi' sorusundan geçiriyoruz. İkincisi, ürünü ilk kez kullanan birini izleyip nerede duraksadığını not ediyoruz; bizim beş saniyede yaptığımız bir işi başkasının iki dakikada yapması, ekranın değil bizim alışkanlığımızın ölçüsüdür.
Eksiği söylemenin ekip içi karşılığı
Dışarıya karşı dürüst olmanın ön koşulu, içeride dürüst konuşabilmektir. Bir ekipte 'bu özellik aslında yarım' cümlesini söylemek cezalandırılıyorsa, o cümle satış toplantısına kadar hiç söylenmez ve orada da söylenmez. Yapılmamışı yapılmış göstermenin kökeni genellikle kötü niyet değil, kötü haber taşımanın maliyetli olmasıdır.
Bunun pratik karşılığı, durumun ürünün kendi içinde işaretlenebilmesidir. Bir modül katalogda 'yakında' olarak durabiliyorsa, o bilgiyi taşımak kimsenin cesaretine kalmaz; sistemin normal bir durumu olur. Kültürü kurallarla değil, kuralı taşıyan yapılarla korumak daha sağlam çalışıyor — insanlar unutur, alan boş kalmaz.
Son olarak, dürüstlüğün bir yönü de kendi kararlarınıza karşıdır. Bir özelliği yanlış tasarladıysanız, onu savunmak yerine geri almak; bir kararın işe yaramadığını görünce yazıp değiştirmek. Bizim hafıza dosyalarımızda 'bu yanlış çıktı' diye başlayan notlar var ve bunlar en değerli notlar — çünkü bir sonraki sefer aynı yoldan gitmemizi engelliyorlar.
Sonuç
Kendi ürününü kullanmak bir pazarlama cümlesi değil, bir kalite mekanizmasıdır: geri bildirim döngüsünü kısaltır, önceliklendirmeyi gerçeğe bağlar ve satarken söylediğinizle teslim ettiğiniz arasındaki mesafeyi kapatır. Bedeli, olgunlaşmamış bir araçla çalışmayı göze almak ve alışkanlık körlüğüne karşı dışarıdan göz getirmeyi ihmal etmemektir.
Bu duruşun ikinci yarısı da uydurmamaktır. Yayımladığınız her sayının bir kaynağı, her alıntının bir sahibi ve her 'yakında'nın gerçek bir gerekçesi olsun. Ürün sayfalarımızda bunun bedelini ödüyoruz ve ödemeye devam edeceğiz; çünkü bir müşterinin size ikinci kez iş vermesi, ilk seferinde ona neyi söylemediğinize bağlı.