Bagaimana product team menghasilkan kemungkinan, menguji asumsi, dan belajar sebelum menggunakan sumber daya yang mahal.
Di sebuah restoran kecil di Bandung, Aditya menyaksikan seorang chef menyiapkan tiga mangkuk saus pasta yang sama.
Yang pertama menerima tomat panggang. Yang kedua pakai tomat segar dengan sedikit gula palem. Yang ketiga termasuk sesendok cabai fermentasi yang dibeli koki dari pasar lokal.
Tidak ada mangkuk yang cukup besar untuk menampung customer. Tidak ada piring hias, menu tercetak, atau daun kemangi yang ditempatkan dengan hati-hati. Koki mencicipi setiap versi, meminta dua staf dapur untuk membandingkannya, mengubah jumlah garam, dan mencoba lagi.
Aditya bertanya kapan hidangan barunya akan siap.
Koki itu tertawa. “Siap untuk apa? Hari ini saya hanya perlu mengetahui arah mana yang memerlukan waktu satu jam lagi.”
Kalimat itu tetap melekat padanya.
Product team sering kali menunggu hingga sebuah ide terlihat lengkap sebelum menunjukkannya kepada siapa pun. Kami menyempurnakan interface, menyiapkan presentasi, dan melindungi konsep dari pertanyaan yang tidak nyaman. Pada saat feedback yang nyata tiba, team telah melakukan upaya yang cukup untuk berharap bahwa ide tersebut benar.
Stanford d.school menjelaskan kemampuan yang berbeda: Rapidly Experiment.
Ini bukan sekadar tentang bergerak cepat. Ini adalah kemampuan untuk menghasilkan kemungkinan-kemungkinan, membuat asumsi-asumsi penting dapat diuji, dan belajar melalui siklus-siklus kecil sebelum biaya perubahan menjadi tinggi.
🍽️ Team Sudah Memilih Hidangannya
Team Aditya sedang membuat feature untuk aplikasi pengiriman bahan makanan. Customer sering kali lupa satu atau dua item setelah melakukan pemesanan, kemudian membuat pesanan kedua atau menghubungi dukungan. Solusi yang diusulkan adalah tombol “Tambahkan item yang terlupakan” yang tersedia selama sepuluh menit setelah checkout.
Konsepnya terasa jelas. Team mendiskusikan posisi tombol, perilaku hitung mundur, dan pembaruan pembayaran. Rekayasa memperkirakan beberapa minggu karena feature tersebut memengaruhi inventaris, perutean, otorisasi pembayaran, dan pengambilan gudang.
Sebelum pengembangan dimulai, Aditya mengajukan pertanyaan sederhana: “Apa yang harus benar agar ide ini bisa membantu?”
Ruangan menjadi lebih sunyi.
Customer perlu memperhatikan opsi tersebut. Mereka perlu mengingat barang yang hilang dalam waktu yang ditentukan. Gudang perlu menerima pembaruan sebelum pengambilan dimulai. Masyarakat perlu percaya bahwa tuduhan kedua itu benar. Menambahkan item tidak boleh menimbulkan lebih banyak kebingungan daripada melakukan pemesanan baru.
Team telah membahas satu solusi seolah-olah itu adalah masalahnya sendiri.
Eksperimen cepat dimulai dengan membuka kembali kemungkinan. Daripada hanya bertanya, “Bagaimana cara kerja tombol ini?” team bertanya, “Bagaimana kami dapat membantu customer pulih ketika mereka menyadari ada sesuatu yang hilang?”
Hal ini menghasilkan lebih banyak arahan: pengingat keranjang terakhir sebelum pembayaran, jendela penambahan singkat pasca-checkout, saran bahan pokok yang terlupakan, duplikasi pesanan yang lebih mudah, dan jalur dukungan yang ringan untuk kasus-kasus yang sensitif terhadap waktu.
Tujuannya bukan untuk membangun semuanya. Itu untuk menghindari menghabiskan waktu berminggu-minggu untuk menyempurnakan ide pertama yang masuk ke dalam ruangan.
🧂 Sebutkan Asumsi Sebelum Memilih Eksperimen
Eksperimen berguna bila dihubungkan dengan pertanyaan pembelajaran.
Tanpa koneksi tersebut, team dapat menghasilkan prototype, pengujian A/B, dan lokakarya yang menciptakan aktivitas tanpa mengurangi ketidakpastian.
Aditya membuat daftar asumsi di balik konsep-konsep utama dan mengurutkannya berdasarkan kepentingan dan ketidakpastian. Satu hal yang menonjol: customer akan segera mengenali barang yang terlupakan sehingga pesanannya dapat diperbarui.
Team tidak memerlukan integrasi pembayaran yang berfungsi untuk menyelidiki asumsi tersebut. Mereka merekrut customer baru, meminta mereka untuk melakukan pemesanan bahan makanan yang realistis menggunakan prototype, dan memperkenalkan perintah pada saat yang berbeda. Mereka juga meninjau waktu pesan dukungan yang menyebutkan item yang terlupakan.
Hasilnya beragam. Beberapa orang langsung mengingat suatu item setelah melihat layar konfirmasi. Yang lain baru sadar ketika memasak beberapa jam kemudian. Jeda waktu sepuluh menit akan membantu kelompok yang bermakna, namun itu bukanlah jawaban keseluruhan.
Pembelajaran itu memakan waktu dua hari, bukan enam minggu.
Eksperimen tersebut tidak membuktikan bahwa feature akhir akan berhasil. Hal ini membuat satu asumsi penting menjadi tidak terlalu pasti.
🥄 Gunakan Porsi Terkecil Yang Dapat Menghasilkan Feedback yang Jujur
Fidelity yang rendah tidak secara otomatis berarti berguna. Sketsa kertas mungkin cukup untuk menguji apakah orang memahami suatu urutan, namun tidak cukup untuk menguji apakah mereka memercayai pembaruan pembayaran. Prototype yang disempurnakan mungkin terasa realistis, namun memakan waktu terlalu lama jika pertanyaannya menyangkut satu label.
Bentuk eksperimen yang tepat bergantung pada apa yang perlu dipelajari team.
Team Aditya menggunakan beberapa eksperimen kecil:
- Flow kertas untuk membandingkan saat pengingat dirasa berguna atau mengganggu.
- Prototype yang dapat diklik untuk menguji apakah orang memahami bahwa satu pesanan sedang diperbarui dan bukan pesanan kedua yang dibuat.
- Simulasi operasional palsu di mana anggota staf secara manual menyetujui penambahan item, memungkinkan team untuk mengamati kasus-kasus ekstrem sebelum mengotomatiskannya.
- Rilis terbatas di satu gudang untuk memahami batasan waktu dan pengambilan.
Setiap percobaan sengaja dibuat tidak lengkap. Masing-masing cukup lengkap untuk pertanyaannya.
Koki di Bandung ini tidak menghidangkan sausnya karena penyajian visual bukanlah ketidakpastian yang ia jelajahi. Jika pertanyaannya kemudian adalah apakah customer akan membayar hidangan tersebut, eksperimen tersebut perlu diubah.
🔁 Tes untuk Mempelajari, Bukan Hanya untuk Mengonfirmasi
Team terkadang menggunakan eksperimen sebagai ruang sidang di mana sebuah ide harus dinyatakan berhasil atau gagal. Framing tersebut menciptakan tekanan untuk mempertahankan konsep tersebut.
Eksperimen cepat bekerja lebih baik ketika team mengharapkan idenya berubah.
Selama sesi kegunaan, salah satu peserta melihat konfirmasi “Tambahkan item” dan bertanya, “Apakah pengemudi harus kembali?” Prototype telah menjelaskan perubahan pembayaran tetapi tidak menjelaskan waktu operasional. Peserta lain mencoba menambahkan product dingin setelah kantong penyimpanan dingin disegel.
Ini bukanlah pengecualian yang mengganggu. Itu adalah informasi tentang sistem yang sedang dirancang oleh team.
Aditya mengubah eksperimennya. Versi berikutnya menunjukkan apakah pesanan masih dapat diedit dan menjelaskan mengapa opsi tersebut mungkin ditutup lebih awal dari yang diharapkan. Team juga mencari pengingat alternatif sebelum checkout untuk barang-barang yang sering terlupakan bersama.
Konsep ini menjadi serangkaian intervensi yang terhubung dan bukan hanya satu tombol heroik.
Pembelajaran terjadi karena team memberikan feedback untuk mengarahkan kembali gagasan tersebut.
🔥 Kecepatan Adalah Tentang Lingkaran Pembelajaran
Rapidly Experiment tidak berarti terburu-buru, menurunkan standar etika, atau melakukan pengujian secara sembarangan. Eksperimen dengan kerangka buruk yang dilakukan dengan cepat dapat menciptakan keyakinan palsu sama efisiennya dengan eksperimen yang lambat.
Kecepatan yang penting adalah jarak antara pertanyaan, representasi yang dapat diuji, bukti, dan keputusan selanjutnya.
Aditya membuat catatan sederhana untuk setiap percobaan:
- Apa yang kita yakini?
- Mengapa itu penting?
- Bukti apa yang bisa menantang keyakinan tersebut?
- Apa cara yang paling bertanggung jawab dan ringan untuk mendapatkan bukti tersebut?
- Apa yang akan kita lakukan secara berbeda tergantung pada apa yang kita pelajari?
Pertanyaan terakhir menghalangi team untuk menjalankan tes menarik yang tidak memiliki konsekuensi. Jika tidak ada hasil yang masuk akal yang dapat mengubah keputusan, maka eksperimen belum siap.
🍝 Menu Lengkapnya Datang Nanti
Beberapa minggu kemudian, product team merilis versi terbatas penambahan item pasca-checkout. Konsepnya tidak persis seperti aslinya.
Jendela editing bergantung pada status gudang, bukan pengatur waktu universal yang tetap. Konfirmasi tersebut membuat perubahan pembayaran menjadi eksplisit. Layar pembayaran menyertakan pengingat lembut berdasarkan keranjang, namun customer dapat mengabaikannya. Operations teamonal memiliki jalur pengecualian yang jelas.
Solusinya lebih kuat bukan karena ide pertama cemerlang, tapi karena team bersedia menjadikannya sebagai bahan pembelajaran.
Aditya kembali ke restoran Bandung beberapa bulan kemudian. Saus percobaan sekarang ada di menu, tetapi versi cabai yang difermentasi telah hilang. Koki telah menyimpan bahan dasar tomat panggang dan meminjam satu teknik kecil dari mangkuk kedua.
“Jadi tidak ada versi aslinya yang menang?” Aditya bertanya.
“Hidangannya menang,” kata koki itu. “Versinya berhasil.”
Itulah gunanya eksperimen yang baik. Mereka tidak ada untuk menjaga martabat sebuah ide. Mereka membantu team menemukan apa yang pantas untuk menjadi nyata.
🧺 Hal-Hal Penting untuk Dibawa ke Proyek Anda Berikutnya
- Eksperimen cepat mengeksplorasi kemungkinan sebelum team berkomitmen pada satu solusi.
- Mulailah dengan asumsi penting yang tidak pasti, bukan dengan format prototype.
- Gunakan representasi terkecil yang bertanggung jawab yang dapat menghasilkan feedback yang jujur.
- Cocokkan fidelity dan metode dengan pertanyaan pembelajaran.
- Perlakukan perilaku mengejutkan dan kasus-kasus kecil sebagai bukti yang dapat membentuk kembali konsep tersebut.
- Ukur kecepatan berdasarkan putaran pembelajaran, bukan berdasarkan seberapa cepat artifact dihasilkan.
- Biarkan eksperimen menggabungkan, mengubah, atau menghentikan ide tanpa menganggapnya sebagai kegagalan.
P.S. Selanjutnya:
“Move Between Concrete and Abstract: Seperti Dokter yang Menghubungkan Gejala ke Sistem yang Lebih Besar” 👀
🔗 Tentang Seri Ini
Ini adalah artikel 4 dari Designerly Thinking: Eight Core Design Abilities, diikuti dengan epilog refleksi. Kemampuan tersebut berasal dari Stanford d.school dan tidak dimaksudkan sebagai rangkaian yang kaku.
- Design Your Design Work: Seperti Menyiapkan Dapur Sebelum Memasak
- Learn from Others: Seperti Menonton Barista yang Mengetahui Pesanan dan Suasana Hati Anda
- Synthesize Information: Seperti Memilah Emas dari Pasir untuk Menemukan Makna dalam Research yang Berantakan
- Rapidly Experiment: Seperti Koki Menguji Porsi Kecil Sebelum Menyajikan Menu Lengkap
- Move Between Concrete and Abstract: Seperti Dokter yang Menghubungkan Gejala ke Sistem yang Lebih Besar
- Build and Craft Intentionally: Seperti Watchmaker yang Merancang Setiap Gear
- Communicate Deliberately: Seperti Seorang Diplomat yang Menyelaraskan Sekutu di Ruang Berisiko Tinggi
- Navigate Ambiguity: Seperti Kapten yang Menempa Rute Melalui Kabut
- Refleksi: Seperti Warung Setelah Tutup, Mengubah Hari yang Sibuk Menjadi Penilaian yang Lebih Baik
