Semua insinyur diwajibkan ikut sales call, dua minggu kemudian platform ditulis ulang sepenuhnya

• Sebuah startup membuat para insinyur ikut langsung dalam sales call, dan hal itu pada akhirnya mengubah secara mendasar cara mereka mengembangkan produk
• Dalam proses sales call, mereka mengetahui bahwa produk kompetitor terlalu rumit bagi pengguna nonteknis, dan bahwa pelanggan, alih-alih menginginkan log/metrik, hanya menginginkan tanda konfirmasi (cek hijau) bahwa monitoring berjalan, serta bertanya apakah “tidak bisa ada yang mengerjakannya untuk kami?”
• Melalui pengalaman ini, tim yang berfokus pada backend mulai memahami sudut pandang pengguna dan mulai merancang sendiri arsitektur baru tanpa campur tangan PM
• Hanya dalam 2 minggu, mereka memangkas 60% fitur platform, menambahkan progress bar untuk menunjukkan kemajuan, membangun integrasi Slack, serta fitur workflow layanan terkelola, dan hasilnya tiket dukungan turun 70%
• Pelajaran dari pengalaman ini adalah bahwa pengguna hanya ingin masalahnya selesai dan tidak peduli pada kode yang elegan, dan bahwa fitur menimbulkan biaya bukan dalam bentuk jumlah kode, melainkan kebingungan pengguna

---

Latar belakang dan eksperimen

• Seorang insinyur senior DevOps menentang keikutsertaan dalam sales call, tetapi setuju dengan syarat mencoba minimal 5 panggilan
• Pendiri menilai bahwa desain produk hanya akan berubah jika para insinyur mendengar langsung bahasa dan masalah pelanggan

Insight dari sales call

• Mereka mendengar bahwa produk kompetitor terlalu rumit bagi pengguna nonteknis
• Pelanggan menginginkan konfirmasi intuitif seperti cek hijau yang sederhana, bukan metrik yang kompleks
• Banyak pelanggan meminta “layanan yang dikerjakan untuk Anda”, karena mereka ingin mengalihdayakan penyelesaian masalah itu sendiri, bukan sekadar memakai alat

Hasil penulisan ulang produk

• Tim menghapus 60% fitur yang ada dan fokus pada fitur inti
• Mereka menambahkan progress bar sederhana untuk memperbaiki pengalaman penggunaan
• Integrasi Slack menyederhanakan alur pertanyaan dan komunikasi
• Mereka menyediakan workflow done-for-you untuk langsung mencerminkan kebutuhan pelanggan
• Pada akhirnya, tiket dukungan turun 70%, dan kemudahan penggunaan serta kepuasan terhadap produk meningkat signifikan

Pelajaran utama

• Pengguna tidak menginginkan solusi teknis yang elegan, melainkan masalahnya terselesaikan
• Memahami pengguna lebih penting daripada ketepatan teknis
• Setiap fitur membawa biaya bukan dalam bentuk kode, tetapi kebingungan pengguna

Perubahan budaya tim

• Setelah itu, perusahaan mewajibkan semua insinyur mengikuti 5 sales call setiap kuartal
• Mendengar langsung kelelahan pelanggan dan permintaan bahwa “pokoknya harus berfungsi dengan baik” menjadi bagian dari budaya untuk membangun intuisi produk di kalangan insinyur

---

Ringkasan utama komentar Reddit

• Perdebatan soal peran PM
  • Sebagian orang menilai masalahnya adalah tidak adanya Product Manager yang baik, dan berpendapat bahwa insinyur harus sampai menangani panggilan pelanggan itu tidak efisien
  • Sebaliknya, ada juga bantahan bahwa “PM hanya berperan sebagai penerjemah, dan hasil terbaik muncul ketika insinyur memiliki langsung masalah pelanggan”
• Nilai dari kontak langsung dengan pelanggan
  • Banyak komentar menekankan bahwa pengalaman insinyur mendengar langsung suara pengguna memberikan insight yang sangat kuat
  • Ada juga pendapat bahwa pada startup tahap awal atau tim kecil, insinyur sering sekaligus menjalankan sebagian peran PM
• Sudut pandang kritis
  • Ada kritik bahwa “ini hanya kegagalan kepemimpinan/budaya yang dibebankan kepada insinyur”
  • Ada pula sanggahan seperti “apakah memotong fitur dan menyederhanakan itu benar-benar perbaikan?”, dengan peringatan bahwa dalam jangka panjang ada risiko mengabaikan power user dan kebutuhan fitur lanjutan
• Berbagi contoh positif
  • Banyak pengalaman dari industri seperti perbankan dan perangkat medis tentang kebijakan serupa, di mana semua karyawan merasakan langsung dukungan pelanggan atau penjualan
  • Ada kesepakatan bahwa dogfooding atau “berhadapan langsung dengan pelanggan” membantu kualitas produk dan budaya tim
• Implikasi keseluruhan
  • Membuat tim merasakan langsung masalah pelanggan adalah alat pembelajaran yang sangat kuat, tetapi
  • pada saat yang sama, inti perdebatan adalah bahwa dalam jangka panjang hal ini perlu dipadukan dengan kemampuan profesional PM, UX, dan desain agar strategi produk tetap seimbang

[meteorizer]

Pada akhirnya ini soal efisiensi.
Ada banyak hal baik dari berdiskusi langsung dengan pelanggan,
tetapi karena komunikasi yang sering seperti rapat dan panggilan telepon, kesinambungan kerja jadi sering terputus dan waktu yang bisa diinvestasikan untuk pengembangan pun berkurang.
Kalau begitu, perusahaan seharusnya menyusun rencana perekrutan untuk mengatasi turunnya produktivitas.
Masalahnya, biasanya mereka tidak berniat melakukan itu.
Pada akhirnya, karena kekurangan waktu, seiring berjalannya waktu kemungkinan besar kualitas akan menurun.
Menurut saya, kelebihan dan kekurangannya harus dipertimbangkan dengan baik.

[laeyoung]

Saya tidak yakin mengapa di Hacker News dibiarkan sebagai tautan old reddit, tetapi jalur ke UI reddit saat ini ada di sini.

[xguru]

Sepertinya di Hacker News, saat memposting URL Reddit, kebanyakan orang menggunakan old reddit. Mungkin karena lebih ringan juga.

[cnaa97]

Jika sebuah organisasi bertujuan menaikkan batas bawah, saya mengakui bahwa organisasi berbasis peran memang cocok, seperti tim yang hanya terdiri dari developer web frontend atau tim developer aplikasi.

Namun, untuk tim atau organisasi yang mengejar batas atas, menyusunnya sebagai organisasi berbasis peran pasti memiliki keterbatasan.
Seperti isi tulisan utama, apakah memang perlu perencana, desainer, PM, dan engineer masing-masing hanya menangani pekerjaannya sendiri dan bekerja seperti ban berjalan di pabrik? Pertanyaan seperti itu pun muncul. Alih-alih bekerja dengan gaya khas "petugas penanggung jawab" yang hanya menangani beberapa hal yang ditugaskan, bentuk yang ideal adalah anggota dengan spesialisasi di bidang masing-masing berkumpul, menetapkan tujuan bersama, lalu seluruh anggota saling mendukung.

Di banyak perusahaan, organisasi dibentuk dalam bentuk task force seperti spin-off atau pembentukan tim, tetapi karena ini juga hanya mengelompokkan orang (peran), penguatan negatif dapat terjadi (pola seperti, saya sedang mencoba melakukan sesuatu, tetapi perusahaan tidak membantu, jadi lebih baik saya menyerah), sehingga yang justru hilang bisa hanya talenta-talenta utama seperti key member. Karena itu, organisasi berbasis tujuan juga pasti membutuhkan dukungan aktif dari organisasi berbasis peran.

[GN⁺]

Opini Hacker News

• Pada akhirnya, mereka merancang arsitektur yang benar-benar baru tanpa “PMing”-ku. Alasannya karena akhirnya mereka benar-benar memahami siapa yang sebenarnya menggunakan produk kami. Kalau melihat pengalaman ini secara keseluruhan, kesimpulannya adalah, “kami mencoba menyuruh engineer ikut sales call, lalu ternyata masalah utamanya adalah PM gagal menjembatani komunikasi antara pelanggan dan engineering, sementara engineer DevOps justru yang paling cepat mengubah kebutuhan pelanggan menjadi solusi yang benar-benar berjalan”
  • Kadang engineer terlalu percaya diri dan menganggap pengguna yang memakai produknya dengan cara yang salah. Logikanya adalah ini terjadi “karena pengguna bertingkah bodoh”, bukan karena ada masalah pada desain rumit yang kubuat. Kalangan Desktop Linux saja bisa menulis satu buku penuh dari pengalaman mengabaikan keluhan pengguna. Kalau ada engineer keras kepala yang merasa dirinya lebih tahu daripada PM dan pengguna, tidak akan ada kemajuan. Tetapi kalau engineer seperti itu dilempar untuk berhadapan langsung dengan pengguna, maka alih-alih PM yang biasanya ramah, mereka akan menerima hujan kritik dari pengguna yang benar-benar kesal, yang memperlakukan “mahakarya keren” itu seperti hamster bermasalah. Proses seperti ini memang menakutkan, tapi juga meruntuhkan ego engineer. Dari sudut pandangku, ini bukan untuk menunjukkan bahwa PM itu bodoh, melainkan untuk membuat engineer lebih rendah hati. Seiring waktu, kesombongan engineer akan kembali lagi, jadi proses ini perlu diulang secara berkala
  • Aku adalah satu-satunya orang di tim teknik mesin sebuah perusahaan besar yang bisa menulis kode. Tim IT internal memang membuat berbagai perangkat lunak sendiri, tetapi sebagian besar dianggap buruk oleh anggota tim kami. Jadi aku mempermudah pekerjaan dengan langsung membuat ulang itu dari nol, atau merancang alat untuk melengkapi program “buruk” yang benar-benar tidak bisa digantikan. Bukan berarti aku lebih jago mengembangkan software daripada tim IT internal, melainkan karena dari sudut pandang pengguna nyata, aku lebih paham apa yang benar-benar dibutuhkan oleh diriku sendiri, yaitu tim kami. Dan karena akulah yang memakai software ini, tentu motivasiku juga lebih tinggi. Karena itu judul tulisan ini sangat terasa relevan bagiku. Meski begitu, menurutku hal yang dibahas di isi tulisannya juga sangat mungkin terjadi di lapangan. Aku sendiri tidak akrab dengan proses formal software development/project management
  • Aku menjalankan startup teknologi kecil dengan pendapatan tahunan 2 juta dolar. Kadang saat kekurangan staf support, aku sendiri turun menangani dukungan pelanggan selama beberapa hari. Setiap kali itu terjadi, anehnya aku selalu menemukan banyak keluhan pelanggan yang biasanya sama sekali tidak pernah diteruskan ke tim engineering. Staf support cenderung fokus “menyelesaikan” masalah sendiri, sehingga perbaikan mendasar tidak pernah benar-benar diteruskan ke engineering
  • Yang menarik, tidak ada yang bertanya kenapa software itu sejak awal bisa seburuk itu. Menurutku tanggung jawabnya tidak bisa seluruhnya dilempar ke satu PM. Sebenarnya ini masalah sistem: Agile/Scrum membuat tanggung jawab kabur, dan developer sibuk memproses tiket yang disusun asal-asalan dalam siklus yang terlalu cepat, sehingga lahirlah software setengah matang seperti ini. Ini hasil yang cukup umum ketika organisasi software “modern” membengkak terlalu besar
  • Pikiran pertamaku saat membaca ini adalah, “dulu software memang dibuat seperti ini, sebelum PM ikut campur ke mana-mana.” Kalau engineer didudukkan di samping orang yang benar-benar menjalankan operasinya, sering kali PM sebenarnya tidak dibutuhkan dan semua orang justru jauh lebih bahagia. Tentu ada juga PM yang hebat, tetapi dalam pengalamanku PM cenderung terobsesi dengan perebutan wilayah, dan mengejutkannya kadang juga tidak terlalu paham baik sisi engineering maupun sisi pelanggan
• Aku sudah beberapa kali mengalami situasi di mana engineer tidak sinkron dengan produk. Ada rekan kerja yang diam-diam menambahkan sesuatu tanpa diketahui orang lain, sehingga UI jadi membingungkan, atau isi website tidak sesuai dengan kondisi produk sebenarnya. Lalu karena ada loop panjang seperti [produk -> PM -> sistem pelacakan bug -> engineer -> perbaikan -> QA -> produk], hal-hal penting memang diperbaiki, tetapi ketidaknyamanan kecil bisa dibiarkan sangat lama. Kalau tinggal [produk <-> engineer] saja, peningkatan produktivitasnya bisa sangat besar. Banyak engineer juga ternyata belum pernah benar-benar merasakan keseluruhan pengalaman produk, bahkan tidak tahu perbedaan kondisi produk tahun ini dan tahun lalu
  • Aku juga punya pengalaman serupa, dan anehnya hal ini lebih sering terjadi di tempat yang punya banyak PM. Pengalaman terburukku adalah di satu perusahaan yang mencoba memaksakan rasio PM dan “Product Designer” sesuai jumlah engineer. Kalau dijumlahkan, desainer, product, project, dan program manager malah lebih banyak daripada engineer. Hasilnya justru jadi lebih buruk. Menghindari birokrasi PM dan kekhawatiran mereka soal wilayah kerja yang diinjak pun sudah jadi pekerjaan tersendiri. PM yang hebat itu sangat berharga, tetapi akhir-akhir ini gelar Product Management terasa terlalu banyak diisi orang yang birokratis dan terobsesi proses. Para influencer Product Management juga memperparah masalah ini
  • Meski begitu, aku juga tidak menganggap memaksa engineer ikut sales call sebagai jawaban yang benar. Menjalankan satu panggilan dengan baik butuh banyak soft skill, sementara engineer tidak dilatih ke arah itu dan itu juga bukan hal yang dipertimbangkan saat perekrutan. (Yang kumaksud dengan ‘sales call’ adalah panggilan konsultasi awal sebelum demo atau PoC. Untuk demo prapenjualan yang kompleks, engineer boleh ikut mendampingi, tetapi secara prinsip peran itu tetap seharusnya dipegang pihak product)
  • Ada begitu banyak cara semuanya bisa salah, dan aku sudah melihat semua kasus itu sendiri. Misalnya, semua komunikasi pelanggan dimonopoli PM atau PO, atau pelanggan sendiri menghindari bicara dengan developer dan hanya menyampaikan interpretasi kebutuhan lewat manajer pengguna, atau developer memang hanya ingin menulis kode, atau semua komunikasi dipaksa lewat PM dan bug tracker saja. Saat memakai platform software komersial, keterbatasan teknis juga bisa membuat workflow jadi sangat buruk. Selalu ada faktor yang menghambat komunikasi, dan itu bisa berasal dari pelanggan, manajer menengah, maupun developer. Bahkan tidak jarang solusi yang salah sudah ditentukan sejak awal, lalu developer dan pengguna memulai tanpa benar-benar tahu detailnya. Ada sangat banyak jalan menuju kegagalan membuat sistem yang benar-benar baik untuk pengguna
  • Menurutku sangat penting bagi engineer untuk memahami produk itu sendiri secara mendalam. Menyamakan sisi produk justru lebih sulit daripada engineering dasarnya. Sebagian besar produk yang pernah kulihat gagal, pada akhirnya gagal karena alasan produk, jadi secara logis memang lebih masuk akal jika kekuatan tim diarahkan ke sisi itu
• Sebaliknya, ada juga kasus engineer akhirnya turun derajat menjadi semacam tim dukungan teknis. Kalau harus mendukung tiap pelanggan secara langsung, yang menumpuk hanyalah hotfix dan solusi khusus per pelanggan, dan karena semua itu juga tidak benar-benar bisa diuji dengan baik, utang teknis hanya akan bertambah. Lalu ketika pesaing yang lebih besar dan didanai dengan baik membuat produk yang lebih keren, perusahaan akan cepat tersingkir. Menurutku ini kegagalan product management yang klasik. Artinya PM gagal meneruskan kebutuhan pelanggan ke engineer dengan benar, atau gagal mendorong balik ke arah sebaliknya. Menugaskan engineer ke sales call bukan pendekatan yang bisa diskalakan ketika basis pelanggan mulai membesar dan matang. Kalau product manager benar-benar ingin engineer melakukan sales call, engineer itu juga seharusnya mendapat sebagian komisi dari tiap akun. Aku tidak akan pernah menangani sales call tanpa komisi
• Untuk lingkungan seperti startup, di mana semua anggota tim perlu benar-benar berempati dengan kebutuhan pelanggan, ini strategi yang sangat bagus. Tingkat keberhasilan proyekku jauh lebih tinggi saat aku ikut mendefinisikan kebutuhan produk secara langsung dan memahami pekerjaan lapangannya. Hasilnya jauh lebih baik dibanding saat aku hanya “menerima” requirement lalu mengimplementasikannya begitu saja
  • Maksudnya karena kamu sendiri yang menulis panduannya jadi lebih mudah diikuti, atau karena keterlibatan langsung itu menghasilkan UX yang lebih baik?
• “Rewrite selesai dalam 2 minggu, 60% fitur dihapus, progress bar sederhana ditambahkan, integrasi Slack dibangun, workflow ‘done-for-you’ disediakan -> tiket support turun 70%” Kalau ini benar, berarti ada sesuatu yang sangat salah
  • Reddit terkenal dengan ledakan cerita karangan, dan entah kisah ini terinspirasi dari kejadian nyata atau sepenuhnya fiksi, nuansa penulisannya penuh elemen khas Reddit dengan gaya storytelling bisnis ala LinkedIn
  • Ini kelihatannya kasus B2B SaaS yang sudah beberapa kali pivot tetapi panduan terkait produknya tetap minim. Tentu saja, kekacauan seperti ini ternyata jauh lebih umum daripada yang orang kira
  • Dari gaya kalimat pendek ala LinkedIn yang diakhiri klimaks dramatis berulang-ulang, mudah sekali menebak bahwa ini fiksi
  • Ya namanya juga Reddit, tentu saja ini karangan. Aku tidak tahu kenapa tulisan seperti ini bisa jadi topik besar
• Kalau hasilnya seperti ini, PM, PO, dan tim marketing seharusnya langsung dipecat semua. Ada dua hal yang jelas: pertama, mereka tidak tahu apa yang sebenarnya diinginkan pelanggan, atau tidak mampu menyampaikan kebutuhan itu dengan benar ke tim pengembang, atau keduanya. Kedua, pola pikir mereka terlalu sistemik dan berlapis, sampai-sampai mungkin lebih baik semua lapisan perantara antara pelanggan dan tim pengembang dihapus saja
• Di tempat kerjaku dulu, engineer juga rutin ikut panggilan penjualan. Memang menarik untuk mengalami sendiri apa yang diinginkan pelanggan dan bagaimana produk kami dijual, tetapi itu tidak revolusioner. Fitur yang diminta pelanggan sebenarnya sudah ada di roadmap, dan ada satu fitur membingungkan juga, tetapi itu dirancang seperti itu karena kebutuhan khusus pelanggan terbesar kami. Tim pengembang ingin membuatnya lebih sederhana, tetapi kalau begitu kebutuhan pelanggan besar itu tidak akan terpenuhi. Jadi akhirnya dibuat versi “ringan” yang lebih mudah dipakai, dan semua pelanggan selain pelanggan besar itu diarahkan memakai versi tersebut. Namun perubahan seperti ini pun bukan terjadi karena ikut sales call; semua orang memang sudah tahu dari awal bahwa itu sulit, hanya saja tidak bisa diubah sampai masuk roadmap
• Aku sangat relate dengan bagian “akhirnya memahami siapa pengguna sebenarnya.” Banyak orang bilang “masalah terbesar kebanyakan engineer adalah overengineering”, tetapi kenyataannya overengineering lebih sering muncul karena mereka tidak benar-benar memahami use case pelanggan. Itu masalah yang lebih mendasar. Sebagai engineer, frustrasi yang paling sering kurasakan justru ketika engineer lain bahkan tidak berusaha memahami produk seperti apa yang benar-benar laku dijual. Entah karena kecocokan kerja, ego, atau biasanya budaya organisasi dan struktur insentif
• Dulu aku bekerja di perusahaan yang membuat solusi robocall untuk CRM, dan saat acara offsite semua orang diminta mencoba melakukan cold call sendiri dan mengikuti skrip yang ada. Tidak ada pemahaman ataupun kepedulian soal kecemasan yang ditimbulkan hal itu pada orang non-sales. Sejak kejadian itu aku mulai berpikir untuk pindah kerja
• Aku pernah melihat situasi serupa secara langsung. Tim monitoring bersikeras bahwa “semua alert harus langsung dibuatkan tiket oleh engineer garis depan.” Masalahnya, jumlah alert-nya lebih dari 10 ribu per jam. Isu penting jadi tenggelam di tengah ‘noise’, manajemen pun kelelahan, dan akhirnya pernah dipaksa, “coba tim monitoring sendiri yang buka semua tiket itu dan selesaikan.” Keesokan harinya, setelah alert prioritas rendah dikecualikan, alert unik turun menjadi belasan per jam, dan sisanya juga ditutup satu per satu. Baru saat itulah “semua papan berwarna hijau” benar-benar berarti hijau (sebelumnya cuma diwarnai hijau secara paksa untuk dipamerkan ke media dan Gartner Group)