- カスタマーサクセスとプロダクト、顧客の関係性
- カスタマーサクセスの、顧客からの機能改善要望への向き合い方とその具体的取り組み例
はじめに
みなさん、こんにちは。
業務の幅が多岐に渡るカスタマーサクセス（以下、CS）において、切っても切り離せないのが「プロダクト」。今回は、CSがプロダクトの進化に対してどのように貢献する余地があるのか、特に機能要望に対してどのように向き合うべきかを筆者の経験・実践に基づいてご紹介していきます。
CSとプロダクトの関係性とその重要性
顧客、CS、プロダクトのトライアングル
まず、下記の記事でもご紹介した通り、カスタマーサクセスにおいては、自分達のプロダクトを理解することが必須かつ最優先です。
カスタマーサクセスにおいて必要な3つの知識とは？ ぞれぞれの知識の学び方 それぞれの知識を組織内で浸透させるためのマネージャーの役割 みなさん、こんにちは！ 今回は、カスタマーサクセス（以下「CS」）を始[…]
これはカスタマーサポートの観点で製品知識が必須であることも理由ですが、「実際にどういった機能、どういった使い方が目の前の顧客の成功に繋がるかを説明できること」がCSに期待されることが大きな理由です。
その中で、顧客の成功（サクセス）に対してプロダクトがボトルネックとなっている点、つまりプロダクトへの機能要望をダイレクトに聞くことができるのもCSです。言い換えると、サクセスのために顧客の望むプロダクトの進化のカギが最も集まるのはCSだということになります。顧客とプロダクトに対してそれぞれCSがアクセスして三角形を作り、生の情報を吸い上げる、ここにCSのプロダクト進化への潜在的な貢献可能性があります。
セールス（営業）が受け取る機能要望との違いは？
勿論、セールスチームも見込み客との商談の中で、「この機能が足りない」という指摘を受けることがあります。その意味ではセールスチームにもプロダクト進化のためのヒントが貯まることになります。
ただ、注意しなければならないのは、見込み客はあくまで見込み客で、プロダクトを使い込む前に要望しているため、「日々使うこのプロダクトに本当に必要な機能なのか」という観点での解像度はかなり低いことが多いです。場合によっては断る理由として機能要望を投げてきているだけという場合もあるため、CSに集まる要望と比較すると玉石混交であることには注意する必要があるでしょう。
カスタマーサクセスの社内におけるプレゼンスの現状 カスタマーサクセスの存在価値の代表例 はじめに -カスタマーサクセスは不要？プレゼンスは低い？- みなさん、こんにちは！ さて、先日以下のような調査結果が発表[…]
CSの機能要望との向き合い方の３ステップ
では、CSはプロダクトの進化に向けて具体的にどのように機能要望と向き合うべきでしょうか？
まだCS内での役割が必ずしも明確に分化していない、アーリーステージから取り組めるステップを以下に示します。
STEP1：まず要望を全ての顧客から聞いてみること
上記の筆者の経験の通り、ある程度プロダクトを使い込んでいる複数の顧客が求める機能要望は、プロダクトの進化のための重要なヒントであることが多いはずです。一部の「声の大きい」ユーザーの要望に引っ張られないためにも、契約してから1ヶ月のユーザーや1年のユーザーなど、全てのユーザーにヒアリングすることを習慣化してみると良いでしょう。どのステージにあるCSにもオススメです。
勿論、このヒアリングのために都度時間をとるのは物理的にも難しい場合があります。筆者の場合は、2回目以降のオンボーディングや更新時のミーティング（ QBR など）では必ず時間をとって、顧客の言いたいことが尽きるまで、要望を聞ききるようにしていました。
QBRの定義、目的とその内容 QBRを実施する際に注意しておくべきこと はじめに みなさん、こんにちは。 カスタマーサクセス（以下、CS）の顧客とのコミュニケーション方法は様々ありますが、一つの重要な機会と位[…]
STEP2：要望を一箇所にまとめること
聞いた要望は、CSだけで対処できるわけではないため、社内に共有することが必要です。そのためには、どこか一箇所にまとめておくことが重要です。
この際に、要望された機能は勿論ですが、背景に存在する課題、刺さる顧客のセグメント、優先度（一旦は CSM の主観でOK）などの要素も合わせて記載できると、後で一覧化して見返す時に非常に便利です。
最近では、こういったアイデアレベルから実際にプロジェクトを立ち上げて開発・改善まで管理できる専用のクラウドサービスも登場しています。初期フェーズではTrelloやAsana、Backlogなどのプロジェクト・タスク管理ツールでも十分ですし、勿論Microsoft ExcelやGoogleスプレッドシートなどの表計算アプリケーションでも十分集約管理が可能です。
やや工数はかかりますが、やり切れると本当にプロダクトにとっての「宝の山」が出来上がります。
STEP3：PdMと定期的に話す機会を持って、優先度や必要性をトリアージ
ここまで来て、元も子もない話をすると、顧客からの機能ベースでの要望は必ずしも筋がいいとは限りません。顧客は、それぞれの担当業務のプロであったとしても、プロダクト開発のプロではないからです。
このため、顧客から頂いた要望は、前述のようにその背景に潜む具体的課題感をベースとして、社内のプロダクトのプロ（多くの場合はプロダクトマネージャー、PdM）と定期的に相談する機会を持って優先度や必要性をトリアージしていくのがベストな進め方です。PdMと話して整理していくと、CSM的には必須だと思っていたものの、実は他の機能で代替可能かつ十分であったり、活用ケースが限定的すぎることが判明することもあります。
この定期的なPdMとの相談会には、CSから顧客の課題感を俯瞰的にも個別的にも見ることができる方（多くの場合はマネージャークラス）が参加するのが良いでしょう。
CSがプロダクト進化を阻害する唯一の可能性
ここまでCSは、顧客と直接話して、解像度が高いが故にプロダクトの進化に貢献できると書いて来ました。もっともそれが仇となり、逆に進化を阻害する可能性があることを最後に記載します。どうしてもCSは顧客の声の代弁者としての側面が強くなりがちで、要望もなるべく叶えてあげたいと思うでしょう。
それ自体は悪くないのですが、プロダクト側にも技術的、工数的、そしてプロダクトビジョン的に様々な「事情」があります。ここを調整しようとせず、CSがただ顧客の要望を叶えるための存在と化してしまうと、プロダクトチームやPdMの関係が悪くなり、結果として顧客の課題解決が遅れてしまったり（更にそれを単純にプロダクトチームの責任にして更に関係悪化を招いたり）してしまうことがあります。これを調整す役割がPMM（Product Marketing Manager）ではあるのですが、組織が必ずしも大きくない段階においては、CSのマネージャーがその調整役を担うことになるのが現実でしょう。
まとめ
CSをやっていると、顧客がサクセスしたと感じられた瞬間は勿論ですが、「要望頂いていた機能が、本日実装されました！」とお伝えするときも結構楽しみな瞬間だと思います。
顧客がサクセスするのも結局はみなさんのプロダクトを通してのことですがから、お客様とお話ししつつサポートするのが好きだからCSをやっている、という方も、是非プロダクトの進化への貢献を積極的に実施できると良いのではないでしょうか！