Wawancara Product Manager: Haruskah Anda Membangun Fitur Kustom untuk Pelanggan Utama yang Mengancam akan Churn?

Perintah dan Skenario yang Berlaku

Pelanggan utama dari produk B2B SaaS mewakili 12% dari ARR dan akan memperbarui kontrak dalam 10 minggu. Pelanggan tersebut menuntut ekspor audit persetujuan proprietary dalam waktu 6 minggu dan menyatakan akan churn jika tidak dipenuhi. Membangun spesifikasi lengkap pelanggan secara langsung awalnya diperkirakan membutuhkan 3 engineer selama 8 minggu, atau 24 engineer-weeks, diikuti oleh sekitar 6 engineer-weeks untuk pemeliharaan setiap tahunnya. Tim hanya memiliki 30 engineer-weeks yang tersedia untuk pekerjaan produk baru pada kuartal berikutnya.

Setelah mewawancarai 40 pelanggan enterprise, tim menemukan bahwa 6 pelanggan memiliki masalah mendasar yang sama: mereka harus memberikan catatan persetujuan kepada tim audit atau kepatuhan (compliance). Hanya pelanggan yang mengancam akan churn yang membutuhkan format file proprietary ini. Porsi pelanggan, linimasa, dan estimasi engineering adalah asumsi kasus wawancara fiktif, bukan tolok ukur industri.

Anda harus merekomendasikan satu jalur di antara kustomisasi langsung, kapabilitas produk yang dapat digunakan kembali (reusable), pengiriman berbayar untuk bagian khusus akun tersebut, atau menolak pekerjaan tersebut. Bank soal product manager publik tahun 2026 secara langsung menanyakan bagaimana cara merespons ketika pelanggan utama mengancam akan churn tanpa fitur kustom. Materi wawancara publik dari Tiongkok juga meminta kandidat untuk menyeimbangkan permintaan kustomisasi akun besar terhadap arah produk, beban pemeliharaan, dan opportunity cost. Pertanyaan pertimbangan produk ini cocok untuk product manager B2B SaaS, product lead, serta pemimpin bisnis atau teknis yang terlibat dalam komitmen pelanggan utama.

Apa yang Dinilai oleh Pewawancara

Pertama, apakah kandidat memperlakukan "pelanggan akan churn" sebagai hipotesis kausal yang perlu diuji? Pelanggan mungkin terhambat oleh persyaratan audit yang nyata, atau mereka mungkin sedang mencari diskon, komitmen pengiriman, atau daya tawar dalam negosiasi. Jawaban yang kuat menjangkau pengambil keputusan pembaruan kontrak serta pemilik bagian pengadaan (procurement), audit, atau kepatuhan. Ini menguji apa yang terjadi tanpa kapabilitas tersebut, apakah alternatif lain dapat mempertahankan pembaruan kontrak, dan apakah pelanggan akan membuat komitmen pembaruan tertulis jika hasil yang disepakati berhasil dikirimkan.

Kedua, dapatkah kandidat beralih dari solusi yang ditentukan pelanggan kembali ke tugas yang harus diselesaikan (job to be done)? Proses produk publik GitLab menyerukan percakapan lebih lanjut mengenai masalah pelanggan dan hasil yang diinginkan. Panduan manajemen produk Atlassian juga menghubungkan kebutuhan pelanggan dengan strategi, nilai, upaya, dan kesesuaian saat memutuskan apa yang akan dibangun. Di sini, pekerjaan mendasarnya adalah menyediakan bukti persetujuan yang dapat diaudit. Format proprietary hanyalah salah satu mekanisme pengiriman yang memungkinkan.

Ketiga, apakah nilai dan biaya dinyatakan atas dasar yang dapat dibandingkan? Dua belas persen dari ARR mengukur konsentrasi pendapatan. Hal itu tidak membuktikan bahwa menolak permintaan tersebut akan menghilangkan seluruh 12%, dan pendapatan tersebut bukanlah keuntungan murni. Kandidat harus membandingkan hilangnya laba kotor pelanggan yang dapat dihindari, nilai produk yang dapat digunakan kembali, biaya pembuatan dan dukungan di seluruh siklus hidup, serta opportunity cost dari hasil roadmap yang tergeser. Setiap masukan yang tidak pasti memerlukan rentang nilai dan tingkat keyakinan (confidence level).

Keempat, dapatkah kandidat menarik batasan yang dapat dipelihara antara produk dan pengiriman proyek? Otorisasi bersama, model ekspor, dan perilaku audit mungkin merupakan bagian dari produk. Pemetaan kolom (field mapping), templat file, dan konektor alur kerja yang digunakan oleh satu akun mungkin termasuk dalam layanan profesional berbayar, implementasi mitra, atau transformasi di sisi pelanggan. Batasan tersebut juga harus tertuang dalam kontrak: cakupan, harga, penerimaan (acceptance), kekayaan intelektual, tingkat dukungan, proses perubahan, dan ketentuan keluar tidak boleh hanya menjadi janji lisan.

Terakhir, pewawancara mengharapkan sebuah keputusan. Menjawab "tergantung" atau "saya akan menilainya dengan RICE" berarti menghindari kasus tersebut. Jawaban yang kuat menyebutkan jalur yang dipilih, apa yang ditolaknya, kapan investasi dihentikan, dan bukti baru apa yang akan mengubah pilihan tersebut.

Pertanyaan Klarifikasi Sebelum Menjawab

• Apakah ancaman churn kredibel secara kausal? Siapa yang memegang keputusan pembaruan kontrak? Apakah celah audit merupakan syarat pembaruan tertulis? Akankah alternatif yang dapat diterima mempertahankan akun tersebut? Kalimat yang disampaikan oleh tim Sales bukanlah kerugian yang pasti.
• Hasil apa yang akan memuaskan pelanggan? Apakah mereka membutuhkan data mentah, tanda tangan yang dapat diverifikasi, kolom tertentu, format file tetap, atau koneksi otomatis ke sistem internal? Jawabannya dapat mengarah pada fitur produk, konfigurasi, antarmuka, hasil kerja layanan, atau konversi di sisi pelanggan.
• Komitmen apa yang menyertai pengiriman? Akankah pelanggan menandatangani pembaruan bersyarat, memperpanjang masa kontrak, membayar biaya implementasi dan pemeliharaan, serta menerima kriteria eksplisit? Tanpa komitmen komersial, vendor menanggung semua risiko investasi sementara pelanggan masih dapat churn karena alasan lain.
• Bagaimana kualitas dari 12% ARR tersebut? Periksa margin kotor, riwayat pembayaran, biaya dukungan, potensi ekspansi, dan jangka waktu kontrak. Pendapatan tinggi dengan biaya layanan yang tidak terkendali, risiko penagihan, atau kesesuaian target pasar yang buruk dapat mengubah keputusan.
• Seberapa luas kebutuhan ini dimiliki bersama? Apakah ke-6 pelanggan memiliki pekerjaan dan model izin yang sama, atau apakah permintaan mereka hanya kebetulan mengandung kata "ekspor"? Label yang luas bukanlah bukti yang cukup untuk membangun sebuah platform.
• Apa saja yang tercakup dalam 24 engineer-weeks? Estimasi harus mencakup penemuan (discovery), desain, tinjauan keamanan dan kepatuhan, pengembangan, migrasi, pengujian, peluncuran, operasi, penerimaan pelanggan, dan pemeliharaan di masa mendatang. Upaya penulisan kode versi pertama secara sistematis meremehkan biaya pengiriman kustom.
• Berapa opportunity cost-nya? Hasil apa saja yang sebelumnya telah dialokasikan pada 30 engineer-weeks tersebut? Berapa banyak pelanggan, komitmen pendapatan, tenggat waktu regulasi, atau target keandalan yang bergeser? Opportunity cost harus menyebutkan hasil yang dikorbankan, bukan sekadar mengatakan "roadmap terpengaruh."
• Siapa yang dapat membuat setiap komitmen? Produk memegang batasan produk, Engineering memegang kelayakan dan estimasi, Sales atau eksekutif memegang ketentuan komersial, serta Keamanan, Hukum, dan Kepatuhan tetap memegang persetujuan mereka. Seorang product manager tidak dapat menjanjikan semua hal ini sendirian.

Kerangka Jawaban 30 Detik

"Saya tidak akan menyetujui permintaan tersebut hanya karena akun itu bernilai 12% dari ARR, dan saya tidak akan menerapkan aturan mutlak yang menentang kustomisasi. Saya akan bertanya kepada pengambil keputusan pembaruan kontrak tentang hasil apa yang belum terpenuhi, apakah ketiadaannya benar-benar menyebabkan churn, dan apakah pengiriman fitur akan menghasilkan pembaruan bersyarat. Saya akan membagi format proprietary menjadi inti ekspor audit yang dapat digunakan kembali dan sebuah adaptor khusus akun, kemudian membandingkan laba kotor yang dapat dihindari, bukti permintaan bersama, biaya siklus hidup, dan nilai roadmap yang tergeser. Berdasarkan asumsi ini, saya menolak pembuatan langsung selama 24 engineer-weeks dan memilih inti yang dapat digunakan kembali ditambah adaptasi berbayar. Pekerjaan baru dimulai jika batasan pembaruan, penerimaan, keamanan, dan pemeliharaan telah dikontrakkan pada tanggal tertentu; jika tidak, saya akan mempertahankan roadmap dan menawarkan alternatif terbatas."

Pembahasan Mendalam Langkah demi Langkah

Mulailah dengan memvalidasi rantai fitur-ke-churn-ke-pembaruan. Wawancarai pemilik operasional pelanggan, pengambil keputusan pembaruan, dan pemohon audit atau kepatuhan secara terpisah. Amati tugas saat ini, kumpulkan bukti kegagalan, dan identifikasi tanggal batas akhir yang dapat diterima. Kemudian ajukan dua pertanyaan kontrafaktual: seberapa besar kemungkinan churn jika tidak ada opsi baru yang muncul, dan seberapa besar opsi yang dipilih dapat mengurangi probabilitas tersebut? Label pipeline atau nada bicara pelanggan tidak dapat menggantikan probabilitas bersyarat tersebut.

Gunakan formula ini untuk mendisiplinkan diskusi:

Perkiraan nilai yang dilindungi = laba kotor tahunan pelanggan × (probabilitas churn tanpa opsi − probabilitas churn dengan opsi)

Tujuannya bukanlah menghasilkan angka desimal hiasan. Berikan rentang, bukti pendukung, dan penanggung jawab untuk setiap probabilitas. Pelanggan yang menandatangani adendum yang menyatakan akan memperbarui kontrak jika kriteria penerimaan eksplisit terpenuhi memberikan bukti yang lebih kuat daripada peringatan lisan. Jika fitur tersebut hanya mengatasi satu dari beberapa penyebab churn, nilai yang dilindungi tidak dapat disamakan dengan 12% ARR penuh dari pelanggan tersebut.

Selanjutnya, pisahkan antara tugas (job), kapabilitas bersama, dan adaptor khusus akun. Dalam kasus ini, 6 pelanggan membutuhkan catatan persetujuan yang dapat diaudit. Oleh karena itu, otorisasi, model peristiwa yang konsisten, riwayat ekspor, dan integritas yang dapat diverifikasi dapat membentuk inti produk. Nama kolom proprietary, urutan file, dan aturan sistem internal hanya melayani satu akun dan cocok untuk adaptor terbatas. Dekomposisi ini tidak serta-merta membenarkan pembuatan platform. Inti bersama hanya ada jika alur kerja, data, dan batasan izin benar-benar berulang di berbagai pelanggan.

Bandingkan tiga opsi yang dapat dieksekusi. Angka upaya di bawah ini tetap merupakan asumsi kasus:

Pembangunan langsung menghabiskan 24 dari 30 engineer-weeks, atau 80% dari kapasitas kuartal tersebut. Dengan staf 3 orang saat ini, pekerjaan itu tetap membutuhkan 8 minggu, sehingga tidak dapat memenuhi permintaan 6 minggu. Opsi yang dapat digunakan kembali mengasumsikan 2 engineer menghabiskan 4 minggu untuk inti 8 engineer-weeks, diikuti oleh 1 engineer yang menghabiskan 2 minggu untuk adaptor. Oleh karena itu, opsi ini dapat selesai dalam 6 minggu, menggunakan total 10 engineer-weeks, dan menghabiskan sekitar sepertiga dari kapasitas triwulanan. Jawaban tetap harus menyebutkan apa yang tergeser oleh opsi tersebut. Layanan profesional juga bukanlah kapasitas gratis; implementasi, operasi, dan dukungan termasuk dalam komponen biaya. Jika perusahaan tidak memiliki kapabilitas layanan, "biarkan tim Layanan yang menanganinya" hanya memindahkan risiko ke tim lain.

Berdasarkan asumsi yang dinyatakan, rekomendasikan untuk tidak melakukan kustomisasi langsung dan pilihlah inti ekspor audit yang dapat digunakan kembali ditambah adaptor khusus akun berbayar. Tetapkan gerbang mulai (start gate) yang ketat pada akhir hari kerja ke-5: pelanggan menandatangani pembaruan atau adendum yang disyaratkan pada kriteria penerimaan eksplisit; Engineering mengonfirmasi cakupan 10 engineer-weeks; Keamanan dan Kepatuhan menyetujui batasan data; dan pemilik komersial menerima hasil roadmap yang bergeser. Jika ada syarat yang tidak terpenuhi, pilih solusi alternatif terbatas dan jangan menghabiskan kapasitas pengembangan produk.

Pilihan ini menggunakan bukti dari 6 tugas pelanggan bersama sembari mencegah format proprietary mencemari inti produk. Tim produk memiliki kapabilitas bersama tersebut. Pemetaan kolom dan templat proprietary mengikuti penawaran harga terpisah, tingkat dukungan, dan proses perubahan tersendiri. Kontrak harus menyatakan tanggung jawab data, sampel penerimaan, tanggal pengiriman, biaya, masa pemeliharaan, estimasi ulang untuk perubahan material, serta ketentuan untuk menghentikan adaptor atau bermigrasi ke format standar. Jangan menjanjikan dukungan untuk setiap kustomisasi di masa mendatang, dan jangan menghitung 5 calon pengguna lainnya sebagai pendapatan yang telah dibukukan.

Terakhir, verifikasi keputusan tersebut. Sebelum pengiriman, konfirmasikan bahwa inti bersama menjalankan tugas umum tanpa percabangan khusus pelanggan. Gunakan sampel yang telah dianonimkan (de-identified) untuk menguji otorisasi, kelengkapan kolom, regenerasi deterministik, dan penerimaan auditor. Setelah pengiriman, ukur apakah pembaruan kontrak telah ditandatangani, apakah pelanggan menggunakan kapabilitas tersebut, apakah 5 pelanggan lainnya akan mengadopsi atau membayar, berapa banyak dukungan yang dihabiskan, dan hasil roadmap mana yang tertunda. Jika pelanggan memperbarui kontrak tetapi tidak pernah menggunakan fitur tersebut, jangan menganggap pembuatan fitur sebagai alasan utama pembaruan kontrak tersebut. Jika upaya adaptor terus meningkat, naikkan harga, persempit dukungan, atau gunakan klausul keluar kontrak.

Aturan yang dapat digunakan kembali adalah: hargai hanya porsi risiko churn yang dapat diubah, jadikan produk hanya untuk tugas lintas pelanggan yang berulang, dan gunakan kontrak untuk menetapkan biaya perbedaan khusus akun serta pemeliharaan jangka panjang.

Contoh Jawaban Berkualitas Tinggi

"Saya akan memperlakukan 12% ARR sebagai batas atas eksposur, bukan sebagai nilai yang dijamin dari pembangunan fitur. Pada hari pertama, saya akan bergabung dengan Sales untuk berbicara dengan pemilik operasional pelanggan, pengambil keputusan pembaruan kontrak, dan pemilik audit. Saya perlu mengetahui apakah mereka memerlukan catatan yang dapat diaudit atau hanya file yang disebutkan, dan apa keputusan pembaruan kontrak jika tanpa fitur, dengan alternatif sementara, dan dengan pengiriman yang disepakati. Bukti terkuat adalah syarat pembaruan tertulis yang terikat pada penerimaan, bukan sekadar 'mereka mungkin akan pergi.'

Saya akan memasukkan nilai dan biaya ke dalam model yang sama. Sisi nilai dimulai dengan laba kotor tahunan pelanggan dan pengurangan probabilitas churn yang dihasilkan oleh opsi tersebut. Sisi biaya mencakup rilis pertama, pemeliharaan tahunan, dukungan, dan hasil roadmap yang tergeser. Spesifikasi langsung memakan biaya 24 engineer-weeks, menghabiskan 80% dari 30 engineer-weeks yang tersedia pada kuartal berikutnya, dan tetap tidak dapat memenuhi tenggat 6 minggu secara kredibel. Saya akan secara eksplisit menolak opsi tersebut.

Riset menunjukkan bahwa 6 dari 40 pelanggan enterprise memiliki tugas yang sama dalam menghasilkan catatan persetujuan yang dapat diaudit, sementara hanya akun ini yang membutuhkan format proprietary. Oleh karena itu, saya akan mengalokasikan 8 engineer-weeks untuk inti ekspor audit yang dapat digunakan kembali dan 2 engineer-weeks untuk adaptor berbayar. Inti tersebut masuk ke dalam produk; kolom dan templat proprietary tetap berada di adaptor dengan batasan pemeliharaan yang jelas. Opsi 10 engineer-weeks ini dapat sesuai dengan jendela 6 minggu dalam kasus ini, tetapi masih memakan sekitar sepertiga dari kapasitas triwulanan, sehingga saya akan menunjukkan kepada pemilik komersial hasil roadmap mana yang akan bergeser.

Saya akan menetapkan gerbang mulai pada akhir hari kerja ke-5: pembaruan atau adendum yang ditandatangani dengan kriteria penerimaan, cakupan engineering yang dibatasi pada 10 engineer-weeks, persetujuan keamanan dan kepatuhan, serta ketentuan biaya, dukungan, perubahan, dan keluar dalam kontrak. Jika ada gerbang yang terlewat, saya tidak akan membiarkan ancaman menjadi janji roadmap implisit. Sebagai gantinya, saya akan menawarkan ekspor standar berbatas waktu dengan konversi manual.

Setelah peluncuran, saya akan memeriksa pembaruan kontrak yang ditandatangani, penggunaan aktual, kesediaan 5 pelanggan lainnya untuk mengadopsi atau membayar, jam kerja dukungan, dan penundaan roadmap. Sekalipun pelanggan memperbarui kontrak, saya tidak akan langsung mengklaim bahwa fitur tersebut otomatis menyelamatkan 12% ARR. Komitmen bersyarat sebelumnya dan bukti penggunaan selanjutnya menentukan seberapa kredibel atribusi tersebut."

Kesalahan Umum

• Langsung menyetujui karena 12% ARR → Konsentrasi pendapatan disalahartikan sebagai nilai kausal, dan ancaman churn menjadi cara untuk memotong antrean → Validasi kontrafaktual churn, laba kotor, komitmen kontraktual, dan wewenang pengambilan keputusan.
• Menyatakan bahwa produk tidak boleh dikustomisasi sama sekali → Sebuah permintaan mungkin mengungkap tugas bersama di target pasar → Temukan bukti alur kerja dan batasan yang berulang sebelum menarik batasan inti produk dan adaptor.
• Mengubah seluruh permintaan proprietary menjadi sebuah platform → Satu akun tidak membuktikan bahwa arsitektur yang digeneralisasi layak mendapatkan investasi → Jadikan produk hanya untuk inti terkecil yang didukung oleh bukti tugas pelanggan yang berulang.
• Hanya menghitung pengembangan rilis pertama → Dukungan, peningkatan, perubahan data, dan penerimaan akan menyita waktu tim selama bertahun-tahun → Estimasikan siklus hidup penuh dan masukkan pemeliharaan ke dalam harga serta ketentuan kontrak.
• Menganggap layanan profesional itu gratis → Risiko hanya berpindah dari Produk ke Implementasi atau Dukungan → Tetapkan pemilik layanan, kapasitas, harga, tingkat dukungan, dan ketentuan keluar.
• Mengumumkan skor RICE yang tepat sebagai jawaban akhir → Probabilitas churn, kesesuaian strategis, dan bukti kontrak mungkin masih berupa tebakan → Gunakan rentang nilai dan tingkat keyakinan untuk masukan penting serta nyatakan pemicu perubahan keputusan.
• Membangun sebelum menegosiasikan pembaruan kontrak → Vendor menanggung semua risiko sementara pelanggan masih dapat churn karena harga, pengadaan, atau alasan lain → Tukarkan komitmen komersial dan kriteria penerimaan yang jelas sebelum memulai.
• Menawarkan opsi tanpa rekomendasi → Pewawancara tidak dapat melihat apakah kandidat berani mengambil tanggung jawab atas suatu trade-off → Sebutkan pilihan, opsi yang ditolak, gerbang mulai, dan rencana cadangan (fallback).

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan Lanjutan 1: Pelanggan mewakili 30% dari ARR, dan kehilangannya dapat mengancam arus kas (cash flow). Apakah jawaban Anda berubah?

Toleransi risiko perusahaan berubah, sehingga validasi dan keputusan eksekutif harus dipercepat, tetapi angka 30% tetap tidak otomatis menyetujui spesifikasi apa pun. Periksa runway jangka pendek dan laba kotor pelanggan, lalu bandingkan pengiriman manual, percabangan terbatas, inti bersama, dan kustomisasi lengkap. Perusahaan secara rasional dapat menerima lebih banyak biaya layanan satu kali untuk mengulur waktu sambil memulai rencana pengurangan konsentrasi. Pemilik yang berwenang menanggung risiko pendapatan tingkat perusahaan harus membuat pengecualian dan menetapkan tanggal keluar.

Pertanyaan Lanjutan 2: Tidak ada pelanggan lain yang membutuhkan kapabilitas ini. Apakah Anda masih akan membangun inti yang dapat digunakan kembali?

Jangan gunakan alur kerja proprietary satu pelanggan sebagai bukti nilai platform. Perlakukan itu sebagai kasus bisnis akun tunggal: apakah laba kotor yang dapat dihindari menutupi pengembangan, pemeliharaan berkelanjutan, dukungan, dan opportunity cost; apakah perusahaan memang sengaja menjual pekerjaan proyek; dan dapatkah kontrak menetapkan harga untuk setiap perbedaan? Jika imbal hasil dan batasan strategis sama-sama terpenuhi, adaptor yang terisolasi mungkin masuk akal, tetapi adaptor tersebut tidak boleh disamarkan sebagai investasi roadmap yang dapat digunakan kembali. Jika tidak, tawarkan alternatif atau tolak.

Pertanyaan Lanjutan 3: Sales telah terlanjur menjanjikan pengiriman dalam 6 minggu. Apa yang Anda lakukan?

Konfirmasikan kata-kata persisnya, wewenang, dan pemahaman pelanggan sebelum menambahkan janji lain di atas kesalahan pertama. Engineering memberikan cakupan yang dapat dipertahankan; pemilik komersial memutuskan apakah akan menegosiasikan ulang tanggal, cakupan, harga, atau kompensasi; Bagian Hukum memeriksa eksposur kontraktual. Jika 6 minggu hanya memungkinkan inti bersama dan adaptor terbatas, dokumentasikan sampel penerimaan dan pengecualian. Perbaiki proses komitmen pra-penjualan setelahnya, tetapi jangan biarkan pekerjaan tata kelola tersebut menggantikan percakapan langsung dengan pelanggan.

Pertanyaan Lanjutan 4: Pelanggan menolak pembaruan bersyarat dan berkata, "Bangun dulu, baru kita bicara." Apakah Anda akan mulai membangun?

Hal itu secara material melemahkan bukti bahwa pengembangan fitur akan mencegah churn. Cari setidaknya kemajuan pengadaan yang dapat diamati, konfirmasi oleh pengambil keputusan, atau fase penemuan berbayar, dan batasi setiap investasi yang tidak dapat dibatalkan. Jika pelanggan menolak setiap bentuk pertimbangan, pertahankan roadmap secara default dan tawarkan kapabilitas yang ada ditambah alternatif layanan berbatas waktu. Jangan mengubah ancaman lisan menjadi komitmen 10 engineer-weeks kecuali pemilik keputusan tingkat perusahaan secara eksplisit menerima ketidakpastian tersebut.

Pertanyaan Lanjutan 5: Format proprietary mengakses data persetujuan yang sensitif, dan tinjauan keamanan tidak dapat selesai dalam 6 minggu. Bagaimana solusinya?

Persetujuan keamanan adalah gerbang mulai, bukan skor yang bisa dikalahkan oleh pendapatan. Carilah opsi yang tidak memperluas batasan data, seperti meminta pelanggan mengubah ekspor standar di lingkungannya sendiri atau menyediakan paket kolom minimal yang telah dianonimkan. Jika opsi-opsi tersebut gagal memenuhi persyaratan, negosiasikan ulang tanggalnya atau tolak. Seorang product manager dapat menjelaskan biaya komersial tetapi tidak dapat mengambil alih risiko keamanan atas nama pemiliknya.

Pertanyaan Lanjutan 6: Anda mengirimkan tepat waktu, tetapi pelanggan tetap churn. Bagaimana Anda meninjau keputusan tersebut?

Rekonstruksi rantai kausal sebelumnya: siapa yang berkomitmen pada apa, apakah penerimaan lolos, apakah fitur tersebut digunakan, dan apakah harga atau pengadaan adalah penyebab sebenarnya. Pisahkan kesalahan pertimbangan, kegagalan eksekusi, dan perubahan kondisi pelanggan. Kemudian perbarui estimasi probabilitas churn, persyaratan bukti pra-penjualan, dan ketentuan kontrak, serta nilai kembali apakah inti bersama masih melayani 5 pelanggan lainnya. Jangan mengakhiri evaluasi dengan "pelanggan bertindak dengan itikad buruk," dan jangan menolak setiap permintaan akun strategis hanya karena satu yang gagal.