Bayangkan timmu baru menghabiskan dua bulan membuat aplikasi belajar bahasa Inggris. Menu kursus sudah rapi, latihan grammar tersedia, dan skor pengguna bisa muncul otomatis. Namun ketika diluncurkan, hampir tidak ada yang kembali menggunakannya. Masalahnya mungkin bukan kualitas coding, melainkan sejak awal tim belum memahami bentuk bantuan yang benar-benar dibutuhkan pengguna.
Inilah jebakan yang sering muncul ketika startup langsung membangun produk minimal atau MVP, singkatan dari Minimum Viable Product. MVP adalah versi paling sederhana yang tetap memberi nilai nyata sekaligus membantu tim belajar dari penggunaan sebenarnya. Namun sebelum sampai ke sana, ada pekerjaan yang kerap dilewati: mendengarkan calon pengguna dengan cukup dekat dan cukup jujur.
Jangan mengubah dugaan menjadi produk
Ide bisnis biasanya berangkat dari dugaan: kelompok tertentu mengalami masalah, solusi tertentu akan membantu, dan mereka bersedia meluangkan waktu atau uang untuk mendapatkannya. Dugaan itu belum menjadi fakta hanya karena terdengar masuk akal bagi pendirinya. Jika langsung diterjemahkan menjadi aplikasi, tim sedang memperbesar biaya dari sebuah tebakan.
Risikonya bukan hanya waktu dan biaya pembuatan. Setelah produk telanjur ada, tim cenderung sibuk memperbaiki warna antarmuka, menambah fitur, atau mengejar unduhan, padahal belum tahu bagian mana yang sebenarnya salah. Kondisi ini dapat disebut MVP trap: tim terus mengoptimalkan sesuatu tanpa umpan balik nyata yang cukup untuk menentukan apa yang perlu dipertahankan, diubah, atau dihentikan.
Validasi dapat dimulai tanpa coding. Prototipe manual berupa alur di Figma, slide PowerPoint, atau coretan kertas sudah cukup untuk memperlihatkan cara kerja solusi. Tujuannya bukan membuat teknologi palsu yang tampak selesai, melainkan membuka percakapan tentang masalah, urutan tindakan, dan manfaat yang dibayangkan.
Misalnya, kamu ingin membantu pekerja muda belajar bahasa Inggris. Tampilkan tiga bagian sederhana: pilihan kursus, latihan, dan perkembangan kemampuan. Lalu ajak orang yang memang sesuai sasaran untuk melihatnya. Jangan hanya bertanya apakah tampilannya bagus; tanyakan bagian yang paling relevan, kegiatan yang selama ini paling sulit, dan bantuan apa yang akan membuat mereka mau belajar secara rutin.
Minat nyata lebih bernilai daripada pujian
Jawaban seperti “menarik” atau “sepertinya berguna” belum cukup kuat. Sinyal yang lebih bermakna muncul ketika seseorang mau mendaftar, mencoba alur manual, memberi waktu untuk wawancara lanjutan, memperkenalkanmu kepada pengambil keputusan, atau membayar sesuai kesepakatan yang jelas. Tindakan semacam itu tidak otomatis membuktikan model bisnis, tetapi menunjukkan bahwa solusi tersebut layak diuji lebih serius daripada sekadar ide yang dipuji.
Jumlah pengguna awal juga tidak memiliki ambang universal. Kelompok kecil yang relevan dapat menghasilkan pembelajaran penting jika percakapannya mendalam dan masalahnya benar-benar mereka alami. Sebaliknya, banyak pendaftar belum tentu berarti produk bernilai apabila mereka hanya mengisi formulir karena penasaran atau tidak pernah menggunakan solusi yang ditawarkan.
Karena itu, jangan memperlakukan target seperti 10 sampai 25 orang sebagai hukum validasi. Angka tersebut dapat menjadi titik awal untuk membentuk kelompok pengguna awal, tetapi kualitas kecocokan, kedalaman masalah, dan konsistensi pola jawaban jauh lebih penting. Yang dicari bukan persetujuan seragam, melainkan bukti yang membantu tim mengambil keputusan.
Pengguna awal sebagai rekan belajar
Early adopter, atau pengguna awal, adalah orang atau organisasi yang merasakan masalah cukup kuat dan bersedia mencoba solusi sebelum produk matang. Mereka bukan sampel yang mewakili seluruh pasar secara otomatis. Mereka adalah cermin awal untuk melihat apakah tim memahami masalah dengan benar, sekaligus sumber masukan untuk menentukan prioritas.
Khairun Rizki menceritakan dalam buku bahwa Sanbercode pernah menguji gagasan Learning Management System berbentuk SaaS, yaitu perangkat lunak yang digunakan sebagai layanan, untuk sekolah. Tim tidak langsung membangun aplikasi. Bersama ITB, mereka mengadakan webinar hybrid tentang digitalisasi pendidikan, lalu memperkenalkan konsep LMS melalui presentasi dan ilustrasi sederhana.
Setelah acara, peserta diminta mengevaluasi acara sekaligus memberi tanggapan terhadap konsep tersebut. Dari ratusan peserta, sekitar 20 sekolah menunjukkan minat untuk mencoba versi awal. Sekolah-sekolah itu kemudian menjadi kelompok diskusi yang diwawancarai lebih jauh mengenai administrasi, pembelajaran jarak jauh, serta kebutuhan guru dan siswa.
Baru setelah pemahaman itu cukup kuat, Sanbercode mulai membangun MVP. Fitur awalnya diarahkan pada kebutuhan yang sudah dikonfirmasi, bukan pada daftar keinginan internal tim. Dalam kisah tersebut, MVP kemudian digunakan oleh sekitar 20 sekolah dan, setelah pendaftaran dibuka untuk publik, lebih dari 600 sekolah bergabung dalam dua sampai tiga bulan tanpa iklan masif.
Angka itu bukan janji bahwa proses serupa akan menghasilkan pertumbuhan yang sama bagi setiap startup. Nilai penting dari pengalaman tersebut terletak pada urutannya: masalah dipahami, pengguna awal dilibatkan, solusi diuji, lalu distribusi diperluas. Jika beberapa pengguna pertama saja belum terbantu secara nyata, memperbesar pemasaran biasanya hanya memperbesar jumlah orang yang kecewa.
MVP dibuat untuk belajar, bukan berpura-pura sempurna
Setelah pola masalah dan kebutuhan mulai jelas, MVP menjadi masuk akal. Ia bukan produk akhir yang sengaja dibuat buruk, dan bukan pula versi setengah jadi yang meminta pengguna memaklumi semua kekurangan. MVP harus cukup berfungsi untuk memberikan nilai pada kasus penggunaan utama serta menghasilkan pembelajaran yang dapat ditindaklanjuti.
Misalnya, bila kebutuhan utama sekolah adalah memantau perkembangan siswa, versi pertama tidak harus langsung memiliki semua fitur administrasi, analitik, dan integrasi. Tim dapat memulai dari alur pemantauan yang paling penting, mendampingi pengguna secara manual bila perlu, lalu mengamati apakah alur itu benar-benar mengurangi pekerjaan mereka. Dari sana, keputusan tentang fitur berikutnya memiliki dasar yang lebih kuat.
Pendekatan ini mengubah ukuran kemajuan. Tim tidak hanya bertanya apakah produk sudah terlihat profesional, tetapi apakah pengguna berhasil menyelesaikan pekerjaan penting, manfaatnya terasa, dan masukan mereka mengubah keputusan produk. Jika hasilnya buruk, itu bukan alasan otomatis untuk menyalahkan pemasaran atau kompetitor. Bisa jadi masalah yang dipilih belum cukup penting, segmen pengguna keliru, atau solusi belum menyentuh akar kebutuhan.
Dalam tujuh hari, pilih satu masalah spesifik dan lima sampai sepuluh calon pengguna yang benar-benar mengalaminya. Tunjukkan prototipe manual atau alur layanan sederhana, lalu catat masalah yang mereka sebutkan, tindakan yang bersedia mereka lakukan, serta alasan mereka menolak. Jangan membangun fitur baru sebelum merangkum pola percakapan itu dan menentukan satu perubahan yang akan diuji pada pertemuan berikutnya.
