Setiap beberapa bulan, ada saja pemilik bisnis yang duduk di depan saya dengan spesifikasi detail untuk sistem yang butuh waktu enam bulan dan ratusan juta rupiah untuk dibangun. Akun member, dashboard admin, modul reporting, aplikasi mobile, poin loyalitas, lengkap semua. Pertanyaan pertama saya selalu sama: bagian mana dari semua ini yang, jika gagal, akan mematikan seluruh ide? Bangun bagian itu dulu. Lewati sisanya.
Itulah keseluruhan filosofi di balik minimum viable product, dan sayangnya sering disalahpahami. Kebanyakan orang mendengar MVP dan mengira itu berarti "versi produk saya yang lebih kecil dan lebih murah." Cara pandang itu diam-diam menghancurkan banyak proyek. Minimum viable product bukan produk kecil. Ia adalah eksperimen yang menyamar sebagai produk, dan tugasnya hanya menjawab satu pertanyaan: apakah akan ada yang benar-benar memakainya?
Jika Anda sedang bersiap menugaskan pembangunan software yang serius, perbedaan ini nilainya lebih besar dari keputusan teknologi apa pun yang akan Anda ambil. Berikut cara menerapkannya.
MVP Adalah Pertanyaan, Bukan Produk
Produk berusaha melayani pelanggan. Eksperimen berusaha menghasilkan jawaban. Kacaukan keduanya, dan Anda akan berakhir "memangkas" proyek enam bulan menjadi proyek empat bulan, yang tidak menguji apa pun dan hanya mengirimkan lebih sedikit fitur.
Mulailah dengan menuliskan asumsi paling berisiko Anda dalam satu kalimat sederhana:
- "Pemilik restoran akan membayar bulanan untuk notifikasi stok otomatis."
- "Pelanggan grosir kami akan memesan lewat aplikasi, bukan lewat WhatsApp."
- "Orang tua akan memesan les online tanpa bicara dengan manusia dulu."
MVP Anda adalah apa pun yang paling murah dan tercepat untuk mendapatkan jawaban ya atau tidak yang nyata atas kalimat itu. Semua yang tidak melayani jawaban itu harus dipangkas, seberapa pun jelasnya "produk lengkap" nanti akan membutuhkannya. Sistem login, panel admin, halaman pengaturan, reporting: hampir tidak pernah dibutuhkan untuk mendapat jawaban itu. Semua itu terasa seperti kemajuan karena familiar, tapi sebenarnya itu cara paling mahal yang pernah ada untuk menghindari kenyataan apakah ada yang peduli.
Proyek Enam Bulan yang Berubah Jadi Uji Coba Enam Minggu
Contoh konkret, sudah dianonimkan. Sebuah perusahaan distribusi ingin membangun portal pemesanan B2B untuk sekitar 300 pelanggan ritel mereka. Spesifikasi awal: akun pelanggan, katalog lengkap dengan stok live, pengecekan limit kredit, mesin promo, penjadwalan pengiriman, dan back office admin. Estimasi jujurnya: enam bulan, sekitar Rp 400 juta.
Asumsi paling berisiko tertimbun di bawah semua itu: akankah pelanggan ritel mereka, yang sudah memesan lewat telepon dan WhatsApp selama lima belas tahun, mau mengubah kebiasaan mereka sama sekali?
Maka MVP-nya menjadi seperti ini. Halaman katalog sederhana yang ramah mobile, tanpa login, menampilkan 50 SKU terlaris dengan harga per tier pelanggan. Form pemesanan yang mengirim data ke Google Sheet. Seorang admin yang mengonfirmasi tiap pesanan secara manual lewat WhatsApp, mengecek limit kredit dengan mata sendiri, dan menginput pesanan ke sistem yang sudah ada. Kami mengundang 25 pelanggan mereka yang paling bersahabat.
Enam minggu kemudian, dengan sebagian kecil dari budget, kami mendapat jawaban, dan jawabannya lebih menarik dari sekadar ya atau tidak. Pelanggan senang menjelajahi katalog dan mengecek harga, tapi dua pertiga dari mereka tetap menyelesaikan pesanan lewat WhatsApp. Perilaku yang perlu kami bangun sistemnya adalah "katalog online, transaksi di chat," bukan portal self-service penuh. Pembangunan sesungguhnya yang kemudian dilakukan terlihat sangat berbeda dari spesifikasi awal, biayanya kurang dari separuh, dan benar-benar dipakai. Versi enam bulan tadinya akan meluncur dengan indah ke dalam kesunyian.
Kadang MVP Tidak Butuh Kode Sama Sekali
Versi dari konsep ini yang paling mengejutkan pemilik bisnis adalah concierge MVP: Anda memberikan layanannya secara manual, dengan tangan sendiri, di balik tampilan depan yang tipis.
Ingin menguji layanan langganan meal-plan? Jangan bangun platform langganannya. Buat halaman Instagram dan Google Form, terima pembayaran lewat transfer, dan masak untuk sepuluh pelanggan pertama Anda sendiri. Ingin menguji alat pengingat invoice otomatis? Tawarkan untuk menjalankannya secara manual untuk lima bisnis menggunakan data mereka dan sebuah spreadsheet. Jika mereka tidak mau menerimanya secara gratis dengan manusia yang mengerjakan, mereka tidak akan pernah mau membayar versi softwarenya.
Concierge MVP terasa seperti curang. Sebenarnya kebalikannya. Ia menempatkan Anda dalam kontak langsung dengan perilaku pelanggan sungguhan, berminggu-minggu sebelum seorang developer menulis satu baris kode pun, dan setiap jam kerja manual mengajarkan Anda apa yang sebenarnya harus dilakukan software itu. Beberapa fitur dalam spesifikasi yang "sudah jelas dibutuhkan" biasanya mati diam-diam selama fase ini karena tidak ada satu pun pelanggan yang pernah memintanya.
Aturan Cakupan yang Menjaga MVP Tetap Jujur
Ketika Anda memang membangun software untuk uji coba ini, beberapa aturan menjaganya tetap minimal:
- Satu tipe pengguna. Bangun untuk pelanggan atau untuk staf, bukan keduanya. Sisi yang lain dikerjakan manual dulu.
- Satu alur inti, dari ujung ke ujung. Seorang pengguna bisa menyelesaikan satu aksi yang benar-benar penting. Yang lain tidak perlu berfungsi.
- Manual di balik layar itu wajar. Notifikasi dikirim manusia, pesanan diproses dengan tangan, laporan disusun di Excel. Otomatisasi hanya untuk yang benar-benar rusak pada volume uji coba Anda.
- Enam minggu atau kurang waktu pembangunan. Jika MVP butuh lebih dari itu, pertanyaan Anda terlalu besar. Pecah jadi lebih kecil.
- Tentukan standar kelulusan sebelum diluncurkan. "Minimal 10 dari 25 pelanggan yang diundang melakukan pemesanan kedua dalam sebulan." Tanpa angka yang ditulis di depan, setiap hasil akan dirasionalisasi sebagai hal yang menggembirakan.
Dan ya, versi pertama sebaiknya sedikit memalukan. Jika Anda benar-benar bangga dengan MVP Anda, berarti Anda memoles hal-hal yang sebenarnya tidak dibutuhkan eksperimen, dan membayar poles itu dengan waktu dan uang. Jelek tapi jujur lebih baik daripada indah tapi tidak dibaca siapa pun.
Apa yang Harus Dilakukan dengan Jawabannya
Tiga kemungkinan hasil, tiga langkah berbeda.
Jawaban ya yang jelas. Pemakaian mencapai standar kelulusan Anda, orang mengeluh ketika bagian manualnya lambat. Sekarang, dan hanya sekarang, pembangunan yang lebih besar jadi masuk akal, dan Anda akan menentukan cakupannya jauh lebih baik karena perilaku nyata sudah menggantikan tebakan. Ini titik di mana spesifikasi tertulis yang tepat benar-benar berguna; lihat Cara Menulis Brief Software yang Tidak Disalahpahami Developer.
Jawaban tidak yang jelas. Tidak ada yang memakainya meski sudah diundang secara sungguh-sungguh. Menyakitkan, tapi Anda baru saja membeli pelajaran itu dengan 10 sampai 15 persen dari harga pembangunan penuh. Hentikan atau ubah arah pertanyaannya. Jangan "menambah fitur dan coba lagi" tanpa hipotesis baru tentang kenapa perilaku akan berubah.
Hasil di tengah yang berantakan. Ada pemakaian, tapi bentuknya salah, seperti klien distribusi saya tadi. Ini sebenarnya hasil yang paling umum dan paling berharga. MVP sudah menjalankan tugasnya: mengarahkan investasi sesungguhnya ke arah yang benar-benar dilakukan pelanggan.
Apa pun hasilnya, tahan dorongan sunk-cost. MVP adalah biaya untuk mendapatkan jawaban. Perlakukan kodenya sebagai sesuatu yang bisa dibuang, karena memang seringkali begitu.
Yang Perlu Dilakukan Sekarang
Sebelum Anda menyetujui pembangunan software besar apa pun, jalankan checklist ini. Tuliskan asumsi paling berisiko Anda dalam satu kalimat. Rancang uji coba termurah yang bisa memberi jawaban ya atau tidak yang nyata, dan cek apakah versi concierge bahkan butuh kode sama sekali. Batasi pembangunan pada enam minggu dan satu alur inti. Tentukan standar kelulusan berupa angka sebelum diluncurkan. Lalu biarkan hasilnya, bukan spesifikasi awal, yang menentukan apa yang dibangun selanjutnya.
Kerajaannya mungkin tetap akan dibangun. Tapi ia dibangun di atas bukti, dan biasanya terlihat berbeda, dan lebih murah, dari spesifikasi yang Anda mulai. Jika Anda ingin sudut pandang kedua tentang apakah proyek Anda ada di tahap uji coba atau tahap pembangunan, itulah percakapan yang biasa saya lakukan dengan para partner sebelum keterlibatan besar apa pun, dan ini masuk dalam rencana yang lebih besar, bukan pembangunan satu kali; selengkapnya di Kenapa Bisnis Anda Butuh Strategi Teknologi, Bukan Sekadar Website.