Hampir semua founder yang pernah saya ajak kerja sama mulai dengan daftar fitur, bukan produk. Scoping MVP adalah disiplin mengambil daftar itu, biasanya 30 sampai 50 item panjangnya, lalu memangkasnya jadi satu alur kerja yang benar-benar membuktikan ide bisnisnya jalan. Kalau langkah ini salah, kamu akan menghabiskan enam bulan dan budget yang nyata untuk membangun hal-hal yang tidak diminta siapa pun, sebelum akhirnya tahu apakah ada yang mau bayar untuk ide intinya sama sekali.
Dorongan untuk membangun semuanya sekaligus datang dari tempat yang wajar: kamu bisa membayangkan seluruh produk di kepala, dan setiap fitur terasa perlu karena jadi bagian dari visi itu. Tapi MVP bukan versi kecil dari produk final. MVP adalah sebuah tes. Satu-satunya tugasnya adalah membuktikan atau mematahkan asumsi paling berisiko dalam bisnismu, secepat dan semurah mungkin.
Berikut metode yang saya pakai sendiri saat klien menyerahkan daftar keinginan fitur, lengkap dengan contoh penerapannya.
Langkah 1: Temukan Satu Alur Kerja yang Menggerakkan Uang
Setiap produk punya tepat satu alur kerja tempat nilai benar-benar diciptakan dan dipertukarkan. Sisanya adalah pendukung, kenyamanan, atau polesan di sekitar loop inti itu. Tugas pertamamu dalam scoping MVP adalah mengidentifikasi satu alur kerja itu, bukan mendata fitur.
Ajukan pertanyaan ini untuk setiap fitur di daftarmu: "kalau fitur ini tidak ada, apakah transaksi inti tetap terjadi?" Kalau jawabannya ya, berarti itu bukan bagian dari MVP. Bisa jadi bagian dari versi 2, atau versi 5, tapi bukan bagian dari apa yang membuktikan bisnismu berjalan.
Untuk aplikasi marketplace, alur kerja yang menggerakkan uang adalah: pembeli menemukan produk, membayarnya, penjual memenuhi pesanan itu. Notifikasi, ulasan, wishlist, dashboard analitik penjual, semua itu bukan alur kerja yang menggerakkan uang. Mereka membuat alur kerja itu lebih enak dipakai, tapi tidak membuatnya ada.
Untuk tool B2B SaaS, alur kerja yang menggerakkan uang biasanya adalah satu aksi yang dilakukan berulang oleh pengguna berbayar, yang sebelumnya mereka lakukan secara manual atau dengan tool yang lebih buruk. Sisanya, sentuhan onboarding, pengaturan admin, white-labeling, adalah sekunder sampai loop intinya terbukti bisa mempertahankan pengguna.
Langkah 2: Bangun Hanya Jalur Itu, Tuntas dari Ujung ke Ujung
Setelah kamu mengidentifikasi alur kerjanya, bangun secara utuh, dari awal sampai akhir, tanpa celah. Alur kerja inti yang setengah jadi lebih buruk daripada alur kerja sempit tapi lengkap, karena celah di tengah jalur yang menggerakkan uang berarti tidak ada yang benar-benar bisa menyelesaikan transaksi sungguhan, yang berarti kamu tidak belajar apa-apa.
Ini bagian yang paling sering dibalik oleh founder. Mereka membangun alur kerja inti sampai 60% lalu mulai menambah fitur sekunder, karena fitur sekunder terasa lebih mudah diselesaikan dan memberi rasa progres. Tahan godaan ini. MVP dengan satu jalur lengkap selalu mengalahkan MVP dengan lima jalur setengah jadi, karena hanya jalur yang lengkap yang bisa diuji dengan pengguna sungguhan melakukan hal yang sungguhan.
Langkah 3: Palsukan atau Kerjakan Manual Sisanya
Ini langkah yang paling menghemat waktu dan uang, dan yang paling bikin tidak nyaman bagi kebanyakan founder. Apa pun di luar alur kerja inti yang tetap harus ada agar bisnis bisa jalan, tapi bukan hal yang sedang kamu uji, sebaiknya dikerjakan manual atau dipalsukan dulu, bukan dibangun.
Contoh yang pernah saya pakai di proyek nyata:
- Customer support: nomor WhatsApp yang dijawab langsung oleh founder, bukan sistem ticketing.
- Sinkronisasi inventaris: spreadsheet bersama yang diupdate manual, bukan integrasi real-time.
- Rekonsiliasi pembayaran: pengecekan manual terhadap mutasi rekening bank, bukan pencocokan otomatis.
- Onboarding: founder memandu pengguna baru lewat panggilan telepon, bukan tutorial dalam aplikasi yang sudah dipoles.
- Tooling admin: query database langsung yang dijalankan founder, bukan dashboard admin.
Tidak ada yang memalukan dari semua ini. Ini adalah urutan yang benar. Kamu membangun otomasinya setelah terbukti ada cukup volume untuk membenarkan otomasi itu. Membangun dashboard admin sebelum kamu punya sepuluh pengguna untuk dikelola adalah uang yang dihabiskan untuk masalah yang belum kamu miliki.
Contoh Nyata: Memangkas 40 Fitur Jadi 6
Seorang founder datang ke saya dengan aplikasi koordinasi logistik untuk penjual online, ingin meluncurkan dengan daftar fitur yang mencakup: perbandingan tarif multi-kurir, cetak label otomatis, pelacakan GPS real-time, dashboard analitik untuk penjual, halaman pelacakan untuk pelanggan, notifikasi SMS, sistem poin loyalitas, impor pesanan massal, manajemen inventaris gudang, dan program referral partner, di antara yang lainnya. Total empat puluh item.
Kami menelusuri pertanyaan alur kerja yang menggerakkan uang: apa satu hal yang, kalau itu berhasil, akan membuktikan penjual mau membayar untuk ini? Jawabannya: penjual membuat pengiriman, sistem otomatis memilih kurir termurah yang masih andal, dan penjual mendapat label yang bisa dilacak tanpa harus membandingkan tarif secara manual di empat aplikasi kurir berbeda.
Itu memangkas daftarnya jadi enam untuk MVP:
- Penjual membuat pengiriman (input form manual, tanpa impor massal)
- Sistem membandingkan tarif dari 2 kurir (bukan multi-kurir, hanya dua yang paling sering dipakai)
- Sistem otomatis memilih opsi termurah di atas ambang batas keandalan tertentu
- Pembuatan label
- Pelacakan status dasar (polling API kurir secara manual, tanpa GPS real-time)
- Dashboard sederhana yang menampilkan status pengiriman per penjual
Sisanya, program loyalitas, notifikasi SMS, manajemen gudang, sistem referral, diparkir dulu. Tiga bulan kemudian, dengan versi enam-fitur yang sudah live, kami punya data nyata soal apakah penjual peduli dengan perbandingan tarif otomatis ini sampai mau membayarnya. Ternyata iya, yang kemudian membenarkan pembangunan sisanya. Kalau ternyata tidak, kami akan tahu itu dengan biaya yang jauh lebih kecil dibanding membangun versi 40-fitur.
Pola ini, membuktikan loop inti dulu sebelum mengotomasi operasi di sekitarnya, terus muncul berulang kali di produk-produk yang berdekatan dengan logistik; lihat Logistics Tech: The Unsexy Edge for Online Sellers untuk pembahasan lebih lanjut soal kenapa lapisan spesifik ini begitu penting bagi penjual online.
Tabel Scoping Singkat
| Pertanyaan | Kalau ya | Kalau tidak |
|---|---|---|
| Apakah transaksi inti gagal tanpa fitur ini? | Pertahankan di MVP | Potong atau palsukan |
| Bisakah ini dikerjakan manual untuk 20-50 pengguna pertama? | Palsukan secara manual | Pertimbangkan untuk dibangun |
| Apakah fitur ini menguji asumsi paling berisiko dalam bisnis? | Pertahankan di MVP | Tunda ke v2 |
| Apakah ketiadaan fitur ini akan menghentikan kita dari belajar apa pun? | Pertahankan di MVP | Potong |
Kesimpulannya
Scoping MVP bukan soal membangun secara kecil, melainkan soal membangun secara sempit dan tuntas. Temukan satu alur kerja yang menggerakkan uang, bangun itu saja sampai tuntas dari ujung ke ujung, dan palsukan sisanya dengan usaha manual sampai pemakaian nyata memberi tahu apa yang layak diotomasi. Kalau kamu sedang di tengah proses scoping dan bingung di mana harus menarik batas, why software estimates are always wrong juga layak dibaca, karena scope yang lebih ketat adalah pengungkit terbesar yang kamu punya atas akurasi estimasi.