Setiap founder bilang MVP mereka "sederhana." Lalu mereka menunjukkan spek dengan lima peran pengguna, program referral, dan dukungan multi-currency sebelum satu pun pelanggan membayar. Itu bukan MVP, itu produk lengkap yang memakai baju lebih kecil. Kalau Anda ingin tahu cara menentukan scope MVP yang benar-benar rilis dalam hitungan bulan, bukan tahun, disiplinnya bukan soal kreativitas, melainkan soal pengurangan.
Saya sudah melihat pola ini berulang kali pada founder-founder di Jakarta dan Tangerang: idenya solid, pasarnya nyata, tapi timnya tetap menghabiskan delapan bulan membangun hal-hal yang belum diminta siapa pun. Penyebabnya jarang sekali soal engineering yang buruk. Ini soal scope creep yang menyamar jadi kehati-hatian, di mana setiap stakeholder menambahkan "satu fitur lagi saja" karena rasanya tidak bertanggung jawab kalau tidak dimasukkan.
Menyusun scope MVP dengan benar berarti memperlakukan disiplin scope sebagai skill produk yang sesungguhnya, bukan sekadar basa-basi sebelum pengembangan "yang beneran" dimulai.
Pilih Satu Pengguna, Bukan Setumpuk Persona
Kebanyakan spek MVP dibuka dengan tiga atau empat persona: admin, power user, casual browser, enterprise buyer. Itu roadmap untuk produk yang sudah matang, bukan titik awal. Pilih satu pengguna yang masalahnya paling menyakitkan dan paling sering terjadi, lalu bangun hanya untuk mereka.
Untuk sebuah jaringan ritel di Tangerang yang membangun tool permintaan stok internal, godaannya adalah melayani store manager, staf gudang, dan finance sekaligus. Kami menyusun scope versi satu hanya untuk staf gudang, kelompok yang setiap hari tiga kali harus memasukkan ulang permintaan kertas ke spreadsheet secara manual. Yang lain menunggu. Batasan itulah yang membuat kami bisa rilis dalam enam minggu, bukan enam bulan.
Satu Alur Kerja, Tuntas dari Ujung ke Ujung
Aturan kedua: MVP Anda harus menyelesaikan satu alur kerja secara penuh, bukan lima alur kerja setengah jadi. Alur approval setengah jadi, dashboard reporting setengah jadi, dan sistem notifikasi setengah jadi, jika dijumlahkan hasilnya nol produk yang benar-benar berfungsi. Satu alur kerja, tuntas dari ujung ke ujung dengan data nyata, jauh lebih baik daripada lima janji yang tidak ditepati.
Ajukan pertanyaan ini untuk setiap permintaan fitur: apakah ini bagian dari alur kerja tunggal yang sedang kita rilis, atau ini hidup di sekitarnya? Kalau hidup di sekitarnya, itu bukan untuk versi satu.
Tentukan Ukuran Keberhasilan Sebelum Menentukan Fitur
Sebelum menyusun scope satu layar pun, tuliskan satu metrik yang menunjukkan MVP ini berhasil. Bukan lima metrik, satu. Untuk proyek-proyek logistik dan ritel yang saya tangani, bentuknya biasanya seperti ini:
- Waktu untuk mencatat permintaan stok turun dari 15 menit jadi di bawah 2 menit.
- Persentase permintaan yang diajukan tanpa perlu telepon ke gudang.
- Jumlah rekonsiliasi manual yang dibutuhkan per minggu.
Kalau sebuah fitur yang diusulkan tidak menggerakkan angka itu, itu scope creep, sebagus apa pun idenya kedengarannya di rapat. Aturan satu-metrik ini jauh lebih efektif mencegah pembengkakan scope dibanding matriks prioritas sebanyak apa pun.
Ritual Parking Lot
Ide-ide bagus tidak berhenti muncul hanya karena Anda sudah menyusun scope MVP. Triknya bukan menolaknya, melainkan menundanya secara terbuka. Saya menjalankan setiap proyek dengan daftar version-two yang terbuka dan tertulis, biasanya berupa dokumen bersama atau kolom board sederhana berlabel "Belum Sekarang." Setiap stakeholder bisa menambahkan ke sana. Tidak ada yang dibuang diam-diam, dan ini menghilangkan tekanan politis untuk menyelundupkan fitur ke versi satu karena takut dilupakan.
Ritual ini lebih penting daripada toolnya. Parking lot yang hanya bisa dilihat tim engineering tidak membangun kepercayaan dengan pihak bisnis. Buat terlihat oleh siapa pun yang mendanai pembangunan ini, sehingga "tidak" terbaca sebagai "belum sekarang, dan ini tempat idenya disimpan."
Apa yang Masuk Versi Satu vs Versi Dua
| Versi Satu | Versi Dua |
|---|---|
| Satu peran pengguna, terlayani penuh | Peran dan izin tambahan |
| Satu alur kerja inti, tuntas ujung ke ujung | Alur kerja terkait dan kasus-kasus tepi |
| Override admin manual bila diperlukan | Tooling admin otomatis |
| Notifikasi dasar (satu kanal) | Alert multi-kanal yang bisa dikonfigurasi |
| Aturan bisnis hardcoded yang berlaku hari ini | Rules engine yang bisa dikonfigurasi |
Baris terakhir itu sering menjebak banyak tim teknis. Engineer suka membangun sistem yang bisa dikonfigurasi karena terasa lebih "benar." Untuk MVP, meng-hardcode aturan bisnis aktual hari ini dan langsung rilis adalah keputusan yang tepat. Anda bisa menggeneralisasinya nanti setelah melihat penggunaan nyata membuktikan bagian mana yang benar-benar perlu fleksibel.
Timeboxing Memaksa Keputusan yang Nyata
Tetapkan tanggal rilis sebelum memfinalisasi daftar fitur, bukan sesudahnya. Tim yang diberi tahu "rilis apa pun yang muat dalam delapan minggu" membuat keputusan scope yang lebih tajam dibanding tim yang diberi tahu "rilis kalau sudah selesai." Deadline adalah forcing function yang mengubah perdebatan kabur soal prioritas menjadi trade-off yang konkret. Di sinilah juga banyak tim diuntungkan oleh suara dari luar: seseorang yang tidak punya keterikatan emosional pada fitur tertentu bisa memangkas lebih cepat dibanding tim internal, yang masing-masing diam-diam melindungi fitur favoritnya.
Kalau tim Anda konsisten melewatkan deadline yang mereka tetapkan sendiri, deadline itu memang tidak pernah nyata, dan setiap stakeholder secara bawah sadar sudah tahu itu. Selesaikan dulu masalah ini sebelum memperbaiki proses scoping Anda. Masih berkaitan dengan masalah disiplin, bukan masalah tooling, baca kenapa bisnis Anda butuh strategi teknologi, bukan sekadar website sebagai tulang punggung dari pembangunan yang tersusun bertahap.
Kesimpulan: Rilis Irisan Tipisnya, Bukan Potongan Utuhnya
MVP adalah irisan tipis dari produk akhir, bukan potongan utuh. Potongan utuh terlihat seperti produk jadi tapi lebih tipis di semua sisi. Irisan tipis adalah satu hal, dikerjakan tuntas, yang benar-benar diandalkan pengguna nyata besok pagi. Kalau Anda sedang menyusun scope untuk build berikutnya, tuliskan satu pengguna, satu alur kerja, dan satu metrik keberhasilan dalam satu halaman sebelum siapa pun membuka tool desain. Sisanya masuk parking lot, secara tertulis, aman di sana sampai tiba gilirannya.