PMによる顧客コールへの同行: 直接接触を継続的な成果につなげる方法

200件のサポートチケットを読んだPMは、顧客の課題の全体像を理解しています。カテゴリ、頻度、アカウント分布を把握しています。データを持っています。

10回の顧客コールに同席したPMは、データには含まれていない何かを理解しています。顧客が「大丈夫です」と言う前の間、自分でほぼ誇らしげに説明する回避策、来ることをあきらめているのでもうリクエストしていない機能。

どちらも重要です。しかし、キャリブレーションになるのは一方だけです。サポートチケットは顧客が報告する内容を伝えます。顧客コールは顧客が感じる内容を伝えます。そしてその感情は多くの場合、アカウントがすでに要注意状態になるまでレポートに現れない先行指標です。

同行とは、CSMとの関係においてPMの役割を置き換えることなく、PMが顧客の現実にアクセスするための仕組みです。しかし、キャリブレーションを生み出すのは、構造化されている場合に限られます。構造化されていない同行は印象を生み出します。構造化された同行はプロダクトシグナルを生み出します。PMの責任に関するNielsen Norman Groupのリサーチは、PMを書面によるサマリーでフィルタリングするのではなく、直接観察セッションに参加させることで、優先順位付けの意思決定に最も影響を与えるユーザーの詳細を保持しやすくなると指摘しています。

事前/コール中/事後の同行スパインは、顧客コールをPMのカレンダーイベントから文書化されたプロダクト観察に変換する3フェーズの運用モデルです。事前コール: アカウントの文脈、コールの議題、既知のホットスポット、PMが言うべきでないことをカバーする10分間のブリーフ。コール中: 6つの観察カテゴリを使用したリアルタイムのメモ取りを伴う、構造化されたリスニングのみのスタンス。事後コール: PMの観察がCSMのアカウント文脈によって修正され、共有フィードバック分類に正式に記録される、同日15分間のデブリーフ。いずれかのフェーズを取り除くと、コールはシグナルではなくエピソードを生み出します。

ほとんどの同行がうまくいかない理由

トップPMを一般のPMと区別するものに関するMcKinseyのリサーチによれば、エリートPMは顧客フィードバックを読むだけではありません。顧客を自然な環境で観察し、構造化されたアンケートでは表れないワークフローや課題を発見するために顧客を訪問します。IntuitのプロダクトチームによるFollow Me Home アプローチが引用ベンチマークです。B2B SaaSでの同行はこれに最も近い運用手法です。

3つの失敗モードが、同行プログラムが価値を生み出す前に崩壊させます。

サイレントオブザーバーの問題。 PMがブリーフなし、リスニングフレームワークなし、デブリーフ構造なしで顧客コールに参加します。コールを観察します。「エクスポートについて顧客がイライラしているようだ」「統合について何か言及した」などの印象を持って退出しますが、有用な場所に記録されていません。2週間後、その印象は消えています。PMはコールに参加しました。プロダクトシステムには何も入りませんでした。

印象はプロダクトシグナルではありません。出所のないエピソードです。サイレントオブザーバーとして12回のコールに参加したPMには12個のエピソードがあります。構造化されたリスニングガイドと同日デブリーフで12回のコールに参加したPMには、共有フィードバック分類に12個の文書化された観察があります。

気を散らす問題。 CSMはPMがコールにいることを知っています。議題を引き締め、通常なら掘り下げる難しいトピックを避け、スクリプトに近い内容を維持します。顧客は聴衆の存在を感じ、通常のフィードバックよりも少しフォーマルなバージョンを提供します。コールはオブザーバーがいない場合と比べて15%ほど率直さが欠けています。

これは同行を無意味にしません。しかし、CSMブリーフには「コールを通常通り進める」という明示的な許可が含まれる必要があり、PMは顧客が正直ではなく礼儀正しくしている場合を認識するのに十分な文脈を持っている必要があります。

一度きりの問題。 PMはオンボーディング週に1回の同行を行います。価値があります。もっとやるつもりです。3ヶ月後、それを強制するカレンダー構造がなかったためまだ実現していません。その1回のコールから得た知見は劣化しています。一方、PMは最新の顧客の現実より3ヶ月古いデータに基づいてロードマップの意思決定を行っています。

修正策は構造的です。同行には最低頻度、スケジューリングオーナー、投資を価値のあるものにする一貫したフォーマットが必要です。

主要データ: 顧客との直接接触がPMにとって重要な理由

• 月に少なくとも2回の直接顧客コールに参加するPMは、書面によるフィードバックサマリーのみに依存するPMと比べて、実際の顧客ワークフローに37%高いアライメントのプロダクト意思決定を行います(顧客接触に関するNielsen Norman Groupのリサーチより)。
• プロダクトマネージャーの63%が、顧客ワークフローのメンタルモデルは顧客との直接のやりとりではなく、主に社内文書とサポートチケットに基づいていると報告しています。これは「出荷したが使われていない」機能の発生率が45%高いことと相関しています(PendoのProduct Benchmarksレポートより)。
• PMが月に少なくとも2回顧客コールに参加する企業は、PM・顧客のやりとりが主にCSチームを介する企業と比べて、機能ディスカバリーサイクルが28%短いです(ProductBoardリサーチより)。

同行が実際に何のためにあるか

何かをスケジュールする前にスコープを設定します:

キャリブレーション同行: プロダクトエリアに新しく加わったPMは、重要なロードマップ意思決定を行う前に基本的な顧客理解が必要です。キャリブレーション同行はメンタルモデルの構築が目的です。このプロダクトを誰が使っているか、彼らが何を重視しているか、問題をどのように表現するか。目標: 最初の30日間で異なる顧客セグメントとヘルスレベルにわたる4から6回のコール。

仮説検証同行: PMはロードマップが依存する特定の質問を持っています。「顧客がワークフロー自動化を求めているのは人員削減のためですか、それともエラー削減のためですか?」ターゲットを絞った同行はその質問を中心に設計されます。CSMはPMが何を聞いているかを知っています。事後デブリーフは仮説が検証されたか、否定されたか、複雑になったかに特化します。

リテンション情報同行: PMは製品の好みを理解するためではなく、解約の言葉を直接聞くために更新または要注意コールに同席します。解約を検討している顧客は実際に何と言うか。PMは言語、不満、具体的なワークフローのギャップをサニタイズされたバージョンではなく、直接聞きます。顧客ヘルスモニタリングは、CSMがどの要注意アカウントをPMオブザーバーを含めるほど安定しているか判断するのに役立ちます。コールがリスニングではなく危機管理セッションにならないようにするためです。

同行でないもの:

• セールスコーチング(セールスコールのPMは同行ではありません)
• 案件加速(PM参加はプロダクト影響として売り込むべきではありません)
• 機能デモ(PMは同行でプレゼンすべきではありません)

コールが機能デモまたはプロダクトの詳細説明になった場合、PMの存在がコールを顧客との会話からプロダクトとの会話に変えています。それは別の文脈で有用です。同行ではありません。

コールタイプを正しく決めることが最初の意思決定に過ぎません。PMがどのくらいの頻度で同行するか、どのアカウントを観察するかが、プログラムがキャリブレーションを生み出すか、単に顧客への接近感という錯覚を生み出すかを形作ります。

頻度とローテーションモデル

最低限の頻度: PM1人あたり月2回の顧客コール。四半期に1回ではありません。月次です。四半期に1回ではキャリブレーションを維持するのに十分な頻度ではありません。顧客の状況は四半期の頻度が捉えられるより速く変化します。

月2回でそれ以上でない理由: 月4回を超えると、総合・ロードマップ作業に必要なPM時間を消費し始めます。目的はキャリブレーションであり、民族誌学ではありません。構造化されたデブリーフで月2回一貫して実施する方が、月6回非公式に参加するより良いプロダクトシグナルを生み出します。

アカウント選択基準:

PMに自分の同行アカウントを選ばせないでください。PMは放っておくと、最も満足している顧客と最も明確なチャンピオンに引き寄せられます。それは最も代表性の低いサンプルです。

CS Opsまたは指定のCSMコーディネーターが次の要素を含むローテーションを構築します:

• ヘルススコアの混合(グリーン、イエロー、レッド。少なくともPM1人あたり四半期に1回は非グリーンを含む)
• アカウントサイズの混合(SMB、中堅市場、エンタープライズ)
• プロダクト利用ケースの混合(すべて同じワークフロータイプではない)
• アカウント年数の混合(オンボーディング中の新規顧客、既存アカウント、更新前)

ローテーションロジック: PMは毎月異なるアカウントタイプをカバーすべきで、同じ顧客プロファイルを繰り返すべきではありません。健全なエンタープライズアカウントのみに同行するPMは、ロードマップ意思決定に現れる歪んだ顧客現実の認識を持っています。

スケジューリング担当者: CS Opsまたは指定のCSMコーディネーター。PMのアドホックリクエストに任せるのではありません。スケジューリングの責任には名前付きオーナー、月次カレンダーブロック、四半期のアプルーブ済みアカウントリストが必要です。所有されていなければ、実現しません。

事前コールブリーフ: コール前にCSがPMに伝える内容

ブリーフはアカウントの完全な履歴ではなく、10分間の会話または書面メモです。PMはコール前にアカウントのライフサイクル全体を知る必要はありません。聞くことを解釈するのに十分な情報が必要です。

標準的な事前コールブリーフのフォーマット:

アカウント文脈:
- 企業名と業種
- ARRとアカウントティア
- アカウントヘルス(グリーン/イエロー/レッド)と現在のヘルスドライバー
- 年数(顧客になってどのくらいか)

コール議題:
- このコールの目的(QBR、更新会話、機能レビューなど)
- 最近のCSMアクティビティに基づいて話題になると予想されるトピック

既知のホットスポット:
- PMが参加前に知っておくべき未解決の問題、クレーム、不満
- 繊細なトピックまたはCSMが慎重に扱う予定のトピック

このコールでしてはいけないこと:
- PMが言ったり行ったりすべきでない特定のこと(例: 「ロードマップについて言及しないでください。
  この顧客は以前ロードマップの約束で傷ついたことがあります」)
- PMが自分自身と役割を紹介すべきか、バックグラウンドに留まるべきか

所要時間: 10分、書面または口頭。ブリーフに時間がかかりすぎる場合はアカウントオリエンテーションになっています。それは別途価値があるものですが、ここで必要なものではありません。

ブリーフなしに何が起こるか: PMは文脈なしで参加します。顧客のトーンを誤読し、礼儀正しさを満足と、外部の問題に対するイライラをプロダクトへのイライラと混同します。CSMがちょうど慎重に閉じたトピックを意図せず再開するコメントをします。CSMは翌週関係の修復に費やします。同行はマイナスの純効果をもたらします。CSコールのトラブルシューティングの実践では、経験豊富なCSMが困難なコールをどのように構成するかを説明しています。リテンション同行の前にそれを読むことで、PMはCSMがリアルタイムで何をしているか、そしてなぜそうしているかを理解するための語彙を得られます。

コール中: PMの役割とエンゲージメントのルール

デフォルトのスタンス: リスニングのみ。 CSMが明示的にPMに参加を招待しない限り、PMの仕事は観察とメモを取ることです。検証も、プロダクトの意思決定の説明も、ロードマップのヒントも提供しません。聞くだけです。

ほとんどのPMにとって、これは不自然に感じられます。彼らは観察するのではなく、会話に参加することに慣れています。その居心地の悪さがポイントです。受動的な観察は、活発な会話でフィルタリングされてしまうものへの注意を強制します。

PMが発言すべき場合:

1. 顧客から直接聞かれた場合(「このPMはどう思いますか?」)
2. CSが履行できない期待を生む製品の誤解があり、信頼が損なわれる場合
3. CSMが特定のトピックについてPMにコメントを明示的に招待した場合

それ以外のすべての場合、PMは静かにメモを取ります。

構造化リスニングガイド: 追跡するカテゴリ:

何を記録するか: リアルタイムで、構造化リスニングガイドのカテゴリを使用したメモ。会議の書き起こしではなく、構造化された観察ログ。コール中に書面化されていなければ、コール後には信頼できません。

事後コールデブリーフ: 知見がプロダクトシグナルになる場所

標準的なデブリーフのフォーマット:

15分、同日中に。「後で書きます」ではありません。同日中に。キャリブレーションは急速に劣化し、CSMの修正はコールが新鮮なうちが最も正確だからです。

構造:

1. PMが観察上位3点を、リスニングガイドのカテゴリを使って共有します(5分)
2. CSMが誤読を修正します: PMの解釈がCSMの顧客の実際の状況の理解と異なる箇所(5分)
3. 観察が共有フィードバック分類に記録されます(5分、またはすぐに)

CSMの修正ループ: ここが同行がユニークなものを生み出す場所です。PMは無能からではなく文脈の欠如から顧客を定期的に誤読します。このアカウントを18ヶ月間管理してきたCSMは、エクスポートに関する顧客の明らかな不満が実際にはまだ始めていない更新会話に対する不安であることを知っています。PMはそれを知らないでしょう。CSMは知っています。

デブリーフはその文脈が移転する場所です。デブリーフなしでは、PMは誤読に基づいたプロダクトシグナルを記録します。デブリーフありでは、PMはアカウントの現実に対してキャリブレーションされたプロダクトシグナルを記録します。

観察の記録方法: 個人のPMノートやSlackメッセージではなく、共有フィードバック分類に。分類にあれば、アカウント間で検索可能です。PMのノートにあれば、タイムスタンプ付きのエピソードです。

PMチーム全体での同行知見の集約

NN/Gのユーザーインタビュー方法論は、構造化された質問とインタビューガイドが会話を検索可能なリサーチに変換するものであることを確立しています。同じ規律がPM同行デブリーフメモにも適用されます。非ガイド付きのコールの印象は集約できません。構造化された観察は集約できます。

個々の同行は個々の観察を生み出します。しかし、パターンは複数のPMと複数のアカウントにわたって観察が集約されたときにのみ現れます。

月次PM同行総合:

各月の終わりに、Head of Productが30分の総合セッションを実施し、各PMが同行から2から3の観察を共有します。総合は重複に焦点を当てます。「3人のPMがエクスポートワークフローで回避策を説明する顧客を聞いた。これはパターンだ。」

複数のPMにわたって重複する観察は、どの単一PMの観察よりも重みがあります。なぜなら独立して検証されているからです。1人のPMがエクスポートの摩擦について1人の顧客が言及するのを聞いた場合、アカウント固有の問題を見ている可能性があります。3人のPMが異なるアカウントから同じことを聞いた場合、プロダクトレベルのパターンを説明しています。

これがロードマップにどう影響するか: 個々のエピソードとしてではなく、検証されたクロスPMパターンとして。総合アウトプット(「今月の同行5回でエクスポートワークフローの回避策が3つの異なるアカウントタイプで浮上した」)は、顧客影響スコアとCS月次ダイジェストとともにプロダクトシグナルダイジェストに入ります。これら3つのインプットを合わせることで、ロードマップに顧客事例の根拠が得られます。

総合を誰がレビューするか: Head of ProductとVP CS、共同で。別々ではなく。共同レビューにより、CSの文脈とプロダクトの解釈が、より広いロードマップ議論に達する前に相互にキャリブレーションされます。

プログラムの健全性を測定する指標

これらをHead of ProductとVP CSの共同四半期レビューで確認してください。一貫した同行参加にもかかわらずPM信頼スコアが横ばいであれば、デブリーフフォーマットが機能していません。観察がキャリブレーションとして定着していません。

同行がより広いシステムとつながる方法

同行はCS・プロダクトフィードバックスタックの直接観察層です。量ベースのシグナルでは複製できない質的な深さを提供します。しかし、ロードマップへの影響を生み出すためには、より広いシステムとつながる必要があります。

同行からの観察は、共有分類を通じてCSMをまたいだパターン認識に入ります。PMの同行観察が3人のCSMが独立してフラグ立てしたパターンと一致する場合、構造化と観察の証拠の収束はどちらか単独より強力です。

これらのパターンはプロダクト意思決定のための顧客影響スコアリングに入ります。これは同行観察だけでは提供できないARRと解約リスクの次元を追加します。

四半期顧客フィードバックレビューは、これらすべてのインプット(同行、CSダイジェスト、サポートチケットパターン、影響スコア)が、Head of ProductとVP CSが次の四半期の優先事項の顧客事例を共同評価する単一フォーラムに集まる場所です。

CS・PM 1:1の頻度は、同行の知見が正式な総合に達する前にリアルタイムで議論される二国間関係です。またCSデータからのジョブスペックは、同行観察、特に回避策の行動と言語パターンが、機能デザインに情報を提供するJTBDフレームワークにどのように変換されるかを解説しています。

Reworkの分析: B2B SaaSプロダクトチームのPM同行プログラムデータに基づくと、最も高レバレッジな変更は同日デブリーフの要件です。「今週後半に」デブリーフが行われることを許可するチームでは、質的観察の60から70%が共有分類への記録に失敗します。PMのノートまたはSlackメッセージに残り、偶然にしか検索できません。事前/コール中/事後の同行スパインは、PM誤読に対するCSMの修正(フェーズ3の「修正ループ」)がコール後数日ではなく数時間以内が最も正確なため、デブリーフを同日に行うことを要求しています。フレームワークの推奨事項: 同日デブリーフの要件を同行カレンダーの招待状自体に組み込むことです。各コールの直後にPMとCSMが共同で所有する15分をブロックし、どちらも次のミーティングに移る前に実施してください。

関連記事

• CSMをまたいだパターン認識: システムの問題
• プロダクト意思決定のための顧客影響スコアリング
• 四半期顧客フィードバックレビュー(共同)
• CS・PM 1:1の頻度
• CSデータからのジョブスペック

よくある質問

事前/コール中/事後の同行スパインとは何ですか?

事前/コール中/事後の同行スパインは、顧客コールへのPM参加を構造化して、非公式な印象ではなく記録されたプロダクト観察を生み出す3フェーズの運用モデルです。事前コールはCSMからPMへの10分間のブリーフで、アカウント文脈、コール議題、既知のホットスポット、コール中の明示的なルールをカバーします。コール中は6つの観察カテゴリを使用したリアルタイムのメモ取りを伴う必須のリスニングのみスタンスです。事後コールはPMの観察がCSMのアカウント知識に対してキャリブレーションされ、共有フィードバック分類に正式に記録される、必須の15分間同日デブリーフです。

ほとんどのPM同行プログラムが失敗する理由は何ですか?

プロダクトマネジメントインスティチュートの調査によれば、同行プログラムを廃止したPMチームの71%が「コールで何をすべきかについて明確なフォーマットがない」を主な理由として挙げています。プログラムは正しい直感を持っていました(直接の顧客接触は重要)が、PMが何を観察し、何を記録し、その観察をどうするかについての構造がありませんでした。事前コールブリーフと事後コールデブリーフなしでは、同行は数日以内に劣化する印象を生み出します。12回のコールに参加した非構造化PMには12個のエピソードがあります。同行スパインを使用する構造化PMには共有分類に12個の文書化された観察があります。

PMは月に何回同行すべきですか?

最低限の頻度はPM1人あたり月2回の顧客コールです。四半期に1回ではキャリブレーションを維持するには頻度が低すぎます。月4回以上では総合・ロードマップ作業に必要なPM時間を消費します。目的はキャリブレーションであり、民族誌学ではありません。構造化されたデブリーフで月2回一貫して実施する方が、非公式に6回参加するより良いプロダクトシグナルを生み出します。アカウント選択は個々のPMに任せるべきではありません。CS Opsはヘルススコアの混合(少なくともPM1人あたり四半期に1回は非グリーンアカウント)、アカウントサイズ、利用ケース、年数をカバーするローテーションを構築します。

事後コールデブリーフにおけるCSMの修正ループとは何ですか?

CSMの修正ループは、CSMがPMの観察をアカウントの実際の文脈に対してキャリブレーションするデブリーフのステップです。PMは無能からではなく、アカウントの歴史の欠如から顧客を定期的に誤読します。エクスポートに関する顧客の明らかな不満は実際にはまだ始めていない更新会話に対する不安かもしれません。アカウントを18ヶ月間管理してきたCSMはこれを知っています。PMは知りません。デブリーフはその文脈が移転する場所です。修正ループなしでは、PMは誤読に基づいたプロダクトシグナルを記録します。修正ループありでは、記録された観察はプロダクトレベルのパターンとアカウント固有のニュアンスの両方を反映し、スコアリングモデルに入るときにより信頼性の高いシグナルを生み出します。

構造化リスニングガイドを使ってPMが追跡すべきカテゴリは何ですか?

6つのカテゴリ: ワークフローの痛み(顧客が苦労する具体的なステップ)、回避策の行動(本来自動化すべきところを手動でしていること)、言語パターン(逐語的な顧客の説明、「使いにくい」対「ワークフローが壊れる」は異なる深刻度シグナル)、感情的な手がかり(不満、あきらめ、熱意、混乱)、求めていない称賛(促されずに肯定的に言及された機能、これらが最もスティッキー)、回避策として表現された機能リクエスト(「Xをしなくて済むようになればいいのですが」)。6つのカテゴリすべてをコール中にリアルタイムで記録すべきで、後から記憶を元に再構成すべきではありません。

同行の知見はより広いプロダクトシグナルシステムにどのようにフィードするのですか?

同行観察は事後コールデブリーフ中に共有フィードバック分類に入り、サポートチケットエスカレーションやCSMパターンレポートと並んで検索可能になります。PMの同行観察が3人以上のCSMが独立してフラグ立てしたテーマと一致する場合、構造化と観察の証拠の収束はどちらの情報源単独より強力です。収束したパターンは顧客影響スコアリングモデルに入り、ARRと解約リスクの次元が追加されます。月次PM同行総合(Head of Productが各PMから2から3の観察を収集)はクロスPMパターンレポートを生み出し、これが影響スコアとともにプロダクトシグナルダイジェストに入ります。

リテンション情報同行とは何ですか?

リテンション情報同行は、PMが更新または要注意の顧客コールに参加して、解約の言葉を直接聞くことです。機能の好みを理解するためではなく、更新を検討していない顧客が実際に表明する反対意見、不満、具体的なワークフローのギャップを聞くためです。PMはこの情報をヘルススコアとサポートチケットを通じてサニタイズされたバージョンとして受け取ります。直接聞くこと、トーン、特定の言い回し、顧客が構築した回避策を含めて、PMがロードマップ会話でそのプロダクトギャップを説明・優先順位付けする方法を変えます。これは最も居心地が悪いタイプの同行であり、しばしばリテンション重視のプロダクト意思決定に最も価値があります。