Ukuran backlog berbanding terbalik dengan frekuensi percakapan dengan pelanggan

• Semakin sering berbicara dengan pelanggan, semakin kecil ukuran backlog
• Penting untuk mengganti waktu perencanaan dengan percakapan bersama pelanggan
• Semakin banyak perantara antara developer dan pelanggan, semakin besar kemungkinan produk gagal memenuhi kebutuhan pelanggan
• Backlog yang besar berarti ada banyak asumsi yang belum tervalidasi dan kemungkinan menciptakan nilai bagi pelanggan lebih rendah

Fokus pada desain komponen teknis, bukan desain UI

• Jangan menghabiskan terlalu banyak waktu untuk desain UI; lebih penting merilis UI dasar dengan cepat lalu memperbaikinya melalui umpan balik pelanggan
• Utang teknis harus dijaga tetap rendah agar perubahan yang dibutuhkan pelanggan bisa dilakukan dengan cepat

Cara orang membayangkan penggunaan aplikasi berbeda dari cara aplikasi benar-benar digunakan

• Penting untuk mengamati bagaimana pelanggan menggunakan aplikasi
• Dengan mengamati perilaku pengguna secara langsung, kita bisa mendapatkan insight yang tidak dapat ditangkap hanya dari metrik kuantitatif

Implementasi account spoofing

• Penting berinvestasi pada fitur account spoofing untuk memahami layar apa yang benar-benar dilihat pelanggan tertentu
  • Account spoofing: fitur yang memungkinkan admin menggunakan aplikasi seolah-olah sebagai pengguna produksi tertentu
• Dengan ini, masalah dapat didiagnosis secara efektif dan ketergantungan pada data uji bisa dikurangi

Pentingnya halaman pertama

• Bagi pelanggan yang pertama kali masuk ke aplikasi, informasi yang paling relevan harus disajikan secara ringkas
• Jika mencoba memuat terlalu banyak informasi di halaman pertama, beban kognitif pengguna akan meningkat

Pelanggan adalah marketer terpenting

• NPS(Net Promoter Score) adalah metrik yang baik untuk menunjukkan apakah pelanggan memiliki kesan yang cukup kuat hingga mau merekomendasikan produk
• Biaya iklan bisa saja dikeluarkan, tetapi memulai dari pelanggan yang puas adalah strategi pemasaran yang efektif

MVP tidak berarti tanpa perbaikan berulang

• MVP tidak boleh menjadi alasan untuk memberikan pengalaman pelanggan berkualitas rendah hanya karena tekanan tenggat waktu
• MVP membantu menentukan apakah iterasi tambahan diperlukan dan, jika ya, aspek apa yang perlu diperbaiki

Opini GN⁺

• Hal terpenting dalam tulisan ini adalah pentingnya pengembangan produk yang mencerminkan kebutuhan pengguna nyata melalui percakapan berkelanjutan dengan pelanggan
• Tulisan ini menekankan pentingnya desain UI yang fleksibel dan komponen teknis yang memungkinkan umpan balik pelanggan cepat diterapkan
• Ini menunjukkan bahwa melampaui MVP, terus meningkatkan produk, dan menaikkan kepuasan pelanggan dapat membawa pada kesuksesan jangka panjang
• Tulisan ini membagikan pelajaran yang didapat dari kehidupan startup dan memberikan insight praktis bagi para founder maupun developer

[GN⁺]

Pendapat Hacker News

• Pendapat tentang cara mengelompokkan fitur/peningkatan

  • Berdasarkan pengalaman, strategi mengubah semua ide menjadi tiket itu tidak efisien. Ini membuat "icebox" yang penuh dengan ide-ide yang pada akhirnya tidak akan pernah dipakai.
  • Bahkan ketika ide di icebox dibutuhkan untuk sebuah kesepakatan penting, orang sering tidak ingat bahwa ide itu ada dan akhirnya membuat tiket baru.
  • Lebih memilih tiket yang realistis untuk diwujudkan dalam jangka pendek atau menengah, sementara ide lainnya disimpan secara terpisah.
  • Tim engineering memelihara daftar utang teknis yang ingin diselesaikan, dan PM memelihara daftar peluang perbaikan per proyek.
  • Untuk fitur/produk baru, PRD ditulis, tetapi tidak langsung diubah menjadi tiket.
  • Backlog raksasa yang sebagian besar tidak akan pernah dikerjakan adalah sinyal PM yang lemah dan takut mengatakan "tidak".

• Hubungan antara ukuran backlog dan tingkat pergantian PM

  • Ukuran backlog berbanding terbalik dengan tingkat pergantian PM.
  • Bagi PM yang sudah lama, backlog adalah alat bantu ingatan atas percakapan produk di masa lalu.
  • PM baru melihat backlog dan merasa bingung, lalu mencoba merapikan hal-hal yang tidak mereka pahami.

• Pendapat yang menentang pemeliharaan backlog berbasis pelanggan

  • Tim yang memelihara backlog pada umumnya mendapatkan backlog mereka dari pelanggan.
  • "Cari fitur yang memperbaiki kehidupan pelanggan lalu jadikan itu fitur berikutnya" bukanlah hal yang sederhana.
  • Bagaimana jika ada banyak pelanggan, dan fitur yang memperbaiki kehidupan masing-masing tidak saling terkait serta rumit?
  • Permintaan pelanggan harus selalu didengarkan, tetapi hampir tidak pernah boleh dibangun persis seperti yang mereka minta.
  • Pelanggan meminta fitur yang tidak hanya menyiratkan implementasi UX, tetapi juga masalah dan proses kerja yang sedang mereka gunakan saat ini.
  • Yang perlu dilakukan adalah mengidentifikasi masalah bisnisnya, lalu membuang ide implementasi UX dan hal-hal yang terlalu spesifik terhadap proses.
  • Fitur minimum yang menyelesaikan masalah bisnis itu harus dibangun secara ekonomis, dengan desain UX yang baik dan konsisten.

• Kebutuhan PM akan tempat untuk mencatat kebutuhan pelanggan

  • PM membutuhkan tempat untuk mencatat kebutuhan pelanggan.
  • Tanpa alat khusus, sebagian besar kebutuhan itu akhirnya menjadi tiket Jira.
  • Ada dua pendekatan: ProductBoard dan Jira Product Discovery.
  • ProductBoard mengambil pendekatan ala CRM, mencatat semua interaksi pelanggan, lalu belakangan memecahnya menjadi kebutuhan dan keinginan.
  • Jira Product Discovery dimulai dari ide, sehingga semua yang didengar dari pelanggan harus segera dipecah menjadi daftar panjang kebutuhan dan keinginan.
  • Keunggulan Jira Product Discovery adalah memisahkan daftar ide dari backlog developer, tetapi juga menciptakan daftar panjang lainnya.
  • Jika ingin menganalisis prioritas produk berdasarkan percakapan dengan pelanggan, ProductBoard adalah alat product discovery yang lebih baik.

• Pentingnya backlog yang dimatangkan oleh umpan balik pelanggan

  • Karena berbicara dengan pelanggan hampir setiap hari, ada fitur dan peningkatan dalam backlog yang secara langsung diinformasikan dan dimatangkan oleh umpan balik pelanggan.
  • Pekerjaan selalu banyak, tetapi perbedaannya terletak pada apakah backlog tersebut benar-benar diinformasikan dan dimatangkan oleh umpan balik pelanggan.

• Manajemen backlog melalui percakapan sehari-hari dengan pelanggan

  • Sebagai orang teknis, berbicara dengan pelanggan setiap hari, teorinya memang menarik, tetapi ada beberapa masalah.
  • Bias kebaruan dan biaya peluang: tetap perlu terus mengumpulkan umpan balik tentang ruang masalah yang sengaja tidak dikerjakan karena ada prioritas yang lebih tinggi.
  • Pengembangan yang reaktif: jika pencatatan umpan balik dilewati, tim akan cenderung fokus pada pekerjaan yang paling baru dan paling mudah diakses, sambil mengabaikan masalah yang lebih lama.
  • Basis pengetahuan tim: jika ada satu penanggung jawab tunggal yang mengumpulkan umpan balik dan memberikan solusi, klaim OP mungkin masuk akal.
  • Jika tim terlibat, dibutuhkan basis data bersama yang memungkinkan pencatatan dan pencarian data point secara asinkron.
  • Backlog bisa tumbuh dengan cepat, tetapi menangani sistem dan orang yang kompleks memang selalu disertai kesulitan.
  • Bagi tim yang terorganisasi dengan baik, dibutuhkan pengelolaan backlog yang baik, termasuk menyimpan pekerjaan yang tidak relevan, menghapus pekerjaan duplikat, memprioritaskan secara berkala, dan memanfaatkan alat sebaik mungkin.
  • Mengelola backlog lebih penting daripada alat itu sendiri, dan mungkin diperlukan sebuah "fasad" di atas backlog yang menampilkan informasi yang dibutuhkan di permukaan sambil tetap memungkinkan penelusuran lebih dalam saat diperlukan.

• Pentingnya mengamati pengguna aplikasi

  • Penting untuk mengamati pelanggan saat mereka menggunakan aplikasi.
  • Kita bisa melacak semua metrik, tetapi melihat pengguna menggulir untuk mencari sesuatu, menekan tombol kembali, atau mencoba mengklik sesuatu yang sebenarnya tidak bisa diklik, memberikan pengalaman yang jauh lebih nyata.
  • Semoga semua perusahaan seperti Apple, Google, dan lainnya mengamati pengguna beberapa kali setiap hari.

• Ketidakbergunaan backlog besar

  • Backlog besar mengandung banyak asumsi yang belum pasti dan kecil kemungkinan menghasilkan nilai bagi pelanggan.
  • Sudah terlalu sering orang salah mengira sesuatu itu bernilai, padahal ternyata tidak ada yang peduli.
  • Backlog besar mencerminkan rendahnya frekuensi percakapan dengan pelanggan, jadi harus dilihat dengan sangat skeptis.

• Peringatan tentang implementasi spoofing akun

  • Spoofing akun memang cara mudah untuk menguji masalah di lingkungan produksi, tetapi tim support dan tim pengembang membutuhkan kepercayaan terhadap data produksi.
  • Di beberapa industri, hal ini bisa menjadi masalah besar bagi pelanggan.
  • Startup tempat kerja terakhir bahkan tidak mengizinkan developer mengakses data produksi sama sekali.
  • Ini sebaiknya dianggap sebagai upaya terakhir dari sisi keamanan, dan lebih baik bekerja dengan asumsi bahwa data pelanggan tidak dapat diakses.

• Struktur pohon dalam perencanaan produk

  • Perencanaan produk seharusnya selalu berbentuk struktur pohon.
  • Node paling atas adalah tujuan bisnis, di bawahnya produk, di bawahnya masalah pelanggan, lalu di bawahnya item backlog.
  • Memiliki terlalu banyak item backlog bisa berarti struktur yang tepat belum dibangun dan belum ada daftar tujuan bisnis yang sudah diprioritaskan.
  • "Berbicara dengan pelanggan" berguna untuk memahami masalah pelanggan, tetapi tujuan bisnis harus diketahui terlebih dahulu. Jika tidak, waktu hanya akan terbuang untuk mengumpulkan umpan balik di area yang pada akhirnya memang tidak akan dikerjakan.