Penyelidikan Pengguna yang Menggerakkan Roadmap, Bukan Sekadar Mengesahkan Sangkaan

PM sudah membuat keputusan. Dokumen roadmap sudah tiga sprint jauh, tiket Jira sudah digubal, dan pengurus kejuruteraan sudah mempunyai anggaran kasar. Kemudian organisasi reka bentuk berkata "kita patut bercakap dengan pengguna dahulu," dan projek penyelidikan pun dijadualkan.

Lima panggilan. Lima pelanggan yang dipilih sendiri oleh CSM kerana mereka "aktif dan suka berbual." Dokumen Notion dengan enam belas petikan, empat daripadanya menyokong secara lembut, tiada yang mengejutkan. PM membaca rumusan, berkata "ini mengesahkan apa yang kita fikir," dan menghantar ciri itu enam bulan kemudian. Kadar penggunaan terhenti pada 11%. Retro selepas pelancaran menyebutnya sebagai "masalah mesej."

Ia bukan masalah mesej. Ia adalah masalah penyelidikan yang berpakaian sebagai penyelidikan pengguna. Kajian itu tidak gagal kerana metodologinya salah. Ia gagal kerana tiada siapa yang sanggup membiarkannya mengubah keputusan. Itu bukan penyelidikan. Itu upacara semata-mata.

Jika anda sudah bosan dengan gelung ini, inilah panduannya. Ia merangkumi bila menggunakan jenis penyelidikan yang mana, cara mengukur kajian dengan betul, cara menulis dapatan yang bertahan menghadapi PM yang skeptik, dan cara keluar dari perangkap "pengguna kata mereka mahu X" yang secara senyap memihak roadmap kepada sesiapa yang paling lantang menjerit dalam QBR terakhir.

Generatif berbanding penilaian: pilih alat yang betul dahulu

Cara tercepat untuk membazirkan belanjawan penyelidikan adalah memilih kategori yang salah. Penyelidikan generatif menjawab "masalah apa yang kita selesaikan?" Penyelidikan penilaian menjawab "adakah perkara yang kita bina menyelesaikannya?" Ia kelihatan serupa dari luar (kedua-duanya melibatkan pengguna, kedua-duanya menghasilkan petikan), tetapi ia menjawab soalan dalam arah yang bertentangan dan memerlukan saiz sampel yang berbeza, pengambilan peserta yang berbeza, dan sokongan stakeholder yang berbeza.

Kebanyakan pasukan B2B SaaS mencapai untuk penilaian apabila soalan sebenarnya adalah generatif. Seseorang berkata "kita perlu menguji papan pemuka baharu," dan ujian kebolehgunaan dijadualkan sebelum sesiapa bertanya sama ada papan pemuka itu adalah perkara yang betul untuk dibina. Menjelang ujian dijalankan, jawapan yang dapat diberikannya adalah sempit: adakah pengguna dapat mencari butang. Soalan yang penting (perlukah papan pemuka ini wujud?) kini sudah tiada kerana prototaip sudah dibina.

Gunakan jadual ini sebagai fungsi memaksa. Sebelum anda mengspesifikasikan kajian, tuliskan keputusan yang akan dibuat oleh pasukan. Jika keputusan itu adalah "perlukah kita bina ini?", anda memerlukan generatif. Jika ia adalah "perlukah kita hantar versi yang kita bina?", anda memerlukan penilaian. Jika ia adalah "perlukah kita lelaran pada versi yang kita hantar?", anda memerlukan berterusan. Kebanyakan permintaan "kita perlukan penyelidikan pengguna" sebenarnya adalah salah satu daripada tiga ini, dan pemohon biasanya tidak tahu yang mana satu.

Ujian kebolehgunaan 5 pengguna: peraturan sebenar Nielsen, bukan versi yang telah disederhanakan

Kertas Nielsen tahun 1993 mendapati bahawa 5 pengguna sudah cukup untuk menyerlahkan kira-kira 85% isu kebolehgunaan dalam kajian. Angka itu dimampatkan menjadi "sentiasa uji dengan 5" dan telah dipetik oleh orang yang tidak membaca kertas itu selama tiga puluh tahun. Peraturan 5 pengguna berlaku dalam keadaan tertentu, dan keadaan tersebut lebih sempit daripada yang kebanyakan pasukan produk anggap.

Peraturan ini terpakai apabila anda mempunyai satu segmen pengguna, melakukan satu tugasan, pada satu antara muka. Pengguna baharu mendaftar. Pentadbir mengkonfigurasi tetapan tunggal. Pengguna akhir memfailkan satu laporan perbelanjaan. Dalam skop itu, matematik berlaku: menjelang pengguna ke-5 anda sudah melihat kebanyakan isu, dan menjelang pengguna ke-8 anda melihat pengulangan.

Peraturan itu gagal apabila mana-mana syarat tersebut terbatal:

• Pelbagai persona. Jika produk B2B anda mempunyai pentadbir, pengguna akhir, dan IT, anda memerlukan 5 daripada setiap satu. Itu adalah 15 sesi, bukan 5. Pentadbir keliru dengan perkara yang tidak pernah dilihat oleh pengguna akhir.
• Isu konseptual, bukan interaksional. Peraturan 5 pengguna menangkap "Saya tidak dapat mencari butang." Ia terlepas "Saya tidak faham mengapa ciri ini wujud." Salah faham konseptual muncul pada kadar rendah setiap pengguna tetapi lebih penting, anda memerlukan 12-15 untuk mengesannya dengan boleh dipercayai.
• Aliran kerja bercabang. Aliran pendaftaran linear diuji dengan baik menggunakan 5. Aliran kerja dengan 6 cabang bersyarat memerlukan liputan sampel pada setiap cabang. Anda boleh menjalankan 5 pengguna dan melihat 4 daripada mereka tidak pernah mencapai cabang di mana pepijat itu berada.
• Perbandingan merentasi segmen. Jika soalannya adalah "adakah ini berfungsi untuk SMB dan perusahaan?", anda memerlukan kajian bersaiz untuk perbandingan peringkat segmen, iaitu minimum 8-12 per segmen.

Apabila stakeholder berkata "jom buat 5 sahaja," tanya persona yang mana, tugasan yang mana, dan keputusan apa yang akan dimaklumkan oleh hasilnya. Jika keputusan itu adalah "hantar atau jangan hantar merentasi seluruh asas pengguna kami," 5 tidak mencukupi. Jika keputusan itu adalah "adakah aliran pendaftaran ini rosak untuk pengguna SMB baharu khususnya," 5 mungkin sudah mencukupi.

Ujian tidak berpandu: Maze, UserTesting, Lyssna, dan apa yang mereka sembunyikan

Platform tidak berpandu telah mengubah kelajuan pereka menjalankan kajian penilaian. Maze, UserTesting, dan Lyssna membolehkan anda menghantar prototaip kepada 50 penguji dan mendapat hasil menjelang Jumaat. Kelajauan itu nyata. Begitu juga kosnya.

Ujian tidak berpandu menang dalam tiga perkara: kelajuan (masa pemulangan 24-72 jam), jangkauan (anda boleh merekrut panel yang tidak akan anda dapat dalam panggilan berpandu), dan perbandingan kuantitatif (A/B dua reka bentuk pada skala). Untuk tugasan yang jelas dan berkonteks rendah yang ditujukan kepada khalayak luas, sukar untuk menandinginya.

Ia kalah dalam tiga perkara, dan produk B2B menghadapi ketiga-tiganya:

1. Aliran kerja yang kompleks. Kajian berpandu membolehkan anda melihat pengguna berfikir secara lantang, bertanya "mengapa anda klik itu?", dan menyelidiki apabila mereka tersekat. Tidak berpandu, anda mendapat video seseorang yang mengklik perkara yang salah dalam kesunyian dan meneruskan. Anda belajar bahawa mereka gagal. Anda tidak tahu mengapa.
2. Antara muka yang penuh jargon. Produk B2B penuh dengan istilah yang pengguna hanya faham dalam konteks. Penguji tidak berpandu dari panel akan meneka, gagal, dan menilai ujian sebagai "mudah" kerana mereka tidak tahu apa yang tidak mereka tahu. Ujian menghasilkan data yang kelihatan bersih dan jurang kefahaman yang senyap.
3. Soalan "mengapa". Apa-apa yang memerlukan pemahaman niat, motivasi, atau penaakulan pertukaran memerlukan moderator. Alatan tidak berpandu telah bertambah baik dalam soalan susulan, tetapi soalan susulan yang direkod mendapat jawapan yang dilatih. Moderator secara langsung mendapat jawapan yang sebenar.

Kadar penyelesaian sebenar menyokong ini. Untuk tugasan berorientasikan pengguna, ujian B2C tidak berpandu mencecah 80-95% penyelesaian. Untuk aliran kerja B2B SaaS, jangkakan 60-75%. Jurang itu penting apabila mengukur: kajian yang memerlukan n=20 sesi yang sah pada aliran kerja B2B memerlukan 28-32 permulaan untuk mencapainya. Rancang untuk pelepasan itu.

Perangkap yang kebanyakan pasukan jatuh ke dalamnya: mereka memilih tidak berpandu kerana pantas, kemudian membuat keputusan yang memerlukan kedalaman berpandu. Maze memberitahu anda kadar klik melalui. Ia tidak memberitahu anda bahawa 4 daripada 12 pengguna SMB tidak tahu apa maksud "tenant" dalam panel tetapan IT anda dan hanya meneka jawapan yang betul.

Perangkap "penyelidikan menunjukkan pengguna mahu X"

Di sinilah kebanyakan penyelidikan B2B berakhir. Berat sebelah pemilihan, berat sebelah terkini, dan berat sebelah pengesahan bergabung, dan kajian dengan lapan peserta menjadi roadmap yang dibina untuk khalayak yang anda tidak miliki.

Berat sebelah pemilihan datang dari siapa yang menjawab panggilan. Customer success memilih pelanggan yang aktif kerana mereka menjawab e-mel. Pelanggan yang aktif lebih berkemungkinan menjadi perusahaan, lebih berkemungkinan menjadi pentadbir, dan lebih berkemungkinan menginginkan ciri yang menjadikan aliran kerja sedia ada mereka lebih berkuasa. Sampel 8 daripada mereka dan anda akan mendengar mesej yang bersatu padu: lebih banyak kebenaran, lebih banyak peranan, lebih banyak kawalan gred perusahaan. Jika perniagaan anda adalah 70% SMB mengikut ARR, anda baru sahaja menjalankan kajian yang ditujukan kepada 30% yang tidak memerlukan bantuan pun.

Berat sebelah terkini datang dari pelanggan lantang terakhir. QBR berlaku minggu lepas, VP mendengar dari akaun $400K, dan "pengguna mahukan SSO" dimasukkan ke dalam dokumen perancangan sebagai petikan tanpa n yang dilampirkan. Menjelang penyelidikan direkrut, soalan yang ditanya bukan "adakah pengguna mahu SSO?" tetapi "seberapa teruk pengguna mahu SSO?", dan saringan pengambilan peserta memihak kepada pengguna yang menganggap SSO berharga.

Berat sebelah pengesahan ada dalam soalan itu sendiri. "Adakah berguna jika anda boleh mengeksport laporan secara pukal?" mendapat ya dari hampir semua orang. "Bagaimana anda mengendalikan pelaporan pada masa ini?" memberitahu anda sama ada eksport pukal adalah halangan sebenar atau sesuatu yang elok dimiliki yang terbenam di bawah sepuluh perkara yang mereka sebenarnya bergelut setiap hari.

Contoh sebenar yang dianonim: kajian terhadap 8 pentadbir dari 3 akaun perusahaan menghasilkan tajuk "pengguna mahu SSO." Roadmap beralih kepada suku setengah kerja SSO dan SCIM. Enam bulan kemudian, churn SMB meningkat kerana pasukan yang memiliki pengaktifan telah dipindahkan ke projek SSO. 8 pentadbir itu gembira. 1,400 akaun SMB yang tidak pernah melepasi minggu ke-2 pengaktifan tidak pernah ditemubual. Kajian itu tidak salah tentang 8 pentadbir. Ia salah kerana dilayan sebagai kajian tentang "pengguna."

Pertahanannya adalah prosedural. Sebelum merekrut, tuliskan: kajian ini adalah tentang segmen yang mana, berapa perkadaran hasil yang diwakili oleh segmen itu, dan keputusan apa yang boleh dimaklumkan secara sah oleh kajian ini? Jika jawapan kepada soalan ketiga adalah "hanya keputusan tentang segmen ini," letakkan itu pada slaid muka laporan. Stakeholder akan menggenaralisasikan melainkan anda menjadikan skop itu eksplisit.

Cara menulis dapatan yang mengubah keputusan

Kebanyakan dapatan penyelidikan mati pada slaid yang ditulisnya. "Pengguna keliru dengan butang eksport" kalah dalam setiap hujah kerana ia tidak mempunyai n, tiada segmen, tiada kekhususan, dan tiada cadangan. Ia boleh benar dan masih diabaikan.

Dapatan yang bertahan menghadapi PM yang skeptik mempunyai lima bahagian:

1. Pemerhatian: apa yang berlaku, secara tingkah laku
2. Bukti: n, segmen, tugasan, jenis kajian
3. Inferens: apa yang ini mungkin bermaksud
4. Cadangan: apa yang perlu dilakukan
5. Tahap keyakinan: seberapa yakin anda

Bandingkan:

Buruk: Pengguna keliru dengan butang eksport.

berbanding:

Baik: 6 daripada 8 pentadbir (n=8, peringkat perusahaan, ujian kebolehgunaan berpandu, tugasan eksport laporan mingguan) meninggalkan aliran eksport pada langkah pemilihan format. Tiga berkata dengan lantang mereka tidak tahu apa maksud "delimited"; dua mengklik format yang salah dan tidak menyedarinya. Inferens: pemilih format adalah halangan kefahaman, bukan isu penemuan. Cadangan: lalai kepada CSV dengan pendedahan "lebih banyak format," hantar di belakang bendera dan ukur delta pengabaian. Keyakinan: sederhana. Sampel adalah kecil dan hanya perusahaan; susulan tidak berpandu selama 2 minggu merentasi SMB akan mengesahkan.

Yang kedua menang kerana ia memberitahu PM dengan tepat apa yang diketahui, apa yang diinferskan, dan tindakan apa yang mengikutinya. PM yang skeptik boleh menyerang mana-mana daripada lima bahagian, tetapi mereka perlu menyerang bahagian yang khusus. Mereka tidak boleh hanya berkata "sampel kecil" dan beredar, kerana cadangan sudah mengambil kira itu dengan rancangan susulan.

Corak kedua yang membantu: mulakan dapatan dengan keputusan yang ia pengaruhi, bukan metodologi. "Kita perlu mengubah lalai eksport" mengesankan. "Kami menjalankan kajian berpandu dengan 8 pentadbir" menidurkan pendengar sebelum cadangan tiba.

Membentangkan penyelidikan kepada PM yang skeptik

Dek penyelidikan 23 slaid yang dihulurkan kepada PM semasa standup tidak akan mengubah roadmap. Ia akan diakui, difailkan, dan diabaikan. PM adalah pembuat keputusan di bawah tekanan masa. Penyelidikan perlu menemui mereka di mana mereka berada.

Lima perkara yang benar-benar berkesan:

Mulakan dengan keputusan. Buka dengan "kajian ini memaklumkan sama ada kita menghantar aliran eksport baharu seperti sedia ada, menghantar dengan satu perubahan, atau membina semula." Kemudian metodologi, kemudian dapatan. PM kini membaca untuk membuat keputusan, bukan membaca untuk menilai penyelidikan.

Antisipasilah bantahan. Sebelum membentangkan, tuliskan tiga bantahan yang anda jangkakan ("sampel kecil," "mereka bukan ICP kami," "kita dah buat keputusan"). Tangani setiap satu dalam dek sebelum ia dibangkitkan. Berkata "n=8 adalah kecil untuk dakwaan merentasi segmen, itulah sebabnya kajian ini hanya bercakap tentang pentadbir perusahaan yang melakukan tugasan eksport" menyahaktifkan serangan sampel-kecil sebelum ia mendarat.

Bawa klip mentah, bukan ringkasan. Video 45 saat seorang pentadbir memandang dropdown format dan berkata "Saya tidak tahu apa maksud mana-mana satu daripada ini" bernilai lima belas slaid petikan. PM lebih mempercayai mata mereka sendiri berbanding sintesis anda. Alatan seperti Dovetail dan UserTesting menjadikan pengambilan klip pantas.

Kaitkan kepada metrik yang PM sudah ambil berat. Jika PM memiliki pengaktifan, bingkaikan dapatan sekitar impak pengaktifan. Jika mereka memiliki pengekalan, bingkaikan sekitar pengekalan. "Geseran eksport ini menyentuh pengaktifan minggu ke-2 untuk pentadbir baharu" mengalahkan "geseran eksport ini adalah isu UX" setiap masa.

Namakan kos mengabaikannya. "Jika kita hantar seperti sedia ada, kita jangkakan lebih kurang 30-40% pentadbir baharu akan meninggalkan tugasan eksport dalam bulan pertama, berdasarkan kadar pengabaian sesi berpandu" memberi PM sesuatu untuk ditimbang terhadap tarikh penghantaran.

Peraturan praktikal: jika dapatan penyelidikan tidak boleh muat dalam satu slaid dengan keputusan, bukti, cadangan, dan satu petikan, ia belum lagi menjadi dapatan. Ia adalah catatan buku nota. Terus usahakan sebelum dibawa ke bilik.

Apa yang perlu dilakukan minggu ini

Pilih satu keputusan roadmap yang akan datang. Tuliskan apa yang sedang diputuskan, siapa yang memutuskannya, dan apa yang perlu benar untuk keputusan itu berubah. Kemudian tanya: adakah pasukan mempunyai bukti untuk perkara yang perlu benar itu? Jika tidak, itulah kajiannya. Jika ya, penyelidikan sudah dilakukan dan langkah seterusnya adalah menyerlahkannya.

Penyelidikan yang menggerakkan roadmap adalah penyelidikan yang ditujukan kepada keputusan tertentu, bersaiz untuk dakwaan yang perlu disokongnya, dan dibentangkan dalam bentuk yang boleh bertindak balas oleh PM yang sibuk. Semua yang lain adalah bengkel. Bengkel tidak mengapa. Hanya jangan mengelirukan mereka dengan kajian.

Ketahui Lebih Lanjut

• Kritik Reka Bentuk yang Memperbaiki Kerja, Bukan Mood Pereka
• Bekerja dengan PM yang Menganggap Reka Bentuk Sekadar Hiasan
• Kelajuan Penghantaran untuk Pereka
• Templat Penerangan Kerja Pereka Produk