Menanggapi permintaan fitur aplikasi saya tidak akan menerapkan [ditutup]


10

Saya seorang pengembang aplikasi baru dan setelah menyukai 20 unduhan aplikasi saya (gratis dan bebas iklan), saya sudah mendapat dua permintaan fitur, dan saya juga tidak akan mengimplementasikannya.

Haruskah saya menanggapi permintaan fitur ini dan jika demikian, bagaimana? Saya lebih suka tidak merespons sama sekali karena saya lebih suka menghabiskan waktu untuk bekerja di aplikasi saya, tetapi menjadi pengembang baru, beberapa peringkat buruk di app store dapat merusak aplikasi saya.


2
Beruntunglah anda! Pengguna yang cukup peduli untuk menggunakan aplikasi Anda dan membicarakannya dengan Anda. Anda melakukan sesuatu dengan benar. Terus lakukan itu. [Jawabannya sangat bagus, jadi saya tidak akan menambahkannya.]
david.pfx

Setelah 2 tahun, 5000+ ulasan, dan ratusan permintaan fitur, saya dapat mengatakan bahwa jumlah fitur yang saya dapatkan adalah indikator terbaik keterlibatan pengguna dan potensi masa depan aplikasi (bahkan sejak awal ketika unduhan buruk). Saya juga dapat menyimpulkan bahwa tidak masalah jika saya menanggapi permintaan fitur, hampir tidak ada pengguna yang berhak dihina jika saya tidak merespons. Beberapa pengguna akan mencoba meningkatkan ulasan 1 * untuk mendapatkan yang mereka inginkan, tetapi mereka biasanya tidak akan mengirim email sebelumnya dan mereka biasanya tidak akan mengubah peringkat mereka bahkan jika Anda melakukan apa yang mereka minta, jadi abaikan saja.
TimSim

Jawaban:


11

Kumpulkan surat "terima kasih atas minat Anda" yang mencakup kemungkinan a) fitur yang TIDAK AKAN PERNAH Anda implementasikan bahkan jika saya muncul di depan pintu Anda dengan sekantong emas, b) fitur yang tidak RENCANAKAN untuk Anda terapkan tetapi mungkin , dan c) fitur yang ingin Anda terapkan tetapi tidak bisa sekarang. Kirimkan itu. Karena Anda hampir tidak pernah tahu kapan Anda mungkin akan memindahkan sesuatu dari a) ke b), atau dari b) ke c).


Saya pikir ini adalah cara terbaik untuk melakukannya. Saya hanya akan menggunakan beberapa balasan saham, berterima kasih kepada mereka dan berkomitmen untuk tidak melakukan apa pun.
TimSim

15

Saya pikir Anda hanya bisa kalah dengan memilih untuk tidak berkomunikasi.

Jika Anda tidak berencana untuk mengimplementasikan fitur sekarang, setidaknya sarankan pengguna bahwa itu tidak dalam rencana saat ini untuk diterapkan, tetapi dapat dipertimbangkan di masa depan. Ini tidak akan membiarkan pengguna berpikir bahwa ini adalah fitur yang dapat mereka harapkan segera dan akan mengirim pesan bahwa Anda juga tidak berencana untuk menggunakannya. Pada akhirnya, Anda mungkin berubah pikiran di masa mendatang (mis. Jika permintaan ini akan lebih sering terjadi, mungkin itu sesuatu yang akan dibayar pengguna?).

Jika Anda yakin bahwa Anda tidak mengimplementasikan fitur ini sebelumnya karena katakanlah Anda ingin pergi ke arah yang sama sekali berbeda dengan aplikasi Anda, maka mintalah pengguna untuk mempertimbangkan mencoba menggunakan aplikasi dengan cara Anda.

Komunikasi dengan pengguna Anda adalah proses yang penting jika Anda ingin membangun basis pengguna untuk aplikasi Anda dan balasan singkat tidak akan membawa Anda banyak waktu untuk menulis.


1
Yah saya menerima saran Anda dan sekarang saya memiliki sahabat pena baru dan satu permintaan fitur berubah menjadi 7 ... dan dia bahkan tidak menilai aplikasi saya.
TimSim

Mungkin tidak ada artinya jika "berkomunikasi" di sini berarti mengatakan "terima kasih atas minat Anda." Jika Anda mengatakan lebih dari itu, pelanggan dapat menyimpulkan bahwa Anda hanya berjanji untuk melakukan apa yang mereka inginkan, terlepas dari apa yang Anda katakan. Dan itu jauh, jauh lebih buruk daripada tidak mengatakan apa-apa sama sekali.
DougM

8

Idealnya, Anda harus menggunakan permintaan seperti itu sebagai kesempatan untuk membantu Anda dan pengguna lebih memahami aplikasi.

Jika Anda memikirkannya, alasan utama mengapa Anda lebih suka mengabaikan permintaan ini adalah informasi yang cukup penting dan Anda lebih suka menyimpan dan mendokumentasikannya daripada dikubur dan dilupakan jauh di dalam benak Anda.

Jika permintaan diabaikan karena Anda tidak punya waktu untuk mengimplementasikannya, tetapi umumnya ide yang bagus, Anda sebaiknya menyimpannya di suatu tempat. Kemudian, ketika Anda punya waktu, Anda dapat kembali ke sana dan mempertimbangkannya kembali.

Atau, jika permintaan diabaikan karena itu ide yang sangat buruk dan Anda dapat menuliskan penjelasan mengapa demikian, ini juga akan menjadi pengetahuan yang berguna untuk disimpan di suatu tempat. Melakukannya akan membuatnya lebih mudah untuk menangani permintaan serupa dari pengguna lain, atau bahkan membantu diri Anda sendiri jika Anda akhirnya lupa mengapa Anda berpikir itu adalah ide yang buruk.

Perlu diingat bahwa mengeja dan menuliskan alasan mengapa beberapa fitur mungkin lebih berbahaya daripada kebaikan akan membantu diri Anda lebih memahami aplikasi Anda, itu dimaksudkan penggunaan, keterbatasan dan poin kuat.

Sebagai contoh, lihatlah di jaringan Stack Exchange. Permintaan fitur yang diputuskan untuk tidak diterapkan di sini tidak dikubur. Justru sebaliknya, ini dipublikasikan, dianalisis secara menyeluruh dan disimpan untuk referensi lebih lanjut dengan mudah ditandai status-ditolak di situs meta Stack Exchange.


Oh, saya suka mendapatkan permintaan fitur dan saya suka mempertimbangkannya tetapi saya tidak ingin menghabiskan banyak waktu untuk menanggapi pengguna. Jika saya pikir itu masuk akal, saya akan menerapkannya, kalau tidak saya tidak akan melakukannya, tetapi perhatian utama saya adalah mendapatkan peringkat bintang 1 dari pengguna yang tidak dapat meyakinkan saya untuk menghabiskan akhir pekan untuk memenuhi keinginan khusus mereka.
TimSim

1
@TimSim - Hanya khawatir tentang mendapatkan ulasan bintang 5 dan 4 daripada mencoba meyakinkan seseorang tidak dapat diyakinkan untuk tidak memberi Anda ulasan bintang 1.
Ramhound

@TimSim dari komentar Anda di sini dan di jawaban lain sepertinya Anda tidak menggunakan pelacak masalah untuk berkomunikasi dengan pengguna. Jika ini masalahnya, maka jawaban yang Anda terima masuk akal ... meskipun saya masih akan merekomendasikan untuk mendapatkan pelacak sebagai
gnat

1

Saya pikir jawaban lain berada di jalur yang benar dalam mendorong Anda untuk berkorespondensi dengan pengguna Anda.

satu permintaan fitur berubah menjadi 7 ..

Berdasarkan komentar ini, Anda tidak memberikan umpan balik yang cukup kepada pengguna tentang jenis fitur yang Anda buka. Mungkin mereka ingin Anda memperluas kapabilitas / fitur tetapi Anda lebih mementingkan kinerja dan kegunaan fitur yang ada? Menolak satu fitur tidak cukup untuk memandu pengguna. Mereka akan terus menggunakan coba-coba dan dalam kasus sahabat pena Anda, pendekatan senapan.

Tujuannya adalah untuk mendorong umpan balik dan memberikan arahan.


0

Semua permintaan ini, bahkan jika Anda tidak berencana untuk mengimplementasikan fitur ini sebelumnya adalah sinyal yang langsung dikirimkan kepada Anda. Itu menjengkelkan, dan itu emas. Terkadang Anda harus menunggu sebelum mengambil keputusan: jika hanya ada satu orang yang meminta sesuatu, Anda tentu bisa berpendapat bahwa aplikasi Anda tidak boleh menerapkan fitur ini, tetapi jika lusinan dari mereka meminta hal yang sama setelah beberapa waktu, itu bisa membuat Anda berpikir tentang desain Anda sendiri (dan Anda harus).

Jadi saya percaya jawaban selalu lebih disukai, karena Anda tidak dapat memedulikan produk Anda tanpa memperhatikan umpan balik ini. Yang paling sederhana adalah hanya menjawab bahwa ada saran yang diterima dan itu berharga untuk Anda, bahkan jika semuanya tidak dapat dilaksanakan , itu tidak akan diabaikan.

dan saya tidak akan mengimplementasikannya juga

Anda harus memikirkannya, dan memutuskan hal-hal mana yang mungkin dapat Anda terapkan, bahkan jika Anda tidak merencanakannya sebelumnya karena itu bisa menjadi ide yang bagus, atau itu dapat membantu Anda untuk membuat desain utama Anda berubah.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.