カスタマーサクセスとプロダクトマネジメントとの連携 完全ガイド
カスタマーサクセスの方から、プロダクトマネジメント（もしくはプロダクト開発、プロダクト企画）とどう連携を取るべきか知りたい、そのためのノウハウを身につけたいという相談を多く頂いていました。
本記事では、プロダクトマネジメントの全体像や、プロダクトマネージャーの業務内容をお伝えしながら、そこから考えるべきCSとプロダクトの連携、CSからPMを目指すキャリアのヒントなどをお伝えします。
PR：カスタマーサクセスのデジタル化・テックタッチ化ならopenpageを導入しましょう！
「プロダクト開発」とはどんな業務を行うか？
まず、プロダクトマネジメントを学ぶうえで、直近とても秀逸だと学ばせて頂いたのは、こちらのオープンエイト様のスライドです。
もともとSaaSベンダーではなかったオープンエイト様が、SaaSの開発組織を立ち上げたときに、どのような変遷を辿っていったかわかる内容になっています。
「開発組織の変遷」では、フェーズ1〜4の組織段階があったと解説されています。ざっくり下記のような変遷です。
■SaaS製品の開発組織の変遷（藤島の解釈）
・フェーズ１はPM、QAがひどいので、そこを対策していく
・フェーズ２はPdM、PjMの体制をちゃんと作る（プロダクト企画、プロジェクト管理）
・フェーズ３は組織拡大して機能で出来ることをどんどん増やす（スピード優先）
・フェーズ４は新規開発と品質改善を両輪で回す
私も自身でSaaS製品「openpage」のプロダクトマネジメントを行っているためイメージがわくのですが、SaaSの製品開発は「新機能開発」と「品質改善」の繰り返しです。
カスタマーサクセスも知るべきプロダクト開発における新機能開発とQA（品質保証）
私が開発チームの取り組み内容を見る限り、下記いずれかにリソースを投下しています。
新機能開発に関しては、下記のnoteで以前まとめた通り、「セールス」と「カスタマーサクセス」は相反することもあり、そのバランスを取りながら製品に機能を付け加えていきます。
また、こちらのスライドにもある通り、特にSaaSの初期フェーズであるほどバグが多く、品質改善（QA：プロダクトの品質保証）のための開発が多く発生します。
最初は要件も甘い状態で開発を進めるため、バグだけでなく、UI/UXの不備も散見されるため、複数にわたるUX改善のための開発も必要です。
カスタマーサクセスにおいてQA業務を兼務したら捗った、という話をLaryerXのかじさんが記事にして話題になりました。
また、「リファクタリング」とはプロダクトの見た目を変えず、中身のソースコードを整理することで、この作業がビジネス側の人からすると開発のよくわからない側面になりがちです。
こちらのMobility Technologies様の登壇資料が詳しいのですが、リファクタリングを正しく行わなければ、新機能開発ができない、開発スピードが遅くなる、バグが大量発生する、といった負のスパイラルが起きます。
まとめると、セールスとカスタマーサクセスのバランスを見つつ新機能を付け加えながら、QAやリファクタリングを適切に行い、製品をスケールさせていくことがプロダクト開発の業務となります。
「プロダクト開発のサイクル」から考えるカスタマーサクセス連携
これまで説明した、新機能開発やQAをどのようなプロセスで行っているのか。これもオープンエイト様のスライドで紹介された工程がわかりやすいです。
スライドでは、「FSの失注理由、CSの機能要望、事業戦略、プロダクト方針をかけ合わせて実装すべき機能を決定し、開発ロードマップを策定」と書かれています。
プロダクト開発の方向性は、一般的にはCEO/COO/CPO/PdM/PMM/POといった役職の方が事業戦略とともに決めていくのですが、その参考情報としてフィールドセールスの方の声やカスタマーサクセスからの要望が非常に重要となります。
カスタマーサクセスが連携として行うべきは、プロダクトの舵取りにあたって重要な顧客の声を経営の意思決定現場に届けてあげること。
これについても、LaryerXのかじさんの記事が素晴らしいです。この記事にあるZapierの連携までは出来なくても、SlackやスプレッドシートにVoCを貯めて、開発の参考にする仕組み作りをするなどは、カスタマーサクセスも積極的に協力するべきです。
とっても大変で重要な製品開発の「QA」をカスタマーサクセスが連携し助ける
またQAについては、こちらもオープンエイト様のスライドに戻ると、「顧客問い合わせや社内発覚からプロダクトの品質不備に気づき、QAに連携するフロー」を取っているのがわかります。
顧客から最も問い合わせをよく受け、プロダクトを日頃触る組織はカスタマーサクセス/カスタマーサポートの部署が中心となるため、QAとの連携は必須です。
ちなみに、開発チーム側でのQAはどのようなことを行っているか。
これも探したらLaryerXのかじさんの記事がヒットし、LaryerX・かじさんどちらもすごいな・・・と思いました。笑
もともとは、「2日間で900項目を手動テスト」していたらしく、下記のようなスプレッドシートにまとめたテスト項目にそって、不具合が起きていないかチェックしていたようです。
さすがに手動は・・・しんどすぎますので、テスト自動化プラットフォームの「Autify」を導入し、一部のテストから自動化し、自動化できる項目を増やしたようです。
このQA作業は、機能が多ければ多いほど発生し、どんなにやっても気づけないバグ・不具合は発生するもの。カスタマーサクセスが行うべきは開発側のQAで漏れてしまったバグの報告です。
QAを優先するか、新機能開発を優先するか。カスタマーサクセスが支えよう。
オープンエイト様スライドの「開発組織変遷」のフェーズ３に話を戻すと、「機能は出した！CSフォロー頼む。」とコメントが入ってます。
これはどういう意味かというと、「品質が低かったりするかもしれないけど、出来る状態にはなんとか機能は作ったので、足りない部分は、バグ報告も聞くけど人的サポートで何とか頑張ってくれ頼む・・・！」みたいなニュアンスだと捉えています。
ここで言うフェーズ３は、ベンチャー経営で言えば「シリーズB～C」あたりのSaaSですが、資金調達した資金を用いてどんどん顧客数を拡張していくフェーズなので、品質を多少犠牲にしてでも新機能を増やしていく、という意思決定を（表には当然出せませんが）していたりします。
その場合のフォローアップはカスタマーサクセスチームにかかっており、これを認識しているかどうかは現場の士気に影響するので頭に入れておくべきです。
カスタマーサクセスが知っておきたいプロダクトマネジメント製品
観点を変え、このプロダクトマネジメントの業務を専門ツールを使って整理する方法がわかると、よりプロダクト開発を理解することが出来ます。
海外で最も有名なツールはproductboardという製品で、日本ではFlyleという製品が代表的なツールです。（Flyleは私と同じビズリーチ出身者が経営しているため陰ながら応援しています。）
これらのツールについている機能が、まさにこれまで説明していた「顧客要望」の管理と、そこから「ロードマップ」を作成する機能です。
プロダクト開発の基本的な流れは、「①顧客要望→②ロードマップ→③githubへ連携（開発のかんばん管理）→④2週間置きなどのスプリントで開発→⑤QA（品質チェック）→⑥ローンチ」という流れです。
プロダクト開発をする方は、顧客要望からどの機能を優先的に開発するべきかを考え、そこからロードマップを敷いて、実際の開発要件をエンジニアに渡すことで開発を進めてます。
こちらはFlyleの説明動画ですが、なんとなく、顧客フィードバックを管理して、そこから要件やロードマップを作ろうとしてるんだな、というのがわかると思います。
またこのURLからproductboardのロードマップ機能のデモを触ることが出来るのですが、いつまでの期間に何を開発するのか、英語ベースですが整理されていることはわかるはずです。
このロードマップを、事業戦略や顧客の声をもとに作り、自社の事業成功ならびに顧客のカスタマーサクセスに繋げられるかがプロダクトマネージャーの腕の見せどころとなります。
また、ロードマップをより会社として自信あるものに仕上げるため、顧客の声を届けることこそカスタマーサクセスの仕事です。
カスタマーサクセスを起点に開発の優先度をつける
本当、秀逸な内容だな・・・と思い、またオープンエイト様のスライドを引用してしまったのですが、このスライドが面白いな、と思ったのは、先ほどの開発ロードマップを敷いたり、何の機能を作るべきかを考えるうえで「カスタマーサクセスの指標」と第一に置いている点です。
スライドにある通り、開発要望の登録をする場合は、カスタマーサクセスがこれを開発しないと「解約」「顧客満足」のリスクがどれだけ上がるのかの肌感覚を持ったうえで登録するような仕組みにしています。
また、中長期的な開発ロードマップに入れる際の指標を、チャーンレートとヘルススコアに置いている点も特徴的です。
弊社openpageの株主であるITVの中野代表は、「SaaSビジネスにおいてはチャーンレートがすべて。あらゆるSaaSの指標はチャーンレートが崩れてしまうと崩壊してしまう。よってプロダクトとカスタマーサクセスの注力が非常に重要である」とよく私に経営アドバイスとして頂いています。
VCの目線からも、SaaSビジネスにおける重要指標はチャーンレートであり、プロダクト開発の意思決定がチャーンレートに基づいて行われる、そのためカスタマーサクセスがプロダクト開発と連携を取る、というのは自然であり、むしろ必然なのではないでしょうか。
まとめ：もっとプロダクトマネジメントを追求したいカスタマーサクセスへ
本記事の内容から、
「顧客要望の収集」
「ロードマップへの意見出し」
「QAへの協力」
などへカスタマーサクセスが連携していく重要性と、そのやり方についても少しイメージを沸かすことが出来たのではないかと思います。
顧客要望管理、ロードマップ、QAなどのそれぞれの項目は、具体的なノウハウについては1つの記事では語りきれない内容ですので、もっと追求していきたい方や、カスタマーサクセスからプロダクトマネジメントを兼務することになった方などへ向けて、参考図書をいくつか掲載します。
顧客要望のヒアリングの進め方がストーリー形式でわかるようになっています。
ロードマップの理解を一層深めるのにおすすめです。
新機能をいたずらに開発してしまい、本来の価値がなおざりになってしまう「ビルドトラップ」を避け、どのように的確にプロダクトマネジメントを行っていくか解説されています。
プロダクト開発を進めるうえでの指標設計や、新機能の開発を進めるうえでのスコアリングの考え方などに触れています。
ロードマップ作成後は、開発チームと連携しながらスプリントのリズムでスクラム開発を進めていくのですが、その進め方についてわかりやすく説明しています。
Googleにおけるテストの考え方を丁寧にまとめあげており、プロダクトQAについて深く学ぶことが出来ます。
おわりに
お読みいただきありがとうございました。
もしよろしければ、記事のシェア・Twitterのフォローをお願いします。
※数社限定で、弊社テックタッチ製品のカスタマーサクセスクラウド「openpage」のトライアルを提供しております。ご興味がある方は製品フォームないしTwitterよりお問い合わせください。
藤島 誓也：Twitterアカウント
https://twitter.com/seiya_fujishima