Program Studi Bisnis Digital • FEB UNDIP

Pengembangan Produk

Pertemuan 12 — Product Protocol dan Quality Function Deployment (QFD)

Menerjemahkan suara pelanggan (Voice of Customer) menjadi target teknis terukur lewat House of Quality, lalu merumuskannya menjadi protokol produk yang mengikat tim pengembangan.

RPS MINGGU 13 • 2×50 MENIT

Selamat pagi/siang, Anda semua. Hari ini kita masuk ke salah satu titik paling krusial dalam pengembangan produk: bagaimana caranya keluhan dan harapan pelanggan yang tadinya berupa kalimat kabur — misalnya "aplikasinya lemot" atau "transfernya kadang gagal" — diubah menjadi angka target yang bisa dikerjakan tim engineering dan desain. Bayangkan Anda product manager di sebuah startup fintech; investor dan tim developer tidak bisa bekerja dari kalimat "bikin aplikasinya lebih cepat", mereka butuh angka pasti seperti "waktu respons di bawah 450 milidetik". Alat yang akan kita pelajari, Quality Function Deployment atau QFD, adalah jembatan sistematis dari suara pelanggan menuju angka teknis itu. Di akhir pertemuan ini hasil kerja QFD kita rangkum menjadi satu dokumen bernama product protocol — semacam kontrak tertulis yang mengikat seluruh tim sebelum produk mulai dibangun.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu menyusun product protocol berbasis voice of customer dan QFD secara sistematis. Secara rinci:

CAPAIAN 1

VoC

Mengumpulkan dan mengorganisasi voice of customer menjadi daftar kebutuhan pelanggan yang terstruktur.

CAPAIAN 2

QFD

Menjelaskan anatomi House of Quality dan menghitung skor prioritas karakteristik teknis.

CAPAIAN 3

TARGET

Menetapkan target teknis lewat benchmarking kompetitif secara terukur.

CAPAIAN 4

PROTOKOL

Menyusun product protocol — dokumen kesepakatan tim sebelum tahap desain dimulai.

Mengapa Banyak Produk Digital Gagal Padahal "Fiturnya Lengkap"?

Bayangkan sebuah startup marketplace membangun 20 fitur baru dalam 6 bulan — filter canggih, chat AI, rekomendasi personalisasi. Setelah rilis, rating aplikasi malah turun.

Penyebab paling umum: tim membangun fitur berdasarkan asumsi internal ("menurut kita ini keren"), bukan berdasarkan kebutuhan pelanggan yang terverifikasi dan diprioritaskan secara sistematis. Fitur yang dibangun bisa jadi tidak menjawab masalah yang paling menyakitkan bagi pengguna.

TANPA QFD

TEBAKAN

Prioritas fitur ditentukan oleh suara paling lantang di rapat, bukan data kebutuhan pelanggan.

DENGAN QFD

TERUKUR

Prioritas fitur punya skor angka yang bisa dipertanggungjawabkan ke seluruh tim dan investor.

Bagian 1 dari 3

Dari Suara Pelanggan ke Kebutuhan Produk

Sebelum menghitung apa pun, kita harus tahu cara mengumpulkan dan merapikan suara pelanggan menjadi kebutuhan yang jelas.

Voice of Customer (VoC): Definisi dan Sumber

Voice of Customer (VoC) adalah kumpulan kebutuhan, keluhan, dan harapan pelanggan yang diucapkan dengan bahasa mereka sendiri — bukan bahasa teknis tim produk.

SUMBER LANGSUNG

WAWANCARA

Wawancara mendalam, focus group discussion (FGD), atau observasi lapangan ke pengguna nyata.

SUMBER TIDAK LANGSUNG

ULASAN

Ulasan Play Store/App Store, keluhan customer service, mention media sosial.

SUMBER TERSTRUKTUR

SURVEI

Kuesioner dengan skala kepentingan (importance rating), biasanya 1–5 atau 1–9.

Prinsip kunci: catat kalimat pelanggan apa adanya ("aplikasinya lemot pas jam sibuk") dahulu — jangan langsung diterjemahkan ke istilah teknis ("optimasi server"). Terjemahan itu baru terjadi di tahap QFD.

Merapikan VoC Menjadi Kebutuhan Pelanggan (Customer Needs)

Kalimat mentah VoC dirapikan lewat affinity diagram — pengelompokan kalimat serupa ke dalam tema, lalu ditulis ulang sebagai pernyataan kebutuhan (bukan solusi).

VoC MENTAH (CONTOH)

"Transfer sering gagal pas jam sibuk"
"Buka aplikasinya lama banget loadingnya"
"Saya harus login ulang terus, capek"

CUSTOMER NEEDS (HASIL AFFINITY)

Transfer berhasil tanpa gagal di jam ramai
Aplikasi terbuka cepat setiap saat
Sesi login bertahan lama, tidak sering minta ulang

Kebutuhan ditulis sebagai "apa yang diinginkan pelanggan", bukan "bagaimana cara mewujudkannya" — solusi teknis baru muncul belakangan di House of Quality.

Apa Itu Product Protocol?

Product protocol adalah dokumen tertulis berisi kesepakatan tim tentang apa yang akan dibangun — hasil akhir kerja VoC dan QFD — sebelum tim desain dan engineering mulai bekerja.

Elemen Utama Product Protocol

Target pasar — siapa pengguna yang dituju
Manfaat kompetitif — keunggulan dibanding pesaing
Fitur & spesifikasi teknis terukur — hasil QFD

Batasan (constraints) — anggaran, waktu, regulasi
Asumsi & risiko yang diketahui sejak awal
Kriteria sukses — indikator produk dianggap berhasil

Analogi: product protocol seperti kontrak kerja antara tim pemasaran, desain, dan engineering — semua sepakat "target"-nya sebelum mulai membangun, sehingga tidak berubah-ubah di tengah jalan (scope creep).

Product protocol adalah muara dari semua yang kita bahas hari ini — sebuah dokumen tertulis yang merangkum kesepakatan tim tentang apa yang akan dibangun. Bayangkan protocol ini seperti kontrak kerja: tim pemasaran, desain, dan engineering semuanya menandatangani kesepakatan tentang target pasar, keunggulan kompetitif, spesifikasi teknis terukur, batasan anggaran dan waktu, sampai kriteria sukses produk. Tanpa protocol yang jelas, proyek pengembangan produk sangat rentan pada apa yang disebut scope creep, yaitu target yang terus membengkak dan berubah-ubah di tengah jalan karena tidak ada kesepakatan tertulis sejak awal. Nah, spesifikasi teknis terukur di dalam protocol ini — itulah yang akan kita hasilkan lewat alat bernama Quality Function Deployment, yang akan kita pelajari di bagian selanjutnya.

Bagian 2 dari 3

Quality Function Deployment (QFD)

Alat sistematis untuk menerjemahkan kebutuhan pelanggan menjadi target teknis terukur lewat House of Quality.

Apa Itu QFD?

Quality Function Deployment (QFD) adalah metode terstruktur untuk menerjemahkan kebutuhan pelanggan (WHATs) menjadi karakteristik teknis produk yang terukur (HOWs), lengkap dengan bobot prioritas.

ASAL

JEPANG

Dikembangkan di galangan kapal Mitsubishi (1966) untuk memastikan spesifikasi teknis benar-benar menjawab kebutuhan pelanggan.

ALAT UTAMA

HOUSE OF QUALITY

Matriks berbentuk "rumah" yang menghubungkan kebutuhan pelanggan dengan karakteristik teknis secara visual dan terukur.

Manfaat utama: mencegah tim membangun fitur berdasarkan opini, dan memastikan setiap keputusan teknis bisa ditelusuri kembali ke kebutuhan pelanggan tertentu.

Quality Function Deployment adalah metode terstruktur yang menghubungkan dua sisi: sisi kebutuhan pelanggan, sering disebut WHATs atau "apa yang diinginkan", dengan sisi karakteristik teknis produk, sering disebut HOWs atau "bagaimana cara mewujudkannya". Metode ini pertama dikembangkan di Jepang, tepatnya di galangan kapal Mitsubishi pada pertengahan tahun 1960-an, untuk memastikan spesifikasi teknis kapal benar-benar menjawab kebutuhan pelanggan, bukan sekadar standar internal perusahaan. Alat utamanya bernama House of Quality, sebuah matriks berbentuk menyerupai atap rumah yang akan kita bedah di slide berikutnya. Manfaat terbesarnya untuk tim produk digital seperti kita: setiap keputusan teknis, misalnya kenapa tim memprioritaskan kecepatan server dibanding fitur baru, bisa ditelusuri kembali dengan jelas ke kebutuhan pelanggan mana yang mendasarinya.

Anatomi House of Quality

Enam ruang utama yang saling terhubung dalam satu matriks:

Perhatikan diagram di layar — ini adalah bentuk klasik House of Quality yang menyerupai rumah dengan atap segitiga. Ruang satu, di sisi kiri, berisi daftar kebutuhan pelanggan hasil affinity diagram tadi, lengkap dengan bobot kepentingannya di ruang dua. Ruang tiga, di bagian atas badan rumah, berisi karakteristik teknis atau HOWs — misalnya waktu respons server dalam milidetik, atau tingkat keberhasilan transaksi dalam persen. Ruang empat di tengah adalah matriks hubungan, tempat kita menilai seberapa kuat setiap karakteristik teknis menjawab setiap kebutuhan pelanggan. Ruang lima, atap segitiga di puncak, adalah matriks korelasi yang menunjukkan apakah dua karakteristik teknis saling mendukung atau justru bertentangan. Ruang enam di kanan berisi penilaian kompetitif dibanding pesaing, dan di bagian bawah kita hitung target serta prioritas teknis akhir. Dua slide berikutnya, kita akan berlatih menghitung isi ruang-ruang ini dari nol.

Hitung dari Nol #1: Skor Prioritas Karakteristik Teknis

Kasus: fitur transfer instan aplikasi dompet digital. Kebutuhan pelanggan "transfer berhasil tanpa gagal" dihubungkan ke karakteristik teknis "waktu respons server".

Langkah	Perhitungan	Nilai
1. Bobot kepentingan pelanggan (survei 40 responden, skala 1–5)	Rata-rata jawaban responden	5 (sangat penting)
2. Nilai hubungan dengan "waktu respons server" (simbol kuat=9, sedang=3, lemah=1)	Hubungan dinilai kuat	9
3. Skor berbobot pasangan ini	5 (bobot) × 9 (hubungan)	45
4. Skor berbobot 2 kebutuhan lain yang juga terhubung ("login cepat"=15, "notifikasi akurat"=9)	Dijumlahkan dengan langkah 3	15 + 9
5. Total skor prioritas teknis "waktu respons server"	45 + 15 + 9	69

SKOR PRIORITAS TERTINGGI

"Waktu respons server" jadi karakteristik teknis prioritas #1

Mari kita hitung bersama, langkah demi langkah, isi matriks hubungan pada House of Quality. Pertama, dari survei ke empat puluh responden, kebutuhan "transfer berhasil tanpa gagal" mendapat bobot kepentingan 5 dari skala 1 sampai 5, artinya sangat penting bagi pelanggan. Kedua, kita nilai seberapa kuat hubungan kebutuhan itu dengan karakteristik teknis "waktu respons server" — QFD memakai simbol standar, kuat bernilai 9, sedang bernilai 3, dan lemah bernilai 1; di sini kita nilai hubungannya kuat, jadi 9. Ketiga, skor berbobot pasangan ini adalah bobot kepentingan dikali nilai hubungan, yaitu 5 dikali 9 sama dengan 45. Keempat dan kelima, karakteristik teknis yang sama biasanya terhubung dengan beberapa kebutuhan pelanggan lain juga, misalnya kebutuhan "login cepat" menyumbang 15 dan "notifikasi akurat" menyumbang 9, sehingga totalnya 45 tambah 15 tambah 9 sama dengan 69. Angka 69 inilah skor prioritas teknis — semakin tinggi skornya, semakin mendesak karakteristik itu untuk dikerjakan lebih dulu oleh tim engineering.

Coba Sendiri: Skor Prioritas House of Quality

Ubah bobot kepentingan pelanggan dan kekuatan hubungan (kuat/sedang/lemah), lalu lihat skor prioritas karakteristik teknis terhitung otomatis.

Hitung dari Nol #2: Menetapkan Target Teknis via Benchmarking

Setelah tahu karakteristik teknis prioritas, tim menetapkan target angka dengan membandingkan performa sendiri terhadap kompetitor terbaik.

Langkah	Perhitungan	Nilai
1. Performa perusahaan saat ini (log server, rata-rata jam sibuk)	Diukur langsung dari sistem	800 ms
2. Performa kompetitor terbaik hasil benchmarking	Diuji manual pada aplikasi kompetitor	500 ms
3. Target baru = 10% lebih baik dari kompetitor terbaik	500 ms × (1 − 10%)	450 ms
4. Rasio perbaikan yang dibutuhkan dari kondisi saat ini	800 ÷ 450	≈ 1,78 kali lebih cepat
5. Persentase penurunan waktu respons	(800 − 450) ÷ 800 × 100	43,75%

TARGET TEKNIS RESMI

450 ms

Ditulis di product protocol sebagai target terukur, bukan "harus lebih cepat"

Sekarang kita tentukan angka target sesungguhnya, bukan sekadar "harus lebih cepat" yang kabur. Pertama, kita ukur performa perusahaan sendiri saat ini: rata-rata delapan ratus milidetik pada jam sibuk, diambil langsung dari log server. Kedua, tim melakukan benchmarking, yaitu menguji manual aplikasi kompetitor terbaik, dan hasilnya lima ratus milidetik — lebih cepat dari kita. Ketiga, target yang wajar bukan sekadar menyamai kompetitor, tapi melampauinya; kita tetapkan target sepuluh persen lebih cepat dari kompetitor terbaik, yaitu lima ratus milidetik dikali sembilan puluh persen sama dengan empat ratus lima puluh milidetik. Keempat dan kelima, kita hitung rasio dan persentase perbaikannya supaya tim engineering paham skala usahanya: dari delapan ratus ke empat ratus lima puluh milidetik itu perbaikan sekitar satu koma tujuh puluh delapan kali lipat, atau penurunan waktu respons sebesar empat puluh tiga koma tujuh puluh lima persen. Angka empat ratus lima puluh milidetik inilah yang nanti ditulis hitam di atas putih dalam product protocol, bukan kalimat yang bisa ditafsirkan macam-macam.

Bagian 3 dari 3

Dari Matriks ke Praktik Nyata

Menerjemahkan hasil House of Quality menjadi isi product protocol, mengenali jebakan umum, lalu berlatih langsung.

Menerjemahkan Target Teknis ke Isi Product Protocol

Hasil House of Quality "diangkat" langsung menjadi baris spesifikasi teknis dalam product protocol.

Contoh Cuplikan Product Protocol (Fitur Transfer Instan)

Elemen Protocol	Isi (Hasil QFD)
Kebutuhan pelanggan prioritas	Transfer berhasil tanpa gagal (bobot 5/5)
Karakteristik teknis prioritas	Waktu respons server (skor 69, tertinggi)
Target terukur	≤ 450 ms pada jam sibuk
Batasan	Anggaran infrastruktur tambahan ≤ Rp 300 juta/bulan

Karena setiap baris protocol berasal dari matriks QFD, tim desain dan engineering tidak perlu berdebat lagi soal "kenapa harus segini" — jawabannya sudah tertelusur ke data pelanggan.

Ilustrasi Penerapan: Fitur Baru Aplikasi E-Commerce UMKM

Misalkan tim produk sebuah platform e-commerce yang melayani UMKM sedang menimbang tiga usulan fitur baru. Berikut ilustrasi bagaimana skor QFD membantu memutuskan.

Usulan Fitur	Kebutuhan Pelanggan yang Dijawab	Skor Prioritas Teknis (Ilustrasi)
Checkout satu klik	"Belanja jangan ribet, saya buru-buru"	82
Filter pencarian lanjutan	"Susah cari barang yang saya mau"	54
Chatbot AI rekomendasi	Belum ada keluhan pelanggan spesifik	19

Tanpa QFD, tim mungkin memilih chatbot AI karena terlihat "canggih" secara teknologi. Dengan skor QFD, jelas terlihat checkout satu klik yang paling menjawab kebutuhan nyata pelanggan.

Mari kita lihat ilustrasi penerapan pada platform e-commerce yang melayani UMKM. Tim produk sedang menimbang tiga usulan fitur: checkout satu klik, filter pencarian lanjutan, dan chatbot AI rekomendasi. Setelah dihitung lewat House of Quality dengan cara yang sama seperti dua contoh sebelumnya, checkout satu klik mendapat skor prioritas tertinggi karena langsung menjawab keluhan pelanggan yang paling sering muncul: proses belanja yang ribet saat mereka sedang buru-buru. Filter pencarian mendapat skor menengah, sementara chatbot AI mendapat skor paling rendah karena belum ada keluhan pelanggan spesifik yang mendasarinya — fitur ini lebih didorong tren teknologi ketimbang kebutuhan nyata. Ini contoh nyata bagaimana QFD mencegah tim terjebak membangun fitur yang terdengar keren tapi sebenarnya bukan prioritas pelanggan. Ingat, angka-angka pada tabel ini ilustrasi untuk latihan berpikir, bukan data riil satu perusahaan tertentu.

Kesalahan Umum dalam Menyusun QFD dan Protocol

JEBAKAN 1

VoC PALSU

Tim menulis kebutuhan pelanggan berdasarkan asumsi internal, bukan hasil wawancara/survei nyata.

JEBAKAN 2

TERLALU BANYAK

Memasukkan puluhan kebutuhan sekaligus ke House of Quality sehingga matriks tak terbaca dan tim kelelahan menilai.

JEBAKAN 3

TARGET ASAL

Target teknis ditentukan tanpa benchmarking kompetitor — hanya "pokoknya lebih baik dari sekarang".

JEBAKAN 4

PROTOCOL DIABAIKAN

Protocol ditulis lalu tidak dirujuk lagi saat desain berjalan — scope creep tetap terjadi.

Sebelum Anda praktik sendiri, penting mengenali empat jebakan yang paling sering membuat QFD gagal di lapangan. Jebakan pertama, tim menulis kebutuhan pelanggan berdasarkan tebakan internal, bukan hasil wawancara atau survei sungguhan — ini disebut VoC palsu, dan seluruh perhitungan sesudahnya jadi tidak berarti. Jebakan kedua, tim memasukkan terlalu banyak kebutuhan sekaligus, kadang sampai puluhan baris, sehingga matriks jadi tidak terbaca dan proses penilaian melelahkan; sebaiknya fokus lima sampai sepuluh kebutuhan paling penting saja. Jebakan ketiga, target teknis ditentukan asal, misalnya "pokoknya harus lebih cepat", tanpa benchmarking kompetitor yang jelas seperti yang kita hitung tadi. Jebakan keempat dan yang paling sering terjadi di startup: protocol sudah susah payah disusun, tapi begitu proses desain berjalan, dokumen itu tidak pernah dirujuk lagi, sehingga scope creep tetap terjadi seolah-olah protocol tidak pernah ada.

Latihan Kelas: Susun Mini House of Quality

Kerjakan berkelompok (4–5 orang), waktu 15 menit. Produk: aplikasi presensi kuliah berbasis QR code.

Instruksi

Tuliskan 3 kebutuhan pelanggan (mahasiswa pengguna aplikasi) dalam bahasa mereka sendiri.
Beri bobot kepentingan tiap kebutuhan (skala 1–5).
Usulkan 1 karakteristik teknis per kebutuhan, beri nilai hubungan (1/3/9).
Hitung skor berbobot tiap pasangan seperti contoh Hitung dari Nol #1.

Perwakilan 2 kelompok akan diminta memaparkan hasil dan skor prioritas tertingginya di 5 menit terakhir sesi.

Rangkuman: Alur VoC → QFD → Protocol

Tahap	Input	Output
1. Voice of Customer	Wawancara, ulasan, survei	Kalimat mentah pelanggan
2. Affinity Diagram	Kalimat mentah	Customer needs terstruktur
3. House of Quality	Customer needs + bobot	Skor prioritas karakteristik teknis
4. Benchmarking	Performa sendiri vs kompetitor	Target teknis terukur
5. Product Protocol	Semua hasil di atas	Dokumen kesepakatan tim

Satu kalimat kunci: QFD memastikan setiap angka di product protocol bisa ditelusuri kembali ke kebutuhan pelanggan nyata — bukan opini tim.

Mari kita rangkum seluruh perjalanan hari ini dalam satu alur yang runtut. Semua bermula dari voice of customer, suara mentah pelanggan yang kita kumpulkan lewat wawancara, ulasan, dan survei. Suara mentah itu dirapikan lewat affinity diagram menjadi customer needs yang terstruktur. Customer needs itu lalu dimasukkan ke House of Quality bersama bobot kepentingannya, menghasilkan skor prioritas karakteristik teknis seperti yang kita hitung tadi, tujuh puluh untuk waktu respons server. Skor prioritas itu kita padukan dengan benchmarking kompetitor untuk menghasilkan target teknis yang terukur, empat ratus lima puluh milidetik misalnya. Dan akhirnya, semua hasil ini dirangkum menjadi satu dokumen product protocol yang mengikat seluruh tim. Ingat baik-baik kalimat kunci ini: QFD memastikan setiap angka di protocol bisa ditelusuri kembali ke kebutuhan pelanggan nyata, bukan sekadar opini tim di ruang rapat.

Mengapa Ini Penting untuk Tugas Kelompok Anda?

Materi hari ini langsung relevan dengan proyek pengembangan produk semester ini, khususnya sebelum masuk tahap desain dan prototyping.

SEBELUM HARI INI

Anda sudah punya konsep produk (dari pertemuan Concept Generation & Concept Testing) tapi mungkin belum tahu fitur mana yang diprioritaskan.

SETELAH HARI INI

Anda punya alat (House of Quality) untuk memutuskan prioritas fitur berdasarkan data, siap dituangkan ke product protocol kelompok.

Wajib dihindari: menyerahkan tugas product protocol tanpa proses QFD di baliknya — dosen akan bertanya "skor prioritasnya dari mana?"

Materi hari ini bukan sekadar teori terpisah — ini adalah alat yang akan langsung Anda pakai dalam tugas kelompok pengembangan produk semester ini. Sebelum hari ini, kelompok Anda mungkin sudah punya konsep produk hasil dari pertemuan-pertemuan sebelumnya tentang pembangkitan konsep dan pengujian konsep, tapi sering kali belum jelas fitur mana yang sebaiknya diprioritaskan lebih dulu. Setelah hari ini, Anda punya alat konkret, House of Quality, untuk memutuskan prioritas itu berdasarkan data, bukan voting suara terbanyak di grup WhatsApp kelompok. Saya ingatkan satu hal penting: kalau kelompok Anda menyerahkan tugas product protocol tanpa proses QFD yang jelas di baliknya, pertanyaan pertama saya pasti "skor prioritas fitur ini datang dari mana?" — jadi pastikan Anda menyimpan matriks perhitungannya sebagai lampiran.

Penutup: Tugas dan Persiapan Minggu Depan

Tugas Sebelum Pertemuan Berikutnya

Kumpulkan 5 VoC mentah dari calon pengguna produk kelompok Anda
Susun 1 House of Quality sederhana (minimal 3 kebutuhan × 3 karakteristik teknis)
Tulis draf awal product protocol kelompok

MINGGU DEPAN

DESAIN & PROTOTYPING

Target teknis dari protocol hari ini menjadi input langsung untuk merancang wujud fisik/digital produk.

Sebelum kita tutup, catat tiga tugas yang harus dikerjakan kelompok Anda sebelum pertemuan berikutnya: kumpulkan minimal lima suara pelanggan mentah dari calon pengguna produk kelompok Anda, susun satu House of Quality sederhana dengan minimal tiga kebutuhan dan tiga karakteristik teknis, dan tulis draf awal product protocol kelompok berdasarkan hasil perhitungan tersebut. Minggu depan kita akan masuk ke tahap desain produk dan prototyping — dan target teknis yang Anda tetapkan hari ini, seperti angka empat ratus lima puluh milidetik pada contoh kita, akan langsung menjadi input nyata untuk merancang wujud produk kelompok Anda. Semakin matang product protocol yang Anda susun hari ini, semakin lancar proses desain minggu depan. Terima Kasih atas perhatiannya, sampai jumpa di pertemuan berikutnya.