見出し画像

カスタマーサクセスとプロダクトはどのように連携するべきか？

Wataru Isono (礒野 亘) @カスタマーサクセス兼インサイドセールス責任者

今回はプロダクトとカスタマーサクセスがどのように連携すべきかというテーマで、自社の取り組みや自分が気をつけていることをご紹介しようと思います。

実は私はカスタマーサクセスに異動した初っ端から、チームに対して「もっとプロダクトとの連携を強化すべきだ」と半ば強固に主張していました。顧客ニーズによって柔軟にサービスを変えられるコンサルと違って、SaaSではプロダクトそのものがサービス。であるがゆえにプロダクトが顧客ニーズを踏まえて進化していかねば未来はないと強く危機感を持ったからです。

結果的にその主張からポジションが作られ、自らが主幹となってプロダクトとの連携を運用することになりました。そこから約1.5年程プロダクトとの連携について色々と試行錯誤をしています。そして今も別の形で取り組みが続いていますが正直完成形には程遠く、まだまだ自社の取り組みも進化していかねばという思いがあります。

なのでこれまでの取り組みを一旦まとめて情報発信しつつも、皆様からも有益な情報を頂きつつディスカッションできればという思いで本記事を書いています。自社ではこう取り組んでいる！というのがあればぜひシェアお願いします。

※3ヶ月続いた「Twitterで募集して票が多かったトピックから順に書いていくシリーズ」もこのnoteで一旦終わりにしようと思います。投票くださった皆様、ありがとうございました。

なぜCSとプロダクトの連携が重要なのか

私がカスタマーサクセスに異動して「よーし、頑張って顧客をサクセスに導くぞ」と闘志を燃やしていた時、ベルフェイス小林さんの書いた下記のnoteに出会いました。

一言でいうと「顧客を成功させるのはカスタマーサクセスではない、プロダクトである」ということです。当時自分が頑張って何とかするぞと意気込んでいたところに、いきなり先制パンチを食らったような気分でした。

しかし言われてみれば納得で、顧客と日々接しているのはカスタマーサクセスかも知れないけど、顧客が日々使っているのはプロダクトの方なんですよね。究極的には顧客が自走してサクセスすべき、という理想から考えても、カスタマーサクセスが超頑張って顧客が成功するよりも、プロダクトが主体となって顧客が成功するほうがWin-Winなわけです。

ではそのプロダクトは完璧かといえば、SaaSにおいてはそれもありえません。環境やユーザの変化に応じて常にアップデートし続けていくことがSaaSの宿命だからです。アップデートの指針になるのはビジョンや技術といった要素もありますが、最も大切なのは顧客からの声。そしてその顧客の声を社内で最も豊富に有しているのが他ならぬカスタマーサクセスなのです。

こういった理由からプロダクトとカスタマーサクセスの連携が非常に重要になります。まとめると下記。

【CSとプロダクトの連携が重要な理由】
1.顧客をサクセスさせるのはプロダクト
2,プロダクトを進化させるのは顧客の声
3.顧客の声はカスタマーサクセスしか持っていない

カスタマーサクセスは、長期的な顧客のサクセスのためにもプロダクトを顧客視点でアップデートしてもらう必要があり、そのためにプロダクトチームと協働し顧客の声を伝えることが大切となってくるのです。

CS→プロダクトへの3階層での要望連携

では実際に弊社でプロダクトへの要望連携をどう行っているかですが、フローにすると下記のようになります。

2020-07-26 18_29_50-PowerPoint スライド ショー - [プロダクト連携.pptx]

※プロダクトチーム、CSチームそれぞれ20～30名程度のチームでの実例

CSからの要望は上図の通り3階層に分けて伝達しています。伝わりやすさを考慮して中心にある赤線の第2階層から順に説明していきます。


第2階層：JIRA（オンライン×ストック）
プロダクトへの要望連携は基本的にはこのJIRAが柱となります。知る人ぞ知るAtlassian（オーストラリアに本社を置くBtoBソフトウェア開発SaaSカンパニー）の提供しているSaaSです。

余談ですが、AtlassianといえばFlywheelと呼ばれるビジネス成長モデルが超有名です。詳しくは「営業チームのいない異色SaaS企業　Atlassian流2兆円SaaS企業の創り方」をどうぞ！

ここに開発用のBoardがあり、CSメンバーは誰でも記入出来るようになっています。CSはプロダクトへの要望があれば随時このチケットのフォーマットに従って

・要望のサマリ
・要望の詳細
・誰の要望か（自分／クライアント）
・どの機能に関するものか

を記載します。記載したチケットは必ず週1のプロダクト企画会議にて精査され、仕様検討のフェーズに移行するか見送るのかの判断がなされます。

因みにこのプロダクト企画会議は非常にオープン＆フラットな場で、事業の誰でも参加可能なことに加えて、持ち込みたい企画やアイデアがあれば誰でも持ち込むことが可能になっています。

見送られたチケットも見送りグループに集約されるものの、四半期に一度程度棚卸しがされ、全てのチケットを技術制約や開発環境を踏まえて再度精査していきます。

JIRAでの開発要望連携のメリットは①ストック可能、②スピーディー、③追跡可能という3点が挙げられます。

①ストック可能：JIRAのチケットは一度作れば管理者が削除しない限り残り続けるので漏れるということが起こりません。また過去に上がった要望もすぐに検索できるので、重複して上げることも避けやすくなっています。

②スピーディー：オンラインで24時間誰でもチケットを作ることが出来るので、顧客要望をミーティングが終わってその日中にあげるなどスピーディーな連携が可能です。不具合の報告もJIRAを使って行っており、迅速な対応が可能になっています。

③追跡可能：要望をあげた人が一番気になるのは「要望がどう処理されたか」ということに尽きると思います。実装されるのか、見送られたのか、別の形で検討されるのか。その点JIRAはアカウントを持っていれば自分のチケットのステータス（一旦見送り、仕様検討など）が変更されたりコメントが付いた場合に逐次通知が来るようになっているので、要望をあげる側もストレスなくあげることが出来ます。

プロダクト企画会議でさばかれたJIRAチケットの情報については、リアルタイムに伝わるようにSlackにもメンバー宛にメンションされるように運営されています（図の「共有」アイコン）。

以上が柱となるJIRAでの要望連携ですが、実はこれだけではプロダクト連携として不十分だなと感じたため、もう2つの階層も運営されています。


第1階層：MIX会（リアル）
MIXというのはMonthly Information eXchangeの略で、CSとプロダクトの月1回の情報交換会のことです。この会ではCSとプロダクトの有志メンバーが月に1度集まって、それぞれの情報をシェアしたりディスカッションしたりしています。CSからは主に顧客の情報、開発からは機能や仕様の情報、という感じですね。この会もプロダクトへの要望連携に活用されています。

というのもJIRAはあくまでオンラインでのコミュニケーションになるので、どうしても意図していることが上手く伝わらなかったり、その重要性を伝えきれなかったり、ということが発生していたのです。

そこでそういった状態を解消するために、プロダクトメンバーに要望をこのMIX会で直接面と向かって伝えています（現在もZoomで継続実施）。JIRAで既にチケット化した要望のうち、これは自分としても上手く伝えきれなかったな、というものを毎月ピックアップして、その要望が出てきた顧客の背景、その裏にあるストーリーをCSから説明しつつ質疑応答を実施する形です。

実際このMIX会でのやり取りで「顧客のやりたいことを勘違いしていたけどよく理解できた」「要望を詳細に理解できたのでもっと良い案を思いつけた」といった反応も生まれているので、オンラインだけでなく時にリアルで会話して伝えることも大切だと考えています。

チームが小さいうちは密にコミュニケーションすることも可能ですが、チームが大きくなると必然的にコミュニケーションパスが限定的になるので、こうやって月1などで強制的に仕組み的に機会を持つのは有効だと思っています。


第3階層：Slack（オンライン×フロー）
第1階層のリアル、第2階層のオンライン×ストックで要望をあげるという意味ではほぼほぼ網羅出来ているのですが、実は1つ抜け落ちている点がありました。それが「気軽に要望をつぶやきたい」というCS側のニーズです。

実はJIRAもMIX会も多少の準備が必要だったり時間がかかったりと、要望をあげるのにはハードルがあります。開発メンバーの顔が見えているならまだしも、例えば入社したばかりのメンバーだとそうも行かないのでどうしても手を出しづらい。でも顧客とは日々接するし、フレッシュな観点でプロダクトへの開発要望も思いつく…。

そういうCSの「気軽に要望をつぶやきたい」というあげる側のニーズに答えるために作ったのが「#顧客要望シェア」というSlackチャンネルです。ここには開発メンバーも入っていますがフォーマットは特になく自由に要望をつぶやくことが出来ます。ただし、JIRAと違って蓄積されないことや正式な要望ではないので、ここにあげられただけの情報は一切プロダクト企画会議では検討されないというルールになっています。

しかしここに情報をあげたことで開発とのディスカッションが盛り上がり「それJIRAに書いてよ！」という話になってJIRAにあがりスピーディに開発・実装に繋がったというケースもあります。またCS側のプロダクト連携機能でここの投稿は逐一チェックし、JIRAに上げたほうが良さそうと思ったものは積極的にメンバーに働きかけるなども行っています。

JIRAやMIX会は若干形式的なところがあるので、それを少し緩めた場も設定することで、要望自体の量が上がりやすいように工夫をしています。


以上の3階層を設けることで、漏れなく重複なく、しかし重要なものは丁寧に、かつライトなアイデアも拾えるように、と総力戦で要望を拾ってプロダクトチームに伝達する仕組みを作っています。

「要望・理由・手段」の3点セットで伝えるべし

もう1つ、弊社内でよくプロダクトチームから言われる内容がとても大切だと思っています。

画像2

それはプロタクトへの要望は「要望・理由・手段」の3点セットであげて欲しいというものです。プロダクトにはCSからだけでなく、様々な方面から色々な改善要望が寄せられています。プロダクトチームはそれらの改善が、一体誰の何を解決するものなのかを見極めながら実装するしないの判断を行っています。それを見極めるためには、この3点、なかでも要望と理由が大切になります。

プロダクトの改善は最終的には手段となって実装されます。しかし困っていることが1つだとしても改善する「手段」というのは複数存在します。プロダクトチームは常に全体のバランスを考えながら検討しているので「1つの改善でなるべく多くの要望やお困りごとを解消したい」と考えているのです。そのためにも何に困っているか、その改善がなされたら何がやりたいのか、という点が重要になってきます。

CSチームは顧客から「〇〇が出来るようにして欲しい」と直接言われる立場にあるので、どうしてもその顧客の要望を叶えたいという一心で「分かりました！帰ってプロダクトチームに連携しておきます！」とつい言いたくなってしまいます。

しかしそれだけでは、プロダクトチームは動きづらいし結果的に動けない。本当に顧客のサクセスに向き合うならば「貴重なご意見ありがとうございます。〇〇様の課題を解決するためにも、よろしければ背景やご課題感についてもう少し詳しくお伺いできないでしょうか」と突っ込んでヒアリングすべきなのです。

CSチームにそういった顧客要望の深堀り、ヒアリングを徹底することが、遠回りなようで実はプロダクト改善への近道になります。

CS・プロダクト連携5つの施策

ここまでで重要な点は書き終えているのですが、せっかくなので上述内容も含めCS・プロダクト連携のために実施している連携施策を、長期・中期・短期に分けてご紹介しようと思います。


①ロードマップ共有会（長期）
プロダクトがこれからのどのような方向性に進化していくかを定めているのがロードマップで、弊社の場合は1年半スパンでの計画になっています。ロードマップは四半期～半年に一度程度で見直しがされる仕組みになっているのですが、この見直しがなされ新しいロードマップが策定されたらその内容をプロダクトオーナーからCSにシェアすることになっていて、それがロードマップ共有会です。

CSは顧客と接する中でプロダクトが今後どのような方向性に進化する予定なのか、と問われることも少なくないので、今後の進化の方向性について理解していることは非常に重要になります。


②MIX会（中期）
上記で説明した施策ですが、月に1回、プロダクトとCSで情報交換の会を持っています。CSから顧客情報をシェアするだけでなく最新の開発状況、裏で活用している技術の紹介などを行っています。

様子などはこちらの社内記事をご覧ください。


③プロダクトユーザ調査（中期）
こちらは年に数回というレベルですが、プロダクトを高頻度で利用し使いこなしている顧客に弊社にお越しいただき、実際にどのように使っているのか、日々の業務でどう利用しているのかを80分程度のインタビューで見せていただくというものになります。

インタビューの様子は、プロダクトチームもリアルタイムで見学出来るようになっていて、顧客への質問もSlackを通してインタビュアーが実施するようなになっています。

顧客が実際にプロダクトをどう使っているかというのは、口で聞くことはあっても意外と目の辺りにすることは少ないのでCSにとっても貴重な場になります。いつも意外な利用方法が発見され、顧客の状況に即した気付きが多いのがユーザ調査の良いところです。


④新機能リリース共有会（短期）
新機能がリリースされる際には、リリース前後でプロダクトチームから、リリースされる新機能についての説明をしてもらうようにしています。新機能が生まれた背景、使用想定、詳細な仕様を1～1.5時間程度かけてCSメンバーに説明してもらいます。

もちろん仕様などは社内ドキュメントにまとまっているのですが、実際に使ってみての疑問なども多いので、こういった場で直接説明してもらうことで理解を深めています。


⑤新機能フィードバック会（短期）
リリースされた新機能を実際にCSメンバーで集まって使ってみて、こんなことに使えるのでないか、こういうシーンで役立つのではないか、といったことを話し合い、その結果をまとめてプロダクトチームにフィードバックする、ということもやっています。

CSは顧客と普段から接しているのでその顧客が使うとして…という想定で使ってみることで意外な発見や、もっとこうすれば良くなりそう、といったことに気づくことが多くあります。それらをプロダクトに早めにフィードバックすることで早期に改善に繋がることがあります。

因みにここのフィードバック会で出た新機能の使い方はその後まとめて、ブログの記事や、ウェビナーのコンテンツに活用したりしています。


明日から使えるCS・プロダクト連携のTIPS10選

最後に例によって（笑）1.5年ほどプロダクト連携をやっていて感じた細かなTIPSを記載しておこうと思います。1つでもお役に立てば幸いです。

■TIPS1：プロダクトのKPI（OKR）を知る
プロダクトにはプロダクトとして追いかけている目標があり、往々にしてそれはCSが追っている目標とは異なる角度で設定されているはずです。プロダクトの活動は基本的にそれをベースに構成されているし、会話の中でも「その機能実装したらどれくらいこのKPIに貢献すんの？」といった雰囲気は出るはずです。

そこで相手がチームとして目指しているものがわかれば、CSも機能提案の仕方が変えることが可能です。例えば「この機能を実装すれば顧客にこう役立てるし、それはこういう数値となって現れあなたのKPIにもこう寄与する。だから実装を検討して欲しい」と伝えれば、プロダクトチームとしても受け入れ方が異なります。相手のKPIや目標を知った上でコミュニケーションするのは協働する上での非常に有効です。

■TIPS2：開発の状況を知る
CSであれば「この前出した要望、検討すると言っていたのにまだ実装できないのか…？」みたいに感じることはあると思います。しかしちょっと待ってください。プロダクトはあなたが思うよりも複雑な裏側、データ基盤、そして処理ロジックを持って動いているのです。今開発上何がボトルネックで、何に取り掛かっているのか、それを知らずに自分の要望の行く末だけ気にしていてもストレスが貯まるだけです。

開発のぶっちゃけの状況や進捗を知るというのはそうした観点ではとても大切です。プロダクトの会議に出席してみる、関係性の近い人に状況を聞いてみる、上司伝いに聞いてみる、定例などでシェアしてもらう、色々やり方はあると思います。プロダクトの率直な状況・状態がわかれば顧客にも一段深い説明が可能になりますし、要望への対応にも納得がいきます。

■TIPS3：プロダクトの決めたお作法に則る
CS含めSalesやマーケなどのビジネス側ではとにかくスピード優先、顧客要望優先みたいな文化があり、時にルールを飛び越えて対応したほうが結果的に早い、吉と出るということが確かにあります。ただこの気配りや配慮をそのまま良かれと思ってプロダクトチームにも適応してしまうと、時にとてもプロダクトチームの生産性を落とすことがあります。

文化にもよるかもしれませんがプロダクトチームにとって例外対応というのが最も非効率的で排除したい対象になります。そういう前提で考えると通常の依頼フローや定まっていないルートでの機能要望提示などをすると、こちらとしては良かれと思ってやっていてもプロダクトにとっては非効率的・非生産的で結果的に対応が遅くなることもあるのです。効率的な対応を優先するならプロダクトの定めたお作法に則るべきでしょう。

■TIPS4：プロダクトチームの近くで仕事をする
ちょっとリモートワーク全盛の今は難しいかもしれませんが、何度かプロダクトチームの近くで作業したことがあるのですが、ただ近いだけで色々と話しかけてもらえたり「ちょっとこの画面案どう思う？」みたいな会話が確実に増えました。交流を増やすには物理的距離というのはすこぶる有効なので、使えるタイミングでは是非活用しましょう。

■TIPS5：顧客のストーリーを伝える
プロダクトチームは意外と「自分のプロダクトが顧客にどう役立っているのか、何に使われているのか」ということに肌感が持てなかったりします。もちろん導入や活用のインタビュー記事はありますが、やはりそれだけでは理解は深まらないものです。そこで大切なのは、顧客のストーリーを伝えることです。

導入事例でも機能要望でもいいのですが、それをただそのまま伝えるのではなく

・顧客のビジネス
・担当者のミッションと悩み
・導入前の課題
・導入のきっかけ
・導入時の反応
・現在の利用状況

といった順番でストーリー立てて伝えるだけで、伝わりやすさは何倍にもなります。もちろん全てを知っている必要はありませんが、少なくとも自分が知る範囲でのストーリーを思い描いて語ることは、顧客像を伝える上でとても有効です。

■TIPS6：ロイヤル顧客の声を伝える
CSは幅広い顧客に接します。使い始めたばかりの顧客もいれば、使いこなしている顧客も居る。ではその時誰の要望から優先して伝えるべきかということですが、これはロイヤル顧客、つまり製品をより使いこなしている顧客の声から優先的に伝えていくべきと考えています。

なぜならロイヤル顧客の方が、製品の価値を深く理解していて期待値がすり合っている可能性が高いからです。導入したばかりの場合は、まだ期待値が擦り合っていなかったりそもそもなかったりするので、そういう時はプロダクトが目指す方向と全く異なる要望になることもあります。そういった要望はもちろんシェアするのは良いのですが、プロダクトの向かう方向性を踏まえてフロンティアを開拓するという意味では、やや趣旨が異なる可能性があります（新市場を開拓するという意味では役立つケースもあります）。

■TIPS7：とにかく1次情報を
1.5年にわたってプロダクト連携活動をしていて1つだけはっきり分かったのは「人間は人から聞いた話よりも、自分の目や耳で見聞きした情報を信じる」ということです。これは合理性うんぬんではなく人間に根深く備わった本能の1つだと思っていて変えることは難しいと思います。

なのでそれを利用することが肝要です。とにかくプロダクトチームが1次情報に触れる機会を準備するべきなのです。100人の顧客の話を聞いて整理して伝える手間暇があれば、その時間で代わりに1人の顧客を呼んで来てプロダクトチームと直接会話してもらったほうが遥かに有益なのは間違いありません。ユーザ会でエンジニアが交流する、ユーザ調査で質問するなど、何でも良いので、とにかくフロントに立って会話してもらうことです。

テクニカルサポートをエンジニアが週替りで担当するなどの施策もよくお伺いしますが、まさにこの1次情報への接点拡大という意味で素晴らしい施策だと思います。

■TIPS8：要望は言葉だけでなく画面案に落として伝える
「要望・理由・手段」の3点セットで伝えようという話と若干矛盾しているかもしれませんが、なんだかんだ具体的な画面イメージレベルまでシェアをすると検討が早まるし具体化しやすいというのは事実だなと感じています。もちろん3点セットは伝えた上でですが、その上で手段を伝えるとした時に言葉だけでなく、書きなぐりでも良いので「こんなイメージ」というのを伝えるとプロダクト側でもイメージをしやすくなります。

それくらいCSとプロダクトが思い描く世界は離れているし、同じ画面を見ていても全く違うことを感じていたりします。手触り感のあるモノに落として議論をするというのは、そういうお互いのビューが異なるという世界観では非常に有効な手段です。

■TIPS9：上げた要望のステータスを可視化する（上げる側のモチベ維持）
JIRAの部分でご説明したとおり、上げた要望が追跡可能であるというのは、チームメンバーに要望をどんどん出してもらうためにも大切です。上げた要望がどう処理されたかブラックボックスでいつまでたってもプロダクトに反映されないという状態が続けば、人間はモチベーションを維持できず活動をやめてしまいます。いわゆるフィードバックの原則というやつです。

反映されているかどうかに関わらず、どう処理されたのか、その理由は何なのか、それらが納得感ある形で上げた本人に伝わる状態を担保しておかないと、いくら「要望をあげて」とメンバーに伝えても上がってこない状態になってしまいます。

■TIPS10：感謝を真っ先に伝える
プロダクトチームに顧客要望（＝不満）ばかり伝えて、顧客からの感謝の声は自分の心の中だけにしまっている、ということはありませんか？当たり前ですがプロダクトチームも人間です。働くためにはモチベーションが必要です。そして顧客からの感謝の声、新機能への反応といったものはプロダクトチームにとって大切な大切なガソリンなのです。

顧客からポジティブな声や反応があれば真っ先にプロダクトチームに伝えるようにしましょう。もし顧客からなくても自分自身で思ったポジティブなことでも感謝でも良いのです。人間はネガティブ・フィードバックだけでは稼働できません。感謝をまず伝える。要望の倍は感謝を伝える。それくらいの心持ちでいることが円滑に協働する上で大切です。

最後に

以上でCSとプロダクト連携をどうすべきかについての記事は終わりになります。冒頭でも記載しましたが、自分自身まだまだ改良せねばと思っていることが多いので、有効な取り組みがあれば是非シェアください。色々と議論させて頂ければと思っています。Twitterやっておりますので。

https://twitter.com/wataridori89102

また1万字超えてしまいましたが、お読みいただきましてありがとうございました。

この記事が気に入ったらサポートをしてみませんか？