Kenapa Mudah Bikin Aplikasi, tapi Gak Mudah Menjual Aplikasi yang Dibutuhkan?

“The aim of marketing is to know and understand the customer so well the product or service fits him and sells itself.” Peter Drucker, dalam buku Management: Tasks, Responsibilities, Practices.

Kamu bisa menghabiskan akhir pekan bikin aplikasi, mengatur fitur, lalu membagikan tautannya ke grup teman, tetapi tetap bingung kenapa gak ada yang mau membayar.

Masalahnya sering bukan karena aplikasimu kurang canggih, melainkan karena orang belum melihat alasan kuat untuk memakainya.

Itulah kenapa menjual aplikasi butuh pemahaman yang beda dari sekadar membuatnya.

Kamu perlu tahu masalah siapa yang diselesaikan, seberapa mudah produk dipakai, dan gimana menjelaskan manfaatnya dengan bahasa yang dipahami calon pengguna.

 

Kenapa Menjual Aplikasi Perlu Dimulai dari Masalah Pengguna?

Banyak aplikasi berangkat dari ide yang terdengar menarik bagi pembuatnya, tetapi belum tentu penting bagi orang lain.

Misalnya, kamu membuat aplikasi pencatat pengeluaran dengan grafik warna-warni karena ingin belajar pemrograman.

Namun calon pengguna mungkin udah nyaman mencatat di spreadsheet, atau merasa pengeluarannya terlalu kecil untuk dilacak setiap hari.

Fitur aplikasinya bisa berfungsi dengan baik, tetapi dorongan untuk pindah dari kebiasaan lama belum cukup kuat.

Clayton Christensen menjelaskan gagasan Jobs to Be Done sebagai cara memahami kemajuan yang ingin dicapai seseorang dalam situasi tertentu.

Artinya, calon pengguna bukan cuma mencari produk dengan daftar fitur panjang.

Mereka mencari cara untuk menyelesaikan pekerjaan yang terasa merepotkan, mahal, lambat, atau bikin khawatir.

Masalah yang spesifik membuat kebutuhan itu lebih mudah dikenali dan diuji.

Daripada berkata aplikasi kamu membantu semua orang mengatur uang, coba cari satu kelompok yang punya masalah jelas.

Contohnya, pekerja lepas yang kesulitan memisahkan uang pribadi dan uang proyek sebelum jadwal bayar tagihan.

Masalah seperti itu bisa ditelusuri lewat percakapan, bukan cuma ditebak dari asumsi pembuat produk.

Kamu bisa mengobrol dengan lima sampai sepuluh pekerja lepas dan menanyakan pengalaman mereka mencatat pemasukan terakhir.

Tanyakan juga bagian mana yang paling bikin mereka menunda, kesalahan apa yang sering terjadi, dan solusi apa yang pernah dicoba.

Hindari pertanyaan seperti apakah mereka suka ide aplikasimu karena orang sering menjawab iya untuk bersikap ramah.

Lebih baik minta mereka bercerita tentang kejadian nyata dan kebiasaan yang udah dilakukan.

Dari cerita itu, kamu bisa melihat apakah masalahnya muncul berulang atau cuma terjadi sekali.

Kalau orang yang diwawancarai gak merasa masalah itu penting, jangan langsung menambah fitur.

Periksa dulu apakah sasaran pengguna dan masalah yang kamu pilih memang tepat.

“Tapi kan aplikasiku bisa dipakai siapa aja?” Bisa saja, tetapi pesan untuk semua orang sering terasa kurang relevan bagi siapa pun.

Memilih kelompok awal bukan berarti menutup peluang pasar lain selamanya.

Kamu sedang mencari pintu masuk yang jelas, supaya pengguna pertama punya alasan untuk mencoba produkmu.

 

Pengalaman Memakai Aplikasi yang Rumit Bikin Calon Pengguna Pergi

Bayangkan seseorang membuka aplikasimu karena ingin membuat anggaran sederhana.

Alih-alih langsung mulai, dia diminta membuat akun, memilih kategori, mengatur notifikasi, membaca panduan, dan mengisi banyak data.

Kalau proses awal terasa seperti mengisi formulir pajak, calon pengguna bisa menutup aplikasi sebelum melihat manfaatnya.

Pengalaman pengguna bukan hiasan setelah produk selesai dibuat.

Pengalaman itu menentukan apakah orang bisa memahami langkah berikutnya tanpa harus menebak-nebak.

Prinsip desain yang sering dibahas oleh Nielsen Norman Group menekankan pentingnya membuat status sistem mudah terlihat dan menggunakan bahasa yang akrab bagi pengguna.

Kamu bisa membaca daftar heuristik usability Nielsen Norman Group untuk memahami beberapa dasar kegunaan antarmuka.

Contoh sederhananya, setelah pengguna menekan tombol simpan, tampilkan tanda bahwa datanya berhasil tersimpan.

Jangan biarkan orang bertanya-tanya apakah tombolnya bekerja atau mereka harus mengulang dari awal.

“Kalau alurnya dibuat sederhana, berarti fiturnya harus dikurangi dong?” Belum tentu.

Kamu bisa menyimpan fitur lanjutan, tetapi tampilkan dulu langkah yang paling dibutuhkan pengguna baru.

Misalnya, aplikasi pencatat biaya proyek cukup meminta nama proyek dan nominal saat pertama dibuka.

Pilihan kategori, laporan bulanan, dan pengaturan pajak bisa dikenalkan setelah pengguna merasakan manfaat awalnya.

Coba minta tiga orang yang belum pernah melihat aplikasi itu untuk menyelesaikan satu tugas sederhana.

Jangan memberi petunjuk selama mereka mencoba, lalu catat bagian yang membuat mereka berhenti atau bertanya.

Kalau mereka gagal menemukan tombol utama, masalahnya mungkin ada di desain, bukan karena mereka kurang teliti.

Kadika pernah mengira tombol berwarna cerah pasti langsung terlihat oleh semua orang.

Ternyata, menurut orang yang mencoba, tombol itu malah tampak seperti hiasan halaman hehehe.

Dari uji kecil seperti itu, kamu bisa memperbaiki hambatan sebelum menghabiskan biaya untuk promosi.

 

Fitur Banyak Belum Tentu Membuat Orang Mau Membeli

Menambahkan fitur terasa produktif karena ada hasil yang bisa dilihat di layar.

Kamu bisa mencoret satu tugas dari daftar kerja setiap kali menu baru selesai dibuat.

Namun, daftar fitur bukan alasan otomatis bagi pelanggan untuk mengeluarkan uang.

Yang ingin mereka tahu adalah apa yang berubah setelah memakai produkmu.

Contohnya, bukan sekadar aplikasi punya pengingat otomatis dan grafik mingguan.

Jelaskan bahwa pengguna bisa melihat tagihan proyek yang mendekati tenggat tanpa membuka lima catatan berbeda.

Fitur baru layak dibuat kalau membantu pekerjaan penting jadi lebih cepat, lebih mudah, atau lebih aman.

Kalau fitur hanya mempercantik daftar spesifikasi, tanyakan lagi siapa yang membutuhkannya dan dalam situasi apa.

Kamu bisa mengurutkan usulan fitur dengan tiga pertanyaan sederhana.

1. Masalah apa yang akan berkurang setelah fitur ini tersedia?

2. Seberapa sering masalah itu muncul bagi pengguna sasaran?

3. Apa bukti bahwa pengguna mau mencoba solusi tersebut?

Pertanyaan itu membantu kamu membedakan kebutuhan nyata dari ide yang cuma terdengar keren saat rapat.

“Tapi pesaing udah punya fitur itu, masa aplikasiku gak ikut?” Lihat dulu apakah fitur tersebut penting untuk masalah yang kamu pilih.

Kamu gak harus meniru seluruh menu pesaing untuk membuat produk yang bernilai.

Bisa jadi kekuatanmu justru ada pada proses yang lebih singkat, dukungan yang lebih responsif, atau harga yang lebih cocok.

Fokus pada satu hasil yang berarti sering lebih mudah dijelaskan daripada menawarkan dua puluh kemampuan sekaligus.

Kalau pengguna memakai aplikasi untuk mengurangi waktu administrasi dari satu jam menjadi lima belas menit, itulah manfaat yang perlu diuji.

Angka tersebut harus berasal dari pengamatan, bukan klaim yang dibikin agar promosi terdengar meyakinkan.

Ukur waktu pengguna menyelesaikan tugas sebelum dan sesudah mencoba produkmu.

Kalau belum ada perubahan berarti, cari bagian proses yang masih bikin mereka kesulitan.

 

Gimana Mengomunikasikan Value Aplikasi dengan Jelas?

Produk yang berguna pun bisa sulit dijual kalau penjelasannya terlalu teknis atau penuh istilah yang cuma dimengerti pembuatnya.

Calon pengguna gak selalu peduli bahwa aplikasimu dibangun dengan teknologi terbaru.

Mereka ingin tahu apakah produk itu bisa membantu pekerjaan mereka dan apa yang perlu dilakukan untuk mulai.

Value produk adalah manfaat yang dirasakan pengguna dibandingkan dengan waktu, tenaga, atau uang yang mereka keluarkan.

Coba susun pesan dengan pola sederhana, yaitu untuk siapa produk dibuat, masalah apa yang dibantu, dan hasil apa yang bisa diharapkan.

Contohnya, aplikasi ini membantu pekerja lepas memisahkan biaya proyek supaya tagihan dan kebutuhan pribadi gak tercampur.

Pesan itu memberi konteks yang lebih kuat daripada sekadar menyebut aplikasi pengelola keuangan modern.

Kamu juga bisa menunjukkan alur produk dalam video pendek berdurasi tiga puluh sampai enam puluh detik.

Tampilkan satu masalah, satu proses penggunaan, dan satu hasil yang bisa dipahami tanpa penjelasan panjang.

Hindari menjanjikan hasil besar yang gak bisa kamu buktikan.

Lebih baik tunjukkan contoh nyata, seperti berapa langkah yang dibutuhkan untuk membuat laporan atau menemukan transaksi.

Kalau masih mencari bentuk pesan yang pas, uji dua versi deskripsi kepada calon pengguna.

Minta mereka menjelaskan kembali apa fungsi produkmu setelah membaca masing-masing versi.

Kalau jawabannya meleset, berarti pesanmu belum jelas bagi orang di luar tim.

“Aku udah menjelaskan semua fitur di halaman penjualan, bukannya itu cukup?” Belum tentu, karena informasi yang banyak bisa membuat manfaat utama tenggelam.

Mulai dari satu hasil paling penting, lalu dukung dengan bukti dan detail yang memang dibutuhkan.

Misalnya, tampilkan tangkapan alur penggunaan, contoh laporan, batas paket gratis, dan biaya langganan secara terbuka.

Orang lebih mudah mempertimbangkan produk ketika mereka tahu apa yang akan didapat dan apa batasannya.

Perhatikan juga bahasa yang dipakai calon pengguna saat menceritakan masalah mereka.

Gunakan kata-kata yang sama di halaman produk selama maknanya tetap akurat.

Dengan begitu, penjelasanmu terasa dekat dengan kebutuhan mereka, bukan seperti brosur yang dibuat untuk memuji produk sendiri.

 

Uji Penjualan Sebelum Membangun Lebih Jauh

Kamu gak perlu menunggu aplikasi sempurna untuk mencari tanda bahwa ada orang yang bersedia membayar.

Buat versi sederhana yang menyelesaikan satu pekerjaan utama, lalu ajak calon pengguna mencobanya.

Untuk layanan bisnis, kamu bisa menawarkan uji coba terbatas kepada tiga sampai lima calon pelanggan yang sesuai sasaran.

Jelaskan apa yang masih belum tersedia dan minta mereka membayar harga perkenalan jika mereka memang melihat manfaatnya.

Kesediaan membayar memberi sinyal berbeda dari komentar positif di media sosial.

Namun, satu transaksi belum membuktikan bahwa model bisnismu pasti berhasil.

Catat alasan orang membeli, alasan mereka menolak, bagian yang membingungkan, dan apakah mereka kembali menggunakan produk.

Setelah sepuluh percakapan, kamu mungkin menemukan pola yang lebih berguna daripada sepuluh fitur baru.

Contohnya, calon pelanggan ternyata bukan keberatan pada harga, tetapi belum paham cara memindahkan data dari sistem lama.

Temuan itu bisa mengarahkan perubahan yang lebih tepat, seperti panduan migrasi atau bantuan saat pengaturan awal.

“Kalau orang menolak, berarti idenya gagal?” Belum tentu, karena penolakan bisa menunjukkan masalah pada sasaran, pesan, harga, atau cara mencoba produk.

Pisahkan kemungkinan itu sebelum mengambil keputusan besar.

Kalau mereka paham manfaatnya tetapi masih memilih cara lama, tanyakan apa yang membuat mereka bertahan.

Kalau mereka tertarik tetapi bingung cara mulai, sederhanakan alur pertama.

Kalau mereka merasa manfaatnya gak cukup penting, pertimbangkan untuk mengubah masalah yang kamu sasar.

Langkah ini membantu kamu memakai waktu dan uang dengan lebih bijak, terutama saat membangun produk sambil mengejar target karier atau pekerjaan utama.

Setelah membaca ini, coba tulis satu kalimat tentang siapa yang paling terbantu oleh aplikasimu dan satu masalah yang ingin mereka selesaikan.

Lalu tanyakan ke tiga orang yang sesuai sasaran apakah mereka benar-benar mengalami masalah itu dan solusi apa yang sedang mereka pakai.

Jawaban mereka bisa jadi lebih berharga daripada menambah satu fitur lagi minggu ini.