Cara menentukan feedback pengguna mana yang dibangun (dan mana yang dilepaskan)
Begitu orang memakai aplikasimu, permintaan mulai mengalir deras. Inilah cara sederhana untuk menentukan feedback pengguna mana yang layak dibangun dengan AI app builder-mu, mana yang diparkir, dan mana yang ditolak dengan sopan.
Beberapa minggu pertama setelah orang mulai memakai aplikasimu terasa sepi. Lalu pesan-pesan mulai berdatangan. “Bisakah kamu menambahkan dark mode?” “Akan keren kalau aku bisa ekspor ke PDF.” “Bisakah tombolnya dibuat biru?” “Kami benar-benar butuh integrasi dengan tools yang sudah kami pakai.” Dalam sebulan kamu punya daftar empat puluh hal, dan AI app builder yang dengan senang hati akan membangun salah satunya untukmu dalam satu sore.
Bagian terakhir itulah jebakannya. Saat membangun setiap fitur itu murah dan cepat, pertanyaan sulitnya berhenti menjadi “bisakah aku membangun ini?” dan berubah jadi “haruskah aku?” Penyumbatannya berpindah dari tanganmu ke penilaianmu, dan tidak ada yang menyodorkan panduan untuk itu.
Tulisan ini adalah cara sederhana untuk menyortir feedback yang masuk ke dalam tiga tumpukan — bangun, parkir, lepaskan — tanpa perlu latar belakang manajemen produk. Tujuannya bukan untuk menolak orang. Tujuannya adalah memastikan hal-hal yang kamu bangun benar-benar memajukan aplikasimu.
Kenapa “bangun saja” berhenti berhasil
Untuk sepuluh fitur pertamamu, “bangun saja apa pun yang diminta orang” adalah strategi yang baik-baik saja. Kamu belum punya cukup pengguna untuk punya pendapat yang bertentangan, dan setiap fitur membuat aplikasinya lebih berguna daripada benda kosong yang ia jadi minggu lalu.
Itu berhenti berhasil sekitar saat kamu punya pengguna yang nyata dan berbeda-beda. Seorang freelancer ingin satu hal, sebuah agensi kecil ingin kebalikannya, dan seorang pengunjung sekali datang ingin sesuatu yang tak satu pun dari mereka akan pernah pakai. Bangun ketiganya dan aplikasimu berubah jadi laci sampah — penuh barang, susah mencari apa pun, berat untuk dibawa. Setiap fitur yang kamu tambahkan adalah fitur yang harus kamu jaga agar terus berfungsi selamanya, jelaskan ke pengguna baru, dan jangan sampai rusak saat kamu mengubah sesuatu di dekatnya.
AI app builder memperburuk ini sebelum memperbaikinya, karena ia menghilangkan rem alaminya. Saat sebuah fitur butuh dua minggu kerja developer, kamu berpikir keras apakah itu layak dua minggu. Saat builder-nya cuma butuh dua puluh menit, kamu tidak berpikir sama sekali — kamu langsung bilang ya. Biayanya tidak hilang. Ia berpindah dari “waktu untuk membangun” ke “beban untuk dibawa”, dan beban lebih sulit dilihat.
Tiga pertanyaan yang menyortir hampir segalanya
Saat sebuah permintaan masuk, jalankan lewat tiga pertanyaan secara berurutan. Sebagian besar hal akan tersortir sendiri setelah dua pertanyaan pertama.
1. Apakah ini membantu orang yang menjadi tujuan aplikasi ini kubangun? Kamu membangun aplikasimu untuk seseorang yang spesifik — fotografer pernikahan, pelatih sepak bola usia muda, host podcast indie. Permintaan dari salah satu orang itu lebih berharga daripada permintaan dari seseorang yang nyasar masuk dan tak akan pernah kembali. Kalau sebuah fitur membantu orang inti melakukan hal utama yang membuat mereka datang, fitur itu naik ke atas. Kalau fitur itu membantu pengunjung yang sebenarnya bukan penggunamu, fitur itu turun ke bawah, sekeras apa pun mereka memintanya.
2. Berapa banyak orang yang benar-benar akan memakainya? Bukan “siapa yang meminta” — siapa yang akan memakai. Satu orang yang meminta dengan keras tidak sama dengan sepuluh orang yang diam-diam akan mendapat manfaatnya. Jujurlah di sini, karena permintaan yang keras terasa seperti permintaan besar, padahal biasanya tidak. Petunjuk yang bagus: tanyakan pada orang itu apa yang ia lakukan hari ini sebagai gantinya. Kalau ia punya akal-akalan kikuk yang ia pakai setiap hari, itu kebutuhan nyata. Kalau ia “mungkin akan memakainya sesekali”, itu nice-to-have yang menyamar.
3. Berapa biayanya bagiku untuk membawanya selamanya? Sebagian fitur itu ringan. Sebuah opsi warna baru, sebuah label yang dirombak, sebuah field tambahan pada formulir — bangun lalu lupakan. Sebagian fitur itu berat: apa pun yang menyentuh pembayaran, apa pun yang mengirim email ke orang sungguhan, apa pun yang menambahkan satu bagian baru utuh dengan aturannya sendiri. Fitur berat bukan hal buruk, tapi mereka harus mengimbangi bebannya dengan melewati dua pertanyaan pertama dengan ruang lebih.
Tiga tumpukan
Jalankan pertanyaan-pertanyaan itu dan hampir segalanya akan mendarat di salah satu dari tiga tempat.
Bangun. Membantu orang intimu, beberapa dari mereka akan memakainya, dan biaya membawanya masuk akal. Yang ini mudah. Kerjakan, dan beritahu orang yang memintanya — orang yang melihat idenya dirilis menjadi pengguna paling setiamu dan sumber terbaikmu untuk ide bagus berikutnya.
Parkir. Ide bagus, tapi masih terlalu dini, atau cuma satu orang yang menginginkannya, atau ia berat dan kamu belum yakin. Jangan menolak dan jangan membangunnya. Tuliskan di suatu tempat yang benar-benar akan kamu lihat — daftar sederhana, sebuah catatan, sebuah papan. Kalau tiga orang lagi meminta hal yang sama dalam sebulan ke depan, ia baru saja mempromosikan dirinya sendiri ke tumpukan bangun dan memberitahumu begitu. Memarkir bukanlah kuburan; ia adalah ruang tunggu.
Lepaskan. Ia tidak cocok dengan tujuan aplikasimu, ia hanya akan melayani satu orang, atau ia akan membuat aplikasinya lebih buruk untuk semua orang lain. Ini butuh penolakan yang sopan dan jujur. “Itu ide yang penuh pemikiran, tapi bukan sesuatu yang aku rencanakan untuk ditambahkan — ini yang akan kusarankan sebagai gantinya” menjaga hubungan dan melindungi aplikasinya. Mengatakan tidak adalah sebuah fitur. Setiap tidak adalah ya untuk menjaga aplikasinya tetap cukup sederhana sampai orang memahaminya.
Sebuah contoh kecil
Seseorang yang kami kenal menjalankan aplikasi booking untuk guru musik, dibangun seluruhnya dengan AI app builder. Dalam satu minggu ia mendapat tiga permintaan: seorang guru ingin SMS pengingat otomatis ke murid, seorang orang tua ingin cara untuk melihat semua les anak-anaknya dalam satu tampilan, dan satu orang ingin aplikasinya diterjemahkan ke bahasa Latin “untuk seru-seruan”.
Pengingat itu melewati ketiga pertanyaan — pengguna inti, banyak dari mereka berurusan dengan murid tidak datang, dan SMS itu berat tapi sepadan. Dibangun. Tampilan orang tua adalah ide bagus dari satu orang, jadi ia memarkirnya; dua orang tua lagi meminta dalam tiga minggu dan ide itu mempromosikan dirinya sendiri. Terjemahan bahasa Latin mendapat penolakan yang hangat. Tak satu pun dari keputusan itu butuh spreadsheet. Mereka butuh tiga pertanyaan dan kesediaan menjawab yang ketiga dengan jujur.
Bagian yang tak seorang pun beritahu kamu
Feedback tersulit untuk ditangani bukanlah ide buruk. Ia adalah ide bagus dari orang yang kamu sukai, untuk aplikasi yang tidak bisa menjadi segalanya. Melepaskan ide-ide itu terasa seperti mengecewakan orangnya. Padahal tidak. Hal paling baik yang bisa kamu lakukan untuk orang yang memakai aplikasimu adalah menjaganya tetap cukup fokus supaya ia tetap jago di satu hal yang membuat mereka datang.
Lain kali saat permintaan menumpuk, jangan buka AI app builder-mu lebih dulu. Buka daftarmu, jalankan setiap item lewat tiga pertanyaan, dan sortir ke dalam tumpukan. Membangun adalah bagian yang mudah sekarang. Menentukan apa yang layak dibangun adalah pekerjaan yang sebenarnya — dan itu pekerjaan yang bisa kamu lakukan tanpa menulis satu baris kode pun.