Setiap founder bilang MVP mereka "sudah minimal." Hampir semuanya salah. Scoping MVP yang benar bukan soal memotong rata di seluruh daftar fitur, tapi soal tahu mana bagian yang kosmetik dan mana yang menopang struktur, dan tidak pernah tertukar di antara keduanya saat tekanan deadline datang.
Saya sudah men-scope MVP untuk sistem inventory sebuah retail chain dan untuk internal tools di perusahaan multifinance, dan argumen yang sama selalu muncul, ada saja yang ingin memotong bagian yang justru struktural karena "terasa" seperti nice-to-have, sambil mempertahankan halaman setting yang tidak akan disentuh siapa pun di bulan pertama. Solusinya bukan rapat yang lebih panjang, tapi hierarki urutan potong yang diterapkan dengan cara yang sama setiap kali.
Berikut hierarki yang benar-benar saya pakai, diurutkan dari yang paling dulu keluar dari daftar peluncuran.
Potong Pertama: Apa Pun yang Bisa Dikerjakan Manual oleh Admin
Korban pertama harus selalu berupa halaman yang ada untuk memudahkan hidup orang internal, bukan untuk melayani pengalaman produk yang sesungguhnya. Dashboard admin, tampilan reporting, tools bulk-edit, ekspor CSV dengan lima opsi filter. Ini semua fitur yang nyata. Tapi bukan fitur MVP, karena seseorang dengan akses database atau spreadsheet bisa menggantikan semuanya untuk beberapa minggu pertama pemakaian.
Secara konkret, ini artinya:
- Tidak perlu UI admin untuk mengubah role user, cukup update database langsung.
- Tidak perlu dashboard analytics, tarik angkanya dengan query SQL saat ada yang bertanya.
- Tidak perlu tool bulk import, muat data awal secara manual atau dengan script sekali pakai.
Ini semua bukan soal malas. Ini soal menyadari bahwa tools semacam ini baru sepadan dengan biaya pembuatannya begitu volume pemakaian membuat kerja manual jadi menyakitkan, dan Anda belum tahu berapa volume itu.
Potong Kedua: Konfigurasi dan Kustomisasi
Lapisan kedua yang dipotong adalah apa pun yang memungkinkan user atau admin menyesuaikan perilaku sistem: halaman setting, matriks permission, theming, preferensi notifikasi. Konfigurabilitas mahal untuk dibangun dengan baik dan hampir selalu prematur, karena Anda belum tahu setting mana yang benar-benar diinginkan user Anda. Hardcode satu default yang masuk akal, luncurkan, dan biarkan pemakaian nyata memberi tahu apa yang perlu menjadi setting nanti.
Saya pernah melihat tim menghabiskan dua dari delapan minggu peluncuran mereka untuk halaman preferensi notifikasi dengan toggle granular, untuk produk yang bahkan belum terbukti ada yang menginginkan notifikasi sama sekali. Itu bukan disiplin scoping, itu membangun untuk power user hipotetis sebelum Anda bertemu user pertama Anda yang sesungguhnya.
Potong Ketiga: Otomasi, Ganti dengan Solusi Manual
Ini lapisan yang paling ditolak orang untuk dipotong, karena "otomasi" terdengar seperti inti dari produk itu sendiri. Tapi otomasi adalah pengganda dari proses yang sudah berjalan, bukan prosesnya itu sendiri. Jika tugas MVP Anda adalah membuktikan sebuah workflow punya nilai, Anda sering bisa mem-fake bagian yang otomatis dengan seseorang dan sebuah checklist untuk kohort pengguna pertama, dan baru membangun otomasinya setelah workflow itu sendiri tervalidasi.
Contoh konkret, fitur logistik yang otomatis menugaskan driver berdasarkan zona dan muatan bisa diluncurkan dengan penugasan manual oleh seorang dispatcher yang melihat daftar sederhana. Daftar itu perlu ada. Algoritma auto-assignment-nya bisa menunggu.
Jangan Pernah Dipotong: Satu Core Loop
Ini garis yang tidak boleh bergeser, seberapa pun besar tekanan deadline-nya: satu core loop yang membuat produk ini menjadi produk ini. Untuk marketplace, itu adalah pasang barang, jelajahi, beli. Untuk sistem fleet, itu adalah catat perjalanan, lihat statusnya, tutup perjalanan itu. Apa pun loop itu untuk bisnis Anda, ia harus berjalan end-to-end, dengan andal, di hari pertama, atau Anda tidak punya MVP, Anda punya prototipe dengan pitch deck yang bagus.
Tes yang saya pakai, jika Anda menghapus loop ini, apakah masih ada alasan bagi user untuk membuka aplikasi ini? Jika jawabannya tidak, berarti itu core, dan tidak boleh di-scope down, ia harus dibangun dengan benar sekalipun itu berarti tanggal peluncuran mundur.
Jangan Pernah Dipotong: Integritas Data Model
Hal kedua yang tidak boleh dipotong adalah kebenaran data model yang mendasari sistem Anda, khususnya relasi dan constraint yang mencegah data buruk masuk ke sistem sejak awal. Ini tidak terlihat oleh user dan sangat terasa menyakitkan bagi Anda enam bulan kemudian saat Anda migrasi database penuh dengan orphaned records dan entitas duplikat karena seseorang memutuskan foreign key constraint hanyalah "polesan backend" yang bisa menunggu.
Memotong UI itu reversibel. Memotong integritas data tidak, karena setiap record yang dibuat di bawah model yang rusak harus dibersihkan atau dibuang nanti, seringnya secara manual, seringnya di bawah tekanan waktu yang lebih berat dari sekarang. Jika Anda sedang menghadapi pembersihan semacam itu, Rewrite atau Refactor? Menentukan Nasib Aplikasi Legacy membahas cara menilai apakah perbaikan masih bisa diselamatkan atau Anda sudah melewati titik itu.
Cara Sederhana Menjalankan Ini Bersama Tim Anda
Saat tim Anda berbeda pendapat soal apa yang masuk scope, jangan berdebat fitur demi fitur dari daftar yang datar. Sebagai gantinya, ajukan dua pertanyaan berikut untuk setiap fitur yang diusulkan, secara berurutan:
- Bisakah seorang manusia menggantikan ini secara manual selama empat minggu tanpa membuat produk gagal?
- Jika ini dipotong, apakah itu merusak data atau menghancurkan satu hal yang membuat user datang ke sini?
Jika jawaban pertanyaan satu adalah ya, potong. Jika jawaban pertanyaan dua adalah ya, itu tetap ada apa pun yang lain harus dikorbankan. Semua yang lain adalah trade-off nyata yang layak didiskusikan sungguh-sungguh, tapi dua pertanyaan ini menyelesaikan sekitar 80% perdebatan scoping sebelum perdebatan itu dimulai.
Kesimpulan
Scoping MVP bukan versi lebih kecil dari produk lengkap, ini adalah taruhan tentang bagian mana dari produk yang struktural dan mana yang sekadar kenyamanan. Potong kenyamanan secara agresif. Lindungi core loop dan data model seolah-olah keduanya adalah satu-satunya hal yang penting, karena untuk versi pertama, memang begitu adanya.