Cara mengumumkan fitur baru (tanpa keheningan)

Kebanyakan pengumuman fitur mati di kanal yang tak dibaca dua kali siapa pun: tweet yang lewat tergulir, email hari rilis yang terkubur di bawah dua belas lainnya yang diterima pelanggan minggu itu, pesan Slack di kanal yang dibisukan setengah tim berbulan-bulan lalu. Fiturnya sudah dirilis. Hampir tak ada yang akan memakainya yang tahu. Memperbaiki itu lebih berkaitan dengan memilih kanal yang tepat untuk pembaca yang tepat daripada menulis pengumuman yang lebih baik, dan menjangkau langsung orang yang secara eksplisit memintanya alih-alih mengandalkan mereka menyadari pesan umum.

Di mana sebenarnya fitur baru harus diumumkan?

Di lebih dari satu tempat, karena “semua orang membaca kanal yang sama” tak pernah benar. Entri changelog atau feed melayani pembaca yang mengecek sesuai jadwalnya sendiri dan menginginkan catatan permanen dan bertanggal. Notifikasi dalam aplikasi melayani pembaca yang sudah memakai produk dan akan memakai fitur itu hari ini jika tahu keberadaannya. Email melayani pembaca yang saat ini tak berada di produk tapi akan kembali untuk update yang tepat. Media sosial melayani jangkauan di luar pengguna yang ada, dengan hampir tanpa penargetan.

Tak satu pun dari keempatnya cukup sendirian. Changelog adalah satu-satunya dokumen yang seharusnya membawa setiap rilis apa pun ukurannya, karena itu catatan yang menjadi rujukan balik semua yang lain; tiga lainnya adalah amplifikasi yang ditambahkan di atasnya, dipilih sesuai seberapa besar fitur itu sebenarnya.

Apa yang harus dikatakan pengumuman lebih dulu?

Hasilnya, bukan mekanismenya. “Kami menambahkan lapisan cache ke endpoint laporan” menggambarkan apa yang dibangun tim. “Laporan sekarang dimuat dalam kurang dari satu detik” menggambarkan apa yang berubah bagi pembaca, dan itulah kalimat yang mendapatkan klik, karena menjawab “apa untungnya bagi saya” di klausa pertama alih-alih ketiga. Mekanismenya milik entri changelog atau halaman detail, bukan judul.

Hal konkret sebelum kata sifat. “Pengalaman laporan yang lebih cepat dan lebih kuat” tak memberitahu pembaca apa pun yang bisa ditindaklanjuti; “laporan sekarang dimuat dalam kurang dari satu detik dan bisa difilter berdasarkan status” memberitahu persis apa yang berubah dan apa yang harus dicoba. Versi kedua juga terasa lebih kredibel, karena klaim yang samar terdengar persis seperti bunyi teks pemasaran ketika tak ada yang konkret untuk dikatakan.

Apa bedanya dengan email update produk?

Tumpang tindih tapi tak identik. Email update produk membahas kanal email secara spesifik, termasuk kadensi, subjek, dan kapan digest mengalahkan kiriman tunggal. Pengumuman fitur baru adalah peristiwa yang mendasarinya; email adalah salah satu dari empat kanal di atas yang bisa membawanya, dipilih ketika fitur cukup besar untuk membenarkan kiriman khusus alih-alih ikut naik di digest berikutnya. Fitur kecil pantas mendapat entri changelog dan mungkin notifikasi dalam aplikasi. Yang signifikan pantas mendapat keempat kanal, diselaraskan waktunya.

Bagaimana menjangkau orang spesifik yang memintanya?

Ini pengumuman dengan imbal hasil terbaik, dan hampir semua tim melewatkannya. Jika sepuluh pelanggan meminta fitur dengan nama, sepuluh orang itu pantas mendapat catatan langsung dan personal saat dirilis, terlepas dari pengumuman lebih luas apa pun yang keluar. Menutup lingkaran umpan balik dengan pelanggan membahas mekanismenya secara lengkap; ringkasannya di sini adalah ini hanya berfungsi jika permintaan asli tetap terhubung dengan yang memintanya, yang lebih merupakan masalah pelacakan daripada masalah pengumuman. Di changeloop, ketika masukan widget menjadi issue GitHub dan pull request yang di-merge menutupnya (fixes #142), menyetujui entri changelog memposting komentar “Shipped —

Bagaimana menulis entri itu sendiri?

Disiplin yang sama seperti entri catatan rilis lainnya: mulai dengan apa yang bisa dilakukan pembaca sekarang, lanjutkan dengan pengaturan yang diperlukan, lewati justifikasi internal. Cara menulis catatan rilis membahas metode lengkapnya; pengumuman fitur baru adalah kasus dengan taruhan tertinggi, karena itu entri yang paling mungkin ditangkap layar, diteruskan, dan dibaca seseorang yang belum pernah melihat changelog produk.

Kapan sebaiknya tak mengumumkan secara luas?

Ketika fitur masih diluncurkan ke sebagian akun, benar-benar beta, atau berharga atau terkunci sedemikian rupa sehingga sembilan dari sepuluh pembaca pengumuman luas belum bisa memakainya. Pengumuman luas untuk fitur yang tak bisa dipakai sembilan dari sepuluh pembaca terbaca seperti umpan, dan membakar kepercayaan pada pengumuman berikutnya lebih daripada membangun antusiasme pada yang ini. Solusinya bukan keheningan, tapi cakupan: beri tahu akun yang memenuhi syarat secara langsung, dan tahan kanal luas sampai ketersediaan menyusul pengumuman.

FAQ

Apakah setiap fitur baru pantas mendapat pengumumannya sendiri? Setiap fitur pantas mendapat entri changelog. Hanya yang cukup signifikan untuk mengubah cara seseorang memakai produk, atau yang diminta secara eksplisit dengan nama, yang pantas mendapat kanal lebih luas seperti email atau media sosial.

Apa kanal terbaik untuk fitur kecil? Changelog saja, ditambah notifikasi dalam aplikasi jika fitur bisa ditemukan dalam alur yang sudah dijalani pengguna. Email dan media sosial layak dipakai untuk fitur yang membenarkan permintaan perhatian.

Bagaimana mengumumkan fitur kepada orang yang secara spesifik memintanya? Jaga permintaan tetap terhubung dengan yang memintanya sejak saat dicatat, lalu beri tahu secara individu saat dirilis, terpisah dari pengumuman lebih luas apa pun. Label status bersama yang bisa dicek sendiri oleh yang meminta juga mengurangi berapa banyak pesan individu yang dibutuhkan sejak awal.

Apakah pengumuman fitur butuh tangkapan layar? Untuk apa pun yang visual, ya; fitur yang dijelaskan tapi tak terlihat jauh lebih sering dilewatkan daripada yang pembaca bisa lihat pratinjaunya. Untuk API atau kapabilitas backend, contoh kode singkat melakukan pekerjaan yang sama seperti tangkapan layar untuk perubahan UI.

Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.

Terkait di changeloop: Contoh changelog, Dokumentasi developer