Bahasa Indonesia
Pekerjaan Discovery sebagai Desainer Produk (Bukan Sekadar Mengeksekusi Spesifikasi PM)
Anda menghabiskan tiga hari untuk sebuah alur. Anda membuka Figma pukul 09.00 Senin dan baru benar-benar keluar pada Rabu siang. Anda menyerahkan satu file kepada PM. Mereka meliriknya, berkata "kelihatannya bagus, rilis saja," dan melanjutkan. Tidak ada yang berubah dalam spesifikasi mereka. Tidak ada yang bergeser dalam roadmap. Anda merasa berguna tapi tidak terlihat. Dan enam bulan kemudian ulasan kinerja Anda berkata "eksekusi baik" alih-alih "membentuk roadmap."
Saya pernah melihat desainer menyalahkan PM untuk ini. PM sibuk. PM tidak memahami desain. PM punya favoritnya sendiri. Tidak ada itu yang merupakan masalah sesungguhnya. Masalah sesungguhnya adalah artefak yang Anda serahkan. Satu desain berarti satu keputusan: rilis atau tidak rilis. PM tidak menolak satu opsi tunggal. Mereka langsung menyetujuinya. Saya menyebut ini jebakan satu opsi, dan hampir setiap desainer yang hanya bekerja pada eksekusi terjebak di dalamnya tanpa menyadarinya.
Solusinya bukan bekerja lebih keras. Melainkan mengubah apa yang ada di meja mereka.
Mengapa ini lebih penting dari dua tahun lalu
Dua tren bertabrakan dalam 18 bulan terakhir. Pertama, desainer discovery (yang membentuk apa yang dibangun, bukan hanya tampilannya) menghasilkan jauh lebih banyak daripada desainer eksekusi di level yang sama. Dari studi gaji publik terbaru (Pencil & Paper's 2025 Product Design Salary Report, Dribbble Salary Database, dan thread gaji desain Read the Docs), kesenjangan berjalan sekitar 18-30% di level menengah dan melebar di atas senior. Desainer produk senior di perusahaan Series B yang membentuk spesifikasi mendekati $190K total kompensasi. Titel yang sama, perusahaan yang sama, level yang sama, hanya eksekusi? Mendekati $150K. Itu bukan selisih kecil. Itu setara harga mobil.
Kedua, PM semakin sering merilis tanpa melibatkan desainer. Cursor, Linear, Lovable, v0, dan gelombang alat desain AI berarti PM dengan selera yang baik bisa merilis alur yang kompeten sendiri. Desainer yang bertahan dari pergeseran itu adalah mereka yang berkontribusi di hulu, di lapisan pendefinisian masalah, bukan lapisan poles. Jika satu-satunya nilai tambah Anda adalah "membuat file Figma terlihat bagus," Anda sedang bersaing dengan AI menuju titik terendah.
Ini bukan kepanikan. Ini klarifikasi. Pekerjaan bergerak ke arah discovery, dan desainer yang sudah beroperasi dengan cara itu semakin maju. Mekanik cara mereka melakukannya bisa dipelajari. Itulah yang dibahas dalam panduan ini.
Discovery vs eksekusi: pemisahan pola pikir yang sesungguhnya
Mode eksekusi menjawab satu pertanyaan: "Bagaimana tampilan dan perilaku ini?" Anda menerima masalah, lingkup, dan batasan. Anda membuat sesuatu. Anda menyerahkannya kembali.
Mode discovery menjawab pertanyaan yang berbeda: "Apakah ini masalah yang tepat untuk diselesaikan?" Anda menerima brief dan mempertanyakannya sebelum membuka Figma. Anda berbicara dengan pelanggan. Anda membuat sketsa alternatif yang tidak sesuai dengan spesifikasi. Anda membawa bukti ke dalam percakapan.
Kedua mode penting. Kesalahannya bukan melakukan pekerjaan eksekusi. Eksekusi adalah sebagian besar minggu desainer mana pun, bahkan di level staff. Kesalahannya adalah melakukan hanya pekerjaan eksekusi dan terkejut ketika Anda diperlakukan seperti meja layanan.
Perilaku konkret per mode:
Desainer mode eksekusi:
- Membuka Figma begitu mendapat spesifikasi
- Bertanya "bagaimana tampilan kondisi kosong?"
- Menyerahkan satu file
- Melacak alur yang dirilis dalam portofolio
- Melapor ke atas: "Saya merilis X, Y, Z kuartal ini"
Desainer mode discovery:
- Membaca spesifikasi, lalu menutup laptop dan berjalan sebentar
- Bertanya "untuk siapa kita membangun ini dan apa yang kita ketahui tentang mereka?"
- Menyerahkan tiga opsi dengan trade-off
- Melacak perubahan spesifikasi yang disebabkan oleh pekerjaan mereka
- Melapor ke atas: "Saya mengubah cara kita mendekati X. Ini bukti pelanggannya dan hasilnya."
Perhatikan kata kerja eksekutifnya. Desainer discovery berkata "mengubah," "menggeser," "mengarahkan ulang." Desainer eksekusi berkata "merilis," "menyelesaikan," "menyerahkan." Set pertama terdengar seperti kepemilikan. Set kedua terdengar seperti throughput.
Aturan 3 jalur
Inilah satu perubahan mekanik yang paling banyak berperan. Setiap kali Anda menyerahkan desain ke PM, serahkan tiga opsi:
- Jalur aman: paling dekat dengan spesifikasi PM. Risiko terendah, hadiah terendah. Hal yang mereka harapkan.
- Jalur ambisius: apa yang akan Anda bangun jika Anda punya dua minggu lagi dan sedikit lebih banyak ruang lingkup. Masalah yang sama, solusi yang lebih ambisius.
- Jalur tidak biasa: opsi yang memecahkan masalah yang berbeda, atau memecahkan masalah yang sama dengan cara yang belum pernah dipertimbangkan siapa pun. Biasanya terinspirasi dari wawancara pelanggan atau serangan flank kompetitor.
Setiap jalur disertai tiga label: biaya waktu, risiko, dan potensi manfaat. Itu saja. Tidak perlu dokumen Notion 10 halaman. Cukup satu halaman dengan tiga frame Figma dan tabel kecil.
Mengapa tiga? Karena cara PM sebenarnya membuat keputusan. Dengan satu opsi, vonis bersifat biner: rilis atau tidak. PM hampir selalu merilis, dan itulah loop persetujuan langsung. Dengan dua opsi, Anda menciptakan biner palsu. PM memilih yang lebih aman dan Anda melatih mereka untuk mengharapkan pilihan aman-vs-berisiko setiap saat. Dengan tiga opsi, Anda menciptakan percakapan nyata. PM harus mengartikulasikan mengapa mereka lebih memilih satu. Dan begitu mereka mengartikulasikan alasannya, Anda sudah bergerak dari "mengeksekusi spesifikasi" ke "bersama-sama memutuskan strategi."
Saya tidak pernah mendapat penolakan untuk serah terima 3 jalur. Saya sering melihat mereka memilih jalur aman. Tapi percakapannya berbeda. Kita mendiskusikan trade-off alih-alih menyetujui poles.
Template kerja yang saya gunakan:
Masalah: [satu kalimat, apa yang kita coba lakukan untuk pengguna]
Jalur A, Aman (1 minggu)
Apa: [apa yang diharapkan PM, dirancang dengan bersih]
Risiko: rendah
Manfaat: dirilis tepat waktu, mencapai OKR
Jalur B, Ambisius (2 minggu)
Apa: [solusi yang lebih ambisius untuk masalah yang sama]
Risiko: sedang, butuh perubahan backend
Manfaat: mengatasi masalah lanjutan yang akan kita hadapi di Q3 bagaimanapun
Jalur C, Tidak Biasa (3 minggu)
Apa: [memecahkan framing masalah yang berbeda sama sekali]
Risiko: tinggi, belum jelas apakah pelanggan menginginkan ini
Manfaat: dampak 10x jika benar; pembelajaran di manapun hasilnya
Bukti pelanggan: [sebutkan wawancara pelanggan yang mengarah ke sini]
Itu satu halaman. Lima belas menit untuk ditulis setelah Anda melakukan pemikiran desain. Terapkan untuk setiap serah terima selama satu kuartal dan lihat apa yang terjadi pada ulasan kinerja Anda.
Pohon peluang-solusi, edisi desainer
Pohon peluang-solusi Teresa Torres adalah kerangka paling bersih yang saya temukan untuk tetap di hulu eksekusi. Versi aslinya: hasil di bagian atas, peluang (masalah dan keinginan pelanggan) di tengah, solusi yang bercabang dari setiap peluang di bagian bawah.
Adaptasi desainer: pekerjaan Anda adalah mengisi lapisan tengah, bukan hanya lapisan bawah. Sebagian besar desainer hidup sepenuhnya di lapisan solusi (membuat sketsa, membuat prototipe, memoles hal-hal yang memecahkan peluang yang sudah diketahui). PM sebagian besar hidup di lapisan hasil (OKR kuartalan, metrik bisnis, narasi eksekutif). Lapisan tengah (masalah pelanggan yang sesungguhnya) adalah wilayah yang diperebutkan. Siapa pun yang mengisinya dengan baik, menguasai roadmap.
Contoh nyata. Saya bekerja pada alur checkout untuk B2B SaaS yang ingin meningkatkan tingkat aktivasi.
Lapisan hasil (wilayah PM): Tingkatkan aktivasi 30 hari dari 38% ke 50%.
Lapisan peluang (pertarungan sesungguhnya):
- Pengguna meninggalkan saat pemberian kursi karena mereka belum tahu siapa yang harus diundang
- Pengguna melewati langkah integrasi karena mereka pikir itu opsional
- Pengguna menyelesaikan pendaftaran tapi tidak pernah kembali karena produk terasa kosong sampai mereka mengundang rekan tim
- Pengguna mengundang rekan tim tapi rekan tim mengabaikan email karena subject line-nya generik
Seorang desainer junior akan diberi "desain ulang layar pemberian kursi" dan membuatnya terlihat bagus. Langkah discovery adalah memetakan keempat peluang, lalu menjalankan putaran wawancara cepat untuk mengetahui mana yang benar-benar merupakan kendala utama. (Ternyata yang ketiga, perasaan produk kosong, dan ukurannya 4x lebih besar dari ketiga yang lain digabungkan. Tidak ada yang membuat spesifikasi untuk itu karena tidak ada yang bertanya.)
Artefaknya sangat sederhana. Buka FigJam. Tiga baris: hasil, peluang, solusi. Sticky notes. Aturannya adalah tidak ada solusi yang dilampirkan ke peluang yang belum divalidasi dalam setidaknya satu percakapan pelanggan. Aturan itu sendiri yang memisahkan desainer discovery dari desainer eksekusi.
Ritme wawancara pelanggan: 3+ per minggu adalah batas minimum
Desainer memberi tahu saya bahwa mereka "tidak memiliki akses ke pelanggan." Ini hampir tidak pernah benar. Biasanya salah satu dari tiga masalah nyata:
- Mereka tidak pernah meminta CSM untuk membantu menghubungkan (lima menit pesan Slack)
- Mereka pikir mereka butuh izin PM untuk menjadwalkan percakapan (tidak perlu)
- Mereka khawatir terlihat menginjak wilayah PM (juga kesalahpahaman, dibahas di bawah)
Tiga percakapan pelanggan per minggu adalah batas minimum. Bukan batas atas. Survei desainer 2025 dari Pencil & Paper menempatkan median untuk desainer senior ke atas di lima wawancara per minggu selama discovery aktif. Tiga adalah minimum untuk bisa menyebut diri desainer discovery.
Cara benar-benar mencapainya:
- Kirim pesan ke CSM sekali. "Hei, saya sedang mencoba berbicara dengan 3 pelanggan per minggu tentang [area masalah]. Bisa bantu hubungkan?" Satu pesan itu menghasilkan wawancara untuk 6-8 minggu ke depan. CSM menyukainya karena pelanggan mereka merasa didengar.
- Ikuti panggilan yang sudah ada. Jika sales melakukan panggilan discovery atau CS melakukan QBR, minta untuk diam-diam mengikuti dua per minggu. Setengah wawancara lebih baik dari nol.
- DM 5 pelanggan di messenger dalam aplikasi. "Saya desainer yang bekerja pada X. Punya 15 menit minggu ini untuk menceritakan apa yang rusak?" Tingkat balasan mencapai 30-50% jika produk memiliki hubungan apa pun dengan pengguna.
- Ambil survei pasca-pembatalan. Ketika churn terjadi, formulir pembatalan adalah tambang emas. Baca semua mingguan. Tarik 5 keluhan paling jelas ke dalam pohon Anda.
Bank pertanyaan contoh, yang saya simpan di halaman Notion dan tarik untuk setiap wawancara:
- Ceritakan kapan terakhir kali Anda mencoba melakukan [tugas]. Apa yang terjadi?
- Di mana Anda tersangkut?
- Apa yang Anda coba sebelum produk ini? Mengapa itu tidak berhasil?
- Jika saya menghapus fitur ini besok, apa yang akan Anda lakukan sebagai gantinya?
- Apa yang harus terjadi agar Anda menggunakannya setiap hari?
- Siapa lagi di tim Anda yang menyentuh ini? Apa yang mereka lakukan secara berbeda?
- Apa bagian terburuk dari minggu Anda terkait [area masalah]?
- Ceritakan saat produk ini mengejutkan Anda (baik atau buruk).
- Jika Anda punya tongkat ajaib, apa yang akan Anda ubah?
- Apakah ada yang seharusnya saya tanyakan tapi tidak?
Perhatikan apa yang hilang: pertanyaan tentang desain Anda. Anda tidak bertanya "apakah Anda suka warna tombol ini." Anda bertanya tentang dunia mereka. Pertanyaan desain datang kemudian, dalam validasi prototipe.
Validasi berbasis prototipe: prototipe Selasa, insight Kamis
Setelah Anda memetakan peluang dan memiliki beberapa sketsa solusi, kirimkan prototipe sebelum spesifikasi difinalkan. Saya menjalankan jadwal yang saya sebut prototipe Selasa, insight Kamis.
Senin-Selasa: Bangun prototipe Figma dari 1-2 jalur paling menjanjikan. Tidak perlu sempurna secara piksel. Cukup fungsional untuk diklik. Maksimum 4-8 jam kerja.
Rabu: Kirim ke 5 pelanggan melalui Maze, UserTesting, atau hanya Loom + DM Slack yang berkata "klik-klik ini selama 5 menit dan beritahu saya apa yang Anda harapkan terjadi." Lima pengguna sudah cukup untuk mengungkap pola 80%; studi klasik Nielsen divalidasi ulang oleh Maze pada 2024.
Kamis: Sintesis. Tiga slide: apa yang berhasil, apa yang rusak, apa yang mengejutkan kita. Letakkan di channel PM.
Jumat: Perbarui dokumen 3 jalur dengan data prototipe. Sekarang serah terima Anda bukan "ini tiga opsi." Ini "ini tiga opsi, dan opsi B sudah diuji dengan lima pelanggan. Tiga menyelesaikan tugas, dua tersangkut di langkah yang sama. Ini rekaman-nya."
Itu mengubah percakapan. PM berdebat dengan pendapat. Mereka tidak berdebat dengan lima rekaman pelanggan yang tersangkut. Data prototipe mengubah Anda dari "desainer berpikir" ke "pelanggan berkata," dan itu adalah jenis otoritas yang berbeda.
Stack alat murah untuk ini:
- Maze: terbaik untuk uji prototipe kuantitatif tak termoderasi. Sekitar $99/bulan.
- UserTesting: terbaik untuk kualitatif termoderasi. Lebih mahal tapi sepadan untuk alur berisiko tinggi.
- Loom + DM Slack ke 5 pelanggan: gratis, efektif secara mengejutkan, hanya membutuhkan Anda benar-benar menekan kirim.
Intinya bukan alatnya. Intinya adalah Anda menguji sebelum spesifikasi dikunci. Itulah discovery. Apa pun setelah spesifikasi dikunci adalah poles eksekusi.
"Tapi Anda bukan PM": kesalahpahaman yang menjaga desainer tetap kecil
Setiap kali saya melatih desainer tentang hal ini, seseorang mengungkap ketakutan yang sama: "apakah PM saya tidak akan berpikir saya melampaui batas?"
Pekerjaan discovery tidak menjadikan Anda PM. Itu menjadikan Anda desainer yang lebih baik. Perbedaan itu nyata dan layak dipertahankan. PM memiliki keputusan tentang apa yang dibangun. Desainer memiliki input yang membentuk keputusan. Membawa bukti pelanggan, tiga opsi, dan data prototipe bukan mengambil pekerjaan PM. Itu melakukan pekerjaan Anda dengan kompeten.
Skrip yang berhasil, berdasarkan pengalaman saya:
Framing adversarial yang harus dihindari: "Saya tidak pikir kita harus membangun apa yang Anda spesifikasikan." (Anda menjadikannya tentang Anda vs mereka.)
Framing discovery yang berhasil: "Saya membuat sketsa tiga jalur sehingga kita bisa memilih bersama. Jalur C muncul dari percakapan dengan dua pelanggan yang menggambarkan masalah berbeda dari brief. Layak dilihat?"
Adversarial: "Spesifikasinya salah."
Discovery: "Saya menguji spesifikasinya dengan lima pengguna Selasa. Tiga tersangkut di langkah dua. Ini rekaman-nya. Apa pendapat Anda?"
Adversarial: "Saya harus berada di rapat roadmap."
Discovery: "Saya ingin membawa temuan wawancara pelanggan ke perencanaan roadmap. Mau saya siapkan ringkasan 5 menit untuk sesi berikutnya?"
Polanya: ubah pendapat menjadi artefak, ubah konfrontasi menjadi undangan. PM sebenarnya tidak ingin berkelahi dengan desainer. Mereka ingin lebih sedikit hal untuk dicari tahu sendiri. Datang dengan opsi, bukti, dan sikap "mari kita putuskan bersama," dan Anda adalah kolaborator paling mudah yang mereka miliki. Datang dengan "saya tidak setuju," dan Anda adalah yang paling sulit. Konten yang sama, framing yang berbeda, reputasi yang sepenuhnya berbeda.
Lacak kemenangan discovery Anda, atau mereka tidak ada
Inilah kebenaran pahit tentang ulasan kinerja di sebagian besar perusahaan produk: pengaruh yang tidak terdokumentasi tidak pernah terjadi. Anda akan bertemu desainer senior yang secara diam-diam membentuk tiga roadmap dalam satu kuartal, kemudian menyaksikan rekan kerja yang merilis dua peluncuran mencolok dipromosikan di depan mereka. Rekan kerja itu menceritakan sebuah kisah. Desainer senior tidak.
Simpan log discovery. Satu baris per kemenangan. Lima kolom:
| Tanggal | Spesifikasi / keputusan yang diubah | Bukti pelanggan | Hasil | Pengakuan PM |
|---|---|---|---|---|
| 2026-02-14 | Menghentikan desain ulang undangan kursi demi perbaikan kondisi kosong | 8 wawancara, 5 menyebut "terasa sepi" sebelum aktivasi | Aktivasi +9 poin dalam kohort uji | Thread Slack dengan Priya 15/2 |
| 2026-03-03 | Reframe alur penagihan menjadi 2 langkah alih-alih modal 1 langkah | Uji Maze, 5 pengguna, 3 keluar di langkah 1 dari satu langkah | Konversi +4 poin pasca-peluncuran | Catatan rapat roadmap 4/3 |
Tiga kolom bersifat deskriptif. Dua bersifat bukti. Kolom "pengakuan PM" penting: ini adalah tangkapan layar Slack, komentar Loom, pengeditan dokumen roadmap. Sesuatu yang bertanggal dan bisa dilacak. Ketika ulasan kinerja datang, Anda tidak merayu "saya pikir saya menambahkan nilai." Anda menunjukkan bukti.
Log ini butuh 5 menit per minggu untuk dikelola. Sebagian besar desainer tidak pernah memulainya. Yang melakukannya masuk ke ulasan kinerja dengan percakapan yang berbeda dari rekan-rekan mereka.
Pergeseran mekanik
Inilah yang ingin saya sampaikan. Pergeseran dari eksekusi ke discovery bukan perubahan kepribadian. Bukan tentang menjadi "lebih strategis," apa pun artinya. Ini mekanik. Anda mengubah empat artefak:
- Serahkan 3 jalur, bukan 1 desain
- Kelola pohon peluang-solusi yang Anda isi dengan wawancara
- Jalankan 3+ wawancara pelanggan per minggu, setiap minggu
- Jalankan loop prototipe Selasa, insight Kamis pada setiap alur yang bermakna
- Simpan log kemenangan discovery dan bawa ke ulasan kinerja
Lima artefak. Tidak ada yang membutuhkan perubahan gelar, izin manajer, atau pekerjaan baru. Anda bisa memulai semuanya hari Senin. Hubungan PM berubah sebagai efek samping, bukan karena Anda berbicara dengan PM tentangnya, tapi karena apa yang Anda taruh di meja mereka berubah.
Itulah seluruh permainannya.
Pelajari Lebih Lanjut

Principal Product Marketing Strategist
On this page
- Mengapa ini lebih penting dari dua tahun lalu
- Discovery vs eksekusi: pemisahan pola pikir yang sesungguhnya
- Aturan 3 jalur
- Pohon peluang-solusi, edisi desainer
- Ritme wawancara pelanggan: 3+ per minggu adalah batas minimum
- Validasi berbasis prototipe: prototipe Selasa, insight Kamis
- "Tapi Anda bukan PM": kesalahpahaman yang menjaga desainer tetap kecil
- Lacak kemenangan discovery Anda, atau mereka tidak ada
- Pergeseran mekanik
- Pelajari Lebih Lanjut