Email Pelanggan untuk Menentukan Kebutuhan Aplikasi yang Sesungguhnya

Mengapa pesan pelanggan adalah tempat terbaik untuk memulai

Cara tercepat membangun aplikasi yang salah adalah memulai dari tebakan. Tim sering melakukannya. Mereka mengira apa yang diinginkan pengguna, memilih fitur yang terdengar pintar, dan menghabiskan minggu-minggu membangun sesuatu yang sebenarnya tidak dibutuhkan siapa pun.

Pesan pelanggan adalah titik mulai yang jauh lebih baik. Mereka menunjukkan apa yang orang coba lakukan sebelum produk Anda ada, di mana mereka tersendat, dan bagian mana yang cukup menyakitkan sampai mereka menulis. Itu jauh lebih berguna daripada opini di rapat perencanaan.

Nilainya ada pada bahasanya sendiri. Pelanggan jarang mendeskripsikan masalah dengan jargon produk. Mereka mengatakan hal seperti, "Saya terus kehilangan pesanan karena harus menyalin detail yang sama ke tiga tempat." Satu kalimat itu memberi tahu Anda tugasnya, rasa sakitnya, dan biaya masalahnya.

Beberapa sinyal biasanya paling penting:

• masalah yang sama muncul dalam kata-kata berbeda
• orang menggambarkan solusi sementara yang sudah mereka gunakan
• masalah itu menghabiskan waktu, biaya, atau perhatian harian
• pesan menyertakan cukup konteks untuk mengerti apa yang salah

Satu email bisa menarik. Sepuluh email serupa adalah bukti. Permintaan yang berulang membantu Anda menghindari membangun untuk pelanggan paling berisik bukannya kebutuhan yang paling umum.

Ini sangat berguna untuk pendiri non-teknis. Jika Anda membentuk aplikasi dengan bahasa sederhana, ide kasar menjadi jauh lebih kuat ketika didukung oleh thread dukungan nyata atau catatan intake. Daripada mengatakan, "Buat CRM," Anda bisa mengatakan, "Buat CRM yang mengingatkan kami untuk follow-up, mencatat panggilan klien, dan mencegah prospek hilang di email."

Itulah yang dilakukan pesan pelanggan dengan baik. Mereka mengubah ide samar menjadi masalah yang benar-benar bisa Anda bangun.

Apa yang dikumpulkan sebelum Anda merencanakan

Sebelum Anda membuat sketsa layar atau menulis daftar fitur, kumpulkan pesan yang menunjukkan rasa sakit nyata. Anda tidak perlu semuanya. Anda butuh beberapa jenis catatan yang mengungkap apa yang orang coba lakukan, di mana mereka tersendat, dan berapa biaya masalah itu bagi mereka.

Materi paling berguna biasanya datang dari empat tempat: email dukungan, catatan sales atau intake, permintaan berulang dari orang berbeda, dan pesan yang menyebutkan solusi sementara, penundaan, langkah yang terlewat, atau waktu yang terbuang.

Pesan spesifik selalu lebih baik daripada keluhan samar. "Saya tidak bisa menemukan faktur setelah ekspor" berguna. "Aplikasi Anda buruk" tidak. Simpan kata-kata lengkap saat Anda bisa, karena frasa tepat sering mengungkap pekerjaan nyata yang harus diselesaikan.

Catatan sales dan intake juga penting. Orang sering menjelaskan tujuan mereka lebih jelas di sana daripada di laporan bug. Seorang prospek mungkin berkata mereka melacak lead di spreadsheet, menyalin pembaruan ke email, dan kehilangan jam setiap minggu. Itu memberi Anda proses saat ini, rasa sakitnya, dan hasil yang mereka inginkan.

Solusi sementara adalah salah satu sinyal terkuat yang bisa Anda temukan. Jika seseorang mengekspor data secara manual setiap Jumat, menyimpan catatan di alat kedua, atau meminta rekan memperbaiki masalah yang sama setiap minggu, kebutuhannya sudah nyata. Biayanya sudah ada.

Simpan sedikit konteks dengan setiap pesan. Catat siapa yang mengirim, apa yang mereka coba lakukan, seberapa sering itu terjadi, dan apa hasilnya. Baris singkat seperti "agen kecil, terjadi mingguan, menyebabkan keterlambatan penagihan" membuat perencanaan nanti jauh lebih mudah.

Jika Anda membangun cepat, langkah ini mencegah umpan balik yang tersebar berubah menjadi fitur acak. Bahkan di platform cepat seperti Koder.ai, input yang lebih baik menghasilkan build pertama yang jauh lebih baik.

Cara menemukan pola di inbox

Baca pesan pelanggan dengan satu tujuan: temukan pengulangan.

Satu email marah bisa terasa mendesak, tetapi keputusan produk yang baik datang dari pola. Perlakukan setiap pesan seperti petunjuk. Anda belum berburu ide fitur sempurna. Anda mencari rasa sakit yang sama muncul berulang kali.

Mulailah dengan mengelompokkan pesan berdasarkan masalah, bahkan ketika pelanggan mendeskripsikannya dengan cara berbeda. Satu orang mungkin berkata, "Saya tidak bisa menemukan pesanan lama saya," dan orang lain berkata, "Saya perlu melihat apa yang saya beli bulan lalu." Keduanya menunjukkan masalah yang sama: riwayat pesanan sulit diakses.

Satu set tag sederhana membantu:

• tidak bisa menemukan informasi
• terlalu banyak langkah manual
• akses atau izin hilang
• sulit dibagikan atau diekspor
• penggunaan mobile membuat frustrasi

Setelah itu, permintaan satu kali jadi lebih mudah dikenali. Jika satu pelanggan ingin format laporan yang sangat spesifik, itu layak dicatat. Itu tidak harus memiliki bobot yang sama dengan masalah yang disebut oleh 12 pengguna dalam dua minggu.

Simpan kata-kata pelanggan sendiri dalam catatan Anda bila memungkinkan. Bahasa asli membantu nanti saat Anda menamai fitur, menulis teks layar, atau menjelaskan masalah ke tim. Itu juga membuat Anda jujur. "Perlu persetujuan faktur lebih cepat" jauh lebih jelas daripada "optimisasi alur kerja."

Frekuensi penting, tetapi relevansi juga penting. Lacak siapa yang punya masalah, bukan hanya seberapa sering muncul. Rasa sakit yang disebut lima kali oleh pengguna harian mungkin lebih penting daripada yang disebut sepuluh kali oleh pengguna trial yang tidak pernah memulai.

Itu sebabnya pola terbaik biasanya didukung dua hal: pengulangan dan kepentingan. Jika beberapa manajer kantor, agen dukungan, dan pendiri semua mengeluh tentang langkah yang hilang sama, pola itu layak diperhatikan.

Ubah pola menjadi kebutuhan yang jelas

Setelah Anda mengelompokkan pesan, ubah setiap klaster menjadi satu kalimat sederhana yang menggambarkan masalah, bukan solusi.

Contoh: "Pelanggan melewatkan janji karena mereka tidak menerima pengingat pada waktu yang tepat."

Jika Anda tidak bisa menjelaskan masalah dengan jelas dalam satu kalimat, kebutuhannya mungkin masih terlalu kabur.

Langkah berikutnya adalah menamai pekerjaan yang ingin diselesaikan pengguna. Buat praktis. Dalam contoh di atas, pekerjaan itu bukan "mengelola notifikasi." Pekerjaan nyata adalah "memastikan klien ingat jadwal tanpa staf harus mengejar mereka."

Perbedaan itu penting karena menghentikan Anda membangun fitur ekstra terlalu awal. Tujuannya menangkap apa yang harus dicapai pengguna, bukan setiap solusi yang mereka sarankan.

Sekarang tulis ulang pola itu sebagai kebutuhan singkat yang bisa dipahami orang non-teknis. Untuk contoh pengingat, versi pertama mungkin mencakup:

• staf bisa mengirim pengingat otomatis sebelum janji
• staf bisa memilih kapan pengingat dikirim
• staf bisa melihat apakah pengingat sudah terkirim
• pengingat memakai detail kontak yang sudah tersimpan di booking

Perhatikan apa yang tidak disertakan. Tidak ada pembicaraan tentang framework, desain database, atau message queue. Itu datang nanti. Pertama, pastikan kebutuhan mengatakan apa yang aplikasi harus lakukan untuk pengguna.

Setelah Anda menulis setiap kebutuhan, kaitkan kembali ke pesan nyata. Tanyakan sendiri email, thread dukungan, atau catatan intake mana yang membuktikan itu penting. Jika Anda tidak bisa menunjuk kata-kata pelanggan nyata, pindahkan item itu ke daftar "mungkin nanti."

Tes cepat membantu:

• Bisakah rekan non-teknis memahaminya?
• Apakah itu menggambarkan satu hasil yang jelas?
• Apakah itu berdasarkan bahasa pelanggan yang berulang?
• Apakah menghapusnya membuat versi satu kurang berguna?

Jika jawabannya ya untuk semua empat, Anda mungkin punya kebutuhan yang solid.

Cara memilih apa yang masuk versi satu

Setelah Anda punya tumpukan permintaan nyata, tugas selanjutnya adalah mengatakan tidak pada sebagian besar dari mereka.

Versi pertama yang baik bukan salinan lebih kecil dari produk penuh. Ia adalah perbaikan terkecil yang jelas menyelesaikan rasa sakit utama yang terus diungkapkan orang.

Metode peringkat sederhana bekerja di sini. Lihat empat hal:

• seberapa sering masalah muncul
• seberapa mendesak terasa bagi pengguna
• apakah itu menghalangi pekerjaan utama yang mereka coba lakukan
• seberapa sulit membangunnya dibandingkan nilai yang ditambahkan

Item versi satu terbaik biasanya bernilai tinggi pada tiga pertama dan masih masuk akal pada yang keempat.

Misalnya pesan pelanggan terus mengatakan, "Saya kehilangan jejak follow-up setelah panggilan dukungan." Versi pertama yang berguna mungkin mencakup catatan kontak, pengingat follow-up, dan label status sederhana. Kemungkinan besar tidak perlu izin tim, laporan lanjutan, atau lima format ekspor di hari pertama. Itu bisa penting nanti, tapi bukan solusi inti sekarang.

Versi satu yang fokus juga mudah dijelaskan dalam satu kalimat. Jika Anda tidak bisa menjelaskannya secara sederhana, mungkin itu mencoba melakukan terlalu banyak.

Itu lebih penting lagi saat Anda membangun cepat. Alat yang membiarkan Anda membuat perangkat lunak dari bahasa sederhana bisa mempercepat, tetapi kecepatan hanya membantu saat scope jelas. Untuk pendiri yang memakai Koder.ai untuk membentuk aplikasi web atau mobile pertama dari chat, kebutuhan yang bersih biasanya menghasilkan rilis pertama yang jauh lebih berguna.

Contoh sederhana

Bayangkan tim sales kecil terus mengirim jenis email dukungan yang sama. Pesannya bukan, "Kami butuh CRM yang lebih baik." Itu jauh lebih sederhana: "Saya lupa menindaklanjuti lead, dan sekarang deal dingin."

Setelah beberapa minggu, polanya mudah terlihat. Satu orang berkata mereka kehilangan jejak setelah panggilan. Yang lain berkata seorang pelanggan minta harga tetapi tidak ada yang membalas selama tiga hari. Ketiga mengatakan catatan scatter di email dan spreadsheet, sehingga pengingat terlewat.

Inbox menunjuk ke rasa sakit nyata. Tim tidak perlu sistem besar dengan pipeline, forecasting, dan pengaturan admin. Mereka butuh cara dasar untuk mengingat siapa yang harus dihubungi selanjutnya, dan kapan.

Catatan intake mendukung ini. Pengguna sudah menyimpan nama kontak, catatan singkat, dan langkah berikutnya di tempat berantakan. Yang kurang adalah alur pengingat sederhana.

Jadi versi satu tetap kecil:

• daftar kontak
• tempat menyimpan catatan
• pengingat untuk follow-up berikutnya

Itu cukup untuk menguji masalah inti.

Jika orang mulai menggunakannya setiap hari, set permintaan berikutnya akan memberi tahu apa yang layak ditambahkan. Mungkin pengguna minta pengingat berulang. Mungkin mereka mau kontak bersama. Mungkin mereka butuh template email. Ide-ide itu tidak diabaikan. Mereka disimpan untuk nanti, di daftar terpisah.

Itu menjaga rilis pertama fokus pada rasa sakit berulang yang muncul di pesan nyata.

Kesalahan yang membuat build pertama kabur

Satu kesalahan umum adalah membangun untuk pelanggan paling berisik bukannya masalah yang paling umum. Satu orang mungkin meminta alur kerja sangat spesifik, tapi jika tidak ada orang lain yang punya rasa sakit sama, permintaan itu tidak seharusnya menentukan versi satu.

Kesalahan lain adalah menganggap fitur yang diusulkan adalah kebutuhan sesungguhnya. Pelanggan sering langsung melompat ke solusi. Mereka minta dashboard, filter, dan alert. Ide-ide itu bisa berguna, tapi tetap tebakan sampai Anda mengerti rasa sakit di baliknya.

Pertanyaan yang lebih baik: apa yang sulit sebelum mereka meminta ini? Jika masalah nyata adalah "Saya terus melewatkan pesanan mendesak," alert mungkin membantu, tapi ringkasan harian atau antrean yang lebih jelas juga bisa. Bangunlah di sekitar rasa sakit, bukan ide fitur pertama.

Tim juga bermasalah saat menggabungkan pengguna yang sangat berbeda ke dalam satu produk awal. Jika admin, staf sales, dan pengguna akhir butuh hal berbeda, mencoba melayani semuanya sekaligus biasanya menghasilkan aplikasi yang membingungkan.

Pilih satu pengguna utama dulu. Lalu definisikan tugas utama yang terblokir dalam satu kalimat sederhana. Pertahankan hanya fitur yang membantu tugas itu terjadi lebih cepat, lebih jelas, atau dengan lebih sedikit kesalahan.

Perangkap mudah lainnya adalah menambahkan edge case sebelum pekerjaan utama berjalan baik. Terlihat bertanggung jawab, tetapi pengguna awal biasanya menilai aplikasi pada satu hal: bisakah mereka menyelesaikan tugas inti tanpa hambatan?

Jika pelanggan terus email tentang pemesanan janji yang lambat, jangan mulai dengan aturan hari libur, rantai persetujuan kompleks, dan pengecualian langka. Mudahkan pemesanan dulu.

Terakhir, jangan abaikan bahasa yang sudah dipakai pelanggan. Pilihan kata mereka memberi tahu bagaimana mereka melihat masalah dan apa yang akan terasa familiar. Jika setiap email mengatakan "pengingat follow-up" dan Anda mengubahnya menjadi "engagement trigger," Anda menciptakan kebingungan yang sebenarnya bisa dihindari.

Sebelum membangun, jalankan satu pemeriksaan terakhir

Sebelum mulai membangun, berhenti dan uji rencana Anda terhadap bukti yang benar-benar Anda miliki.

Cari bukti pengulangan. Satu email kuat menarik. Tiga atau lebih pesan yang menggambarkan frustrasi sama adalah pola.

Nama pengguna dan masalahnya dengan bahasa sederhana. Jangan tulis "manajemen alur kerja yang lebih baik." Tulis sesuatu seperti, "Pemilik toko kecil kehilangan pesanan karena permintaan terkubur di thread email."

Cocokkan setiap fitur ke satu titik sakit. Jika sebuah fitur ada hanya karena terdengar mengesankan, potong saja.

Coba jelaskan produk dalam satu kalimat pendek. Jika kalimat itu terus panjang, scope mungkin terlalu lebar.

Lalu hapus apa yang bisa menunggu. Versi satu bukan produk final Anda. Pertahankan bagian yang menyelesaikan rasa sakit utama sekarang dan pindahkan sisanya ke daftar nanti.

Kalimat seperti "Aplikasi ini membantu desainer freelance mengirimkan penawaran lebih cepat tanpa mengejar persetujuan lewat email" jelas. Jika kemudian Anda menambahkan chat tim, analitik, dan portal klien sebelum memperbaiki masalah penawaran, scope sudah meleset.

Apa yang dilakukan setelah Anda menemukan pola

Setelah masalah yang sama muncul berulang, ubah catatan Anda menjadi ringkasan singkat: siapa yang punya masalah, apa yang memperlambat mereka, dan hasil apa yang mereka inginkan sebaliknya.

Bisa sesederhana: "Pelanggan baru terus bertanya di mana faktur disimpan, dan dukungan menghabiskan terlalu banyak waktu menjawab pertanyaan yang sama."

Dari sana, tulis daftar fitur ringkas. Fokus pada beberapa hal yang langsung menyelesaikan rasa sakit berulang itu. Jika masalahnya kebingungan faktur, versi satu mungkin hanya perlu halaman faktur yang bisa dicari, notifikasi email, dan tampilan status sederhana.

Sebelum membangun, tunjukkan draf itu ke beberapa pengguna nyata. Anda tidak perlu demo lengkap. Mockup kasar, walkthrough singkat, atau bahkan pesan singkat sering cukup untuk menanyakan, "Apakah ini menyelesaikan masalah yang Anda tulis kepada kami?"

Jawaban mereka biasanya memberi tahu apa yang kurang, apa yang tidak perlu, dan apa yang tampak bagus di kertas tapi tidak membantu di penggunaan nyata.

Jaga build pertama cukup kecil untuk diuji cepat. Itu penting baik Anda bekerja dengan tim pengembang atau menggunakan platform seperti Koder.ai untuk mengubah kebutuhan berbahasa sederhana jadi aplikasi. Kualitas rilis pertama tetap bergantung pada seberapa jelas Anda mendefinisikan masalah nyata.

Setelah peluncuran, terus baca inbox. Rilis pertama bukan akhir perencanaan. Email baru, balasan dukungan, dan catatan umpan balik akan memberi tahu apakah Anda menyelesaikan seluruh masalah atau hanya sebagian.

Anggap peluncuran sebagai putaran riset berikutnya. Simpan permintaan baru, beri tag pengulangan, dan sesuaikan berdasarkan apa yang dilakukan pengguna selanjutnya. Begitulah versi pertama yang kecil dan fokus tumbuh menjadi sesuatu yang orang terus gunakan.