Tüm mühendislere satış görüşmesi zorunlu tutulunca platform 2 haftada tamamen yeniden yazıldı

• Bir startup, mühendislerin doğrudan satış görüşmelerine katılmasını sağlayarak ürün geliştirme biçimini kökten değiştirdi
• Satış görüşmeleri sırasında, rakip ürünlerin teknik olmayan kullanıcılar için fazla karmaşık olduğunu ve müşterilerin log/metriklerden çok, izleme sisteminin çalıştığını gösteren bir onay işareti (yeşil tik) istediğini; hatta sadece “bunu biri bizim yerimize yapamaz mı?” diye sorduklarını fark ettiler
• Bu sayede backend odaklı ekip kullanıcı bakış açısını anlamaya başladı ve PM müdahalesi olmadan yeni bir mimariyi kendi başına kurgulamaya başladı
• Sadece 2 hafta içinde platformdaki özelliklerin %60'ı kaldırıldı, ilerlemeyi gösteren bir progress bar eklendi, Slack entegrasyonu ve done-for-you workflow özellikleri geliştirildi; sonuç olarak destek talepleri %70 azaldı
• Bu deneyimden çıkan ders, kullanıcıların sadece sorunlarının çözülmesini istediği, zarif kodla ilgilenmediği ve özelliklerin kod miktarı değil kullanıcı kafa karışıklığı şeklinde bir maliyet ürettiğiydi

---

Arka plan ve deney

• Kıdemli DevOps mühendisi satış görüşmelerine katılmaya karşı çıktı, ancak en az 5 görüşme deneme şartıyla kabul etti
• Kurucu, mühendislerin ürün tasarımını değiştirebilmesi için müşterilerin dilini ve sorunlarını doğrudan duyması gerektiğine karar verdi

Satış görüşmelerinden çıkan içgörüler

• Rakip ürünlerin teknik olmayan kullanıcılar için fazla karmaşık olduğu söylendi
• Müşteriler karmaşık metriklerden çok, basit bir yeşil tik gibi sezgisel bir doğrulama istiyordu
• Birçok müşteri “vekaleten hizmet” talep ediyor, ürünü sadece kullanmak yerine sorunun çözümünü dışarı devretmek istiyordu

Ürünün yeniden yazılmasının sonuçları

• Ekip mevcut özelliklerin %60'ını kaldırdı ve temel işlevlere odaklandı
• Basit bir progress bar ekleyerek kullanıcı deneyimini iyileştirdi
• Slack entegrasyonu ile talep akışını sadeleştirdi
• Done-for-you workflow sunarak müşterilerin taleplerini doğrudan yansıttı
• Sonuç olarak destek talepleri %70 azaldı, ürünün kullanılabilirliği ve memnuniyet ciddi biçimde arttı

Temel dersler

• Kullanıcılar zarif teknik çözümler değil, doğrudan sorunlarının çözülmesini istiyor
• Teknik doğruluktan çok kullanıcıyı anlamak daha önemli
• Her özellik, kod değil kullanıcı kafa karışıklığı şeklinde bir maliyet taşır

Ekip kültüründeki değişim

• Ardından şirket, tüm mühendislerin her çeyrekte 5 satış görüşmesine katılmasını zorunlu hale getirdi
• Mühendislerin müşteri yorgunluğunu doğrudan duyması ve “sadece düzgün çalışsın yeter” talebiyle karşılaşarak ürün sezgisini geliştirmesi şirket kültürünün parçası oldu

---

Reddit yorumlarından öne çıkan özet

• PM rolü tartışması
  • Bazıları, sorunun iyi bir Product Manager eksikliği olduğunu ve mühendislerin müşteri görüşmesi yapmasının verimsiz olduğunu savundu
  • Buna karşılık, “PM sadece bir çevirmen rolünde kalıyor; en iyi sonuçlar, mühendisler müşteri sorunlarını doğrudan sahiplendiğinde ortaya çıkıyor” diyenler de vardı
• Müşteri temasının değeri
  • Birçok yorumda, mühendislerin doğrudan kullanıcı sesini duyma deneyiminin güçlü içgörüler sağladığı vurgulandı
  • Erken aşama startup'larda veya küçük ekiplerde, mühendislerin kısmen PM rolünü de üstlenmesinin yaygın olduğu görüşü paylaşıldı
• Eleştirel bakış
  • “Bu sadece liderlik/kültür başarısızlığının mühendislere yıkılması” şeklinde eleştiriler yapıldı
  • “Özellikleri kesip sadeleştirmek gerçekten iyileştirme mi?” itirazı da vardı; uzun vadede güç kullanıcılarını ve gelişmiş özellik taleplerini görmezden gelme riski olduğu uyarısı yapıldı
• Olumlu örnek paylaşımları
  • Bankacılık, tıbbi cihaz gibi çeşitli sektörlerden, benzer biçimde tüm çalışanların müşteri desteği/satış deneyimi yaşadığı sistemlere dair çok sayıda örnek paylaşıldı
  • Dogfooding ve “müşterinin karşısına doğrudan çıkma” deneyiminin ürün kalitesine ve kültüre katkı sağladığı konusunda fikir birliği vardı
• Genel çıkarım
  • Müşteri sorunlarını doğrudan hissettirmek güçlü bir öğrenme aracı, ancak
  • uzun vadede dengeli bir ürün stratejisi için bunun profesyonel PM·UX·tasarım yetkinlikleriyle birleştirilmesi gerektiği tartışmanın ana noktası olarak öne çıktı

[meteorizer]

Sonuçta bu bir verimlilik meselesi sanırım.
Müşteriyle doğrudan görüşmenin gerçekten birçok iyi yanı var ama
toplantılar, telefon görüşmeleri ve benzeri sık iletişim yüzünden işin sürekliliği sık sık bozuluyor ve geliştirmeye ayrılabilecek zaman azalıyor.
Bu durumda şirketin, düşen üretkenliğe karşılık verecek bir işe alım planı yapması gerekir.
Sorun şu ki çoğu zaman böyle bir niyetleri olmuyor.
Sonuçta zaman yetersizliği nedeniyle, zaman geçtikçe kalite düşüşü yaşanma olasılığı artacaktır.
Artılarını ve eksilerini iyi değerlendirmek gerektiğini düşünüyorum.

[laeyoung]

Neden Hacker News'te eski reddit bağlantısı olarak bırakıldığından emin değilim ama şu anki reddit UI bağlantısı burada.

[xguru]

Hacker News'ta Reddit URL'si paylaşılırken çoğunlukla old reddit kullanılıyor gibi görünüyor. Muhtemelen daha hafif olduğu içindir.

[cnaa97]

Tabanı yükseltmeyi hedefleyen bir organizasyonsa, yalnızca web front-end geliştiricilerinden oluşan bir ekip ya da uygulama geliştirici ekibi gibi rol bazlı organizasyonların uygun olduğunu kabul ediyorum.

Ancak zirveyi hedefleyen ekip veya organizasyonlarda, rol bazlı yapılanmanın kaçınılmaz olarak sınırları vardır.
Metindeki içerikte olduğu gibi, gerçekten de planlamacı, tasarımcı, PM ve mühendisin işleri ayrı ayrı üstlenip bir fabrikanın konveyör bandı gibi çalışması mı gerekiyor? sorusu ortaya çıkıyor. Sadece birkaç sorumluluğu alıp çalışan tipik bir "sorumlu kişi" tarzı iş yerine, her alanda uzmanlığı olan üyelerin bir araya gelip ortak hedefleri birlikte belirlediği ve tüm üyelerin destek verdiği bir yapı idealdir.

Birçok şirkette organizasyonlar, spin-off, ekip oluşturma gibi task force biçimleriyle kuruluyor; ancak burada da sadece insanları (rolleri) bir araya getirdikleri için olumsuz pekiştirme (ben bir şey yapmaya çalışıyorum ama şirket bana yardımcı olmuyor, o zaman vazgeçeyim gibi bir kalıp) ortaya çıkabiliyor ve sonuçta sadece kilit üyeler gibi önemli yetenekler kaybedilebiliyor. Bu yüzden amaç odaklı organizasyonların da rol bazlı organizasyonlardan aktif destek alması mutlaka gerekir.

[GN⁺]

Hacker News yorumu

• Sonunda, benim “PM’lik” yapmama gerek kalmadan tamamen yeni bir mimari tasarladılar. Çünkü ürünümüzü gerçekte kimin kullandığını nihayet gerçekten anlamışlardı. Bu deneyime genel olarak bakınca çıkan sonuç şu: “Mühendislere satış görüşmeleri yaptırdık ve sonunda asıl sorunun, PM’lerin müşteriyle mühendislik arasında doğru düzgün iletişim kuramaması olduğu; buna karşılık DevOps mühendisinin müşteri ihtiyaçlarını gerçekten çalışan çözümlere hızla dönüştüren kişi olduğu ortaya çıktı.”
  • Bazen mühendisler o kadar özgüvenli oluyor ki kullanıcıların ürünü yanlış kullandığını düşünüyorlar. Mantık şu: “Kullanıcı aptalca davrandığı için böyle oldu, benim yaptığım karmaşık tasarımda sorun yok.” Sadece Desktop Linux dünyasındaki insanların bile kullanıcı şikayetlerini görmezden gelme deneyimleri üzerine bir kitap yazabilecek kadar malzemesi vardır. İnatçı bir mühendis kendini PM’den ve kullanıcıdan üstün görüyorsa hiçbir şey ilerlemez. Ama böyle bir mühendisi doğrudan kullanıcıyla muhatap ederseniz, her zamanki nazik PM yerine gerçekten sinirli kullanıcılar çıkıp bu “harika yaratımı” sanki sorunlu bir hamster’mış gibi yerden yere vurur. Bu süreç korkutucudur ama aynı zamanda mühendis egosunu da kırar. Benim açımdan bu, PM’in aptal olduğunu göstermeye çalışmak değil, mühendisi alçakgönüllü yapmaktır. Zamanla mühendis kibri geri geldiği için bu sürecin periyodik olarak tekrarlanması gerekir
  • Ben büyük bir şirketteki makine mühendisliği ekibinde kod yazabilen tek kişiyim. Şirket içi IT ekibi çeşitli yazılımları kendisi geliştiriyor ama bizim ekibin çoğuna göre bunların büyük kısmı kötü. Bu yüzden işleri kolaylaştırmak için ya bunları baştan yapıyorum ya da yerine koyulması imkansız kadar “kötü” programları tamamlayan araçlar tasarlıyorum. Şirket içi IT ekibinden daha iyi geliştirici olmamdan çok, gerçek kullanıcı bakış açısı sayesinde kendim, yani bizim ekip için gerçekten ne gerektiğini daha iyi kavradığımı düşünüyorum. Üstelik bu yazılımı kullanan kişi de benim, dolayısıyla motivasyonum doğal olarak daha yüksek. Bu yüzden başlık bana çok tanıdık geldi. Yine de metinde anlatılan şeylerin sahada fazlasıyla yaşanabilir olduğunu düşünüyorum. Resmi yazılım geliştirme/proje yönetimi süreçlerine ise çok hakim değilim
  • Yıllık 2 milyon dolar gelirli küçük bir teknoloji girişimi yönetiyorum. Bazen destek ekibinde yeterli insan olmadığında birkaç günlüğüne müşteri desteğini bizzat üstleniyorum. Bunu her yaptığımda, normalde mühendislik ekibine hiç ulaşmayan bir sürü müşteri şikayeti buluyorum. Destek çalışanları sorunları kendi başlarına “çözmeye” odaklandıkları için, esas iyileştirmeler mühendisliğe kadar gitmeme eğiliminde oluyor
  • Dikkatimi çeken şey, yazılımın neden en başta bu kadar kötü olduğunu kimsenin sorgulamaması. Bana göre bunun tüm sorumluluğunu tek bir PM’e yükleyemezsiniz. Aslında sorun; Agile/Scrum gibi, sorumluluğun bulanıklaştığı ve geliştiricilerin kötü hazırlanmış biletleri çok hızlı döngülerle işlemek zorunda kaldığı, sonuçta da böyle özensiz yazılımlar üreten sistemsel bir yapı. “Modern” yazılım organizasyonları şiştiğinde sık görülen sonuç bu
  • Bu yazıyı görünce aklıma ilk gelen şey, “PM’ler her şeye dahil olmadan önce yazılım zaten böyle yapılıyordu” oldu. Mühendisleri gerçek operatörlerin yanına oturtunca, aslında PM’e ihtiyaç kalmadığını ve herkesin çok daha mutlu olduğunu sık sık görüyorum. Elbette harika PM’ler de var, ama benim deneyimime göre PM’ler alan kavgasına takılma eğiliminde oluyor ve şaşırtıcı biçimde ne mühendislik ne de müşteri tarafı hakkında pek bilgi sahibi olmayabiliyorlar
• Birçok yerde mühendislerin ürünle uyumsuz düştüğünü defalarca gördüm. Bir ekip arkadaşı haber vermeden bir şey ekliyor ve arayüz karışıyor ya da web sitesindeki içerik ürünün gerçekte yaptığı şeyle uyuşmuyor. Ayrıca [ürün -> PM -> bug tracking sistemi -> mühendis -> düzeltme -> QA -> ürün] gibi uzun döngüler yüzünden önemli şeyler düzeltiliyor ama küçük sürtünmeler gerçekten çok uzun süre kalıyor. Geriye sadece [ürün <-> mühendis] kalsa, üretkenlikte şaşırtıcı bir artış olabilir. Birçok mühendis, ürünün genel deneyimini gerçekten hiç yaşamamış oluyor; hatta bu yıl ile geçen yıl arasındaki farkı bile bilmiyorlar
  • Ben de benzer bir deneyim yaşadım ve ilginç biçimde bu durum PM’in çok olduğu yerlerde daha sık ortaya çıkıyordu. Yaşadığım en kötü örnek, bir şirketin PM ve “Product Designer” sayısını mühendis sayısına oranlı olacak şekilde zorla belirlemeye çalışmasıydı. Tasarım, ürün, proje ve program tarafındaki herkesi topladığınızda mühendislerden daha fazla insan vardı. Sonuç sadece daha kötü bir durum oldu. PM’lerin bürokrasisinden ve iş alanıma müdahale etme kaygılarından kaçınmak başlı başına bir işti. Harika PM’ler gerçekten çok değerli, ama bugünlerde Product Management unvanı, bürokratik ve sürece takıntılı fazla sayıda insanı çekiyor gibi geliyor. Product Management influencer’ları da sorunu daha da büyütüyor
  • Yine de mühendisleri zorla satış görüşmelerine sokmanın doğru çözüm olduğunu düşünmüyorum. Bir telefon görüşmesini başarılı biçimde yürütmek için çeşitli soft skill’ler gerekir; mühendisler bu alanlarda eğitilmiş değildir ve işe alımda da bu genelde değerlendirilmez. (“Satış görüşmesi” derken demo ya da PoC öncesindeki ilk keşif görüşmesini kastediyorum. Karmaşık pre-sales demolarında mühendis eşlik etse bile, bunun sahibi prensipte ürün tarafı olmalı diye düşünüyorum)
  • İşlerin ters gidebileceği o kadar çok yol var ki bunların hepsini bizzat gördüm. Örneğin tüm müşteri iletişimini PM ya da PO’nun tekeline bırakmak; müşterinin geliştiriciyle konuşmaktan kaçınıp sadece kullanıcı yöneticisinin taleplerini yorumlayarak iletmesi; geliştiricinin sadece kod yazmak istemesi; her iletişimin yalnızca PM ve bug tracker üzerinden yapılmasının dayatılması... Hepsi mümkün. Ayrıca ticari yazılım platformları kullanıldığında teknik kısıtlar yüzünden iş akışı çok kötü hale gelebiliyor. Her zaman iletişimi tıkayan bir unsur oluyor ve bunu müşteri, orta kademe yönetici ya da geliştirici fark etmeksizin herhangi biri yaratabiliyor. Hatta azımsanmayacak sıklıkta, yanlış çözüm daha en başta belirlenmiş oluyor ve geliştiriciyle kullanıcı ayrıntıları hiç bilmeden işe başlıyor. Kullanıcı için gerçekten iyi bir sistem üretememenin yolu çok fazla
  • Mühendislerin ürünün kendisini derinlemesine anlamasının gerçekten önemli olduğunu düşünüyorum. Temel mühendislikten daha zor olan nokta, ürün tarafının yerine oturması. Benim deneyimlediğim ürünlerin çoğu nihayetinde ürün sebepleriyle başarısız oldu; bu yüzden ekibin gücünü bu yöne odaklamak daha mantıklı görünüyor
• Öte yandan, mühendislerin sonunda teknik destek ekibine dönüşmesi de mümkün. Her müşteri şirketini tek tek desteklemeye başladığınızda, ortalık hotfix ve müşteriye özel çözümlerle dolar; bunların hiçbiri doğru düzgün test edilemez, teknik borç birikir ve iyi finanse edilmiş büyük bir rakip daha şık bir ürün yaptığında hızla geride kalırsınız. Bunun tipik bir ürün yönetimi başarısızlığı olduğunu düşünüyorum. Yani ya PM müşterinin ihtiyacını mühendise düzgün aktaramıyordur ya da ters yönde gerekli itişi yapamıyordur. Mühendisleri satış görüşmelerine dahil etmek, müşteri tabanı belli bir ölçeğe ve olgunluğa ulaştığında ölçeklenebilir bir yöntem değildir. Eğer bir ürün yöneticisi gerçekten mühendisin satış görüşmesi yapmasını istiyorsa, o mühendisin de ilgili hesapların komisyonundan pay alması gerekir. Ben komisyon almadan satış görüşmesi yapmam
• Startup gibi tüm ekip üyelerinin müşteri ihtiyaçlarıyla derin empati kurması gereken ortamlarda bu çok güçlü bir strateji. Ürün gereksinimlerini gerçekten tanımlamaya katıldığım ve işi uçtan uca kavradığım projelerde başarı oranım çok daha yüksek oldu. Yalnızca gereksinimleri “alıp” aynen uyguladığım durumlara kıyasla çok daha iyi sonuçlar çıktı
  • Bunun anlamı, yönergeleri bizzat yazdığın için takip etmenin daha kolay olması mı; yoksa doğrudan dahil olduğun için daha iyi bir UX çıkması mı, onu merak ettim
• “2 haftada rewrite tamamlandı, özelliklerin %60’ı kaldırıldı, basit bir progress bar eklendi, Slack entegrasyonu kuruldu, ‘done-for-you’ workflow sunuldu -> destek biletleri %70 azaldı.” Eğer bu gerçekten olduysa, ortada ciddi biçimde yanlış giden bir şey var
  • Reddit, kurgu hikayelerin patlamasıyla meşhur ve bu hikaye de ister gerçek olaylardan esinlenmiş olsun ister tamamen uydurma olsun, tipik Reddit yazım unsurlarını LinkedIn tarzı iş hikayeciliğiyle karıştırıyor
  • Bence bu, birkaç kez pivot etmiş ama ürünle ilgili yönlendirmesi zayıf kalmış bir B2B SaaS vakası. Elbette işlerin bu şekilde sarpa sarması, düşünüldüğünden çok daha yaygın
  • LinkedIn tarzı kısa cümlelerin ardından tekrar tekrar dramatik sonuç gelmesi, bunun kurgu olduğunu kolayca ele veriyor
  • Reddit sonuçta; tabii ki kurgu. Böyle bir şeyin neden bu kadar ilgi gördüğünü anlamıyorum
• Eğer sonuç buysa PM, PO ve pazarlama ekibinin tamamı hemen işten çıkarılmalı. İki şey net: Birincisi, bu insanlar ya müşterinin gerçekten ne istediğini anlayamadı ya da bu ihtiyacı geliştirme ekibine doğru aktaramadı, ya da ikisi birden. İkincisi, kafaları o kadar sistem odaklı çalışıyor ki, belki de müşteriyle geliştirme ekibi arasındaki tüm ara katmanları kaldırmak daha iyi olabilir
• Önceki işimde de mühendisler düzenli olarak satış görüşmelerine katılırdı. Müşterilerin ne istediğini ve ürünümüzün nasıl satıldığını görmek ilginçti ama devrim niteliğinde değildi. Müşterinin istediği özellik zaten yol haritasındaydı; kafa karıştırıcı bir özellik de vardı ama o da en büyük müşterimizin özel ihtiyacı yüzünden öyle tasarlanmıştı. Geliştirme ekibi bunu daha basit yapmak istiyordu, ancak öyle olursa büyük müşterinin talebini karşılayamıyorduk. Sonunda kullanımı daha kolay ayrı bir “light” sürüm yapıldı ve büyük müşteri dışındaki herkes onu kullanabildi. Ama bu değişim de satış görüşmelerine katılındığı için olmadı; herkes bunun zor olduğunu zaten baştan biliyordu, sadece yol haritasına girene kadar değiştirilemiyordu
• “Gerçek kullanıcının kim olduğunu sonunda doğru anlamak” kısmına çok katılıyorum. “Çoğu mühendisin en büyük sorunu over-engineering” denir ama gerçekte over-engineering çoğu zaman müşteri kullanım senaryolarını yeterince anlamamaktan kaynaklanıyor. Daha temel mesele bu. Benim de mühendis olarak en sık yaşadığım hayal kırıklığı, diğer mühendislerin gerçekten satılan ürünün ne olduğunu öğrenmeye çabalamaması. Sebep bazen işe uygunluk, bazen ego ama çoğu durumda mesele organizasyon kültürü ya da teşvik yapısı
• Bir zamanlar CRM için robocall çözümü geliştiren bir şirketteydim; bir offsite etkinlikte herkesin bizzat cold call yapması ve hazırlanan script’i uygulaması istendi. Bunun satış dışı çalışanlarda ne kadar kaygı yarattığını ne anladılar ne de umursadılar. O olaydan sonra iş değiştirmeyi düşünmeye başladım
• Benzer bir durumu eskiden bizzat görmüştüm. Monitoring ekibi, “Tüm alarmları frontline engineer’lar doğrudan ticket olarak açmalı” diye ısrar ediyordu. Ama saatte 10 binden fazla alarm geliyordu. Önemli sorunlar tamamen “gürültü” içinde kayboluyordu; yöneticiler de tükenmişti. Bir noktada “Madem öyle, monitoring ekibi siz bir günlüğüne hepsini kendiniz açıp çözün” denmek zorunda kalındı. Ertesi gün, düşük öncelikli alarmlar elenince benzersiz alarm sayısı saatte birkaç düzineye düştü ve kalanların da hepsi sırayla kapatıldı. Ancak o zaman “panodaki her şey yeşil” durumu gerçekten doğru hale geldi (ondan önce bu sadece medya ve Gartner Group’a göstermek için zorla yeşile boyanmış bir tabloydu)