Program Studi Bisnis Digital • FEB

Pengembangan Produk

Pertemuan 5 — Memahami dan Memecahkan Masalah Konsumen

Dari ide yang mengambang menjadi masalah konsumen yang jelas, terukur, dan siap dijawab dengan konsep produk.

RPS MINGGU 5 • 2×50 MENIT

Selamat datang kembali di mata kuliah Pengembangan Produk. Pada tiga pertemuan lalu Anda sudah belajar tentang Product Innovation Charter sebagai kompas strategis, lalu bagaimana ide-ide baru digali secara kreatif. Hari ini kita masuk ke langkah yang sering dilompati oleh tim produk pemula: benar-benar memahami masalah konsumen sebelum buru-buru membuat solusi. Bayangkan tim yang membangun aplikasi keuangan canggih untuk UMKM, tetapi ternyata pemilik warung hanya butuh cara mencatat utang pelanggan dengan cepat lewat HP — itu contoh nyata kegagalan memahami masalah. Sepanjang dua jam ke depan, Anda akan belajar membedakan masalah asli dari gejala permukaan, menggali masalah lewat wawancara dan observasi, serta mengubah keluhan mentah menjadi pernyataan masalah yang bisa diukur dan diprioritaskan.

Bagian 1 dari 3

Mengapa Masalah Konsumen adalah Titik Awal NPD

Sebelum bicara solusi, tim produk yang baik lebih dulu memastikan mereka mengerti masalah yang sebenarnya dialami konsumen.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu mengidentifikasi dan memecahkan masalah bisnis digital melalui analisis kebutuhan pelanggan secara kreatif (Sub-CPMK minggu 5). Secara rinci:

MEMBEDAKAN

Gejala

vs. akar masalah konsumen

Mampu memisahkan keluhan permukaan dari kebutuhan yang sesungguhnya mendasarinya.

MENERAPKAN

Teknik Gali

wawancara, observasi, JTBD

Mampu memakai teknik kualitatif untuk menggali masalah konsumen secara sistematis.

MENGUKUR

Prioritas

severity × frekuensi × reach

Mampu menghitung skor prioritas masalah agar tim tidak mengejar semua masalah sekaligus.

MERUMUSKAN

Problem Statement

siap dibawa ke tahap konsep

Mampu menulis pernyataan masalah yang jelas sebagai jembatan ke perumusan konsep produk minggu depan.

Posisi Hari Ini dalam Proses NPD

Kerangka Crawford & Di Benedetto membagi pengembangan produk baru (New Product Development/NPD) jadi tahap berurutan. Memahami masalah konsumen adalah jembatan dari ide mentah ke konsep produk yang terarah.

Dua Cara Memulai: Solution-First vs Problem-First

Problem-based concept generation berarti tim memulai dari masalah yang tervalidasi, baru mencari solusi — bukan sebaliknya.

Solution-First (berisiko)

Mulai dari "kita bisa bikin fitur X"
Validasi masalah dilakukan belakangan, kalau sempat
Contoh: aplikasi fintech lokal meluncurkan fitur investasi mikro rumit, padahal pengguna baru butuh cara menabung sederhana

Problem-First (dianjurkan)

Mulai dari "konsumen mana yang kesulitan apa"
Masalah digali & diukur dulu sebelum konsep dirancang
Contoh: GoFood lahir dari masalah nyata — UMKM kuliner sulit menjangkau pelanggan tanpa modal pemasaran besar

Jebakan umum: tim jatuh cinta pada solusi favoritnya sendiri, lalu mencari-cari masalah yang "pas" untuk membenarkannya. Urutannya harus dibalik.

Sekarang bandingkan dua cara memulai pengembangan produk ini. Jalur solution-first terdengar cepat dan seru karena tim langsung bicara fitur, tetapi risikonya besar: mereka membangun sesuatu yang canggih namun tidak ada yang benar-benar membutuhkannya. Jalur problem-first lebih lambat di awal karena tim harus turun ke lapangan dulu, tetapi jauh lebih aman karena setiap keputusan desain nanti berpijak pada bukti. Contoh GoFood yang saya sebutkan nyata terjadi: masalahnya jelas, yaitu pedagang kuliner rumahan kesulitan dikenal pelanggan baru, dan solusinya dirancang persis untuk masalah itu. Callout peringatan di slide ini penting sekali Anda camkan, karena ini kesalahan paling sering saya lihat pada proyek akhir mahasiswa: jatuh cinta pada ide sendiri lalu mencari pembenaran, bukan mencari masalah nyata terlebih dahulu.

Kebutuhan Terucap vs Kebutuhan Tersembunyi

Konsumen sering hanya mampu mengucapkan gejala, bukan akar kebutuhannya. Ini disebut perbedaan expressed needs (kebutuhan terucap) dan latent needs (kebutuhan tersembunyi/laten — kebutuhan yang belum disadari konsumen sendiri).

EXPRESSED NEED

"Ingin Bor"

apa yang diucapkan konsumen

Konsumen ke toko bangunan dan minta dibelikan bor listrik yang bagus.

LATENT NEED

"Ingin Lubang"

apa yang sebenarnya dibutuhkan

Yang benar-benar dibutuhkan hanyalah lubang rapi di dinding — bor cuma alat perantara.

Konteks lokal: pelanggan UMKM sering "minta diskon" (expressed) padahal kebutuhan aslinya adalah kepastian arus kas (latent) — harga tetap boleh sama asal pembayaran fleksibel.

Studi Kasus: Ketika Solusi Mencari Masalah

Kasus Google Glass (2013–2015)

Teknologi kacamata pintar canggih dari sisi rekayasa
Tim tidak pernah memvalidasi: masalah konsumen sehari-hari apa yang benar-benar diselesaikan?
Konsumen justru khawatir soal privasi & kegunaan tidak jelas — produk ditarik dari pasar konsumen umum

Pelajaran untuk Bisnis Digital Indonesia

Sebelum membangun fitur "canggih", tanyakan: masalah siapa, seberapa sering, seberapa mengganggu?
Startup yang bertahan (Tokopedia, Ruangguru) besar karena masalah yang mereka pecahkan nyata & terverifikasi lewat riset pengguna, bukan asumsi tim

Hitung dari Nol: Skor Prioritas Masalah

Tim produk dompet digital menggali keluhan "sulit membagi tagihan bersama teman" (fitur split bill) lewat wawancara 20 pengguna & survei 500 responden.

Langkah	Perhitungan	Nilai
1. Severity — rata-rata skor gangguan (skala 1–5) dari 20 wawancara	jumlah skor wawancara ÷ 20	4
2. Frequency — median 8×/bulan, dinormalisasi ke skala 1–5 (acuan maks 10×/bulan)	8 ÷ 10 × 5	4
3. Reach — persentase responden survei yang mengalami masalah ini	310 ÷ 500 × 100%	62%
4. Skor Prioritas = Severity × Frequency × Reach	4 × 4 × 0,62	9,92

SKOR PRIORITAS MASALAH

9,92

dari skala maksimum 25 (5×5×100%)

Sekarang kita hitung bersama sebuah skor prioritas masalah, salah satu alat paling praktis untuk memutuskan masalah mana yang dikerjakan tim lebih dulu. Langkah pertama, severity, kita dapat dari rata-rata tingkat gangguan yang dilaporkan dalam dua puluh wawancara mendalam, hasilnya 4 dari skala 5. Langkah kedua, frequency, kita normalisasi dari data median delapan kali kejadian per bulan menjadi skala yang sama, hasilnya juga 4. Langkah ketiga, reach, kita hitung dari survei kuantitatif ke lima ratus responden, di mana tiga ratus sepuluh orang mengaku mengalami masalah ini, sehingga hasilnya 62 persen. Terakhir kita kalikan ketiganya menjadi skor akhir 9,92 dari skala maksimum 25. Angka ini bukan sekadar pajangan — ia dipakai untuk membandingkan masalah split bill dengan masalah lain yang mungkin skornya cuma 3 atau 4, sehingga tim tahu mana yang harus dikerjakan lebih dulu.

Coba Sendiri: Hitung Skor Prioritas Masalah

Ubah nilai severity, frequency, dan reach untuk masalah pilihan Anda, lalu lihat skor prioritas akhirnya naik-turun secara langsung.

Bagian 2 dari 3

Menggali & Memahami Masalah Konsumen

Setelah tahu mengapa masalah penting, saatnya belajar teknik konkret untuk menggalinya di lapangan.

Kerangka Jobs-to-be-Done (JTBD)

Konsumen tidak membeli produk — mereka "mempekerjakan" produk untuk menyelesaikan sebuah tugas dalam hidupnya (Jobs-to-be-Done/JTBD).

Job = Situasi + Motivasi + Hasil yang Diinginkan

Contoh Klasik: Milkshake

Situasi: perjalanan pagi ke kantor yang membosankan
Motivasi: butuh sesuatu yang mengenyangkan & bisa dinikmati sambil menyetir
Job: "temani perjalanan pagi saya", bukan sekadar "saya lapar"

Contoh Lokal: Ojek Online

Situasi: jam sibuk, jalanan macet, rapat harus tepat waktu
Motivasi: hindari stres & ketidakpastian waktu tempuh
Job: "pastikan saya tiba tepat waktu tanpa cemas", bukan sekadar "saya butuh transportasi"

Kerangka Jobs-to-be-Done ini mengubah cara kita bertanya soal konsumen. Alih-alih bertanya "siapa target pasar saya", kita bertanya "tugas apa yang sedang ingin diselesaikan konsumen ketika mereka mempekerjakan produk saya". Contoh milkshake dari peneliti Clayton Christensen sangat terkenal: perusahaan itu awalnya bingung kenapa milkshake laris di pagi hari, sampai mereka sadar konsumen sebenarnya "mempekerjakan" milkshake untuk menemani perjalanan membosankan ke kantor, bukan sekadar rasa lapar. Di konteks kita, ketika seseorang membuka aplikasi ojek online saat jam sibuk, job yang sebenarnya bukan "saya butuh kendaraan", melainkan "saya ingin kepastian waktu tiba supaya tidak cemas". Perhatikan bedanya: kalau Anda hanya fokus pada job permukaan, Anda akan merancang fitur pemesanan kendaraan; kalau Anda paham job sesungguhnya, Anda akan merancang fitur estimasi waktu yang akurat dan notifikasi proaktif.

Tiga Teknik Menggali Masalah secara Kualitatif

Wawancara Mendalam

Tanya pengalaman nyata, bukan pendapat hipotetis
"Ceritakan terakhir kali Anda mengalami ini"
Hindari pertanyaan menggiring jawaban

Observasi Kontekstual

Amati konsumen memakai produk di lingkungan aslinya
Menangkap masalah yang tak disadari konsumen sendiri
Contoh: amati pedagang pasar mencatat utang di buku kecil

Empathy Map

Petakan: Say, Think, Do, Feel konsumen
Menyatukan data kualitatif jadi satu gambaran utuh
Dikerjakan tim bersama setelah sesi wawancara/observasi

Empathy map (peta empati) adalah alat visual untuk merangkum apa yang konsumen katakan, pikirkan, lakukan, dan rasakan — membantu tim melihat pola dari banyak wawancara sekaligus.

Ketiga teknik ini biasanya dipakai berurutan dalam satu proyek riset pengguna. Wawancara mendalam memberi Anda cerita dan konteks langsung dari mulut konsumen, tetapi hati-hati: orang sering tidak akurat menjelaskan perilakunya sendiri, jadi selalu minta cerita kejadian nyata, bukan opini umum. Observasi kontekstual melengkapi kelemahan itu, karena Anda melihat langsung apa yang sebenarnya dilakukan konsumen, misalnya mengamati pedagang pasar tradisional yang masih mencatat utang pelanggan di buku kecil meski smartphone mereka sudah mendukung aplikasi kasir digital. Terakhir, empathy map membantu tim merangkum semua temuan wawancara dan observasi itu ke satu kanvas visual, sehingga anggota tim yang tidak ikut turun lapangan pun bisa memahami konsumen dengan cepat. Untuk proyek akhir Anda, saya sarankan lakukan minimal lima wawancara dan satu sesi observasi sebelum menyimpulkan apa pun.

Teknik "5 Whys": Menembus ke Akar Masalah

Kasus: "Mengapa UMKM kuliner tidak mau memakai pembukuan digital?"

Tahap	Pertanyaan & Jawaban
Why #1	Kenapa tidak pakai pembukuan digital? → "Ribet, harus input satu-satu"
Why #2	Kenapa terasa ribet? → "Tidak ada waktu di sela melayani pembeli"
Why #3	Kenapa tidak ada waktu? → "Transaksi ramai justru saat jam makan siang"
Why #4	Kenapa harus dicatat manual saat itu juga? → "Takut lupa kalau ditunda"
Why #5 (akar masalah)	Kenapa takut lupa? → Tidak ada cara mencatat otomatis tanpa mengganggu proses melayani pembeli

Akar masalah bukan "UMKM anti-teknologi", melainkan pencatatan yang mengganggu alur kerja di jam sibuk — ini yang harus dijawab konsep produk, bukan sekadar "tambah tombol input cepat".

Teknik lima mengapa ini sederhana tapi sangat ampuh untuk menembus gejala permukaan. Perhatikan bagaimana jawaban pertama, "ribet", terdengar seperti keluhan umum yang mudah diabaikan tim produk. Tapi kalau kita terus bertanya mengapa, kita sampai pada akar masalah yang jauh lebih spesifik dan bisa ditindaklanjuti: pedagang butuh cara mencatat transaksi yang tidak mengganggu mereka saat sedang sibuk melayani pembeli di jam makan siang. Ini slide tanpa animasi bertahap karena saya ingin Anda melihat keseluruhan rangkaian sekaligus, persis seperti sesi lima mengapa yang sesungguhnya di lapangan — Anda perlu melihat benang merah dari pertanyaan pertama sampai kelima. Bandingkan dua solusi yang mungkin muncul: kalau tim berhenti di why pertama, mereka membuat aplikasi pembukuan yang "lebih sederhana" tapi tetap mengganggu; kalau mereka sampai ke why kelima, mereka bisa merancang pencatatan otomatis lewat notifikasi atau pemindaian struk singkat.

Voice of Customer (VOC): dari Keluhan ke Kebutuhan

Voice of Customer (VOC) adalah proses menerjemahkan kata-kata mentah konsumen menjadi pernyataan kebutuhan yang terstruktur — fondasi untuk QFD (Quality Function Deployment) di pertemuan mendatang.

Kata Mentah Konsumen	Kebutuhan Terstruktur (VOC)
"Aplikasinya lama banget pas jam ramai"	Waktu muat halaman tetap cepat pada beban tinggi
"Saya bingung uang saya kepakai ke mana"	Riwayat transaksi mudah ditelusuri & dikategorikan
"Kalau salah kirim uang, ribet banget urusnya"	Ada konfirmasi & pembatalan sebelum transaksi final

VOC yang baik ditulis sebagai kebutuhan yang dapat diuji, bukan solusi — "waktu muat cepat" benar, "tambahkan server baru" salah (itu sudah solusi, bukan kebutuhan).

Voice of Customer adalah jembatan penting antara riset kualitatif yang kita lakukan hari ini dengan teknik Quality Function Deployment yang akan Anda pelajari beberapa pertemuan mendatang. Intinya sederhana: setiap kali konsumen mengeluh dengan bahasa sehari-hari, tugas tim produk adalah menerjemahkannya menjadi pernyataan kebutuhan yang jelas dan bisa diuji. Perhatikan tiga contoh di tabel ini, semuanya diambil dari pola keluhan nyata pengguna aplikasi dompet digital dan e-commerce di Indonesia. Poin paling penting ada di callout: kebutuhan terstruktur harus berhenti di level "apa yang dibutuhkan", bukan sudah melompat ke "bagaimana cara menyelesaikannya". Kalau Anda menulis "tambahkan server baru" sebagai kebutuhan, Anda sudah memaksakan satu solusi tertentu padahal mungkin ada cara lain yang lebih murah untuk mencapai kecepatan yang sama.

Hitung dari Nol: Net Problem Score dari Survei

Survei ke 400 pemilik UMKM pengguna aplikasi kasir digital tentang masalah "laporan keuangan sulit dipahami".

Langkah	Perhitungan	Nilai
1. % Sangat bermasalah (180 dari 400 responden)	180 ÷ 400 × 100%	45%
2. % Cukup bermasalah (120 dari 400 responden)	120 ÷ 400 × 100%	30%
3. % Tidak bermasalah (100 dari 400 responden)	100 ÷ 400 × 100%	25%
4. Net Problem Score = (%Sangat + %Cukup) − %Tidak	(45% + 30%) − 25%	50

NET PROBLEM SCORE

skor positif tinggi → masalah nyata & layak diprioritaskan

Kalau slide sebelumnya menghitung prioritas satu masalah lewat wawancara, sekarang kita hitung skor serupa dari data survei berskala lebih besar, meniru logika Net Promoter Score yang mungkin sudah Anda kenal dari mata kuliah pemasaran. Dari empat ratus responden, seratus delapan puluh orang menyatakan sangat bermasalah, seratus dua puluh cukup bermasalah, dan seratus sisanya tidak bermasalah — coba jumlahkan, seratus delapan puluh tambah seratus dua puluh tambah seratus sama dengan empat ratus, pas dengan total responden. Kita ubah masing-masing jadi persentase, lalu net problem score dihitung dengan menjumlahkan kelompok yang bermasalah dan mengurangi kelompok yang tidak bermasalah, hasilnya 50. Angka positif dan cukup tinggi ini artinya masalah laporan keuangan yang sulit dipahami benar-benar nyata dan layak masuk prioritas tinggi tim produk, bukan sekadar keluhan segelintir orang.

Coba Sendiri: Hitung Net Problem Score

Ubah jumlah responden di tiap kategori "sangat/cukup/tidak bermasalah" dan lihat bagaimana Net Problem Score bergeser.

Perangkap Umum saat Menggali Masalah Konsumen

Leading question (pertanyaan menggiring): "Anda pasti suka kalau ada fitur X, kan?" — jawaban konsumen jadi tidak jujur karena mengikuti arah pertanyaan.

Confirmation bias: tim hanya mendengar jawaban yang mengonfirmasi ide favorit mereka, mengabaikan sinyal yang bertentangan.

Sampel terlalu kecil/tidak representatif: mewawancarai 3 teman dekat lalu menyimpulkan untuk seluruh pasar.

Percaya niat, bukan perilaku: "Saya akan pakai kalau ada" sering tidak sama dengan perilaku beli/pakai yang sesungguhnya.

Sebelum kita lanjut ke bagian merumuskan masalah, penting sekali Anda waspada pada empat jebakan ini karena bisa merusak seluruh hasil riset Anda. Pertanyaan menggiring membuat responden hanya menjawab apa yang menurut mereka Anda ingin dengar, bukan apa yang sebenarnya mereka rasakan — sangat berbahaya kalau tim sudah punya solusi favorit sebelum wawancara dimulai. Confirmation bias, atau bias konfirmasi, membuat tim secara tidak sadar hanya mencatat jawaban yang mendukung asumsi mereka dan mengabaikan yang bertentangan. Sampel yang terlalu kecil, misalnya hanya mewawancarai teman sekelompok sendiri, jelas tidak bisa mewakili pasar sasaran yang lebih luas. Terakhir, dan ini yang paling sering menjebak mahasiswa, jangan langsung percaya kalau responden bilang "saya pasti akan pakai" — banyak riset menunjukkan niat yang diucapkan sering jauh berbeda dari perilaku nyata saat produk benar-benar diluncurkan.

Bagian 3 dari 3

Dari Masalah ke Peluang Tervalidasi

Masalah yang sudah digali harus dirumuskan rapi agar bisa dibawa ke tahap perumusan konsep minggu depan.

Merumuskan Problem Statement yang Baik

Struktur standar: Siapa — Situasi — Hambatan — Dampak. Hindari menyisipkan solusi di dalam pernyataan masalah.

[Siapa] mengalami [hambatan] saat [situasi], sehingga berdampak [dampak yang dirasakan]

Contoh Terisi

"Pemilik warung kelontong kesulitan melacak stok barang yang hampir habis saat toko sedang ramai pembeli, sehingga sering kehabisan barang laris tanpa disadari & kehilangan penjualan."

Versi salah (sudah mengandung solusi): "Pemilik warung butuh aplikasi stok berbasis AI" — ini melompat langsung ke solusi, bukan menjelaskan masalah.

Memetakan Prioritas: Matriks Severity × Frekuensi

Skor prioritas dari Bagian 1 & 2 bisa diplot ke matriks 2×2 untuk memutuskan masalah mana yang dikerjakan lebih dulu.

Matriks ini adalah cara visual untuk mengambil semua skor prioritas masalah yang sudah Anda hitung dan membandingkannya sekaligus. Sumbu mendatar menunjukkan seberapa sering masalah terjadi, sumbu tegak menunjukkan seberapa parah dampaknya bagi konsumen. Kuadran kanan atas, yang saya beri garis tebal, adalah prioritas utama tim — masalah yang sering terjadi dan sangat mengganggu, seperti contoh split bill dengan skor 9,92 yang kita hitung tadi. Kuadran kiri bawah sebaliknya, sering dan cukup aman diabaikan dulu karena baik frekuensi maupun keparahannya rendah. Dua kuadran lainnya butuh pertimbangan lebih hati-hati: masalah yang jarang tapi sangat parah biasanya perlu dipantau kalau-kalau meningkat, sementara masalah yang sering tapi ringan bisa diperbaiki bertahap tanpa perlu proyek besar. Gunakan peta ini setiap kali kelompok Anda punya banyak temuan masalah dari wawancara dan bingung mana yang dikerjakan duluan.

Coba Sendiri: Plot Masalah ke Matriks Prioritas

Masukkan skor severity dan frekuensi untuk beberapa masalah temuan wawancara Anda, lalu lihat masing-masing jatuh ke kuadran mana.

Latihan Kelas: Rumuskan Problem Statement

Instruksi (kerja kelompok 4–5 orang, 15 menit)

Pilih satu jenis usaha digital lokal (contoh: UMKM kuliner, jasa laundry, toko online kecil)
Rumuskan minimal 1 problem statement lengkap (Siapa–Situasi–Hambatan–Dampak), tanpa menyisipkan solusi
Beri estimasi kasar Severity (1–5) & Frequency (1–5) berdasarkan asumsi masuk akal
Hitung Skor Prioritas = Severity × Frequency, siap dipresentasikan 2 menit per kelompok

Pengingat: kalau hasil rumusan kelompok Anda masih berbunyi "butuh aplikasi X", itu tanda Anda melompat ke solusi — kembalikan ke format Siapa–Situasi–Hambatan–Dampak.

Rangkuman & Persiapan Pertemuan 6

Yang Sudah Kita Pelajari

Problem-first lebih aman daripada solution-first
Expressed need vs latent need — gali sampai akar (5 Whys, JTBD)
Skor Prioritas = Severity × Frequency × Reach
Problem statement: Siapa–Situasi–Hambatan–Dampak, tanpa solusi

TUGAS SEBELUM PERTEMUAN 6

1 Wawancara

+ 1 problem statement final

Wawancarai 1 calon pengguna nyata terkait ide proyek kelompok Anda, lalu tuliskan problem statement final memakai format hari ini. Bawa hasilnya minggu depan.

Minggu depan (Pertemuan 6): dari problem statement ini kita akan merumuskan atribut & konsep produk lewat perceptual mapping dan trade-off analysis.

Mari kita rangkum perjalanan dua jam kita hari ini. Kita mulai dari alasan mengapa problem-first lebih aman daripada solution-first, lalu belajar membedakan kebutuhan yang terucap dari kebutuhan tersembunyi memakai kerangka Jobs-to-be-Done dan teknik lima mengapa. Kita juga sudah dua kali menghitung dari nol: skor prioritas masalah dari data wawancara, dan net problem score dari data survei — dua alat kuantitatif yang bisa langsung Anda pakai di proyek kelompok. Terakhir kita berlatih menulis problem statement yang bersih dari solusi. Sebagai tugas sebelum pertemuan berikutnya, saya minta setiap kelompok mewawancarai minimal satu calon pengguna nyata terkait ide proyek Anda dan membawa problem statement final versi tertulis. Minggu depan kita akan memakai problem statement ini sebagai bahan baku untuk merumuskan atribut dan konsep produk lewat perceptual mapping serta trade-off analysis — jadi pastikan tugas ini benar-benar dikerjakan, bukan dikarang di menit terakhir.