Kejayaan Pelanggan & Penjajaran Produk

Beginilah cara kebanyakan permintaan ciri bergerak melalui syarikat SaaS: Seorang CSM mendengar "kami perlu eksport pukal" daripada pelanggan yang kecewa. CSM mencatatnya dalam platform CS sebagai permintaan ciri. PM membaca "eksport pukal: 4 akaun" dalam ringkasan maklum balas mingguan. Ia masuk ke dalam backlog di bawah 30 permintaan lain. Enam bulan kemudian, pelanggan meninggalkan syarikat. Temu bual selepas perkhidmatan tamat: "Kami tidak dapat mengeluarkan data kami untuk menjalankan laporan yang diperlukan oleh pimpinan kami."

Permintaan ciri itu nyata. Tetapi "eksport pukal" adalah penyelesaian yang dicadangkan oleh pelanggan, bukan tugas yang mereka ingin produk lakukan untuk mereka. Tugas sebenar ialah: apabila saya perlu membuat laporan kepada pihak luar, saya perlu mengeluarkan data dalam format yang boleh dibaca oleh pihak berkepentingan saya, tanpa perlu menyalin dan menampal baris demi baris.

Itu adalah masalah yang berbeza. Ia mungkin diselesaikan dengan eksport. Atau dengan pautan papan pemuka yang boleh dikongsi. Atau dengan integrasi Salesforce asli. Pasukan CS mempunyai isyarat mentah. Tiada seorang pun yang mentafsirkannya.

Jobs-to-be-Done (JTBD) adalah lapisan terjemahan. Ia tidak memerlukan pengumpulan data baru. Ia adalah disiplin pentafsiran semula yang diterapkan pada data yang sudah ada pada CS.

Apakah JTBD Sebenarnya (dan Bukan)

Pembingkaian asal Clayton Christensen adalah mudah: orang tidak membeli produk. Mereka menyewa produk untuk menyelesaikan satu tugas. Artikel HBR asas Christensen tentang JTBD menjelaskan perkara ini dengan jelas: contoh minuman susu pekat terkenal. McDonald's mendapati bahawa pemandu yang berulang alik pada waktu pagi menyewa minuman susu pekat untuk membuatkan perjalanan yang membosankan terasa lebih pendek dan menahan lapar hingga waktu makan tengah hari, bukan kerana mereka lapar atau ingin memanjakan diri. Tugaslah yang menentukan strategi produk. Minuman susu pekat yang lebih pekat, jerami yang lebih mudah digunakan, dijual di tingkap pandu masuk.

Bob Moesta, yang mengoperasikan JTBD pada peringkat pengamal, mendorong lebih jauh: tugas bukan sekadar fungsional. Ia mempunyai konteks (situasi yang mencetuskan keperluan), hasil yang diinginkan (seperti apa "selesai" kelihatan), dan kekangan (apa yang pelanggan tidak dapat atau tidak mahu lakukan). Format pernyataan tugas yang dihasilkan oleh karyanya adalah yang patut digunakan oleh pasukan CS:

Struktur pernyataan tugas:

"Apabila [situasi], saya perlu [hasil fungsional], tanpa [kekangan]."

Ini bukan format user story. "Sebagai pengguna, saya ingin eksport pukal" menerangkan keutamaan. Pernyataan JTBD menerangkan situasi, hasil, dan apa yang menjadikan pendekatan semasa tidak boleh dikerjakan. Ini adalah perkara yang berbeza, dan perbezaan itu penting untuk keputusan produk.

JTBD juga tidak sama dengan "titik kesakitan." Titik kesakitan menerangkan geseran. Tugas menerangkan niat. Pelanggan yang berkata "laporan lambat" sedang menerangkan kesakitan. Tugas yang mendasarinya ialah "apabila saya membentangkan secara langsung kepada pimpinan, saya perlu menarik data pelanggan dalam bawah lima saat, tanpa kehilangan kredibiliti kepada roda muat yang berpusing." Titik kesakitan mengarah kepada baiki prestasi. Pernyataan tugas mengarah kepada soalan: situasi apa yang mencetuskan keperluan, dan seperti apa "diselesaikan dengan baik" sebenarnya kelihatan?

Untuk perbualan VP CS dan Head of Product, lensa operasi Moesta lebih berguna daripada lensa teori Christensen. Soalannya bukan "tugas apa yang dilakukan oleh produk kami?" Soalannya ialah "tugas apa yang sebenarnya pelanggan sewa ia untuk lakukan, dan tugas mana yang kami gagal?" Penyelidikan McKinsey tentang kejayaan pelanggan 2.0 membuat titik selari: pasukan CS yang menggunakan pengetahuan pelanggan untuk mendedahkan tugas yang tidak dipenuhi mewujudkan pengekalan yang lebih tahan lama berbanding mereka yang memberi tumpuan kepada pengurusan hubungan semata-mata.

Fakta Utama: JTBD dan Kualiti Isyarat CS

Menurut Laporan Pengurusan Produk 2024 ProductPlan, 72% pasukan produk menyatakan maklum balas pelanggan adalah salah satu daripada tiga input teratas mereka untuk keputusan pelan hala tuju produk, tetapi hanya 31% yang mempunyai proses berstruktur untuk mentafsirkan maklum balas tersebut pada peringkat tugas dan bukannya peringkat ciri.

Temu bual peralihan pelanggan secara konsisten dinilai sebagai sumber data CS dengan isyarat tertinggi untuk pengekstrakan JTBD, menurut penyelidikan Penanda Aras Kejayaan Pelanggan Gainsight, namun kurang daripada 40% pasukan CS yang menjalankan temu bual keluar berstruktur yang bertanya tentang apa yang cuba dicapai oleh pelanggan.

Pasukan yang menerapkan pemberat ARR pada pernyataan tugas (bukan hanya bilangan permintaan ciri) melaporkan penjajaran 2.3x lebih tinggi antara maklum balas CS dan item pelan hala tuju produk yang dihantar, menurut tinjauan Keadaan Pengurusan Produk Productboard.

Di Mana Data CS Sesuai dengan Model JTBD

Data CS adalah bahan mentah terkaya untuk pengekstrakan tugas di kebanyakan syarikat SaaS. Cabarannya ialah ia datang dalam format yang salah. Berikut adalah cara setiap sumber memetakan kepada komponen JTBD.

Nota panggilan sebagai konteks situasi. Apabila CSM menulis "pelanggan berkata aliran kerja pelaporan menyakitkan semasa mesyuarat perancangan Isnin mereka," itu adalah klausa situasi: "apabila saya menjalankan mesyuarat perancangan Isnin." Ia terbenam dalam nota, tetapi ia ada. CSM menangkap "apabila" secara berterusan. Mereka hampir tidak pernah mendedahkannya sebagai input JTBD.

Temu bual keluar kadar peralihan pelanggan sebagai isyarat kegagalan tugas yang paling jujur. Apabila pelanggan meninggalkan syarikat, mereka memecat produk daripada satu tugas. Temu bual keluar yang dijalankan dengan baik bertanya: apa yang anda cuba capai yang produk tidak bantu anda lakukan? Apa yang anda akan lakukan sebagai gantinya? Ini adalah emas tulen JTBD. Klausa kekangan hampir selalu muncul dalam temu bual kadar peralihan pelanggan: "Saya tidak dapat melakukan X tanpa Y," di mana Y adalah perkara yang produk gagal sediakan. Pasukan CS yang menggandingkan temu bual keluar dengan isyarat sistem amaran awal sering dapat menangkap kegagalan tugas sebelum peralihan pelanggan dan bukannya selepasnya.

Verbatim QBR sebagai pernyataan hasil yang terselindung. Apabila pelanggan berkata dalam QBR "kami mahu ini menjadi sumber kebenaran tunggal kami untuk data pelanggan," mereka menyatakan hasil yang diinginkan. Itu adalah klausa tengah pernyataan tugas. CSM mendengarnya sebagai aspirasi. Ia sebenarnya adalah takrifan tugas.

Lonjakan tiket sokongan sebagai bukti tugas negatif. Apabila 15 tiket tiba dalam seminggu tentang aliran kerja yang sama, itu adalah bukti bahawa produk gagal melaksanakan satu tugas bagi pelanggan yang cukup ramai untuk mencetuskan kekecewaan aktif. Tugasnya bukan "baiki pepijat." Ia adalah "fahami tugas apa yang cuba dilakukan oleh semua 15 akaun ini apabila mereka menghadapi halangan ini."

Verbatim NPS daripada penyokong berbanding penentang. Penyokong menerangkan tugas yang dilakukan produk dengan baik. Penentang menerangkan tugas yang produk gagal. Kontras antara dua kohort tersebut memetakan secara langsung kepada tempat prestasi tugas kukuh dan di mana ia rosak. Data trend NPS menjadi jauh lebih boleh diambil tindakan apabila ia dilapisi dengan penggunaan produk dan isyarat kesihatan akaun. Akaun dengan penggunaan tinggi dan NPS yang merosot adalah kohort yang paling mendesak.

Bahan mentah itu ada. Jurangnya adalah proses pengekstrakan yang menukarkannya kepada pernyataan tugas yang boleh ditindaklanjuti oleh produk.

Proses Pengekstrakan: Daripada Isyarat Mentah kepada Pernyataan Tugas

Kerangka Kerja Bernama: Pengekstrakan JTBD 5 Langkah Pengekstrakan JTBD 5 Langkah menukar data CS mentah kepada pernyataan tugas yang disahkan menggunakan penandaan berasaskan situasi, penggubahan pernyataan tugas, pengesahan verbatim berbilang akaun, pemberat ARR, dan penyerahan peta tugas kepada produk. Kerangka kerja ini dibangunkan daripada teori JTBD asal Clayton Christensen dan pengoperasian pengamal Bob Moesta, disesuaikan untuk pasukan CS SaaS pasaran pertengahan yang memerlukan perisikan tugas berstruktur tanpa mengubah proses data CS sedia ada mereka.

Ini adalah proses lima langkah. Ia tidak memerlukan alat khusus. Dokumen dikongsi sudah mencukupi.

Langkah 1: Tarik data CS mengikut tema, bukan mengikut permintaan ciri. Jangan mulakan dengan "apa yang diminta oleh pelanggan?" Mulakan dengan "situasi apa yang terus diterangkan oleh pelanggan?" Tarik nota panggilan, tiket sokongan, dan verbatim QBR dari suku tahun lepas dan tandakan mengikut jenis situasi, bukan mengikut kawasan produk.

Langkah 2: Tulis semula setiap kluster sebagai pernyataan tugas. Ambil kluster nota sekitar satu tema dan tulis satu atau dua pernyataan tugas menggunakan format: "Apabila [situasi], saya perlu [hasil yang diinginkan], tanpa [kekangan]." Jangan melicinkan kekangan. Ia sering kali merupakan bahagian yang paling penting.

Langkah 3: Sahkan dengan tiga atau lebih verbatim daripada akaun yang berbeza. Pernyataan tugas yang hanya boleh bersumber kepada satu akaun adalah anekdot, bukan corak. Anda memerlukan sekurang-kurangnya tiga verbatim daripada akaun yang berbeza (idealnya daripada akaun pada peringkat ARR yang berbeza) sebelum menganggapnya sebagai tugas yang disahkan.

Langkah 4: Lampirkan berat ARR dan bilangan akaun kepada setiap tugas. "7 akaun mewakili $420 ribu ARR gagal melaksanakan tugas ini" adalah input pengutamaan produk. "7 akaun" hanyalah kiraan. Berat ARR mengubah pernyataan tugas menjadi keputusan perniagaan. Disiplin pengukuran yang sama terpakai di sini seperti dalam saluran paip maklum balas yang lebih luas.

Langkah 5: Serahkan peta tugas, bukan senarai ciri. Output kepada produk adalah satu set pernyataan tugas dengan verbatim sokongan, berat ARR, dan bilangan akaun. Bukan senarai permintaan ciri. Jika anda menyerahkan senarai ciri kepada produk, anda mendapat keputusan peringkat ciri. Jika anda menyerahkan peta tugas, anda mendapat keputusan peringkat keupayaan.

Analisis Rework: Berdasarkan penanda aras pasukan CS, pasukan produk yang menerima peta tugas berbanding senarai ciri semasa sesi maklum balas suku tahunan membuat keputusan pelan hala tuju produk peringkat keupayaan dalam masa kira-kira separuh masa berbanding mereka yang menilai giliran permintaan ciri mentah. Format pernyataan tugas (situasi + hasil + kekangan) memberi PM konteks untuk menilai pertukaran tanpa menjadualkan temu bual susulan untuk setiap item. Ambang pengesahan tiga verbatim juga menapis anekdot daripada corak, mengurangkan peratusan perbincangan pelan hala tuju produk yang dihabiskan oleh kes tepi satu akaun.

Contoh Praktikal: Sebelum dan Selepas

Dua contoh ini menunjukkan terjemahan dalam praktik.

Contoh 1:

Permintaan ciri: "Kami perlu eksport pukal."
Pernyataan tugas: "Apabila saya perlu membentangkan data pelanggan kepada pasukan pimpinan kami setiap suku tahun, saya perlu mengeluarkan data itu dalam format yang boleh dibaca oleh alat BI kami, tanpa perlu menyalin 300 baris secara manual ke dalam hamparan."
Implikasi produk: eksport pukal mungkin menyelesaikan masalah ini, tetapi integrasi BI asli, titik hujung API, atau paparan yang boleh dikongsi dengan pemformatan eksport juga boleh. Pernyataan tugas membuka ruang penyelesaian.

Contoh 2:

Permintaan ciri: "Boleh anda baiki kelambatan dalam laporan?"
Pernyataan tugas: "Apabila saya berada dalam mesyuarat pelanggan secara langsung dan perlu menarik data penggunaan mereka untuk menjawab soalan, saya perlu laporan dimuat dalam bawah lima saat, tanpa kehilangan perhatian pelanggan kepada roda muat yang berpusing."
Implikasi produk: "baiki kelambatan" adalah samar-samar. Pernyataan tugas memberitahu produk bahawa pencetusnya adalah mesyuarat langsung, hasilnya adalah mengekalkan perhatian pelanggan, dan kekangannya adalah kelewatan pemuatan. Itu adalah ringkasan kejuruteraan yang jauh lebih spesifik.

Contoh 3:

Verbatim penentang NPS: "Kami tidak dapat mengurus kebenaran mengikut cara yang diperlukan oleh pasukan keselamatan IT kami."
Pernyataan tugas: "Apabila kami memasukkan pasukan baru ke platform, saya perlu mengkonfigurasi akses berasaskan peranan yang sepadan dengan dasar keselamatan dalaman kami, tanpa perlu meminta pasukan sokongan anda untuk membuat perubahan manual."
Implikasi produk: permintaan ciri yang tersirat di sini ialah "kebenaran terperinci." Pernyataan tugas mendedahkan konteks (proses penerimaan pelanggan), hasil yang diinginkan (pematuhan dasar layan diri), dan kekangan (kebergantungan pada sokongan vendor).

Contoh 4:

Temu bual keluar kadar peralihan pelanggan: "Kami akhirnya membina penyelesaian kami sendiri kerana kami tidak dapat membuat aliran kerja sesuai dengan proses kami."
Pernyataan tugas: "Apabila kami mengendalikan [aliran kerja tertentu], kami perlu sistem menyesuaikan diri dengan proses sedia ada kami, tanpa perlu mereka bentuk semula proses itu untuk memenuhi alat."
Implikasi produk: ini adalah kegagalan tugas klasik "produk terlalu dogmatik." Pelanggan menyewa produk untuk menyesuaikan diri dengan aliran kerja mereka. Produk menyewa mereka untuk menyesuaikan diri dengan aliran kerja produk. Mereka memecatnya.

Di Mana JTBD Gagal dengan Data CS

Pengekstrakan JTBD gagal dengan cara yang boleh diramal. Mengetahuinya terlebih dahulu mencegah sesi sintesis yang sia-sia.

CSM yang merumuskan dan bukannya memetik. Apabila CSM menulis "pelanggan mahukan pelaporan yang lebih baik," situasi, hasil, dan kekangan semuanya telah dilucutkan dalam rumusan itu. Parafrasa membunuh pengekstrakan JTBD. Penyelesaian disiplin adalah mudah: nota panggilan memerlukan satu petikan verbatim bagi setiap isu yang dieskalasikan, bukan rumusan. Ini adalah perubahan amalan penandaan, bukan perubahan alat.

Kecenderungan terhadap akaun kecil. Sepuluh tiket SMB tentang ciri yang sama akan menenggelamkan dua verbatim perusahaan dalam kiraan mentah. Tetapi jika dua verbatim perusahaan tersebut mewakili $800 ribu ARR dan tiket SMB mewakili $50 ribu secara gabungan, pemberat ARR dalam Langkah 4 membetulkan perkara ini. Jangan jalankan pengekstrakan JTBD tanpa melampirkan nombor ARR.

Kecenderungan terhadap data terkini dalam nota panggilan. Verbatim QBR dari 18 bulan lalu tentang tugas yang produk gagal lakukan masih merupakan bukti, terutama jika produk belum menanganinya. Menapis pengekstrakan tugas kepada 90 hari terakhir melepaskan kegagalan tugas yang berterusan dan tidak diselesaikan.

Pelanggan yang menerangkan gejala, bukan niat. Sesetengah pelanggan boleh mengartikulasikan tugas dengan jelas. Yang lain hanya menerangkan gejala ("papan pemuka tidak berfungsi untuk kami"). Apabila verbatim adalah gejala sahaja, langkah pengekstrakan adalah hipotesis: tugas apa yang mungkin ditunjukkan oleh gejala ini? Hipotesis ini memerlukan sekurang-kurangnya tiga verbatim yang menyokong sebelum menjadi pernyataan tugas yang disahkan.

Membina Amalan JTBD di Jahitan CS-Produk

Sesi perlombongan tugas bulanan adalah kadar operasi yang tepat untuk kebanyakan pasukan pasaran pertengahan. Penyelidikan Keadaan Kejayaan Pelanggan TSIA secara konsisten mendapati bahawa amalan maklum balas berstruktur (bukan peningkatan isu secara ad-hoc) adalah pembeza utama antara pasukan CS yang mempengaruhi pelan hala tuju produk dan yang tidak. Sesi berjalan selama 90 minit, melibatkan VP CS, Head of Product, dan seorang wakil CS Ops. Sesi ini adalah sambungan CS sebagai saluran suara pelanggan, disiplin berstruktur yang menukar isyarat lapangan kepada perisikan produk. Outputnya adalah tiga hingga lima pernyataan tugas yang disahkan, bukan senarai ciri.

Apa yang dicakup oleh sesi ini: CS Ops mengeluarkan data maklum balas suku tahun mengikut tema. VP CS membentangkan dua hingga tiga calon pernyataan tugas dengan verbatim sokongan. Produk mengemukakan soalan penjelasan tentang konteks situasi dan kekangan. Kumpulan mengesahkan sama ada setiap calon memenuhi ambang tiga verbatim dan menerapkan pemberat ARR. Sesi berakhir dengan peta tugas berperingkat yang memberi maklumat kepada ulasan maklum balas suku tahunan.

Perubahan penandaan yang membolehkan ini: CSM perlu menandakan nota panggilan dengan jenis situasi pada masa penangkapan. Bukan secara retroaktif. Empat tag situasi merangkumi 80% tugas yang relevan dengan CS: pelaporan eksekutif, proses penerimaan pasukan, aliran kerja merentas pasukan, dan mesyuarat pelanggan langsung. Ini adalah situasi pencetus yang paling kerap muncul dalam pengekstrakan JTBD bersinyal tinggi.

Berapa banyak tugas per suku tahun: tiga hingga lima pernyataan tugas yang disahkan adalah jumlah yang tepat. Lebih daripada lima membebankan perbualan pelan hala tuju produk. Kurang daripada tiga mencadangkan proses pengekstrakan tidak menarik daripada sumber data yang mencukupi.

Integrasi dengan Saluran Paip VoC yang Lain

JTBD berada pada peringkat abstraksi yang lebih tinggi daripada permintaan ciri. Ia memberi maklumat kepada strategi pelan hala tuju produk, bukan backlog sprint. Ini adalah perbezaan yang penting.

Permintaan ciri adalah input backlog. Ia menjawab "keupayaan khusus apa yang pelanggan mahukan?" Pernyataan tugas adalah input strategi. Ia menjawab "kemajuan apa yang cuba dibuat oleh pelanggan?" Pasukan produk memerlukan kedua-duanya, tetapi ia harus dihalakan secara berbeza. Permintaan ciri pergi kepada saluran paip VoC yang memberi maklumat kepada backlog produk. Peta tugas pergi kepada perbualan strategi pelan hala tuju produk: khususnya ulasan maklum balas pelanggan suku tahunan, di mana VP CS dan Head of Product membuat keputusan pengutamaan pada peringkat keupayaan.

Apabila CS membawa peta tugas kepada ulasan maklum balas pelanggan suku tahunan, ia mengubah sifat perbualan. Daripada "yang mana daripada 20 permintaan ciri ini perlu kami bina?" soalannya menjadi "tugas yang mana daripada lima ini perlu kami selesaikan pada suku tahun akan datang?" Produk dapat merespons pernyataan tugas dengan pelbagai penyelesaian yang lebih luas. Dan langkah pengukuran maklum balas berwajaran ARR memastikan pengutamaan tugas mencerminkan realiti komersial, bukan jumlah tiket.

Perbezaan itu penting kerana JTBD dan permintaan ciri berwajaran ARR menjawab soalan yang berbeza. Permintaan ciri menjawab "apa yang pelanggan mahukan?" JTBD menjawab "apa yang cuba dicapai oleh pelanggan?" Kedua-duanya sah. Gunakan JTBD apabila keputusan produk adalah tentang pelaburan keupayaan. Gunakan permintaan ciri berwajaran ARR apabila keputusan adalah tentang fungsi tertentu.

Nota Alat

Tiada alat khusus diperlukan. Templat berstruktur dalam Notion, Confluence, atau Google Doc dikongsi mengendalikan peta tugas untuk kebanyakan pasukan pasaran pertengahan. Medan templat: situasi, hasil yang diinginkan, kekangan, verbatim sokongan (minimum tiga), bilangan akaun, berat ARR, dan jenis data sumber (nota panggilan / temu bual kadar peralihan pelanggan / QBR / tiket sokongan).

Transkrip Gong dan Chorus adalah bahan mentah yang berguna. Cari mengikut kluster kata kunci, bukan mengikut niat, kerana carian AI pada transkrip tidak mendedahkan niat tugas dengan boleh dipercayai lagi. Cari corak "apabila kami," "kami perlu," "kami tidak dapat," "kami terpaksa." Frasa-frasa ini paling kerap muncul dalam klausa situasi dan kekangan pernyataan tugas yang terbenam dalam perbualan pelanggan.

Gainsight dan ChurnZero mendedahkan maklum balas pada peringkat akaun, yang berguna untuk pemberat ARR. Tetapi ia tidak mengekstrak pernyataan tugas. Itu adalah langkah sintesis manusia. Apa yang platform CS membantu adalah menarik verbatim yang dikaitkan dengan kluster akaun tertentu. Apa yang mereka kabur adalah corak peringkat tugas merentas akaun, kerana ia dibina sekitar rekod akaun, bukan kategori tugas.

Diagnostik: Adakah Penandaan Semasa Anda Menyokong Pengekstrakan JTBD?

Sebelum melabur dalam sesi perlombongan tugas bulanan, jalankan diagnostik ini. Lima soalan:

Adakah nota panggilan merangkumi sekurang-kurangnya satu petikan verbatim bagi setiap isu yang dieskalasikan, atau hanya parafrasa CSM?
Adakah tema tiket sokongan ditandakan mengikut jenis situasi, atau hanya mengikut kawasan produk?
Adakah temu bual keluar kadar peralihan pelanggan bertanya "apa yang anda cuba capai?" secara eksplisit?
Adakah verbatim QBR ditangkap dalam format yang boleh dicari, atau terbenam dalam nota dek?
Adakah ARR dilampirkan kepada sebarang rekod maklum balas sebelum ia mencapai produk?

Jika anda menjawab "tidak" kepada tiga atau lebih daripada ini, proses pengekstrakan JTBD akan menghasilkan bahan mentah berkualiti rendah. Baiki penandaan sebelum menjadualkan sesi perlombongan.

Sprint Perlombongan Tugas 2 Minggu

Untuk pasukan yang baharu kepada JTBD, ini adalah cara terpantas untuk menghasilkan peta tugas yang disahkan pertama anda tanpa mengubah proses data CS anda.

Minggu 1, hari 1-2: Tarik nota temu bual kadar peralihan pelanggan suku tahun lepas (semuanya) dan tandakan setiap satu mengikut jenis situasi. Tulis draf pernyataan tugas untuk setiap kluster dua atau lebih.

Minggu 1, hari 3-5: Tarik tiga tema peningkatan sokongan teratas dari suku tahun lepas. Semak sama ada setiap satu memetakan kepada situasi yang sudah ditandakan dalam temu bual kadar peralihan pelanggan. Jika ya, kukuhkan pernyataan tugas dengan verbatim sokongan.

Minggu 2, hari 1-2: Tarik verbatim QBR dari dua suku tahun lepas. Tandakan sebarang pernyataan hasil ("kami mahu menggunakan ini untuk...") atau pernyataan kekangan ("kami tidak dapat melakukan ini kerana..."). Tambah kepada kluster tugas yang relevan.

Minggu 2, hari 3-5: Muktamatkan tiga hingga lima pernyataan tugas dengan sekurang-kurangnya tiga verbatim setiap satu. Lampirkan berat ARR dan bilangan akaun. Bentangkan kepada tiga PM dan tanya: "Adakah ini kedengaran seperti masalah yang sepatutnya diselesaikan oleh strategi produk kami?" Jika PM menambah verbatim baru, tugas itu nyata. Jika mereka menolak dengan "kami sudah menyelesaikan itu," minta mereka tunjukkan di mana. Jurang antara jawapan mereka dan bukti pelanggan adalah tempat pemarkahan impak pelanggan untuk keputusan produk paling berguna.

Sprint 2 minggu menghasilkan peta tugas pertama anda. Proses pengecaman corak yang berjalan secara berterusan merentas CSM adalah apa yang memastikan peta tugas itu terkini antara sesi suku tahunan.

Soalan Lazim

Apakah Jobs-to-be-Done (JTBD) dalam konteks data CS?

Jobs-to-be-Done adalah kerangka kerja, dibangunkan oleh Clayton Christensen dan dioperasikan oleh Bob Moesta, yang membingkai semula maklum balas pelanggan daripada keutamaan yang dinyatakan ("Saya mahu eksport pukal") kepada matlamat kemajuan yang mendasari ("apabila saya perlu membentangkan kepada pimpinan, saya perlu mengeluarkan data dalam format yang boleh dibaca oleh alat BI saya, tanpa menyalin 300 baris secara manual"). Diterapkan pada data CS, JTBD adalah disiplin pentafsiran semula. Ia menukar nota panggilan sedia ada, temu bual kadar peralihan pelanggan, dan verbatim QBR kepada pernyataan tugas yang boleh digunakan oleh pasukan produk untuk keputusan pelan hala tuju produk peringkat keupayaan dan bukannya penambahan backlog peringkat ciri.

Bagaimana pernyataan tugas JTBD berbeza daripada user story?

User story menerangkan keutamaan: "Sebagai pengguna, saya mahu eksport pukal." Pernyataan tugas JTBD menerangkan situasi, hasil yang diinginkan, dan kekangan: "Apabila saya perlu membentangkan data pelanggan kepada pimpinan setiap suku tahun, saya perlu mengeluarkan data itu dalam format yang boleh dibaca oleh alat BI kami, tanpa menyalin 300 baris secara manual ke dalam hamparan." Pernyataan tugas membuka ruang penyelesaian. Ia mungkin diselesaikan oleh eksport, integrasi BI asli, titik hujung API, atau paparan yang boleh dikongsi dengan pemformatan eksport. User story menyempitkan penyelesaian kepada ciri tertentu sebelum PM menilai keseluruhan pilihan.

Berapa banyak verbatim yang diperlukan oleh pernyataan tugas untuk dianggap disahkan?

Kerangka kerja Pengekstrakan JTBD 5 Langkah memerlukan sekurang-kurangnya tiga verbatim daripada tiga akaun berbeza sebelum menganggap calon tugas sebagai corak yang disahkan dan bukannya anekdot satu akaun. Idealnya, tiga akaun tersebut merentas peringkat ARR yang berbeza. Verbatim perusahaan dan verbatim SMB yang menerangkan situasi tugas yang sama membawa berat pengesahan yang lebih daripada tiga akaun SMB. Setelah disahkan, pernyataan tugas juga harus membawa berat ARR dan bilangan akaun sebelum memasuki perbualan produk.

Sumber data CS mana yang menghasilkan bahan mentah JTBD terbaik?

Temu bual keluar kadar peralihan pelanggan adalah sumber JTBD bersinyal tertinggi: pelanggan yang memecat produk menerangkan tugas yang gagal dilakukannya dengan kejelasan yang luar biasa. Verbatim QBR mendedahkan pernyataan hasil dalam klausa tengah format tugas ("kami mahu ini menjadi sumber kebenaran tunggal kami"). Nota panggilan menangkap konteks situasi dalam klausa pembuka ("apabila kami berada dalam mesyuarat perancangan Isnin kami"). Lonjakan tiket sokongan adalah bukti tugas negatif. Apabila 15 tiket mengenai aliran kerja yang sama, produk gagal melaksanakan satu tugas bagi pelanggan yang cukup ramai untuk mencetuskan kekecewaan aktif. Verbatim penentang NPS melengkapkan gambar: penyokong menerangkan tugas yang dilakukan produk dengan baik, penentang menerangkan tugas yang gagal.

Mengapa pengekstrakan JTBD gagal dalam praktik, dan bagaimana ia diperbaiki?

Tiga mod kegagalan yang paling biasa ialah CSM yang merumuskan dan bukannya memetik (melucutkan situasi dan kekangan dalam parafrasa), kecenderungan terhadap akaun kecil dalam kiraan tiket mentah (diperbaiki dengan pemberat ARR dalam Langkah 4), dan kecenderungan terhadap data terkini dalam penarikan data (diperbaiki dengan melanjutkan tetingkap pengekstrakan kepada 12-18 bulan, kerana kegagalan tugas yang tidak diselesaikan berterusan melebihi 90 hari). Penyelesaian asas adalah perubahan penandaan pada masa penangkapan: CSM menandakan nota panggilan dengan salah satu daripada empat jenis situasi (pelaporan eksekutif, proses penerimaan pasukan, aliran kerja merentas pasukan, mesyuarat pelanggan langsung) dan bukannya mengikut kawasan produk. Ini menjadikan pengekstrakan JTBD retrospektif jauh lebih pantas.

Bagaimana JTBD berbeza daripada analisis titik kesakitan?

Titik kesakitan menerangkan geseran: "laporan lambat." JTBD menerangkan niat: "apabila saya membentangkan secara langsung kepada pimpinan, saya perlu menarik data pelanggan dalam bawah lima saat, tanpa kehilangan kredibiliti kepada roda muat yang berpusing." Analisis titik kesakitan membawa kepada penyelesaian (perbaiki prestasi). JTBD membawa kepada ringkasan produk: apa yang mencetuskan keperluan, seperti apa "diselesaikan dengan baik" kelihatan, dan apa yang menjadikan pengalaman semasa tidak boleh dikerjakan. Pasukan produk yang menerima pernyataan tugas berbanding senarai titik kesakitan membuat keputusan pengutamaan yang lebih berkualiti tinggi kerana mereka memahami konteks kegagalan, bukan hanya gejala.

Berapa banyak pernyataan tugas yang disahkan yang perlu dihasilkan oleh pasukan CS setiap suku tahun?

Tiga hingga lima pernyataan tugas yang disahkan setiap suku tahun adalah jumlah yang tepat untuk kebanyakan pasukan CS pasaran pertengahan. Kurang daripada tiga mencadangkan proses pengekstrakan tidak menarik daripada sumber data yang mencukupi atau disiplin penandaan terlalu lemah untuk mendedahkan corak yang berbeza. Lebih daripada lima membebankan perbualan pelan hala tuju produk. Pasukan produk yang membuat keputusan peringkat keupayaan terhadap lapan atau sepuluh tugas serentak cenderung untuk menangguhkan semua daripadanya. Tiga hingga lima mewujudkan fungsi pemaksaan yang betul: cukup luas corak untuk mendedahkan jurang strategik sebenar, cukup sempit untuk menghasilkan keputusan sebenar dalam ulasan maklum balas pelanggan suku tahunan.

Ketahui Lebih Lanjut

Tara Minh

Senior Operations & Growth Strategist