Minimum viable product adalah versi terkecil dari sebuah produk yang sudah bisa memberi manfaat nyata ke pengguna sungguhan, supaya Anda tahu ide itu jalan atau tidak sebelum menghabiskan seluruh anggaran. Kenyataannya, banyak MVP yang tidak minimum dan juga tidak viable. Pengerjaannya makan sembilan bulan, ada panel admin dengan empat puluh pengaturan, lalu diluncurkan ke pasar yang belum pernah diajak bicara. Berikut cara kami membantu founder dan tim internal menjaga MVP cukup kecil untuk dirilis dan cukup berguna untuk dijadikan bahan belajar.
Mulai dari Satu Masalah dan Satu Angka
Tulis dalam satu kalimat untuk siapa produk ini dibuat dan masalah apa yang diselesaikannya. Lalu pilih satu angka yang akan menunjukkan produk ini berhasil atau tidak. Untuk aplikasi booking, angkanya bisa berupa persentase pengguna yang booking untuk kedua kalinya dalam sebulan. Untuk aplikasi internal, bisa berupa jumlah jam kerja yang dihemat per minggu. Setiap permintaan fitur diukur terhadap kalimat dan angka itu. Kalau sebuah fitur tidak menggerakkan angkanya, fitur itu menunggu.
Uji Idenya Sebelum Menulis Kode
- Ngobrol dengan sepuluh sampai dua puluh orang yang punya masalah itu, tanyakan bagaimana mereka mengatasinya sekarang dan berapa biayanya bagi mereka.
- Tunjukkan prototipe yang bisa diklik di Figma dan perhatikan di mana orang kebingungan.
- Buat landing page dengan daftar tunggu atau tombol pre-order untuk melihat apakah ada yang mendaftar.
- Jalankan layanannya secara manual untuk beberapa pelanggan pertama, cukup dengan spreadsheet dan WhatsApp, untuk memahami alur kerja yang sesungguhnya.
Langkah-langkah ini hanya butuh beberapa hari dan biayanya kecil. Hasilnya sering mengubah cakupan MVP lebih banyak daripada keputusan teknis mana pun.
Pangkas Daftar Fitur dengan Tegas
| Kategori | Contoh | Masuk MVP? |
|---|---|---|
| Alur inti | Langkah yang dilalui pengguna untuk mendapat manfaat utama, misalnya cari, booking, dan bayar | Ya, dan dikerjakan dengan baik |
| Keamanan dan kepercayaan dasar | Login, reset password, backup data, HTTPS, pembatasan akses dasar | Ya, karena semua ini sulit ditambahkan belakangan |
| Operasional | Halaman admin untuk memperbaiki data dan membantu pelanggan | Versi sederhana, atau ubah data langsung di database untuk awalnya |
| Fitur pertumbuhan | Referral, poin loyalitas, rekomendasi | Setelah terlihat orang memakai alur intinya |
| Pemolesan dan kasus pinggir | Dark mode, banyak bahasa, metode pembayaran yang jarang dipakai | Nanti, sesuai permintaan pengguna |
Latihan yang berguna adalah bertanya apa yang terjadi kalau sebuah fitur belum ada di hari peluncuran. Kalau jawaban jujurnya hanya beberapa pengguna akan sedikit kesal, fitur itu tidak perlu masuk MVP.
Pilih Teknologi yang Bisa Dipertahankan
Minimum tidak sama dengan sekali pakai. Kalau MVP-nya berhasil, biasanya MVP itulah yang menjadi produk, jadi bangun di atas teknologi umum yang developernya mudah dicari. Aplikasi web dengan Next.js atau Laravel, aplikasi mobile lintas platform dengan Flutter kalau memang perlu, database terkelola seperti PostgreSQL, dan payment gateway yang sudah jadi cukup untuk sebagian besar kasus. Hindari microservices, Kubernetes, dan infrastruktur buatan sendiri di tahap ini. Pakai layanan siap pakai untuk email, pembayaran, peta, dan autentikasi daripada membangunnya dari nol.
Susun Timeline yang Realistis
Untuk MVP yang fokus pada satu alur utama, tim kecil berisi dua sampai empat orang sering bisa mencapai rilis pertama dalam delapan sampai dua belas minggu. Proyek yang jauh lebih lama dari itu biasanya bermasalah di cakupan. Rencanakan dalam iterasi pendek satu atau dua minggu, demokan software yang sudah jalan di akhir setiap iterasi, dan pegang tanggal peluncuran sambil membiarkan daftar fitur menyusut kalau perlu.
- 1Minggu 1 sampai 2: pastikan cakupan, alur pengguna, dan desain layar-layar inti.
- 2Minggu 3 sampai 8: bangun alur inti dari ujung ke ujung lebih dulu, lalu fitur pendukung, dengan environment staging sejak awal.
- 3Minggu 9 sampai 10: uji coba dengan sekelompok kecil pengguna sungguhan dan perbaiki hal yang menghambat mereka.
- 4Minggu 11 sampai 12: luncurkan ke kelompok yang lebih luas, dengan analytics dan monitoring error yang sudah terpasang.
Ukur Apa yang Dilakukan Pengguna
Pasang product analytics seperti PostHog atau event Google Analytics di setiap langkah alur inti, supaya terlihat di titik mana pengguna berhenti. Pasang error tracking seperti Sentry supaya crash sampai ke tim lebih dulu daripada komplain. Setelah itu ajak pengguna ngobrol setiap minggu. Angka menunjukkan apa yang terjadi, percakapan menjelaskan alasannya.
Tentukan Langkah Berikutnya
- Kalau angka utamanya membaik, investasikan ke fitur yang terus diminta pengguna dan ke utang teknis yang memperlambat tim.
- Kalau orang mendaftar tapi tidak kembali, alur intinya belum cukup menyelesaikan masalah. Perbaiki itu dulu sebelum menambah fitur.
- Kalau hampir tidak ada yang mendaftar, tinjau ulang masalah atau target penggunanya. Menambah fitur jarang bisa mengatasi masalah permintaan.
Tujuan MVP adalah belajar. Peluncuran hanyalah saat pembelajaran itu dimulai.
Siapa pun yang membangun MVP Anda, pastikan source code, akun cloud, dan domain menjadi milik Anda sejak awal. Kami membangun MVP untuk startup dan perusahaan dengan tim dedicated yang kecil, demo setiap minggu, dan serah terima penuh atas kode dan infrastrukturnya.
Poin penting
- Tentukan satu target pengguna, satu masalah, dan satu angka yang menunjukkan MVP berhasil atau tidak.
- Validasi lewat wawancara, prototipe, dan layanan manual sebelum menulis kode.
- Pertahankan alur inti dan keamanan dasar, lalu tunda fitur pertumbuhan dan pemolesan.
- Bangun di atas teknologi umum dan layanan terkelola, karena MVP yang berhasil akan menjadi produknya.
- Rencanakan sekitar delapan sampai dua belas minggu untuk MVP yang fokus, dan pangkas cakupan sebelum menggeser tanggal.
