Penyelarasan Customer Success & Product

Hampir setiap tim CS memiliki versi dari keduanya: serangkaian percakapan advisory board di mana pelanggan senior memberikan masukan tentang arah strategis, dan praktik yang lebih longgar untuk melibatkan pelanggan saat membangun sesuatu yang baru. Masalahnya adalah sangat sedikit tim yang menarik garis tegas di antara keduanya. Pelanggan yang duduk di advisory board kuartal lalu ditarik ke dalam tinjauan prototipe karena mereka engaged. PM yang menginginkan masukan desain menjadwalkan "sesi advisory" dengan lima akun dan membawa mereka melihat mock Figma. Kosakatanya kabur, ekspektasinya kabur, dan hasilnya ikut kabur.

Perbedaannya bersifat operasional, bukan filosofis. Customer council dan advisory board berkaitan dengan arah strategis. Mereka melibatkan kelompok pelanggan yang lebih luas, berjalan dengan kadensa kuartalan, dan menghasilkan masukan tentang ke mana produk harus pergi dalam 12-18 bulan ke depan. Co-design berkaitan dengan fitur spesifik. Ia melibatkan 3-6 akun, berjalan selama 4-8 minggu, dan menghasilkan masukan langsung tentang bagaimana fitur tersebut harus bekerja di tingkat build. Komitmen waktu, ekspektasi pelanggan, format sesi, dan ukuran keberhasilan semuanya berbeda.

Mencampuradukkan keduanya menciptakan dua mode kegagalan. Advisory board diposisikan sebagai pengaruh co-design yang sebenarnya tidak dimilikinya, menghasilkan utang ekspektasi ketika roadmap bergerak ke arah yang tidak disetujui peserta. Engagement co-design mengembang menjadi percakapan strategis, meluaskan cakupan ke wilayah yang tidak dapat dipenuhi oleh satu fitur pun. Kedua kegagalan ini menghabiskan modal hubungan, dan keduanya dapat dicegah dengan disiplin operasional.

Artikel ini membahas cara menjalankan co-design. Artikel 11 membahas advisory board. Garis di antara keduanya adalah apa yang artikel ini mulai dengan menggambarkannya dengan jelas.

Model Operasi Customer Co-Design yang didefinisikan di sini berbeda secara eksplisit dari customer advisory board (artikel 11 dalam koleksi ini), yang membahas arah strategis di seluruh kelompok yang lebih luas dengan kadensa kuartalan. Co-design bersifat operasional, bukan strategis: ia membentuk fitur spesifik dalam pipeline pembangunan bersama 3-6 akun selama 4-8 minggu. Model ini memiliki empat disiplin operasi: (1) disiplin cakupan: co-design mencakup satu fitur, bukan arah produk; (2) disiplin kohort: 3-6 akun yang mewakili versi paling akut dari masalah tersebut, bukan yang paling setia atau terbesar; (3) disiplin peran: Product memimpin keputusan pembangunan, CS memfasilitasi sesi, Engineering mengamati; (4) disiplin ekspektasi: pelanggan mendesain bersama "apa"-nya, engineer memiliki "bagaimana"-nya, Product memiliki keputusan final. Setiap kegagalan co-design dapat ditelusuri kembali ke pelanggaran salah satu dari keempat disiplin ini.

Advisory Board vs. Co-Design: Perbedaan yang Diperlukan

Riset McKinsey tentang membangun organisasi B2B yang berpusat pada pelanggan menunjukkan bahwa perusahaan yang mencampuradukkan masukan advisory strategis dengan co-design fitur spesifik berakhir dengan data pelanggan yang tidak menjawab pertanyaan strategis maupun pertanyaan pembangunan secara tepat. Perbedaannya bersifat operasional, bukan filosofis, dan kebingungannya cukup umum sehingga layak dinyatakan dengan tepat.

Customer advisory board mengumpulkan kelompok yang lebih luas, biasanya 8-15 perwakilan pelanggan senior, untuk memberikan masukan tentang arah strategis. Pertanyaannya adalah: ke mana seharusnya produk dibawa dalam setahun ke depan? Masalah apa yang Anda antisipasi yang belum kami selesaikan? Di mana pesaing kami memiliki keunggulan yang ingin Anda tutup? Advisory board bersifat forward-looking dan luas. Mereka tidak membentuk fitur individual. Mereka membentuk visi produk yang mendorong roadmap. Kadensanya kuartalan. Outputnya adalah konteks strategis untuk tim PM.

Co-design mengumpulkan kohort kecil (3-6 akun) untuk memberikan masukan operasional pada fitur spesifik yang sudah ada dalam pipeline pembangunan. Pertanyaannya adalah: apakah workflow ini sesuai dengan cara Anda sebenarnya melakukan tugas ini? Di mana dalam alur ini Anda mengalami masalah? Apa yang akan membuat ini cukup berguna untuk mengubah cara kerja tim Anda? Co-design bersifat present-tense dan sempit. Ia membentuk fitur spesifik yang sedang dibangun sekarang. Kadensanya intensif selama engagement singkat. Outputnya adalah feedback tingkat pembangunan yang dapat ditindaklanjuti.

Kapan Anda membutuhkan co-design vs. kapan masukan advisory sudah cukup. Jika pertanyaannya adalah "haruskah kita membangun kategori kemampuan ini?", masukan advisory sudah cukup. Jika pertanyaannya adalah "apakah implementasi spesifik dari kemampuan itu sesuatu yang benar-benar dapat digunakan oleh pengguna target kita?", Anda membutuhkan co-design. Masukan advisory memberi tahu Anda apakah Anda membangun ke arah yang benar. Co-design memberi tahu Anda apakah yang Anda bangun akan benar-benar berhasil.

Keputusan praktis: co-design diperlukan ketika ada cukup ambiguitas desain dalam fitur spesifik sehingga kesalahan dalam membuatnya berarti membangun ulang sebagian besar bagiannya setelah peluncuran, dan ketika Anda memiliki pelanggan yang memiliki use case spesifik dan keahlian domain untuk mengevaluasi solusi yang diusulkan.

Key Facts: Hasil Program Co-Design

Fitur yang dikembangkan dengan sesi co-design pelanggan terstruktur memiliki tingkat adopsi 41% lebih tinggi pada 90 hari setelah GA dibandingkan fitur yang dikembangkan hanya dengan masukan advisory (Pendo, 2024).

Sesi co-design yang difasilitasi PM menghasilkan 35% lebih sedikit feedback kritis dibandingkan sesi yang difasilitasi CS, karena peserta melunakkan kritik ketika orang yang membangun apa yang mereka evaluasi ada di dalam ruangan (UserTesting, 2024).

Engagement co-design yang berakhir tanpa sesi penutupan formal memiliki tingkat kekecewaan ekspektasi yang dilaporkan peserta 2,1 kali lebih tinggi pada peluncuran GA, dibandingkan engagement yang menyertakan panggilan debrief terstruktur (Gainsight, 2024).

Siapa yang Diundang ke Co-Design (dan Siapa yang Tidak)

Kriteria seleksi lebih spesifik daripada untuk program beta atau advisory board, dan biaya kesalahan dalam memilihnya lebih tinggi. Seleksi advisory board yang buruk menghasilkan masukan strategis yang samar. Seleksi co-design yang buruk menghasilkan keputusan tingkat pembangunan berdasarkan use case yang salah.

"Fitur yang dikembangkan dengan sesi co-design pelanggan terstruktur memiliki tingkat adopsi 41% lebih tinggi pada 90 hari setelah GA dibandingkan fitur yang dikembangkan hanya dengan masukan advisory." (Pendo, 2024)

Filter akuitas masalah. Kriteria pertama: apakah akun ini memiliki masalah spesifik yang dibangun fitur ini untuk diselesaikan, dan apakah mereka mengalaminya secara cukup akut untuk memberikan feedback yang bermakna pada solusi yang diusulkan? Bukan "apakah mereka mengalami kategori umum dari masalah" tetapi "apakah masalah ini merupakan kendala operasional nyata bagi mereka sekarang?" Akun yang memiliki masalah secara teoritis ("kami mungkin mengalami masalah ini jika tim kami berkembang") tidak dapat mengevaluasi solusi dengan spesifisitas yang sama seperti akun yang mengalaminya secara operasional, setiap hari.

Gerbang kesehatan CS. Hanya health score hijau atau kuning. Co-design dengan akun merah adalah ekstraksi, bukan kolaborasi. Pelanggan yang mengelola krisis dukungan aktif, konflik anggaran, atau implementasi yang terhenti tidak memiliki kapasitas mental untuk memberikan feedback produk yang jujur. Mereka sedang mengelola situasi mereka sendiri. Dan jika pengalaman co-design membuat frustrasi (yang sering terjadi pada pekerjaan fitur tahap awal), hal itu memperburuk hubungan yang sudah tertekan. Glosarium CS & Product alignment mendefinisikan tingkatan health score dan kosakata bersama yang dibutuhkan CS dan Product untuk menerapkan gerbang ini secara konsisten.

Filter kemampuan. Apakah pelanggan ini memiliki keahlian domain untuk mengevaluasi apakah solusi yang diusulkan benar-benar menyelesaikan masalah? Pelanggan yang memiliki masalah tetapi tidak memiliki kecanggihan teknis atau operasional untuk membedakan "workflow ini tidak sesuai dengan proses kami" dari "workflow ini membingungkan" adalah kontributor co-design yang terbatas. Anda membutuhkan akun di mana praktisi yang hadir dalam sesi dapat menjelaskan dengan tepat bagaimana mereka saat ini melakukan hal yang akan digantikan fitur tersebut, karena pemahaman itulah yang membuat feedback mereka tentang solusi yang diusulkan tepat daripada berkesan saja.

Batas atas kohort. 3-6 akun. Ini bukan panduan yang lunak. Ini adalah realitas operasional dari apa yang dapat dikelola PM dan apa yang dapat dikelola CSM secara bermakna di seluruh engagement 4-8 minggu. Enam sudah ambisius. Delapan menjadi komite. Pada 10, Anda menjalankan beta, bukan engagement co-design, dan Anda telah kehilangan keintiman yang membuat feedback co-design berbeda dari data survei.

Framing undangan sama pentingnya dengan seleksi. "Bantu kami membangun ini dengan benar" adalah framing yang tepat. "Beri kami daftar keinginan Anda" adalah yang salah. Undangan harus spesifik tentang cakupan fitur, eksplisit tentang komitmen waktu (biasanya 3-5 sesi selama 4-8 minggu, masing-masing 60-90 menit), jelas bahwa ini adalah tentang masukan desain daripada pengaruh roadmap, dan jujur bahwa keputusan pembangunan final adalah milik Product, bukan kohort co-design. Dengan kohort yang tepat, struktur engagement menentukan apakah sesi-sesi tersebut menghasilkan sinyal nyata.

Menyusun Engagement Co-Design

Engagement co-design yang berjalan lebih dari 8 minggu biasanya menandakan perluasan cakupan. Engagement co-design dengan lebih dari 5 sesi biasanya menandakan bahwa masalahnya tidak cukup terdefinisi dengan baik sejak awal. Struktur di bawah ini berlaku untuk engagement yang memiliki cakupan yang baik.

Pra-kerja: Product berbagi pernyataan masalah dan batasan. Sebelum sesi pertama, peserta menerima brief tertulis dari PM: masalah yang diselesaikan, mengapa pendekatan yang diusulkan dipilih, dan batasan apa yang tidak dapat dinegosiasikan (keterbatasan teknis, persyaratan regulasi, keputusan arsitektur yang ada). Pelanggan tidak mendesain bersama dalam kekosongan. Mereka membutuhkan konteks tentang apa yang mungkin sebelum dapat memberikan masukan yang bermakna tentang apa yang terbaik.

Sesi 1: Validasi masalah. Tujuan sesi ini bukan untuk menunjukkan solusi kepada pelanggan. Tujuannya adalah untuk memvalidasi bahwa pemahaman Product tentang masalah sesuai dengan pengalaman nyata pelanggan. PM mempresentasikan pernyataan masalah. Pelanggan merespons: "apakah ini secara akurat menggambarkan apa yang Anda hadapi?" Perbedaan di sini (dan hampir selalu ada beberapa) adalah output paling berharga dari seluruh engagement. Perbedaan ini muncul sebelum pekerjaan pembangunan apa pun terkunci.

Sesi 2: Feedback prototipe. PM mempresentasikan prototipe awal atau mockup workflow. Tugas pelanggan: melaluinya sebagaimana mereka sebenarnya akan menggunakannya, sambil menceritakan reaksi mereka. Bukan "apakah Anda menyukai ini?" tetapi "tunjukkan apa yang akan Anda lakukan selanjutnya." CSM menangkap titik gesekan, momen kebingungan, dan solusi sementara yang disarankan pelanggan secara spontan. Engineering mengamati dan mencatat tetapi tidak mempresentasikan, membela, atau menjelaskan apa pun. Mereka ada untuk mendengar secara langsung, bukan untuk membenarkan keputusan.

Sesi 3: Iterasi solusi. PM mempresentasikan prototipe yang direvisi yang menggabungkan feedback dari sesi 2. Tujuannya: mengonfirmasi bahwa perubahan tersebut mengatasi gesekan, mengungkap masalah baru yang diperkenalkan oleh perubahan tersebut, dan mulai menyempitkan menuju desain yang berhasil. Sesi ini biasanya lebih singkat dari sesi 2. Jika iterasinya baik, ada lebih sedikit yang perlu ditantang.

Sesi 4-5 (jika diperlukan): Persetujuan final dan kasus tepi. Sesi-sesi ini untuk peserta yang memiliki use case cukup kompleks sehingga sesi 1-3 tidak sepenuhnya menyelesaikan cara fitur bekerja untuk mereka. Tidak setiap kohort membutuhkan sesi 4-5. Jika engagement tiga sesi menghasilkan sinyal yang cukup jelas untuk menyelesaikan desain, menambahkan sesi demi struktur membuang-buang waktu peserta dan berisiko mengikis niat baik yang menjadi fondasi program.

Aturan kehadiran. Karya MIT Media Lab tentang co-design teknologi berbasis komunitas mengonfirmasi bahwa nilai co-design berasal secara khusus dari "co" (struktur partisipasi itu sendiri, bukan hanya outputnya), itulah mengapa model kehadiran vendor di sini memisahkan peran daripada menyatukannya menjadi satu kehadiran tim produk. Dari vendor: PM memimpin, CSM memfasilitasi, Engineering mengamati. PM ada untuk mendengar use case dan membuat keputusan pembangunan real-time tentang feedback mana yang akan digabungkan. CSM ada untuk mengelola dinamika sesi: mendorong peserta yang pendiam, mengarahkan ulang peserta yang mendesain ulang seluruh produk alih-alih fitur spesifik, dan menangkap sinyal relasional yang mungkin terlewat PM. Engineering ada untuk mendengar use case dalam bahasa pelanggan, bukan untuk mempresentasikan batasan teknis atau membela pilihan implementasi.

Dari pelanggan: praktisi yang menjalani masalah setiap hari, bukan sponsor eksekutif. Eksekutif yang mendengar tentang masalah dari tim mereka adalah pendukung strategis yang berguna. Mereka adalah peserta co-design yang buruk karena tidak memiliki spesifisitas operasional untuk mengevaluasi apakah solusi yang diusulkan berhasil di tingkat workflow. Peserta yang tepat dapat mengatakan "ketika saya melakukan tugas ini, saya melakukannya dengan cara ini, dan alur yang diusulkan terputus di langkah tiga karena X."

Peran CS dalam Sesi Co-Design

"Sesi co-design yang difasilitasi PM menghasilkan 35% lebih sedikit feedback kritis dibandingkan sesi yang difasilitasi CS, karena peserta melunakkan kritik ketika orang yang membangun apa yang mereka evaluasi ada di dalam ruangan." (UserTesting, 2024)

CS memfasilitasi; CS tidak mengadvokasi. Ini adalah garis yang paling sulit untuk dipertahankan. Tugas CSM dalam sesi co-design bukan untuk membuat pelanggan merasa nyaman dengan produk atau untuk melindungi hubungan dari feedback kritis. Tujuannya adalah untuk mengungkap sinyal jujur: mengajukan pertanyaan lanjutan ketika feedback pelanggan samar, mendorong ketidakpuasan yang diekspresikan pelanggan dengan sopan daripada langsung, dan tidak melunakkan transkrip.

Mengelola peserta yang dominan. Hampir setiap kohort co-design memiliki satu: pelanggan yang engaged, artikulatif, dan vokal, yang pendapatnya menenggelamkan peserta lain. Tugas fasilitasi CSM adalah secara aktif mendistribusikan ulang waktu bicara: "Kami sudah banyak mendengar dari [akun A] tentang hal ini. [Akun B], bagaimana ini terasa untuk workflow tim Anda?" Suara terkeras dalam sesi co-design jarang yang paling mewakili.

Menangkap feedback dalam format output terstruktur. Hasil dari setiap sesi bukan transkrip dan bukan ringkasan. Ini adalah catatan feedback terstruktur yang dapat langsung dirujuk Product saat membuat keputusan pembangunan. Format: titik gesekan (spesifik, berkonteks workflow) / akun mana yang mengangkatnya / tingkat keparahan (pemblokir / signifikan / minor) / perbaikan yang disarankan pelanggan (jika ditawarkan) / pembacaan awal PM (gabungkan / tolak / selidiki lebih lanjut). Format ini disepakati sebelum engagement dimulai. CSM tidak mengimprovisasinya sesi demi sesi. Panduan menangkap feedback secara sistematis menyediakan taksonomi lengkap untuk menerjemahkan catatan sesi menjadi catatan siap backlog.

Menandai perluasan cakupan secara real-time. Ketika peserta mulai mendesain seluruh produk alih-alih fitur spesifik ("selagi kita membahas ini, bagaimana jika Anda juga membangun ulang cara seluruh dashboard bekerja?"), CSM mengarahkan ulang: "Itu masukan yang lebih luas yang sangat bagus, dan kami akan menangkapnya secara terpisah. Untuk sesi hari ini, kami ingin tetap fokus pada [cakupan fitur spesifik] agar kita bisa cukup mendalam untuk berguna." Pengarahan ulang itu adalah tanggung jawab CSM, bukan tanggung jawab PM. Kehadiran PM di ruangan mempersulit mereka untuk mengarahkan ulang tanpa terlihat defensif.

Hal Tidak Dapat Dikompromikan Product dalam Co-Design

Keputusan pembangunan adalah milik Product. Selalu. Co-design adalah masukan tentang cara fitur dibangun, bukan delegasi keputusan pembangunan kepada komite pelanggan. Hal ini perlu dinyatakan pada framing pendaftaran dan diperkuat di setiap pembukaan sesi. "Kami ingin perspektif Anda tentang apakah pendekatan ini berhasil untuk workflow Anda. Keputusan final tentang apa yang kami bangun adalah milik kami, dan kami akan jujur kepada Anda tentang masukan mana yang kami gabungkan dan mengapa."

Batasan teknis tidak dapat dinegosiasikan dan harus dinyatakan di awal. Sesi co-design di mana peserta mendesain solusi ideal mereka dan kemudian PM harus menjelaskan mengapa tidak ada yang dapat dilakukan secara teknis membuang-buang waktu semua orang dan menciptakan utang ekspektasi. Sebelum sesi 1, brief tertulis harus menyatakan dengan jelas: "Inilah yang secara teknis tetap dalam desain ini. Inilah di mana Anda memiliki pengaruh nyata." Pelanggan yang memahami ruang batasan mendesain di dalamnya. Pelanggan yang tidak memahaminya mendesain di luar batasnya, menghasilkan feedback yang tidak dapat ditindaklanjuti.

Pelanggan mendesain bersama "apa"-nya; engineer dan PM memiliki "bagaimana"-nya. Peserta dapat mengatakan "Saya perlu dapat menetapkan ulang kepemilikan tugas secara massal tanpa kehilangan jejak audit." Itu adalah "apa". Cara mengimplementasikannya secara teknis (model data mana, pola API mana, komponen UI mana) adalah keputusan engineering. Garis antara apa dan bagaimana adalah tempat disiplin cakupan berada.

Ketika peserta co-design tidak setuju satu sama lain. Itu terjadi dalam hampir setiap engagement multi-akun, karena akun memiliki workflow berbeda, batasan berbeda, dan definisi "sudah jelas" yang berbeda. Product yang memediasi. Bukan dengan merata-ratakan ketidaksepakatan ("kami akan membuat versi yang sebagian memuaskan keduanya") tetapi dengan membuat keputusan eksplisit: "Kami telah mendengar dua model workflow berbeda di sini. Kami akan membangun untuk model [Akun A] karena lebih dekat dengan ICP utama kami. Untuk [Akun B], begini cara kami menyarankan Anda mengadaptasi workflow Anda ke fitur tersebut." Mediasi yang transparan lebih baik daripada berpura-pura ketidaksepakatan tidak ada.

Manajemen Ekspektasi Sepanjang Proses

Risiko ekspektasi dalam co-design berbeda dari risiko dalam advisory board. Peserta advisory board mengharapkan pengaruh strategis. Peserta co-design mengharapkan workflow spesifik mereka tercermin dalam apa yang dirilis. Ketika fitur final tidak terlihat persis seperti yang mereka desain, peserta merasa bahwa co-design adalah pertunjukan belaka daripada kolaborasi yang tulus.

Pada sesi 1, nyatakan modelnya secara eksplisit. "Anda ada di sini karena Anda memiliki versi paling akut dari masalah yang kami selesaikan dan keahlian domain untuk memberi tahu kami apakah solusi yang kami usulkan benar-benar berhasil. Masukan Anda akan langsung menginformasikan apa yang kami bangun. Tetapi Anda bukan satu-satunya masukan. Kami juga bekerja dalam batasan teknis, menyeimbangkan berbagai use case, dan membuat keputusan produk yang mungkin tidak sepenuhnya mencerminkan preferensi satu akun pun. Kami akan transparan kepada Anda tentang apa yang kami gabungkan dan apa yang tidak, serta mengapa."

Cara menangani peserta yang idenya tidak digabungkan. CSM membuat keputusan secara proaktif, sebelum fitur dirilis. "Kami membahas [masukan spesifik] di sesi 3. Kami akhirnya memutuskan untuk tidak mengimplementasikannya dalam rilis ini karena [alasan spesifik]. Saya ingin Anda mengetahui ini secara langsung, sebelum Anda melihat fitur di GA." Percakapan itu, yang dilakukan sebelum peserta menemukan celah sendiri, adalah tindakan yang menjaga hubungan. Jika dilakukan setelah, terasa seperti pengendalian kerusakan.

Panggilan debrief bukan pilihan. Riset HBR tentang mendapatkan feedback pelanggan yang jujur menetapkan bahwa penutupan engagement feedback adalah saat kepercayaan dikonfirmasi atau rusak. Pelanggan perlu melihat bahwa masukan mereka ditanggapi serius, tidak hanya diproses. Setiap engagement co-design diakhiri dengan panggilan debrief 30 menit di mana PM menjelaskan kepada peserta co-design: apa yang masuk ke dalam build, apa yang tidak, dan mengapa. Ini adalah penutupan formal engagement. Peserta yang tidak menerima debrief (yang mengalami engagement sebagai "kami memberikan waktu kami dan kemudian fitur hanya dirilis") adalah sumber masalah reputasi co-design yang mempersulit rekrutmen di masa mendatang.

Ketika Co-Design Berjalan Salah

Tiga mode kegagalan mencakup sebagian besar yang salah, dan masing-masing memiliki perbaikan spesifik.

Perluasan cakupan: pelanggan mendesain seluruh produk. Sesi telah bergeser dari fitur spesifik menjadi percakapan tentang seluruh pengalaman produk. Penyebab: framing undangan terlalu luas ("bantu kami meningkatkan produk"), CSM tidak mengarahkan ulang cukup awal, atau PM mulai mengajukan pertanyaan yang membuka cakupan lebih luas ("dan apa lagi yang akan membuat kategori pekerjaan ini lebih baik untuk Anda?"). Perbaikan: nyatakan ulang cakupan di awal setiap sesi, latih CSM untuk mengarahkan ulang secara terlihat dan tanpa permintaan maaf, dan pertahankan pertanyaan PM terikat ketat pada fitur yang sedang didesain bersama.

Penangkapan hubungan: PM mengatakan ya untuk segalanya. PM begitu fokus untuk menjaga hubungan peserta yang positif sehingga mereka memberi sinyal persetujuan atas masukan yang tidak berniat mereka implementasikan, untuk menghindari konflik di ruangan. Ini menghasilkan dua masalah: peserta yang merasa divalidasi selama sesi dan merasa dikhianati pada GA, serta catatan feedback yang terlalu merepresentasikan komitmen yang tidak ada. Perbaikan: CSM (bukan PM) yang mengelola nada sesi. Tugas PM adalah mendengar dan mencatat, bukan merespons secara afirmatif pada setiap saran. Format output terstruktur (gabungkan / tolak / selidiki) memaksa pengakuan eksplisit tentang masukan mana yang ditindaklanjuti dan mana yang tidak.

Bias kohort: peserta tidak mewakili ICP yang lebih luas. Kohort co-design dipilih karena mereka tersedia dan engaged, bukan karena mereka mewakili target use case. Feedback mencerminkan workflow spesifik mereka, yang merupakan kasus tepi, bukan use case inti. Fitur yang dibangun berdasarkan spesifikasi tersebut bekerja dengan baik untuk peserta co-design dan buruk untuk basis pelanggan umum. Perbaikan: terapkan filter akuitas masalah secara ketat saat seleksi. Jika akun yang paling akut mengalami masalah tidak cukup sehat atau tersedia untuk berpartisipasi, tunda co-design sampai kandidat yang lebih baik dapat diidentifikasi. Jangan substitusikan dengan peserta yang lebih memenuhi kriteria hubungan daripada kriteria use case.

Setelah Co-Design: Menutup Engagement

Pengakuan peserta tanpa menjanjikan akses masa depan yang berlebihan. Peserta co-design menginvestasikan waktu dan kepercayaan. Penutupan engagement harus mengakui hal itu secara spesifik: "Anda memberikan kami [N sesi / N jam] waktu Anda selama [N minggu]. [Fitur spesifik yang dirilis] mencerminkan apa yang Anda sampaikan langsung kepada kami. Terima kasih." Itu adalah tingkat pengakuan yang tepat. Terlalu banyak berjanji ("kami akan memastikan Anda menjadi akun pertama yang kami datangi untuk fitur berikutnya di area ini") menciptakan utang pendaftaran dalam program co-design berikutnya bahkan sebelum dimulai.

Peserta co-design melihat fitur final sebelum GA. Ini tidak dapat dinegosiasikan. Peserta yang berpartisipasi dalam 4 sesi dan kemudian melihat pengumuman GA pada saat yang sama dengan setiap pelanggan lain merasa bahwa masukan mereka diserap, bukan dihormati. Urutannya: PM berbagi fitur final dengan peserta co-design 1-2 minggu sebelum GA. Peserta memiliki kesempatan untuk menandai hal kritis yang terlewat. Kemudian dirilis kepada semua orang. Struktur panggilan debrief, ringkasan tertulis, dan turnaround 48 jam semuanya dijelaskan dalam artikel menutup lingkaran umpan balik. Kadensa tersebut berlaku di sini persis seperti untuk program beta dan advisory.

Retrospektif sebelum co-design berikutnya. Debrief engagement bukan hanya untuk peserta. Ini untuk tim internal. Format sesi apa yang menghasilkan sesuatu yang berguna? Format feedback mana yang berhasil? Apakah akun yang tepat dipilih? Apa yang akan kami ubah tentang framing undangan? Retrospektif internal 60 menit setelah setiap engagement co-design meningkatkan kualitas yang berikutnya dan mengurangi tingkat kegagalan dari waktu ke waktu.

Pertimbangan Mid-Market

Co-design membutuhkan banyak sumber daya. Perusahaan mid-market tanpa fungsi riset UX yang didedikasikan masih dapat menjalankannya, tetapi perlu menyesuaikan ekspektasi. Versi minimum yang dapat dijalankan: satu PM, satu CSM, tiga akun, tiga sesi, tidak diperlukan prototipe Figma. Mockup workflow awal yang dijelaskan dalam bahasa sederhana sudah cukup. PM membaca output terstruktur, CSM memfasilitasi, dan outputnya cukup spesifik untuk menginformasikan pembangunan.

"Engagement co-design yang berakhir tanpa sesi penutupan formal memiliki tingkat kekecewaan ekspektasi yang dilaporkan peserta 2,1 kali lebih tinggi pada peluncuran GA, dibandingkan engagement yang menyertakan panggilan debrief terstruktur." (Gainsight, 2024)

Yang tidak bisa diskalakan ke bawah: panggilan debrief, kriteria seleksi akuitas masalah, dan penetapan ekspektasi eksplisit pada sesi 1. Itu adalah elemen penting. Segala sesuatu yang lain dapat disederhanakan. Melacak peserta co-design mana yang siap aktivasi setelah GA adalah tempat identifikasi hambatan adopsi mengambil alih. Tim co-design sudah mengetahui titik gesekannya; tim pasca-penjualan membutuhkan pengetahuan itu untuk mempercepat aktivasi bagi basis yang lebih luas.

Analisis Rework: Program co-design ringan secara operasional (3-6 akun, 3-5 sesi, 4-8 minggu) tetapi memerlukan pelacakan ketat atas hasil sesi, health score peserta, dan disposisi feedback di beberapa percakapan yang berlangsung bersamaan. Tim CS mid-market yang menjalankan co-design di Rework dapat menggunakan pelacakan tugas tingkat proyek untuk mengelola struktur sesi, menautkan catatan feedback ke kesehatan akun, dan menampilkan filter akuitas masalah bersama data ICP tanpa membangun sistem manajemen riset terpisah. Format feedback terstruktur (titik gesekan / tingkat keparahan / disposisi PM) langsung dipetakan ke model tugas dan komentar Rework.

Pertanyaan yang Sering Diajukan

Apa itu Model Operasi Customer Co-Design?

Model Operasi Customer Co-Design adalah struktur operasional untuk menjalankan co-design fitur bersama 3-6 pelanggan terpilih selama 4-8 minggu. Ini berbeda secara eksplisit dari customer advisory board, yang memberikan arahan strategis kepada kelompok yang lebih luas setiap kuartal. Co-design membentuk fitur spesifik dalam pipeline pembangunan. Model ini berjalan berdasarkan empat disiplin: cakupan (satu fitur, bukan arah produk), kohort (seleksi akuitas masalah, bukan seleksi loyalitas), peran (CS memfasilitasi, Product memimpin keputusan pembangunan, Engineering mengamati), dan ekspektasi (pelanggan mendesain bersama "apa"-nya, engineer memiliki "bagaimana"-nya).

Bagaimana co-design berbeda dari customer advisory board?

Advisory board mengumpulkan 8-15 pelanggan senior secara kuartalan untuk memberikan masukan tentang arah strategis: ke mana produk harus pergi dalam 12-18 bulan ke depan. Co-design mengumpulkan 3-6 akun selama 4-8 minggu untuk memberikan feedback tingkat build pada fitur spesifik yang sudah ada dalam pipeline. Masukan advisory menjawab "haruskah kita membangun kategori kemampuan ini?" Co-design menjawab "apakah implementasi spesifik ini akan benar-benar berhasil untuk pengguna target kami?" Mencampuradukkan keduanya menghasilkan kelelahan advisory dan perluasan cakupan co-design.

Siapa yang harus diundang ke sesi co-design?

Kriteria seleksi memiliki tiga gerbang: (1) akuitas masalah: akun memiliki masalah spesifik yang diselesaikan fitur ini, secara operasional dan akut, bukan teoritis; (2) health score: hanya hijau atau kuning; akun merah sedang mengelola situasi mereka sendiri dan tidak dapat mengevaluasi fitur baru secara objektif; (3) kemampuan: praktisi yang hadir dapat mendeskripsikan dengan tepat bagaimana mereka saat ini melakukan tugas yang akan digantikan fitur tersebut, karena spesifisitas operasional itulah yang membuat feedback mereka tepat daripada berkesan. Batas atas kohort adalah 6 akun. Di atas itu, Anda menjalankan beta, bukan engagement co-design.

Mengapa CS yang harus memfasilitasi sesi co-design, bukan Product?

Sesi co-design yang difasilitasi PM menghasilkan 35% lebih sedikit feedback kritis dibandingkan sesi yang difasilitasi CS, karena peserta melunakkan kritik ketika orang yang membangun apa yang mereka evaluasi ada di dalam ruangan (UserTesting, 2024). Fasilitator CS menciptakan pemisahan antara lapisan hubungan dan lapisan evaluasi. Tugas CSM adalah mendorong ketidakpuasan yang diekspresikan peserta dengan sopan, mengarahkan ulang perluasan cakupan secara real-time, dan menangkap catatan feedback terstruktur, tanpa melunakkan transkrip. PM mengamati dan membuat keputusan pembangunan real-time; Engineering mengamati dan mendengar use case dalam bahasa pelanggan.

Apa yang terjadi ketika peserta co-design tidak setuju satu sama lain?

Product yang memediasi. Bukan dengan merata-ratakan ketidaksepakatan atau berpura-pura tidak ada, tetapi dengan membuat keputusan eksplisit: "Kami telah mendengar dua model workflow berbeda. Kami akan membangun untuk model Akun A karena lebih dekat dengan ICP utama kami. Untuk Akun B, begini cara kami menyarankan Anda mengadaptasi workflow Anda ke fitur tersebut." Mediasi yang transparan lebih baik untuk hubungan daripada kompromi yang samar. Peserta yang memahami mengapa model mereka tidak dipilih menghormati keputusan itu. Peserta yang menerima solusi setengah-setengah dan kemudian menemukan bahwa itu tidak cocok untuk salah satu workflow pun merasa tertipu.

Apa yang harus dicakup panggilan debrief co-design?

Panggilan debrief adalah sesi 30 menit dengan PM dan CSM hadir, diadakan bersama peserta co-design sebelum GA. Ini mencakup: apa yang masuk ke dalam build, apa yang tidak, dan mengapa. Engagement co-design yang berakhir tanpa sesi penutupan formal memiliki tingkat kekecewaan ekspektasi yang dilaporkan peserta 2,1 kali lebih tinggi pada peluncuran GA (Gainsight, 2024). Ringkasan tertulis menyusul dalam 48 jam. Peserta yang berkontribusi 4 sesi dan menerima debrief merasa benar-benar dikonsultasikan. Peserta yang melihat pengumuman GA pada waktu yang sama dengan setiap pelanggan lain merasa diekstrak.

Berapa lama engagement co-design harus berjalan?

Engagement co-design yang memiliki cakupan baik berjalan 3-5 sesi selama 4-8 minggu. Engagement yang berlanjut lebih dari 8 minggu biasanya menandakan bahwa masalahnya tidak cukup terdefinisi dengan baik sejak awal, atau cakupannya meluas ke wilayah yang tidak dapat dipenuhi oleh satu fitur pun. Program dengan lebih dari 5 sesi menunjukkan penurunan kualitas sesi akibat kelelahan peserta dalam 73% kasus mid-market (ProductLed, 2024). Panggilan debrief bukan pilihan. Segala sesuatu yang lain dapat disederhanakan untuk tim yang lebih kecil. Tetapi debrief dan kriteria seleksi akuitas masalah adalah elemen penting dari model.

Pelajari Lebih Lanjut

Tara Minh

Senior Operations & Growth Strategist