Cara membuat roadmap produk dari umpan balik pelanggan

Cara membuat roadmap produk intinya begini: kumpulkan apa yang sudah diminta pelanggan, kelompokkan menurut masalah di balik tiap permintaan, urutkan kelompok itu dengan aturan yang bisa Anda jelaskan, tentukan seberapa yakin Anda pada masing-masing, lalu terbitkan hasilnya dalam format yang cocok dengan siapa pembacanya. Urutannya penting. Tim yang mulai dari tata letak lalu mengisinya dengan ide mendapat dokumen yang tampak selesai tetapi tanpa bukti. Tim yang mulai dari permintaan mendapat roadmap yang lebih pendek dengan alasan di balik setiap barisnya.

Dari mana mulai ketika membuat roadmap produk?

Mulailah dari bukti yang sudah Anda pegang, bukan dari halaman kosong. Permintaan fitur yang terbuka, percakapan support yang diberi tag keluhan sama, catatan panggilan penjualan, dan data pemakaian dari produk Anda sendiri semuanya adalah masukan. Taruh semuanya dalam satu daftar dan tuliskan dari mana setiap item berasal.

Permintaan jarang datang dalam bentuk yang siap pakai. “Tambah integrasi Slack” dan “beri tahu tim saya ketika tugas berubah” bisa jadi kebutuhan yang sama. Itulah sebabnya langkah berikutnya adalah pengelompokan, dan mengapa tracker yang menggabungkan duplikat berguna; permintaan fitur duplikat membahas caranya. Ingat juga bahwa tiket dukungan dan permintaan fitur membawa sinyal yang berbeda jenis, dan roadmap yang dibangun hanya dari salah satunya akan condong ke arah yang salah.

Bagaimana mengubah permintaan menjadi item di roadmap produk?

Kelompokkan permintaan menurut masalahnya, beri nama tiap kelompok sebagai hasil, dan simpan jumlahnya. Kelompok berisi empat belas permintaan yang semuanya menggambarkan filter yang hilang setelah halaman dimuat ulang menjadi satu item: “Filter terakhir yang dipakai tetap tersimpan”. Jumlahnya masuk ke kolom sumber, sehingga siapa pun yang membaca roadmap bisa melihat bobot di baliknya.

Tulis hasil dengan kata-kata pelanggan. “Implementasi persistensi saved view” memberi tahu engineer apa yang harus dibuat dan tidak memberi tahu pelanggan apa-apa. Perumusan hasil juga memaksa pertanyaan yang berguna: jika Anda tidak bisa mengatakan apa yang berubah bagi pelanggan, mungkin itu tugas internal yang tempatnya di daftar lain.

Bagaimana memutuskan apa yang lebih dulu?

Pilih satu aturan penilaian, tuliskan, dan terapkan ke setiap item. RICE, yang menilai reach, impact, confidence, dan effort, adalah yang paling umum; tulisan Intercom tentang RICE adalah sumber aslinya. Aturan yang lebih sederhana sama baiknya jika Anda bisa menjelaskannya: jumlah permintaan, dibobot menurut apakah peminta adalah akun berbayar yang aktif, dibagi perkiraan kasar usaha.

Yang penting adalah aturannya dinyatakan, karena pelanggan pertama yang bertanya mengapa permintaannya tidak ada di daftar akan menginginkan jawaban. Di mana aturan dan penilaian Anda tidak sejalan, katakan di barisnya. Memprioritaskan permintaan fitur membahas metode penilaian, soal pembobotan pendapatan, dan apa yang bisa dan tidak bisa dikatakan upvote.

Seberapa yakin Anda pada tiap item?

Beri label keyakinan pada setiap item sebelum menerbitkan apa pun. Skala tiga nilai sederhana sudah cukup: pasti berarti tim akan terkejut jika item itu tidak rilis pada periodenya, perkiraan berarti itulah rencananya kecuali ada yang berubah, dan dijajaki berarti tidak ada janji.

Satu kolom ini mencegah sebagian besar kerusakan roadmap. Tanpanya, pelanggan membaca item yang dijajaki sebagai komitmen, tim penjualan mengutipnya, dan sekuartal kemudian itu jadi keluhan. Esai Marty Cagan tentang alternatif untuk roadmap menyampaikan argumen dasarnya: daftar fitur dengan tanggal adalah daftar tebakan yang disajikan sebagai rencana, dan solusinya adalah bersikap eksplisit tentang apa yang Anda ketahui.

Format apa yang sebaiknya dipakai roadmap?

Pilih tata letak paling akhir, menurut pembaca. Pelanggan yang bertanya apakah Anda sudah mendengar mereka butuh tampilan publik yang pendek. Pimpinan yang bertanya mengapa pekerjaan ini butuh tema atau hasil. Tim yang berubah arah tiap bulan cocok dengan Now, Next, dan Later tanpa tanggal. Contoh roadmap produk menampilkan enam format dengan item realistis dan bagaimana masing-masing gagal, dan template roadmap produk memberi kolom yang bisa disalin setelah Anda memilih.

Kebanyakan tim berakhir dengan dua dokumen: roadmap strategis untuk pembaca internal dan versi publik yang lebih ringkas yang hanya menampilkan apa yang bersedia Anda pertanggungjawabkan. Jika Anda menerbitkan satu, roadmap publik menjelaskan cara menggerakkannya dari label pada issue yang sudah Anda lacak.

Bagaimana menjaga roadmap agar tidak basi?

Beri setiap baris tanggal tinjau dan simpan roadmap di tempat pekerjaan berada. Roadmap yang diperbarui manual di alat terpisah jadi basi karena tak ada yang pekerjaan hariannya mencakup itu. Jika tiap kolom dipetakan ke label pada issue, roadmap berubah ketika labelnya berubah.

Tutup lingkarannya ketika item rilis. Orang yang memintanya harus mendengar kabarnya, dan entri changelog adalah tempat yang lazim; lingkaran umpan balik pelanggan menguraikan seluruh jalurnya. Jika Anda memutuskan tidak membuat sesuatu, katakan juga. Jawaban “tidak” yang jelas berguna bagi orang yang bertanya, dan menolak permintaan fitur membahas rumusan katanya.

FAQ

Apa saja langkah cara membuat roadmap produk? Kumpulkan permintaan dan data, kelompokkan menurut masalah di balik masing-masing, urutkan dengan aturan tertulis, beri label seberapa yakin Anda pada tiap item, pilih format untuk pembaca, dan tetapkan tanggal tinjau. Mulai dari bukti membuat roadmap tetap pendek dan bisa dibela.

Roadmap produk sebaiknya didasarkan pada apa? Pada permintaan pelanggan, tema support, data pemakaian, dan strategi Anda, menurut urutan seberapa sering masing-masing dilewatkan. Roadmap tanpa sumber di balik barisnya hanyalah daftar keinginan.

Berapa lama roadmap produk sebaiknya mencakup? Cukup lama untuk berguna dan cukup pendek untuk dipercaya. Bagi banyak tim kecil, itu kuartal berjalan secara rinci dan satu atau dua kuartal berikutnya sebagai tema. Apa pun yang lebih jauh masuk ke “later” tanpa tanggal.

Siapa yang harus terlibat dalam membuat roadmap produk? Pemilik produk memutuskan, engineering memeriksa kelayakan dan usaha, dan support serta penjualan menyumbang permintaan dan tema yang mereka dengar. Pelanggan melihat hasilnya di versi publik, tetapi tidak menyuntingnya.

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

Terkait di changeloop: Dokumentasi developer, Contoh changelog