- Dalam diskusi roadmap produk, tim sales, marketing, R&D, dan penanggung jawab bisnis sama-sama membicarakan pelanggan, tetapi jika job yang membuat pelanggan “merekrut” produk itu terlewat, standar penilaian menjadi kabur
- Intuit terjebak dalam feature chase setelah mengikuti 150 permintaan fitur dari survei, dan tidak punya kompas untuk membedakan fitur mana yang benar-benar penting
- Dalam kasus milkshake, pertanyaan tentang rasa, harga, dan tekstur tidak meningkatkan penjualan, tetapi ketika situasi pembelian diamati, perjalanan panjang ke kantor dan rasa lapar para komuter pagi muncul sebagai job yang inti
- Bahkan untuk milkshake yang sama, pada pagi hari ia bersaing dengan bagel, protein bar, dan jus, sedangkan pada sore hari ia bersaing dengan pilihan camilan untuk anak, sehingga kriteria evaluasi dan produk pesaing menjadi berbeda
- Untuk menemukan job to be done, perlu mengamati masalah yang dekat, pilihan untuk tidak melakukan apa pun, perilaku jalan memutar, hal-hal yang ingin dihindari orang, dan penggunaan yang tidak lazim
Mengapa permintaan pelanggan tidak bisa menjadi kompas roadmap
- Dalam rapat roadmap, masukan pelanggan yang berbeda-beda masuk dari tiap departemen
- Tim sales merasa merekalah yang paling tahu kebutuhan paling mendesak karena terus berbicara dengan pelanggan
- Tim marketing melihat peluang membuat versi baru, rasa baru, warna baru, atau penawaran khusus dengan memanfaatkan brand yang ada
- Tim R&D fokus pada fitur dan manfaat yang lahir dari teknologi atau aplikasi baru
- Penanggung jawab bisnis menginginkan peluncuran yang membantu P&L sebelum akhir tahun
- Masing-masing pendekatan ada benarnya, tetapi bisa jatuh ke bias konfirmasi dengan hanya melihat informasi yang mendukung sudut pandangnya sendiri
- Masalah yang lebih besar adalah tidak satu pun model itu secara langsung mencerminkan job pelanggan
Intuit yang terjebak mengejar fitur
- Intuit menjalankan survei secara luas dengan menanyakan fitur baru yang diinginkan pelanggan, dan pelanggan memberikan daftar panjang fitur yang mereka harapkan
- Menurut Cook, yang saat itu menjadi CEO Intuit, pelanggan meminta “150 fitur”, dan tim pengembang berdebat selama berminggu-minggu tentang fitur mana yang lebih penting
- Semua anggota tim yakin pilihan mereka sesuai dengan keinginan pelanggan, tetapi sebenarnya mereka tidak punya standar penilaian
- Jika tidak memahami pekerjaan apa yang ingin pelanggan “pekerjakan” dari produk tersebut, sulit membedakan fitur yang tepat, dan Cook mengibaratkannya sebagai berlayar tanpa kompas
Mengapa penjualan milkshake tidak meningkat
- Sebuah jaringan fast-food memanggil pelanggan yang cocok dengan profil konsumen ideal untuk menanyakan cara menjual lebih banyak milkshake
- apakah harus lebih murah
- apakah harus lebih banyak potongan
- apakah harus lebih kenyal untuk dikunyah
- apakah rasa cokelatnya harus lebih kuat
- Pelanggan memang mengatakan apa yang mereka inginkan, tetapi tidak jelas apa yang harus dilakukan berdasarkan jawaban itu
- Jaringan tersebut mencoba berbagai hal sesuai umpan balik pelanggan, tetapi beberapa bulan kemudian tidak ada perubahan penjualan pada kategori milkshake
Job milkshake pagi yang terungkap lewat observasi
- Pertanyaannya diubah menjadi “untuk menyelesaikan pekerjaan apa orang datang ke restoran ini dan merekrut milkshake”
- Tim mengamati pelanggan di toko selama 18 jam sehari
- kapan mereka membeli milkshake
- pakaian apa yang mereka kenakan
- apakah mereka datang sendirian
- apakah mereka membeli makanan lain juga
- apakah mereka meminumnya di toko atau pergi dengan mobil
- Sebelum pukul 9 pagi, milkshake terjual banyak, dan pembelinya umumnya datang sendirian, hanya membeli milkshake, lalu pergi dengan mobil
- Job yang sama pada pelanggan pagi adalah bertahan melewati perjalanan panjang dan membosankan ke kantor serta menghindari rasa lapar di pertengahan pagi
- Ada alternatif pesaing, tetapi tidak ada yang sempurna
- pisang habis terlalu cepat sehingga lapar datang lagi di pertengahan pagi
- donat meninggalkan remah dan membuat jari lengket, sehingga pakaian dan setir mobil jadi kotor
- bagel sering terasa kering dan kurang enak, dan ada masalah harus mengoleskan cream cheese atau selai sambil mengemudi
- Milkshake membuat waktu terasa terisi karena minuman kental itu harus diminum lama melalui sedotan kecil, membuat kenyang sepanjang pagi, dan muat di cup holder
Produk yang sama pun menghadapi persaingan berbeda tergantung waktunya
- Orang merekrut milkshake untuk job yang berbeda dalam dua situasi berbeda sepanjang hari
- Milkshake pagi bersaing dengan bagel, protein bar, dan botol jus segar
- Milkshake sore bersaing dengan pilihan mampir ke toko mainan untuk anak atau pulang lebih awal untuk bermain basket
- Bahkan untuk produk yang sama, jika job-nya berbeda maka produk pesaing dan kriteria evaluasinya juga berubah
Lima petunjuk untuk menemukan Job to be done
-
1. Temukan job yang dekat dengan Anda
- Bahkan di dunia yang berpusat pada data, sebagian inovasi besar berawal dari intuisi tentang Job to be done
- Khan Academy dimulai dari keinginan Sal Khan membantu sepupunya belajar matematika tanpa stres, dan ternyata banyak orang merasakan kesulitan yang sama
-
2. Bersaing dengan pilihan untuk tidak melakukan apa pun
- Jika konsumen tidak menemukan solusi yang memuaskan job mereka, mereka bisa memilih untuk tidak melakukan apa pun
- Perusahaan tidak hanya perlu melihat cara merebut pangsa dari pesaing yang ada, tetapi juga melihat di mana permintaan yang tak terlihat berada
- Menurut Chip Conley, kepala global hospitality dan strategi Airbnb, 40% “tamu” Airbnb menjawab bahwa tanpa Airbnb mereka tidak akan bepergian atau akan tinggal bersama keluarga
-
3. Lihat perilaku jalan memutar dan perilaku kompensasi
- OpenTable lahir dari perilaku jalan memutar lama seputar reservasi restoran
- Setelah menyamakan waktu yang memungkinkan dengan teman-teman lalu menelepon restoran, jika ternyata tidak ada meja, orang harus menghubungi teman-temannya lagi dan mengulangi proses mencari restoran lain
- OpenTable menyelesaikan job reservasi ini
-
4. Temukan hal-hal yang tidak ingin dilakukan orang
- Clayton Christensen menyebutnya negative jobs, dan job negatif bisa menjadi peluang inovasi yang baik
- Alumni Harvard Business School Rick Krieger dan para mitranya memulai QuickMedx setelah menunggu berjam-jam di UGD untuk tes radang tenggorokan putra mereka, dan ini kemudian menjadi cikal bakal CVS MinuteClinics
- CVS MinuteClinic langsung melayani pasien tanpa janji, dan perawat profesional dapat meresepkan obat untuk penyakit sehari-hari seperti konjungtivitis, infeksi telinga, dan radang tenggorokan
- Karena banyak orang tidak ingin pergi ke dokter jika memang tidak perlu, MinuteClinic kemudian hadir di lebih dari 1.000 lokasi di 33 negara bagian di dalam toko farmasi CVS
-
5. Lihat penggunaan yang tidak lazim
- Jika orang sendiri menciptakan perilaku jalan memutar atau perilaku kompensasi untuk menyelesaikan suatu pekerjaan, itu bisa menjadi sinyal bahwa job tersebut penting dan frustrasi terhadap solusi yang ada juga besar
- Situasi seperti ini bisa mengarah pada peluang inovasi berpotensi tinggi
Pertanyaan yang lebih baik
- W. Edwards Deming berkata, “Jika Anda tidak tahu cara mengajukan pertanyaan yang tepat, Anda tidak akan menemukan apa pun”
- Pertanyaan yang lebih baik bukanlah menanyakan apa yang diinginkan pelanggan, melainkan “untuk pekerjaan apa mereka merekrut produk itu”
1 komentar
Pendapat di Hacker News
Kesalahan klasik dalam manajemen produk umumnya berawal dari asumsi bahwa pengguna tahu kebutuhan mereka sendiri. Kenyataannya, itu jarang terjadi, dan memahami kebutuhan yang sebenarnya adalah tugas pihak produk
Sampai orang benar-benar menggunakannya, tidak ada bukti bahwa apa yang sedang dibuat adalah sesuatu yang diinginkan pengguna, dan sesuatu yang diminta pengguna juga tidak boleh langsung dianggap sebagai kebutuhan
Meski tim sales mengatakan “kalau kita tidak membuat X, kontrak tidak akan bisa ditutup”, bisa saja setelah X dibuat tidak ada perbedaan apa pun. Penyebabnya adalah analisis dari sisi sales yang keliru
Khususnya untuk produk baru, pengguna tidak akan memintanya lebih dulu, jadi perlu dijelaskan dan ditunjukkan; contoh “ketika mobil pertama kali muncul, pelanggan menginginkan kuda yang lebih cepat” termasuk di sini
Kalau seseorang meminta sesuatu, alasannya harus digali. Jika pergi ke bengkel dan meminta alternator diganti, lalu mereka langsung menggantinya, ketidakpuasan bisa tetap ada; tetapi ketika ditanya “mengapa harus diganti”, ternyata masalahnya ada pada solenoid, dan memperbaikinya menyelesaikan tujuan sebenarnya, yaitu bisa bergerak
Karena itu developer senior sering kali menunjukkan insting produk yang lebih baik daripada product manager. Orang yang baru 1–2 tahun menjadi developer, lalu mengambil sertifikasi dan pindah ke peran produk, sulit mengalahkan kedalaman pengalaman seorang veteran
Apa pun asumsinya, jika tidak berdialog dan menggali, keputusan yang diambil akan menjadi suboptimal
Saya sepenuhnya setuju bahwa riset pengguna berguna untuk memahami area masalah dan ruang fitur, tetapi dalam praktiknya saya jauh lebih sering melihat orang yang membuat Segway daripada penemu mobil
Banyak yang membuat sesuatu berdasarkan intuisi founder atau riset pengguna yang buruk, lalu dengan enteng mengabaikan permintaan pelanggan sebagai “kuda yang lebih cepat”. Saya tidak punya waktu, energi, maupun kemauan untuk beradaptasi dengan workflow kustom tambahan yang dibuat dengan asumsi bahwa saya tidak memahami bidang kerja saya sendiri
Pasti ada perbedaan antara B2C dan B2B, tetapi ketika nasihat semacam ini diterapkan, saya hampir tidak pernah melihat pembedaan itu. Saya tahu maksudnya bukan mengabaikan feedback pengguna, tetapi saya terlalu sering melihatnya ditafsirkan begitu, jadi kita perlu analogi baru
Tentu saja jangan diterima mentah-mentah, tetapi mengamati perilaku pengguna sering kali memberi insight lebih banyak daripada bertanya apa yang mereka inginkan. Namun lingkungan observasinya harus dirancang dengan baik agar jelas apa yang ingin dipelajari
Misalnya, “harus bisa berjalan-jalan di dalam pesawat luar angkasa, dan setelah tabrakan mikrometeorit bisa melakukan spacewalk untuk memperbaiki lambung kapal”
Sebaliknya, perusahaan atau developer juga sering menerapkan logika ini secara berlebihan, lalu menyalahkan pemain yang tidak menikmati game mereka seolah-olah pemainnya yang salah
Karena sales paling banyak berhubungan dengan pengguna, product manager biasanya mudah mengikuti saja apa yang mereka katakan
Kalau banyak menangani dukungan lewat email, sering terlihat kasus XY problem yang menyamar sebagai permintaan fitur. https://en.m.wikipedia.org/wiki/XY_problem
Seseorang meminta sebuah fitur, dan biasanya fitur itu mudah ditambahkan, tetapi saya berusaha memahami masalah dasarnya dulu. Pelanggan sering tidak menyampaikan masalahnya, melainkan solusi versi mereka sendiri, dan solusi itu bisa merupakan pendekatan yang buruk atau bahkan sama sekali keliru
Agar fitur bisa ditambahkan dengan elegan, didokumentasikan, dan berguna juga bagi orang lain, kita harus memahami rasa sakit sebenarnya yang ingin diselesaikannya
“Temukan rasa sakit dan hilangkan” juga merupakan teknik penjualan yang kuat. Kadang fitur ditambahkan bukan karena rasa sakit pelanggan, melainkan karena rasa sakit internal tim sales; fitur yang tidak akan dipakai pelanggan sungguhan bisa masuk hanya karena pengambil keputusan menganggapnya penting dan demonya terlihat bagus
Terutama saat mengganti software legacy, selalu ada tekanan untuk memindahkan juga berbagai hal remeh-temeh yang kemungkinan besar sudah tidak dipakai lagi dan biaya pembuatannya lebih besar daripada nilainya
Misalnya, ada orang bisnis yang tidak bisa melepaskan pembuatan laporan yang sebenarnya tidak dibaca siapa pun
Artikelnya bagus, tetapi saya benar-benar tidak suka judulnya. Ada banyak hal yang harus ditanyakan kepada pelanggan, tetapi sangat sedikit yang boleh diterima mentah-mentah
Mengimplementasikan begitu saja fitur yang diminta pelanggan adalah jalan pintas menuju kegagalan, dan kita harus terus bertanya serta menggali lebih jauh melampaui “tolong buat saya bisa melakukan X”
Agar adil, artikelnya sebenarnya mengatakan hal itu juga, tetapi saya sudah lelah dengan judul yang klise
Saya setuju dengan rekomendasi Christensen dan Deming, dan ingin menambahkan Sidney Dekker. Khususnya "Field Guide to Human Error" bagus, dan buku-bukunya yang lain sepertinya juga layak
Salah satu cara terbaik untuk memvalidasi apakah sebuah solusi nyata dan bisa dijual ke pelanggan adalah bertanya “apakah Anda akan membeli ini sekarang?” Jika jawabannya “ya, kirim invoice dan mari proses pesanannya”, berarti ada sesuatu yang sudah tervalidasi
Sebaliknya, jika responsnya seperti “hmm, mungkin, saya akan bicara dulu dengan komite pembelian”, berarti masih belum jelas arahnya
Walaupun produknya belum siap sehingga belum bisa sampai ke penjualan nyata, seperti yang dikatakan Steve Blank, pertanyaan bisa dilanjutkan dengan “apakah Anda akan membayar satu juta dolar sekarang?”, “kalau begitu, berapa yang akan Anda bayar?”, “kalau kami berikan gratis, apakah Anda akan langsung mengadopsinya?” Jawaban-jawaban seperti ini menunjukkan posisi produk itu sebenarnya di mata pelanggan
https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
Berdasarkan pengalaman, pelanggan tidak tahu apa yang mereka inginkan. Karena itu ada alasan mengapa pendiri ingin membuat sesuatu yang bisa menyelesaikan masalah itu dengan lebih baik
Saya benar-benar tidak suka nasihat “jangan membuat sebelum memvalidasi”. Bagi saya, itu secara harfiah tidak pernah berhasil sekali pun, dan rasanya seperti mengajukan pertanyaan yang menggiring sambil menembak kaki sendiri
Harus ada keyakinan tentang mengapa mengerjakan hal ini. Jika Anda terjun ke industri yang sama sekali tidak Anda pahami, peluang gagal 99%. Jika Anda tahu apa yang Anda lakukan, peluang sukses semestinya di atas 60%
Produk yang membuat orang langsung paham bahwa masalahnya terpecahkan itu mudah dijual. Karena Anda pernah mengalami masalah yang sama, lalu berusaha memecahkannya
Karena itu saya rasa banyak situs yang mengutamakan validasi sengaja membuat penjelasan solusinya samar
Dengan kata lain, Anda sendiri adalah pelanggan arketipe
Kutipan klise “kalau Henry Ford bertanya kepada orang-orang apa yang mereka inginkan, mereka akan bilang kuda yang lebih cepat” bukan menjadi klise tanpa alasan. Kebanyakan orang tidak tahu apa yang mereka inginkan, dan karena itulah perancang produk yang bagus dibayar mahal
Yang perlu dibedakan adalah visi produk dan cara mendengarkan umpan balik
Tidak ada trik ajaib dalam merancang produk baru yang menyelesaikan masalah orang; itu adalah keterampilan yang memadukan pengalaman, intuisi, pemahaman teknologi, pengamatan terhadap alternatif yang ada, serta prediksi perubahan teknis/ekonomi/sosial
Sebaliknya, mendengarkan umpan balik adalah memastikan apakah rancangan bekerja sesuai niat, apa yang membuat pengguna bingung, dan apa saja hambatannya. Di sini, metode klasik seperti observasi pengguna, pengujian, dan survei berguna
Kelihatannya mudah, tetapi sama sekali tidak. Saya sudah melihat banyak desainer yang tidak mau melenturkan prinsip meski realitas bertabrakan dengan ideologi, serta perusahaan yang entah kenapa tidak memperbaiki bug yang dialami sebagian besar pengguna dan memicu kemarahan di forum dukungan serta media sosial
Kedua keterampilan itu sangat berbeda, dan menguasai salah satunya saja sulit, apalagi keduanya. Tulisan itu memakai Intuit sebagai contoh, tetapi dinamika bisnis yang benar-benar hebat—melobi pemerintah agar racun tetap ada sambil menjual penawarnya—diserahkan kepada pembaca
Pelanggan ingin mengurangi rasa sakit saat melaporkan pajak, tetapi Intuit melobi pemerintah agar rasa sakit itu tetap kuat
Sejarah produk kami telah melewati seluruh spektrum ini
Pada awalnya, kami hanya peduli pada bagaimana bank-bank sebagai pelanggan memandang bisnis mereka, dan bagaimana produk kami bisa memperbaikinya. Kami cepat menumpuk ide tanpa tahu apa yang kami lakukan, dan kelabakan menyesuaikan diri bahkan dengan kemauan kecil pelanggan. Kami merasa tidak pantas mendapatkan bisnis mereka
Di tengah perjalanan, hasil mulai terlihat, dan kami sadar bahwa jika kami membangun produk untuk memuaskan lebih dari 10 pelanggan masing-masing dengan cara yang mereka inginkan, pada akhirnya tidak akan ada yang tersisa
Sekarang produk kami lebih mirip paket konsultasi turnkey daripada perangkat lunak atau teknologi tertentu. Pelanggan kini meminta panduan kepada kami tentang bagaimana menjalankan bisnis mereka. Begitu Anda mengemudikan bus seperti ini, Anda bisa menstandardisasi software stack dengan jauh lebih percaya diri. Belakangan, kata “membosankan” masuk ke kosakata kami
Hal menarik dari kelompok pelanggan kami adalah mereka punya kecenderungan kuat untuk bergerak berkelompok. Jika Anda bisa membuat beberapa pihak bergerak ke arah tertentu, sisanya bisa dibuat mengikuti hampir tanpa usaha. Saya rasa ini bukan cerita yang hanya berlaku untuk bankir yang cenderung menghindari risiko
Jebakan umum yang luput dari tulisan itu adalah mendengarkan minoritas pelanggan yang paling bersuara
Jika hanya membaca Hacker News atau platform lain yang ramah teknologi, tidak aneh jika Anda mengira ada permintaan besar untuk iPhone berlayar kecil tetapi bertenaga
Kenyataannya, penjualan iPhone mini mengecewakan. Artinya, orang-orang yang lama menulis online tentang hardware teknologi tidak mewakili seluruh basis pelanggan iPhone
Rasio yang rendah bukan berarti jumlah unit yang dikirim rendah
Secara realistis, perusahaan apa pun yang Anda bangun kemungkinan besar akan menjual jauh lebih sedikit daripada iPhone Mini. Kalau begitu, karena penjualannya mengecewakan menurut standar Apple, apakah harus dipecat dan bangkrut? Apakah semua perusahaan yang menjual kurang dari 20 juta unit harus dilikuidasi? Apakah perusahaan yang menargetkan basis pelanggan lebih kecil daripada pengiriman iPhone kecil tidak boleh ada dan harus digantikan oleh produk rata-rata untuk orang rata-rata? Apakah Mac Studio, layar XDR, dan MacBook 15 inci seharga 4.000 dolar juga harus hilang?
Saya mengenal beberapa orang yang sangat puas dengan iPhone mini, dan kini tidak ada lagi perangkat yang bisa mereka upgrade. Meski begitu, pilihan ini memang lebih murah
Kalau orang bisa menyelesaikan masalahnya sendiri, mereka tidak akan membayar
Untuk melakukan sesuatu dengan komputer memang dibutuhkan kemampuan teknis tertentu, tetapi kebanyakan bisa diselesaikan dengan mengikuti aturan dan menggunakan Excel secara kreatif
Nilai muncul dari memberi orang framework untuk memecahkan masalah, memikirkan untuk mereka sampai ke kasus-kasus pengecualian yang belum terpikirkan, lalu mengompilasi sistem aturan itu menjadi program
Lucunya, menanyakan kepada pelanggan apa yang tidak mereka inginkan justru benar-benar berhasil
Menanyakan kepada pelanggan apa yang mereka inginkan mirip dengan desain ala komite. Yang diinginkan orang adalah bentuk yang mengurangi beberapa hal dari visi yang tertata rapi dan konsisten secara internal, yang dibuat oleh satu seniman