How to Find Better Problems Before You Build
Problem discovery membantu founder dan engineer membedakan pain point yang berulang dari feature request satu kali sebelum menghabiskan waktu untuk membangun solusi.
Banyak proyek software dimulai dari request yang terdengar jelas: tambahkan satu tombol, buat satu integrasi, atau otomatisasi satu langkah yang terasa mengganggu. Masalahnya, request pertama belum tentu menggambarkan masalah yang paling penting. Artikel Lalit Maganti tentang cara menemukan problem sebagai staff engineer menawarkan pendekatan yang lebih sabar: dengarkan friksi yang berulang, biarkan bukti terkumpul, lalu uji bentuk masalahnya sebelum membangun solusi besar.
1. Apa itu problem discovery untuk engineer?
Problem discovery adalah proses menemukan hambatan yang benar-benar berulang dalam pekerjaan pengguna atau tim. Maganti tidak memulai dari sesi brainstorming kosong. Ia menyerap keluhan di meeting, chat, presentasi, dan email, kemudian memperhatikan masalah mana yang muncul lagi dalam konteks berbeda.
Pendekatan ini berbeda dari sekadar mengumpulkan feature request. Pengguna sering menyebut solusi yang mereka inginkan, padahal kebutuhan di baliknya bisa lebih luas. Pertanyaan yang lebih berguna adalah: pekerjaan apa yang ingin mereka selesaikan, bagian mana yang paling lambat, dan mengapa fitur yang sudah ada belum cukup?
2. Mengapa masalah perlu dibiarkan menumpuk?
Request yang paling keras belum tentu menjadi prioritas terbaik. Dalam contoh Maganti, fitur yang diminta satu tim bisa kehilangan relevansi ketika prioritas mereka berubah. Menunggu memberi ruang bagi bukti tambahan: masalah yang sama mungkin muncul di beberapa tim, atau beberapa request berbeda ternyata punya pola yang sama.
Bagi founder dan indie hacker, praktiknya tidak harus rumit. Simpan catatan singkat berisi siapa yang mengalami masalah, kapan masalah itu muncul, workaround yang dipakai, dan apakah masalah tersebut muncul kembali. Catatan ini membantu membedakan pain yang persisten dari ide yang hanya terdengar menarik pada satu percakapan.
3. Cari bentuk umum, bukan solusi yang paling elegan
Maganti memakai contoh Perfetto, tool untuk melihat rekaman aktivitas sistem. Beberapa tim meminta perubahan UI yang berbeda, tetapi kebutuhan dasarnya serupa: mereka ingin menyesuaikan tampilan untuk workflow masing-masing. Dari pola itu, solusi yang lebih umum berupa extension dapat dipertimbangkan.
Namun, pola yang terlihat rapi tetap sebuah hipotesis. Sebelum coding penuh, pressure-test dengan percakapan, RFC singkat, atau throwaway prototype. Jika dua masalah ternyata memiliki constraint berbeda, memisahkan solusi justru lebih sehat daripada memaksakan satu abstraksi.
4. Langkah praktis untuk proyek kecil
Mulai dengan problem log sederhana. Kumpulkan lima sampai sepuluh pain point sebelum memilih satu. Tandai masalah yang muncul berulang, berdampak pada lebih dari satu workflow, dan bisa diuji dengan prototype kecil. Setelah itu, tanyakan apakah solusi tersebut menyelesaikan kebutuhan inti atau hanya menyalin request awal.
Staffeng.com menempatkan kemampuan memecahkan masalah kompleks sebagai salah satu pola kerja staff-plus engineer, tetapi konteks organisasi tetap menentukan. Untuk proyek kecil, prinsipnya sama: jangan membangun lebih cepat daripada kemampuan Anda mengumpulkan bukti.
Referensi: https://lalitm.com/post/find-problems-staff-engineer/