Jebakan Scope Creep: Cara Menolak Fitur yang Terdengar Bagus Padahal Tidak

Kamu merilis sebuah aplikasi. Pengguna berdatangan. Dan sekarang kotak masukmu penuh dengan permintaan fitur yang semuanya terdengar seperti ide bagus.

“Bisa nggak ditambahkan export ke Excel?” Masuk akal. “Bisa nggak invoice dikirim otomatis?” Logis. “Bisa nggak diintegrasikan dengan Stripe?” Di situlah uang sungguhan berada. “Bisa nggak ditambahkan aplikasi mobile?” Semua orang meminta itu. “Bisa nggak ini di-white-label untuk pelanggan kami sendiri?” Oh, sekarang ada model bisnis.

Setiap permintaan kalau sendirian terdengar cerdas. Digabungkan, kedengarannya seperti kamu sedang membangun lima produk berbeda.

Ini namanya scope creep, dan ia membunuh lebih banyak aplikasi kecil buatan AI daripada masalah teknis mana pun. Bukan karena kamu membangun fiturnya — tapi karena kamu kehabisan waktu, uang, atau kewarasan saat mencoba membangunnya.

Bagaimana scope creep membunuh aplikasi yang berfungsi

Inilah yang terjadi. Kamu mengiyakan tiga permintaan pertama karena tampak masuk akal. Kamu meminta AI builder-mu menambahkannya. Butuh dua minggu alih-alih satu karena setiap fitur baru bertabrakan dengan kode yang sudah ada. Sekarang kamu punya aplikasi yang mengerjakan lima hal, dan mengerjakan tiga dengan baik dan dua dengan lumayan.

Lalu permintaan keempat tiba: “Bisa nggak ada level izin yang berbeda-beda?” Tiba-tiba kamu perlu memikirkan ulang siapa yang bisa melihat apa di setiap layar. Itu bukan fitur; itu perubahan arsitektur. Kamu meminta AI builder-mu mengerjakannya. Ia menyentuh segalanya. Dua minggu menjadi tiga. Aplikasi jadi lebih lambat karena kamu menambahkan logika ke setiap tampilan.

Saat permintaan kedelapan, kamu sudah berhenti merilis hal baru untuk pengguna awalmu karena terlalu sibuk menjaga mesin permintaan fitur tetap berputar. Orang-orang yang menyukai aplikasi tiga bulan lalu frustrasi karena tidak ada yang mereka minta selesai. Orang-orang yang mengajukan permintaan baru frustrasi karena fitur memakan waktu selamanya.

Kamu membangun sesuatu yang berfungsi. Kamu merusaknya dengan mencoba menjadi segalanya.

Kerangka keputusan

Kamu butuh sebuah gerbang. Setiap permintaan fitur melewati tiga pertanyaan:

Pertanyaan 1: Apakah ini termasuk dalam aplikasi ini, atau ini aplikasi yang berbeda?

Aplikasi pertamamu mengerjakan satu pekerjaan dengan sangat baik. Aplikasi penjadwalan menjadwalkan sesuatu. Aplikasi invoice membuat invoice. Itu aplikasi yang berbeda. Kalau ada yang meminta aplikasi penjadwalanmu membuat invoice, kamu bukan menambahkan fitur — kamu meminta aplikasi penjadwalan mengerjakan akuntansi. Itu produk yang berbeda.

Tes yang bagus: “Kalau saya ambil fitur ini dan merilisnya secara mandiri, apakah orang mau membelinya?” Kalau ya, fitur itu kemungkinan termasuk dalam aplikasi yang berbeda. Kalau jawabannya “tidak, ini hanya masuk akal sebagai bagian dari hal yang lebih besar,” maka kamu sedang membangun scope yang tepat.

Kamu akan mendapat permintaan seperti “integrasikan dengan CRM kami.” Apa yang sebenarnya itu maksudkan adalah “jadilah CRM-mu sendiri.” Itu aplikasi yang berbeda. Kamu bisa berintegrasi dengan CRM nanti. Kamu tidak bisa menambahkan fitur senilai satu CRM tanpa menjadi CRM.

Pertanyaan 2: Apakah ini menyelesaikan masalah bagi sebagian besar penggunamu, atau hanya yang satu ini?

Satu pelanggan menyukai aplikasimu dan punya ide fitur. Itu masalah nyata yang mereka miliki. Itu juga masalah nyata yang hanya mereka miliki.

Kalau kamu punya dua puluh pengguna dan satu meminta sesuatu, periksa: apakah sembilan belas lainnya juga menunggu ini, atau orang ini baru saja memikirkannya? Kamu bisa bertanya langsung: “Sebelum Anda, apakah Anda pernah berpikir untuk menanyakan ke orang lain apakah mereka membutuhkan ini?” Biasanya jawabannya tidak.

Ini pertanyaan berbahaya karena satu pelanggan yang bertanya itu mungkin pelanggan terpentingmu. Mungkin kamu perlu menjaga mereka tetap senang. Itu keputusan bisnis, bukan keputusan produk. Tapi masuklah dengan mata terbuka: kalau kamu membangun sesuatu untuk satu pelanggan, kamu bukan menumbuhkan aplikasimu, kamu sedang membangun praktik konsultasi.

Pertanyaan 3: Berapa biayanya dan berapa biaya bagi ide aslinya?

Segalanya ada biayanya. Export ke Excel menghabiskan waktu engineering-mu. Ia menambah kompleksitas aplikasimu. Ia menghabiskan fokus. Bangun itu alih-alih optimasi performa yang dikeluhkan penggunamu setiap hari, dan kamu sudah membuat sebuah pilihan.

Tanyakan secara konkret: “Kalau saya bangun ini, apa yang tidak saya bangun?” Kalau jawabannya “tidak ada, kita punya waktu tak terbatas,” kamu tidak jujur. Kita tidak punya. Waktu itu terbatas.

Biaya bagi ide asli sering tidak terlihat. Saat kamu tenggelam dalam permintaan fitur, kamu berhenti merawat hal inti yang disukai orang darimu. Inti jadi lebih lambat. Inti jadi lebih banyak bug. Inti terasa terabaikan. Dan akhirnya orang pergi karena aplikasi yang dulu berfungsi hebat sekarang berfungsi lumayan dan mengerjakan hal-hal yang tak pernah dirancang untuknya.

Contoh nyata: formulir intake

Seseorang membangun formulir intake klien yang sederhana. Klien mengisinya, sang coach meninjaunya, mereka menjadwal. Itulah aplikasinya.

Permintaan satu: “Bisa nggak saya menandai intake yang mendesak?” Ya, itu variasi dari alur kerja inti. Bangun.

Permintaan dua: “Bisa nggak saya export intake ke Excel untuk arsip saya?” Ini fitur dokumen. Itu bukan tugas aplikasi. Intake hidup di dalam aplikasi. Kalau mereka butuh Excel, mereka bisa copy-paste. Tapi oke, export mungkin masuk akal sebagai kemudahan. Bangun.

Permintaan tiga: “Bisa nggak intake otomatis membuat event kalender?” Sekarang kamu sedang mengerjakan penjadwalan. Aplikasi ini untuk intake, bukan penjadwalan. Kalau ada yang menginginkan keduanya, mereka kemungkinan menginginkan sistem penjadwalan sungguhan, bukan tambalan yang menempelkannya. Tolak dengan sopan.

Permintaan empat: “Bisa nggak coach mengirim follow-up intake lewat SMS?” Sekarang kamu jadi sistem komunikasi. Tidak.

Saat permintaan tiga, kamu sudah mencapai batas. Aplikasi ini adalah intake. Apa pun yang lain adalah aplikasi yang berbeda. Kamu bisa berintegrasi dengan aplikasi-aplikasi itu nanti. Kamu tidak bisa menambahkannya tanpa menjadi aplikasi-aplikasi itu.

Cara mengatakan tidak

Bagian tersulit adalah benar-benar mengatakannya. Kamu tidak ingin membuat penggunamu frustrasi.

Jujurlah: “Itu ide bagus, tapi itu produk yang berbeda dari yang kami bangun di sini. Yang kami bangun adalah [satu pekerjaanmu]. Kalau kami mencoba mengerjakan penjadwalan atau invoice atau urusan CRM, kami akan lumayan di semuanya dan hebat di tidak satu pun.”

Sering kali pelanggan akan paham. Mereka bertanya karena idenya terlintas pada mereka, bukan karena mereka sedang mengujimu.

Kadang mereka akan mendesak balik. “Tapi saya butuh keduanya.” Saat itulah kamu merekomendasikan: pakai aplikasi penjadwalan sungguhan. Pakai aplikasi invoice sungguhan. Pakai CRM sungguhan. Lalu pakai aplikasi ini untuk hal yang ia kerjakan dengan baik. Itu jawaban yang jujur.

Godaan untuk menjadi segalanya

Bagian tersulit dari membangun produk kecil adalah mengatakan tidak. Tidak terasa seperti meninggalkan uang di atas meja. Bagaimana kalau pelanggan itu sebenarnya bersedia membayar untuk keduanya? Bagaimana kalau fitur itu akan membuatmu sepuluh kali lebih besar?

Mungkin. Tapi kamu bukan produk sepuluh kali lebih besar kalau kamu tidak merilisnya. Kamu adalah produk setengah jadi yang mengerjakan lima hal dengan buruk. Orang-orang yang menyukai intinya frustrasi. Orang-orang yang menginginkan fitur baru frustrasi. Dan kamu sudah menyudutkan diri sendiri di mana menambahkan apa pun yang baru berarti harus me-refactor lima hal lama dulu.

Produk yang tumbuh adalah yang mengerjakan satu pekerjaan dengan sangat baik, lalu menambah dengan hati-hati. Mereka tidak mencoba menjadi Salesforce sejak hari pertama. Mereka adalah aplikasi yang kamu ambil saat butuh mengerjakan satu hal itu, dan aplikasi yang kamu percaya akan cepat dan andal saat kamu memakainya.

Katakan tidak. Lindungi intinya. Lakukan itu, dan kamu akan membangun sesuatu yang benar-benar ingin digunakan orang.