Hampir setiap founder yang saya ajak bicara ingin tahu seberapa kecil seharusnya sebuah MVP, dan hampir semuanya menarik batas terlalu longgar. Versi "minimum" mereka punya lima fitur, tiga tipe pengguna, dan halaman pengaturan sendiri. Itu bukan minimum viable product. Itu produk lengkap dengan label yang terlalu optimis.
Jawaban jujurnya, versi pertamamu harus lebih kecil dari yang terasa nyaman. Kecil sampai terasa tidak nyaman. Kalau merilisnya tidak membuatmu sedikit malu, berarti kamu membangun terlalu banyak. Tujuan MVP bukan untuk membuat orang terkesan. Tujuannya adalah mempelajari satu hal tentang perilaku pelanggan nyata, secepat dan semurah mungkin.
Saya akan bagikan tes yang saya pakai untuk memangkas ide yang kegemukan menjadi sesuatu yang bisa kamu rilis dalam hitungan minggu, dan pendekatan manual-dulu yang justru dilewatkan kebanyakan pemilik bisnis karena terasa kurang serius.
MVP Menjawab Satu Pertanyaan, Bukan Banyak
Ini reframe yang mengubah segalanya. MVP bukan produk kecil. MVP adalah eksperimen. Dan setiap eksperimen punya tepat satu pertanyaan yang ingin dijawab.
Pertanyaanmu hampir selalu tentang perilaku pelanggan, bukan pendapat mereka. Bukan "apakah orang suka ide ini" tapi "apakah orang benar-benar akan melakukan hal yang aku pertaruhkan." Contohnya:
- Apakah pelanggan mau bayar di muka untuk langganan kotak jajanan lokal?
- Apakah pemilik bengkel mau booking slot layanan secara online, bukan datang langsung?
- Apakah pelanggan restoran mau pesan langsung kalau biaya aplikasi agregator dihilangkan?
Begitu kamu menamai satu pertanyaan itu, kamu punya pisau. Setiap fitur yang diusulkan harus lewat potongan yang sama: apakah ini membantu menjawab pertanyaan itu? Kalau ya, dia bertahan. Kalau tidak, dia dicoret, sebagus apa pun idenya. Dashboard laporan itu, bahasa kedua itu, sistem loyalti itu, semuanya menunggu, karena tidak satu pun membantumu memastikan apakah taruhan utamamu benar.
Latihan Memangkas
Ambil daftar fiturmu dan saring berdasarkan satu pertanyaanmu. Kebanyakan daftar akan menyusut drastis. Begini contohnya untuk ide pemesanan online hipotetis dengan pertanyaan "apakah pelanggan mau pesan langsung untuk menghindari biaya agregator":
| Fitur | Membantu menjawab pertanyaan? | Putusan |
|---|---|---|
| Halaman yang menampilkan menu | Ya, mereka perlu melihatnya | Pertahankan |
| Cara untuk melakukan pemesanan | Ya, itulah perilaku yang diuji | Pertahankan |
| Cara untuk membayar atau konfirmasi | Ya, itulah komitmennya | Pertahankan |
| Akun pelanggan dan login | Tidak, tamu bisa langsung pesan | Coret |
| Poin loyalti | Tidak | Coret |
| Dashboard analitik admin | Tidak, bisa dihitung manual | Coret |
| Dukungan multi-cabang | Tidak, uji satu cabang dulu | Coret |
Yang tersisa hanya menu, pemesanan, dan konfirmasi. Itu produk yang bisa kamu rilis dalam hitungan minggu, bukan kuartal. Semua yang kamu coret bukan dibatalkan. Itu masuk antrean, menunggu sampai pertanyaannya terjawab "ya."
Versi Concierge yang Sering Dilewatkan
Ini langkah yang terasa terlalu tidak serius untuk dicoba, dan justru karena itulah ia begitu ampuh: seringkali kamu bisa menjawab pertanyaanmu hampir tanpa perangkat lunak sama sekali.
Ini kadang disebut concierge MVP. Kamu memberikan hasil akhirnya secara manual, di belakang layar, sementara pelanggan merasakan sesuatu yang terlihat sudah jadi. Beberapa contohnya:
- Alih-alih membangun aplikasi pemesanan, taruh menu di katalog WhatsApp Business dan terima pesanan lewat chat. Kalau orang memesan, kamu dapat jawabanmu. Kamu belum membangun apa pun.
- Alih-alih sistem booking otomatis, publikasikan formulir sederhana dan konfirmasi tiap slot secara manual. Kalau booking masuk, permintaannya nyata.
- Alih-alih mesin rekomendasi, biarkan manusia yang memilih rekomendasi dan mengirimkannya secara personal. Kalau pelanggan merespons, konsepnya berjalan.
Versi manual terasa di bawah standar produk teknologi yang "sungguhan," dan perasaan itulah jebakannya. Versi manual menjawab pertanyaan yang sama persis dengan biaya dan waktu jauh lebih kecil. Kalau pelanggan tidak mau versi manualnya, mereka juga tidak akan mau versi otomatis yang sudah dipoles, dan kamu baru saja menghemat berbulan-bulan waktu serta puluhan juta rupiah untuk mengetahuinya.
Bangun perangkat lunaknya hanya setelah versi manual membuktikan orang memang menginginkannya. Urutan itulah seluruh disiplinnya.
Mengapa Lebih Kecil Bukan Sekadar Lebih Murah, Tapi Lebih Cerdas
MVP yang mungil bukan sekadar keputusan anggaran. Ia memberimu sinyal yang lebih bersih. Ketika kamu merilis lima fitur sekaligus dan hasilnya gagal, kamu tidak bisa tahu taruhan mana yang salah. Ketika kamu merilis satu, hasilnya jelas tanpa ambigu. Kamu belajar persis mana yang benar dan mana yang tidak.
Lebih kecil juga berarti kamu tahu hasilnya lebih cepat, dan di bisnis yang masih muda, kecepatan belajar adalah soal bertahan hidup. Founder yang menguji tiga MVP murah dalam waktu yang dipakai kompetitor untuk membangun satu versi gemuk akan jauh lebih memahami pasarnya.
Ini logika yang sama dengan scoping yang ketat, dan kedua keterampilan ini saling menguatkan. Untuk versi yang lebih tajam tentang apa yang harus dilindungi dan apa yang harus dicoret, baca Scoping MVP: Apa yang Dipangkas Lebih Dulu dan Apa yang Tidak Boleh Dicoret. Dan contoh nyata memulai dari yang kecil di dunia nyata ada di Restoran Ini Lepas dari Biaya Agregator Lewat Pemesanan Langsung.
Kesimpulan Praktisnya
Ketika kamu bertanya seberapa kecil seharusnya sebuah MVP, jawabannya: cukup kecil untuk menjawab tepat satu pertanyaan tentang perilaku pelanggan, dan tidak lebih besar dari itu.
- Namai satu pertanyaanmu. Pastikan itu tentang apa yang akan dilakukan orang, bukan apa yang mereka katakan.
- Coret setiap fitur yang tidak membantu menjawabnya. Antrekan, jangan hapus selamanya.
- Coba dulu versi manual, versi concierge. Kalau tidak berhasil secara manual, perangkat lunak pun tidak akan menyelamatkannya.
- Rilis, amati perilaku nyata, dan biarkan hasilnya menentukan apa yang dibangun selanjutnya.
Rasa malu yang kamu rasakan saat merilis sesuatu sekecil itu adalah harga dari belajar dengan cepat. Bayar itu. Jauh lebih murah dibanding alternatifnya.