2.4 Pekerjaan yang Ingin Diselesaikan
Setelah kita tahu siapa penggunanya, langkah berikutnya adalah memahami pekerjaan apa yang sedang mereka coba selesaikan—bukan fitur apa yang mereka minta.
Coba bayangkan skenario ini. Seorang staf finance datang ke tim IT dan berkata, "Saya butuh tombol export ke Excel di laporan aging piutang." Kalau tim langsung mengerjakan, mereka akan membuat tombol, menentukan format, mengatur layout, dan selesai. Tapi apakah itu yang sebenarnya dibutuhkan?
Coba tanya lebih dalam. Ternyata staf finance itu setiap akhir bulan harus mengirim rekap piutang ke kepala divisi. Kepala divisi minta datanya dalam format tertentu karena dia akan menggabungkannya dengan data dari sistem lain. Staf finance menghabiskan empat puluh menit setiap kali menyalin data dari layar ke Excel, merapikan kolom, dan menyesuaikan format.
Pekerjaan yang ingin diselesaikan bukanlah "memiliki tombol export". Pekerjaan yang ingin diselesaikan adalah "data piutang bisa sampai ke kepala divisi dalam format yang siap pakai, tanpa perlu mengetik ulang atau merapikan manual."
Inilah inti pendekatan yang disebut jobs-to-be-done. Alih-alih mendengarkan fitur yang diminta, kita mencari hasil yang ingin dicapai pengguna. Pengguna tidak membeli bor karena mereka ingin punya bor. Mereka membeli bor karena mereka ingin lubang di dinding. Pengguna tidak minta tombol export karena mereka ingin tombol. Mereka ingin data bisa dipindahkan tanpa kerja manual.
Perbedaan ini kelihatan sepele, tetapi dampaknya besar pada solusi yang kita rancang. Kalau kita hanya membuat tombol export, kita mungkin menyelesaikan permintaan, tetapi belum tentu menyelesaikan masalah. Mungkin solusi yang lebih tepat adalah integrasi langsung antara sistem finance dan sistem kepala divisi. Mungkin cukup dengan jadwal kirim otomatis setiap akhir bulan. Mungkin laporan bisa langsung tampil di dashboard yang bisa diakses bersama.
Berikut adalah diagram yang merangkum alur berpikir jobs-to-be-done dari contoh di atas.
Semua ini tidak akan muncul kalau kita berhenti di "buatkan tombol export."
Pendekatan jobs-to-be-done mengubah cara kita bertanya. Daripada "fitur apa yang Anda mau?", kita bertanya "setelah pakai solusi ini, apa yang bisa Anda lakukan yang sebelumnya tidak bisa?" Atau "pekerjaan apa yang terasa berat dan ingin Anda hilangkan?" Atau "hasil seperti apa yang membuat Anda puas?"
Pertanyaan-pertanyaan ini mengarahkan percakapan ke hasil, bukan ke bentuk teknis. Pengguna jadi lebih mudah menjelaskan apa yang sebenarnya mereka butuhkan. Tim teknis jadi lebih leluasa mencari solusi terbaik, bukan sekadar mengeksekusi permintaan.
Dalam konteks AI, pendekatan ini jadi semakin relevan. AI bisa membantu kita menulis ulang deskripsi kebutuhan, merapikan catatan wawancara, atau bahkan menyarankan pola solusi dari hasil serupa di organisasi lain. Tapi AI tidak bisa menggantikan percakapan yang menggali pekerjaan yang ingin diselesaikan. Hanya manusia yang bisa duduk bersama pengguna, mendengar cerita mereka, dan menangkap apa yang benar-benar mereka butuhkan.
Setelah kita paham pekerjaan yang ingin diselesaikan, langkah selanjutnya adalah melihat konteks yang lebih luas. Pekerjaan itu tidak terjadi di ruang hampa. Ia terjadi di dalam organisasi dengan proses bisnis, aturan, peran, dan batasan operasional. Itu menjadi arah pembahasan berikutnya.
