Cara Menulis Non-Goals dalam PRD MVP agar AI Tidak Membuat Aplikasi Terlalu Besar

Ketika menjelaskan ide aplikasi kepada AI, kebanyakan orang fokus pada daftar fitur yang ingin ada. Jarang yang menulis apa yang sengaja belum dibuat. Akibatnya, agent melihat ruang kosong sebagai undangan untuk menambah: role baru, notifikasi, dashboard lanjutan, pembayaran, integrasi, atau pengaturan yang belum pernah dibutuhkan. Hasilnya terlihat ambisius, tetapi MVP menjadi lambat dibangun dan sulit diuji.

Non-goals adalah bagian PRD yang menyebut batas scope secara eksplisit. Ia bukan daftar kekurangan atau pengakuan bahwa produk belum lengkap. Ia adalah keputusan sadar bahwa sesuatu ditunda karena belum diperlukan untuk membuktikan nilai utama. Di Skematik, non-goals membantu generator dan agent fokus pada MVP, lalu memberi tim alasan yang jelas ketika ide tambahan muncul di tengah implementasi.

Mengapa AI perlu diberi tahu apa yang tidak dibuat

Agent dioptimalkan untuk membantu menyelesaikan permintaan. Saat Anda menulis “aplikasi booking”, ia dapat berasumsi perlu pembayaran online, kalender sinkron, pengingat WhatsApp, multi-cabang, kupon, dan analitik. Beberapa memang mungkin berguna nanti, tetapi asumsi itu tidak sama dengan kebutuhan MVP. Non-goals memutus jalur spekulasi sebelum masuk ke task, skema data, dan kode.

Batas juga membantu manusia. Saat klien meminta tambahan kecil, tim dapat menilai apakah itu mendukung tujuan MVP atau masuk fase berikutnya. Tanpa batas tertulis, diskusi scope menjadi debat ingatan. Dengan non-goals, semua orang dapat melihat apa yang sengaja ditunda dan alasan mengapa keputusan itu masuk akal saat ini.

Tulis non-goals yang spesifik dan dapat dipahami

• “Belum ada pembayaran online pada MVP; pembayaran dicatat manual oleh admin.”
• “MVP hanya untuk satu cabang, belum ada pemisahan data antar-cabang.”
• “Belum ada notifikasi otomatis; admin melihat daftar booking dari dashboard.”
• “Belum ada aplikasi mobile native; pengguna memakai web responsif.”
• “Belum ada import data massal; input awal dilakukan satu per satu.”

Hindari kalimat seperti “fitur lanjutan tidak termasuk” karena tidak memberi batas nyata. Sebutkan fitur atau kemampuan yang mungkin terlihat wajar bagi orang lain, tetapi memang belum akan dibuat. Jika sebuah fitur mungkin ditambahkan kemudian, tulis juga pemicu atau alasan fase berikutnya agar penundaannya tidak tampak asal.

MVP bukan produk setengah jadi. MVP adalah produk dengan satu janji utama yang dapat dibuktikan tanpa membawa seluruh masa depan ke rilis pertama.

Pilih batas berdasarkan hipotesis yang ingin diuji

Tanyakan: masalah paling kecil apa yang perlu diselesaikan agar pengguna mau mencoba atau membayar? Untuk sistem booking, mungkin pelanggan cukup bisa memilih slot dan admin bisa melihat daftar booking tanpa tabrakan. Pembayaran online mungkin berguna, tetapi tidak diperlukan untuk menguji apakah orang mau melakukan booking. Untuk kasir, pencatatan transaksi dan stok dasar mungkin lebih penting daripada loyalty points atau integrasi akuntansi.

Jangan memakai non-goals untuk menyembunyikan masalah penting. Jika aplikasi menyimpan uang atau data sensitif, keamanan dan validasi bukan fitur tambahan yang dapat ditunda. Bedakan antara kemampuan yang memperluas nilai produk dengan perlindungan minimum yang membuat jalur inti aman dipakai.

Turunkan batas scope ke task dan acceptance criteria

Setelah non-goals ditulis, periksa task graph. Hapus task yang hanya melayani kemampuan yang ditunda. Periksa skema data agar tidak terlalu dini menyiapkan puluhan tabel untuk fase jauh. Periksa acceptance criteria supaya tidak menjanjikan perilaku yang belum ada. Konsistensi inilah yang membuat non-goals benar-benar menjaga waktu dan biaya, bukan hanya catatan di overview.

Jika agent menyarankan fitur di luar batas, jangan langsung menganggapnya buruk. Catat sebagai kandidat fase berikutnya, lalu lanjutkan task MVP. Ide yang bagus tetap bisa disimpan tanpa memaksa rilis pertama memikul semua pekerjaan. Riwayat versi PRD membantu saat keputusan fase dua mulai dipersiapkan.

Review non-goals pada setiap perubahan besar

1. Tulis tiga sampai lima kemampuan yang paling mungkin membuat scope melebar.
2. Pastikan batas tidak meniadakan keamanan atau fungsi inti.
3. Cek bahwa task dan acceptance criteria tidak masih menjanjikan fitur yang ditunda.
4. Gunakan daftar ini saat menerima permintaan baru di tengah proyek.
5. Pindahkan item ke scope hanya ketika ada alasan bisnis dan kapasitas yang jelas.