Gereksiz Unsurları Kaldırmanın Önemi

• Karmaşık hale gelmiş ürünler, daha fazla açıklamadan ziyade gereksiz unsurları kaldırarak iyileşebilir; Pinecone'un fiyat hesaplayıcısı vakası bunu gösteriyor
• Fiyat hesaplayıcısı, kullanıma dayalı maliyeti önceden tahmin etmeyi sağlamayı amaçlıyordu; ancak küçük bir giriş hatası bile tahmini maliyeti 1.000 kata kadar şişirerek kayıt olmayı engelliyordu
• Şirket içinde sorunu açıklamalar ve varsayılan değerler ekleyerek çözmeye çalıştılar, ancak yapılan düzeltmeler yeni kafa karışıklıkları yarattı ve özel Slack kanalında 550'den fazla mesaj birikti
• Hesaplayıcının kaldırıldığı A/B testinde, hesaplayıcıyı görmeyen ziyaretçilerin kayıt olma olasılığı %16, iletişime geçme olasılığı ise %90 daha yüksekti; ayrıca fiyatla ilgili destek taleplerinde artış olmadı
• Bir kez eklenen unsurlar, değerleri azalsa bile kalmaya eğilimlidir; bu yüzden ürün, proje ve süreçlerde büyük parçaları kaldırma kararları bilinçli biçimde gözden geçirilmelidir

---

Pinecone fiyat hesaplayıcısının kaldırılması vakası

• Pinecone, kullanıma dayalı fiyatlandırmada kullanıcıların gerçek maliyeti önceden tam olarak bilmesinin zor olması nedeniyle fiyat sayfasına bir maliyet hesaplayıcısı yerleştirdi
• Potansiyel kullanıcılarla yapılan görüşmeler sonucunda, bazı kullanıcıların hesaplayıcıda çok yüksek tahmini maliyetler görüp kayıt olmaktan vazgeçtiği doğrulandı
  • Söz konusu kullanım senaryosu Pinecone ölçütlerine göre nispeten küçüktü
  • Hesaplayıcı beklenenden çok daha kafa karıştırıcı ve hassastı
  • Küçük bir yanlış anlama ya da hatalı giriş bile tahmini maliyeti 1.000 kata kadar abartabiliyordu
• Hesaplayıcı kullanıcılara yanlış bir güven veriyordu ve kullanıcılar, belgeleri kontrol etmeden, ekibe sormadan veya bizzat kullanarak doğrulamadan hesaplayıcıdaki değeri gerçek maliyet gibi kabul ediyordu
• Hızlı bir müdahaleyle açıklamalar, feragat notları, ayrıntılar ve varsayılan değerler eklendi; ancak bir kafa karışıklığını azaltma çabası başka bir kafa karışıklığı yarattı
• Şirket içi tartışmalar da büyüdü; özel Slack kanalında 550'den fazla mesaj birikti ve toplantılarla dokümantasyona çok zaman harcandı
• Birisi “Hesaplayıcı gerçekten gerekli mi?” diye sordu, ancak ilk başta çoğunluğun görüşü arasında kayboldu
• Daha sonra, hesaplayıcıyı ve onun yol açtığı sorunları kaldırmanın gerçekten değer kaybı yaratıp yaratmadığını görmek için bir A/B testi yapıldı
  • Hesaplayıcıyı görmeyen ziyaretçilerin kayıt olma olasılığı, görenlere kıyasla %16 daha yüksekti
  • İletişime geçme olasılığı %90 daha yüksekti
  • Fiyatla ilgili destek taleplerinde artış olmadı
• Şirket içi ankette 10 çalışanın 7'si hesaplayıcılı sürümün daha iyi olacağını tahmin etmişti, ancak test sonuçları bunun tersini gösterdi

Kaldırmak neden zordur?

• Birçok organizasyon sorun çözerken çıkarmayı değil, eklemeyi önce düşünür
  • Kaldırma büyük fayda sağlayabilecek olsa bile sezgisel bir seçenek haline gelmesi zordur
  • İlgili bir araştırma olarak People systematically overlook subtractive changes alıntılanıyor
• Ödül sistemleri de genellikle bir şey eklemeye göre şekillenir; kaldırma için teşvik ise nadirdir
  • Kaldırmanın da ödüllendirilmesi gerektiğine örnek olarak Negative 2000 Lines Of Code birlikte sunuluyor
• Bir unsurun eklenmesini güçlü biçimde savunan kişi, onun artık değer katmadığını kabul etmekte zorlanabilir
• Başkasının eklenmesini savunduğu bir unsuru kaldırmaya çalışmak, o kişinin muhakemesine ya da emeğine saldırı gibi görünebilir; bu yüzden olduğu gibi bırakmak daha kolay gelir
• Zaten var olan bir şeyin iyi bir nedenle var olduğu varsayılır ve yeniden gözden geçirilmez
• Mevcut duruma alışıldığında, kaldırmayı yeterince düşünmeden değişimin kendisinden kaçınma eğilimi doğar
• Özsel olmayan unsurları cesurca kesip atmaya dayanan sadeleştirme; müşteri yanıt oranlarının iyileşmesine, daha güvenilir sistemlere, daha hızlı büyümeye ve gelire yol açabilir
• Küçük budamalardan ziyade proje, ürün ve süreçlerin büyük parçalarını kaldırma seçimi gerekir; ekip içinde güçlü direnç doğuran kaldırmaların içinde daha büyük faydalar saklı olabilir

[GN⁺]

Hacker News yorumları

• Bu hesaplayıcının iyi mi kötü mü olduğunu bilmiyorum ama gerekçe ilk bakışta pek mantıklı görünmüyor
  Kullanıcılardan ürünün pahalı olabileceği gerçeğini saklarsanız kayıtların artması gayet doğaldır. Bunun gerçekten daha iyi olup olmadığı, daha sonra hoşnutsuzluk yaratan faturalar alıp almayacaklarına bağlıdır ve bunu kayıt sayfasındaki kısa bir A/B testi ile anlayamazsınız
  Arama sonucu snippet'larından bilgi kaldırılınca tıklama oranının arttığı türden örnekleri de sık görüyorum. Eskiden snippet'ta olan bilgiyi görmek için artık tıklamak gerekiyorsa tıklamanın artması elbette normaldir, ama gerçekte hangisinin daha iyi olduğu unutulup gidiyor

  • O hesaplayıcının sorunu, kullanıcı biraz hatalı veri girerse ya da bazı metriklerin anlamını yanlış anlarsa gerçek fiyatın 1000 katı bir teklif üretmesiydi
    İkilem, “bu durum nasıl düzeltilir?” idi; çözüm de “berbat hesaplayıcıyı kaldıralım” oldu. 1000 kat maliyet gizlenmedi; yanlış 1000 kat teklif yüzünden kullanıcı kaybetmenin önüne geçildi
  • Dark pattern ihtimalinin hiç kabul edilmemiş olması da üzücü. Birçok şirket, fiyat bilgisini kaldırınca potansiyel müşterilerin funnel'ın daha derinine indiğini ve harcadıkları zaman yüzünden rakibe gitmek isteseler bile sonunda satın aldıklarını biliyor
    Araba bayilerinin çevrimiçi fiyat görmeyi zorlaştırıp insanları e-posta atmaya ya da bayiye gelmeye yönlendirmesi buna örnek. Hesaplayıcılar karşılaştırmalı alışverişi kolaylaştırır; birçok şirket de bunu sevmez. Bilinçli olsun olmasın, dikkate alınması gereken bir motivasyon
  • Bu neredeyse tüm sektörün kör noktası ve teknoloji sektörünün ötesinde endüstriyel tasarım ile ürün mühendisliğinin geneline yayılmış durumda
    Kullanıcıya karşı şeffaf olunca daha kafa karıştırıcı görünmeniz kaçınılmaz oluyor. Çünkü karşılaştırma ölçütü, kullanıcıyı mezbahaya sürülen aptal bir hayvan gibi ele alıyor. Bu ölçüte göre kullanıcıyı düşünen bir insan gibi ele alan her özellik kafa karışıklığı yaratıyor ve dönüşüm oranına zarar veriyor
  • Kesinlikle doğru. Ekibimizdeki A/B test meraklıları bir keresinde fiyat sayfasındaki boşlukları ciddi biçimde azaltıp kayıt düğmesini ilk ekranda görünür hale getirdi ve kayıt düğmesine tıklamaların artmasını deneyin başarılı olduğunun kanıtı saydı
    Elbette fiyat sayfası çirkinleşti ama “kayıtlar artıyor” denince bunun önemi kalmadı. Bu durumda hesaplayıcı, terimlere aşina olmayan insanlar için göz korkutucu olabilir; ama ilk içgüdüsel karar “bunu nasıl sadeleştiririz?” olmalıydı. Her şeyi istatistiksel olarak analiz edip kanıtlamak zorundaymış gibi davranan A/B testi kültüründen pek hoşlanmıyorum
  • Bunu aşırı basit ve sık sık yanlış sonuç veren bir hesaplayıcı fonksiyonu olarak görmek mümkün değil mi?
    Kullanıcı en başta kalmıyorsa sonradan memnun mu memnuniyetsiz mi olduğunu nasıl test edebilirsiniz? Döngüyü kapatıp etkileşimi artırırsanız, sonraki etkileşimlerle müşteriyi doğru biçimde eğitme ve memnun etme olasılığınız da artar

• Yazının büyük fikrini yaymak istediğim için upvote verdim ama sınır çok çabuk bulanıklaşabiliyor
  “Bu kısmı kaldırırsak değerli bir şey kaybolur mu?” düşünce biçimi, erken aşamadaki projelerde bazen ters etki yarattı. Özellikle kod ve veride, gelecekteki değeri tahmin etmek zor olduğu için
  Bir keresinde yeni bir projede gönderi etiketleri için ek metadata sütunları içeren erken bir SQL şeması hazırlamıştım, ertesi hafta kıdemli mühendis YAGNI ilkesini öne sürerek hepsini kaldırdı. O sırada roadmap'te yoktu, dolayısıyla teknik olarak haklıydı; ama ilk iş yaklaşık bir saat sürmüştü ve veriyi tutmanın maliyeti neredeyse sıfırdı
  1 yıl sonra o sütunları gerektiren özelliği yapan kişi yine bendim ve bu kez kullanıcıları olan canlı bir DB migration'ı da dahil olmak üzere aynı işi yeniden yapmak zorunda kaldım. Bu yüzden tersini de sormak lazım: “Bu kısmı kaldırırsak değerli bir şey ortaya çıkar mı?” Bu yazıda cevap açıktı, ama benim durumumda değildi

  • O duruma katılıyorum ama ürün daha sonra bunlara ihtiyaç duymuş olsa bile, kıdemli mühendisin o anda kaldırma kararı hâlâ doğru olabilir
    Yanlış hatırlamıyorsam SpaceX'te buna benzer bir fikri yakalayan bir metrik var. Kaldırılan özellikler içinde sonradan yeniden eklenen ikinci özelliğin oranı. Eğer kaldırdığınız her özellik yeniden ekleniyorsa özellik tekrar suçu oranı %100 olur; yani fazla sık kesip biçiyorsunuz demektir. %70 de yüksek, %30 da yüksek
    Ama %0 da kötüdür. Çünkü gereksiz özellikleri yeterince ayıklamaya çalışmıyorsanız sonunda şişkinlik kaçınılmaz olur. Ürünün erken döneminde bu oranın daha yüksek olması, olgunlaştıkça ise sıfır olmayan ama düşük bir seviyeye inmesi mantıklı görünüyor
    Bugün itibarıyla en iyi ürünün tam olarak hangi özelliklerden oluştuğunu bilemezsiniz; bu yüzden gereksizi budamak için olasılıksal bir yaklaşım benimsemek sorun değildir. Gerekirse yeniden eklersiniz ve bu çok sık yaşanmadığı sürece ilk kaldırma kararından şüphe etmek için neden yoktur
    Ya da gerçek hayatta ikisini de deneyip sonuca bakmak yerine, hipotezler ve dillendirilmeyen ön kabullerin vekil göstergeleri üzerinden 6 ay boyunca sadece toplantı da yapabilirsiniz
  • Gelecekte lazım olabilir diye bir şey eklemenin temel sorunu şu: insanlar ayrılır, unutur ve 1 yıl sonra metadata sütunu hâlâ duruyordur ama artık ne için konulduğunu kimse bilmez
    Sonra soru “Bunu kullanabilir miyiz? Silebilir miyiz?” olur ve birileri eski bir alanı yeniden kullanıp büyük bir felakete yol açan Knight Capital olayını hatırlar. Böylece mevcut alanları bırakmak her zaman daha güvenli görünür ve sonunda metadata ile metadata_1 ortaya çıkar. Ertesi yıl da neden iki metadata alanı olduğunu kimse bilmediği için durum daha da kafa karıştırıcı olur
  • Çoğu durumda gereksinimleri önceden tahmin etmeye çalışmak, gerekmeyen şeyler inşa etmenize yol açar. Gerçekten ihtiyaç doğsa bile çoğu zaman ihtiyaç duyulan şey çok farklı bir biçimdedir
    Benim karşılaştığım en kötü kod tabanları, karmaşık gelecekteki kullanım senaryoları düşünülerek tasarlanmış olanlardı. Bu örnekte de kod tabanının sütunlara ancak 1 yıl sonra ihtiyacı oldu. Bu yüzden gelecekte ihtiyaç olabilir diye eklenen tüm kod parçalarını kaldırmayı bir emsal olarak doğru buluyorum. Sonradan yeniden gerekli olsalar bile
  • Savunmacı ya da varsayımsal iş yapma konusunda ya fazla ileri gitmeye ya da yetersiz kalmaya sürüklenmek kolay
    Birine göre bu erken optimizasyon olur, bir başkasına göreyse “daha önce benzer bir örüntü gördüm ve o zaman elimizde olmasını istediğim şeyi şimdi ekleyeceğim” yaklaşımıdır. Hangisinin doğru olduğunu istikrarlı biçimde ayırmanın bir yolu varmış gibi görünmüyor
  • O alan yeniden eklenmemiş olsaydı bu yorumu yazar mıydın?
    Anlattığın durumda kabaca üç sonuç var. Birincisi, alan tam da ilk uyguladığın haliyle faydalı hale gelir. İkincisi, özellik uygulanır ama başka alanlarla ya da farklı bir uygulamayla yapılır. Üçüncüsü, özellik hiç uygulanmaz
    Bu üç seçeneğin olasılığını eşit kabul etsek bile, en baştan yapmış olmanın kazanç sayılacağı durum yalnızca üçte birdir. Eğer kaldırılmamış olsaydı, bu arada yaptığınız diğer özelliklerin metadata sütunlarıyla düzgün çalıştığını doğrulamak için ne kadar bilişsel maliyet doğacağını da hesaba katmak gerekir
    Bu sefer senin öngörün doğru çıkmış ve projeyi çok iyi anladığın görülüyor, ama kararın doğru olup olmadığına tüm sonradan oluşan bilgileri bilerek değil, o anda mevcut bilgilerle bakmak gerekir

• “Şirket içi oylamada 10 kişiden 7’si hesap makinesi olan sürümün daha iyi olacağını düşündü” kısmı ilginç ve tipik bir dinamik.
  Genel olarak iyi bir yazıydı ama bu nokta daha fazla vurgulanabilirdi. İlgililerin %30’u hesap makinesini kötü buluyorsa, çoğunluk sorun görmese bile bu potansiyel olarak büyük bir probleme işarettir.
  Burada kurumsal siyasete dikkat etmek gerekir. İnsanlar siyasi bir kazançları yoksa genelde başka bir ekibi eleştirmek istemez. Bu yüzden şirkete “Ekibimizin yaptığı bu şeyin net etkisi olumlu mu?” diye sorarsanız, varsayılan cevap sırf gereksiz huzursuzluk çıkmasın diye “evet” olmaya meyillidir.
  Böyle bir durumda %30’un bunun değer yıkıcı olabileceğini söylemesi, göründüğünden çok daha önemlidir. Neden böyle düşündükleri oldukça derinlemesine incelenmelidir. Bu olayda gerçekten buna dikkat edilmiş ve iyi bir sonuca varılmış ama bu oylama sonucu en baştan ciddi bir sorunun kanıtıydı.

  • İlke olarak katılıyorum ama bir değişikliğin ne kadar tartışmalı olduğunu nasıl nicel olarak ölçebileceğimiz zor. Hiçbir özellik %100 uzlaşı sağlamaz. %30 kulağa iyi gelmiyor ama %20’den anlamlı biçimde farklı mı?
    Çıkarlar işin içine girince daha da karmaşıklaşıyor. Satış ekibi her türlü karanlık kalıbı açmak ister, müşteri desteği ise sepete uzatılmış garantinin otomatik eklenip sonra iade işlemiyle uğraşmaktan bıkmış olabilir.
    Yazıda, hesap makinesi kaldırılınca daha fazla satış tamamlandığı için bunun kullanıcı için de daha iyi olabileceği söylenmesi komikti. Belki de kullanıcının uygun bir fiyat şoku yaşayıp ayrılması aslında doğru seçimdi, ama bu ihtimal görmezden gelinmiş.
  • İç oylamanın bir başka sorunu da, özelliği kullanan kişinin bakış açısı yerine özelliği yapan kişinin bakış açısını içermesi.
    Hesap makinesi kodunun projenin geri kalanına göre berbat olduğunu, eski kütüphaneler kullandığını, güncellenince bozulduğunu, güvenlik açıkları olabileceğini, anormal derecede çok kaynak tükettiğini ve build sistemini bozduğunu hayal edin. Kimse onunla uğraşmak istemez.
    Bu durumda bunun iyi bir fikir olup olmadığı sorulursa çoğu kişi “hayır” der ve o karmaşanın ortadan kalkmasını ister. O zaman %70 çok iyi bir sayıdır. Tersine, insanların üzerinde çalışmayı sevdiği bir özellikse %70 gerçekten kötü bir sayı olur.
  • Yazı sadece o %30’un hesap makineli sürümün “daha iyi performans göstereceğinden” emin olmadığını söylüyor; bunun “kötü bir fikir” olduğunu düşündüklerini söylemiyor.
    Elbette öyle düşünmüş olabilirler ama bu oldukça büyük bir sıçrama. Pek fark yaratmayacağını düşünüyor olabilirlerdi ya da hesap makinesinin yanlış sonuç verdiği durumlar yüzünden performansın düşük olacağını tahmin etmiş olabilirlerdi.

• Genel mesaj ilginç ama bu bölüm biraz duraksatıyor.
  “Bir metriği biraz yanlış anlamak ya da yanlış girmek bile tahmini 1000 kata kadar şişirebilir” sözü, gerçek kullanımda da bir metriği biraz yanlış anlayıp yanlış değerlendirirseniz planladığınızdan 1000 kat daha fazla ücret ödeyebileceğiniz anlamına mı geliyor?
  Online ücretlendirme sistemlerinde bu gayet gerçekçi. Bir GCP prototipini yanlış yapılandırıp 2-3 dolar tutar sanmıştım; birkaç gün ilgilenmeyince 100 doların üstünde fatura çıkmıştı.
  Sadece slider’ı biraz oynatınca tahmini fiyatın çılgınca arttığını görünce müşterilerin vazgeçmesini anlamak kolay. Aracı kaldırmak kayıt olmaya yardımcı olabilir ama sonradan bu sorunla karşılaşan müşterilere yardımcı olmaz.

  • Aslında bunun olması pek olası değil. Gerçekte yaşanan iki örnekten nedeni anlaşılıyor.
    Bir kullanıcı saniye başına sorgu sayısını arama sayısı × her aramanın top-k değeri olarak hesapladığını sanmıştı. top-k, geri almak istediğiniz sonuç sayısıdır. top-k’nin 10 olduğunu varsayarsanız, saniye başına sorgu sayısına gerçekte olması gerekenden 10 kat yüksek bir değer girer ve gerçek faturasından yaklaşık 10 kat yüksek bir tahmin görürsünüz.
    Başka bir kullanıcı ise vektör sayısını embedding sayısı × embedding boyut sayısı olarak hesapladığını sanmıştı. 1.536 yaygın bir boyut sayısı olduğu için girilen değer kelimenin tam anlamıyla 1.536 kat daha yüksekti. Gerçek kullanım Pinecone tarafından doğru hesaplandığı için bu kadar yüksek ücretlendirilmez.
    Vektör boyutu, yapay zeka mühendisleri için temel bir kavramdır ve QPS de veritabanı yöneticileri için temel bir metriktir; ancak Pinecone’un kullanıcıları arasında yapay zekaya yeni olanlar, veritabanı yönetimine yeni olanlar ya da her ikisine de yeni olanlar çoktur.

• Yazar kendi tavsiyesine kendisi uymalı. Yazının ortasına giren “Psst... Get the next post in your inbox” ifadesini kaldırmalı, kaydırırken peşinizden gelen o aptal düğmeyi de kaldırmalı.
  Sadece o sayfada abone olmanın beş farklı yolunu saydım. Gerçekten beş tane gerekli mi? İçeriğin ortasında bunu insanların gözüne sokmak zorunda mı? İnsanları bölüp sinirlendirmenin daha fazla abone getirdiğini mi düşünüyor? Böyle aboneler mi istiyor?
  Bir şeyi kaldırmak çoğu zaman nettir. “Daha daha daha, para kazan, müşteri çek” çukuru gibi düşünceden çıkıp, “Kullanıcıya saygı göstermek için doğru olan nedir ve onları cüzdanı sıkılacak bir hedef değil de bir insan olarak görerek nasıl yardımcı olabiliriz?” diye düşünmek yeterli.

  • Katılıyorum ama veriler bunu söylemiyor. Bu sinir bozucu unsurlar iş hedeflerine çok iyi hizmet ediyor.
    Çoğu işletmenin HN okurlarına konfor sağlamak için değil, para kazanmak için var olduğunu unutmamak gerekir.
  • Blog SEO’sunun dersini gerçekten anladıysanız, okur kitlesini büyütmeye çalışırken, okurun dikkatini çalan çok sayıda harekete geçirici mesaj eklemek, seçici okurlara verdiği rahatsızlığa değecek kadar açık biçimde değerlidir.
    Kullanıcıya saygı göstermenin ne olduğu ayrı bir soru, ama tamamen alakasız da değil.

• Özel bir Slack kanalı açılması, şirketin dört bir yanından görüş içeren 550’den fazla mesaj birikmesi ve hesap makinesini düzeltmek için ne eklenmesi gerektiğine dair toplantılara onlarca saat ve binlerce kelime harcanması, aşırı istihdamın bir belirtisi.
  İnsan sayısı fazla olunca inisiyatif kaybolur. Gerçekten neyin önemli olduğunu unutup komite usulü uzlaşı sağlamak zorunda hissediyorsanız, çok fazla insan var demektir.

  • Olabilir ama bu, sadece iki kişi varken bile ortaya çıkabilen bisiklet kulübesi tartışmasının da belirtisi olabilir.
  • Sadece o tek cümleden, şirkette fazla çalışan olduğu sonucuna nasıl vardığını anlayamadım.
  • En azından tasarım tartışmasını şirket geneli bir kanalda yaparsanız bunlar olur.
    Komite usulü tasarım en azından komitenin içinde kalmış olur.

• Müşterinin yararlı şekilde modelleyemeyeceği kadar karmaşık olan fiyatlandırma yapısının kendisini kaldırmak daha iyi olmaz mı?

  • Yazıya göre en büyük etken, seçeneklerin çok olması değil, kullanıcının seçenekleri yanlış anlaması.
    Yani A seçeneği x dolar, B seçeneği 10x dolar ise ve kullanıcıların çoğu yanlışlıkla B’ye ihtiyaç duyduğunu düşünüyorsa, hesap makinesi yanlış anlamaya yol açan bir araç haline gelir.
    Ben “fiyat için iletişime geçin” yaklaşımını epey seviyorum. Kabaca fiyat aralığını hızlıca öğrenmek isteyen kullanıcı için sinir bozucu ama standart fiyatı olmayan ya da internette kolayca açıklanamayacak, pazarlığa açık fiyatlandırmaları ayırt etmeye yardımcı oluyor. Kullanıcının normalde geçip gideceği durumları da yakalayabiliyor. Elbette çoğu e-ticaret türü durumda uygun değil.

• Şirketimizde yaklaşık 250 ürün var ve bunların 5’i gelirin %80’ini sağlıyor.
  Bu 5 ürünün geliştirme ekipleri hata düzeltmelerine bile ancak yetişebiliyor; önemli ve yeni özellikler eklemekte zorlanıyor. Kim isterse istesin yol haritasına bir şey koymak başlı başına imkansız bir mücadele.
  Şirkette binlerce geliştirici var ama çoğu, gelire neredeyse hiç katkı sağlamayan ürünlerde çalışıyor.
  İleri gidebilmek için ürünlerin çoğunu kesip ekipleri kalan ana gelir getiren ürünleri öne itecek şekilde yeniden düzenlemek gerektiği açık görünüyor. Ama böyle bir şey olmadı, olacağına dair bir belirti ya da söylenti de yok. Şirket içi siyaset gerçekten sert.

• Benzer bir deneyim yaşadım. Birbirine oldukça benzeyen birçok ürünün olduğu bir web sitesinde, insanların ne alacaklarına karar vermekte zorlanıp bu yüzden satın almaktan vazgeçebileceğinden endişe ediyordum.
  Bu yüzden, kullanıcı birkaç soruyu yanıtladığında en uygun bir veya iki ürünü öneren bir ürün öneri applet’i yaptım. Düzgün hale getirmek biraz uğraştırdı ama tamamlandıktan sonra iyi çalışıyordu.
  Siteye koyduk ve dönüşüm oranı sert şekilde düştü. A/B testi yapınca dönüşüme gerçekten zarar verdiği netleşti. Neden zarar verdiğini hâlâ bilmiyoruz ama olan buydu. Bu yüzden ana sayfadan alıp FAQ bölümüne taşıdık ve neredeyse kimse kullanmaz oldu.

  • Test etmenin değeri de burada. Sonuçlar bazen sezgisel olmuyor.
  • Belki de öneri applet’i insanlara gerçekten yardım etti ve yeni sunduğu ek bilgilere dayanarak satın almamanın en iyi karar olduğuna varmalarıyla sonuçlandı.
    İnsanlar kararsızdı ve kendi kendilerine deneme yanılmayla bunu çözme zahmetinden kurtulmuş olabilirler.
    Bir hizmet söz konusuysa, emin olmadan önce yine de kaydolup sonra batık maliyet yanılgısından yararlanan Amazon Prime tarzı bir strateji işe yarıyor olabilir. Ya da applet olmasa en ucuz sürümün yeterli olacağını düşünüp kaydolacaklardı, ama applet bu umudu hemen söndürmüş olabilir.
    Fiziksel bir üründe ise kötü bir satın alımdan kaçınmalarına yardım etmiş olabilir.
    İnsanların bunu FAQ içinde aramasını beklemem. Footer’da olsa belki, ama FAQ’da değil.

• İlginç bir vaka çalışması ama daha geniş çıkarımlar konusunda şüpheliyim. Pinecone, diğer vektör veritabanı hizmetleriyle karşılaştırıldığında pahalı olmasıyla biliniyor. Yatay bir fiyat karşılaştırması yapıldığında piyasada daha iyi birkaç seçenek var.
  Hesaplayıcıyı kaldırmak temel sorunu çözmüyor. Sadece maliyeti bulanıklaştırıyor ve kullanıcıların en başta seçenekleri karşılaştırmasını zorlaştırıyor. Benim açımdan bu, karşılaştırma adımını azaltarak fiyat etkisini yeterince anlamayan daha fazla kullanıcının veri yüklemesine yol açabilir.
  Basitleştirme bazen değerli olabilir ama bu durumda kullanıcıdan çok şirkete yarıyor gibi görünüyor. Hesaplayıcıyı tamamen kaldırmak yerine doğruluğunu ve kullanılabilirliğini artırmak daha iyi olabilirdi. Özellikle maliyetlerin hızla artabildiği B2B hizmetlerde fiyat şeffaflığı önemlidir.