SaaSビジネスの組織をデザインしていくために、「The Model」の考え方を中心に据えるのが正攻法となってきました。ところが、部署ごとに分かれてKPIを追いかける状態において、各部門がお互いを理解し合えなければ、有機的な連携はありえません。
SaaS専門に支援をするALL STAR SAAS FUNDも、投資先の企業と日々ディスカッションする中で、この「部門間連携」についての課題をよく耳にするようになりました。「ビジネスモデルに矛盾が少なく、美しいSaaS」を志向するうえでも、部門間連携においても、よりよいあり方を考えるのは大切なことだと考えます。
そこで、SaaSのセールス、イネーブルメント、カスタマーサクセス、組織・経営のスペシャリストたちを擁するALL STAR SAAS FUND公式メンターのみなさんにご協力いただき、この「部門間連携」をテーマに語っていただくシリーズ連載の機会を設けました。
第1回は向井俊介さん×山田ひさのりさんによる「セールスとCS」の連携、第2回は戸栗頌平さん×山田ひさのりさんの「マーケとCS」の連携を考えました。
そして、第3回は「CSとプロダクト」がテーマ。CS側からは引き続き、Sansanでカスタマーサクセス部のDXと既存顧客へのマーケティング強化を推進し、同部門の戦略立案・実行サポートを行う傍ら、IT企業へのカスタマーサクセスアドバイザリーに従事する山田ひさのりさんが登場。
プロダクトの立場からは、2019年にfreeeへ入社し、新規事業とfreee会計のコア機能のプロダクトマネジメントを統括し、2021年1月よりVP of Product Managementを務める宮田善孝さんを招きました。
お互いの考え方を明かす中で見えてきた、よりよい連携の理想像を、探っていきましょう。
プロダクト＆CSから見る、toCとtoBの決定的な違いとは？
山田：僕らは、toCからtoBへ移った経歴が共通していますね。toCって、どうしてもプロダクトがキングオブキングなのですが（笑）、toBだとビジネスサイドといかに良好な関係を保ったり、巻き込んだりしていけるかが鍵になってきます。宮田さんはマインドチェンジ、うまくできましたか？
宮田：僕が最初にプロダクトとビジネスが両輪であることをまざまざと思い知らされた瞬間があって、それはユーザーからのフィードバックを得るときです。toCなら問い合わせ履歴やアクセスログを分析して集計すれば、何となくユーザーの動向が見えますし、それで十分です。
でも、toBでSaaSを扱うようになって最も違うと感じたのは、それをセールスやCSの方々から生の声で聞くことがプロダクト開発の基点になることです。そのときから思想をガラッと変えて、プロダクトとビジネスサイドが両輪であり、しかもCSというユーザーと最も接する部門と、いかに協同できるかが、プロダクトを成功させる鍵の一つだと思いました。
山田：やっぱりそうなんですね。それはビジネスサイドとしては「頼られている感」があってうれしい（笑）。もっとも、私もそう思います。toBはそもそもお客さまが気づいてないようなイシューを、営業やCS経由で感じ取ることができますから。
宮田：その背景には、toCでデータ分析をしていたときは、ユーザーのペルソナがある程度共通化しているといいますか。分析し、集計すればユーザー像を把握できると思うのですが、toBの場合は業務プロセスが個社ごとに違うし、そこを理解しないとプロダクトがどのように使われるのかも異なります。お客さまの「真の課題」を見るためにも、実際に対面でユーザーと会った経験や、そこから出てきたインサイトが重要だなと思えてますね。
山田：お客さまの社内の部門間に働く力関係を捉えないと、サービスや機能が広がらなかったり、使われなかったりすることも意外とあるじゃないですか。
宮田：ありますね。
山田：それもtoCとtoBの決定的な違いだと思って、強く印象に残っています。
宮田：まったくです。少し言い方を変えると、SaaSはバイヤーとエンドユーザーが違うケースが多いんですよね。なので、買う人は「良い」と導入してくれたけれど、エンドユーザー側にもしっかり価値を届けないと、使い続けてもらえなかったりする。そこはSaaSの難しさでもあり、また醍醐味でもあったりするのかなと。
山田：いやぁ、わかりますね。ちょっと今日は聞きたいことがたくさんありますし、ときには詰問のような話もしてしまうかもしれないのですが、よろしくお願いします。
宮田：ええ、ぜひぜひ。
CSとPdMが対立構造になりやすい理由
山田：セールスとCSは「顧客の代弁者」だと思っています。そういう人から見ると、担当しているお客さまが言ってくれたことが、なかなかプロダクトに反映されないことに、やきもきするものです。お客さまの声が重要だとは認識していても、プロダクト側がどういった優先順位でそれを反映していくかが見えないことも多いように感じます。
Backlogなどを見れば優先順位や結果はわかるのですが、「なぜこの順位に至ったのか」にビジネスサイドとしては、もやもやするんですね。そのあたり、宮田さんはどういった考えをお持ちですか。
宮田：僕がfreeeで実践していることとしては、そもそもの初期は残念ながらドメイン知識に乏しかったので、ユーザーのフィードバックを直接受けていかないといけないと思っていました。ただ、その数を担保しようとすると、すべて自分で聞きに行っているとスケールしないので、CSやセールスにご協力いただいて、インサイトをまとめてもらい、咀嚼していくやり方をしていました。
自分でセールスに同行したり、導入支援の現場に行ったりするのも重要です。なぜなら、実際に話を聞くと、聞いていないことにまでイメージが膨らむからです。そのイメージこそ重要だと僕は思っていて、個別のプロダクトを担当していたときはよくやっていました。
もう一つ、CSやセールスとPdMが対立構造になりやすい理由は、いくつか挙げられます。主に次の2点が、プロダクトと向き合っていて僕がよく見るケースですね。
まずは「すでにドメインを習熟している人がPdMを務めるケース」です。特にプロダクトをローンチする前後は、PdMは直感を信じやすい気がするんです。そこで一度は「直感が当たらない」という認識を持って、初めてCSやセールスからインサイトを受け始めるようになります。プロダクトの初期ほど、一般論として協業しにくい状況ができてしまいがちですね。
もう一つのパターンとして、グロースフェーズになると、ユーザー数がスケールしても、PdMの数はスケールしないじゃないですか（笑）。
山田：確かにそうですね（笑）。
宮田：そうすると、フィードバックは受けたくても、CSやセールスからの要望や、場合によっては障害情報を見きれない瞬間が絶対きます。そうなると、CSやセールスからすれば「要望を見てくれない」となるし、プロダクトサイドからすると「こんな量の要素は見きれない」となって、ひずみが起きてきてしまうのです。
山田：ちょっと深ぼっていきたいんですけど、PdMにとって、そもそもCSの意見ってありがたいものなんでしょうか？
というのも、CSやセールスの言うことを全部聞いてもよくないだろう、と感じることもあって。時にはお客さまが憑依していることもありますし（笑）、お客様の課題をどうにか解決したくて独自の解釈や説明をしている場合もあるでしょうから。プロダクト側としても「ここまでは聞いてもよい」といった線引きをしているように感じています。
宮田：具体的な例でいくと、CSやセールスから上がってくる要望については、「リソースの2割ぐらいで対応します」とアッパーを決めてしまうやり方があります。
他にも、CSやセールスは実際に会っているからこそだと思うのですが、ある特定のユーザーからしか聞かれない意見を「要望」として上げてしまうケースも結構あるはずです。PdMの目線からすると、個社対応はSaaSという座組ではどうしても対応しにくいですから、一歩引いた目で「この要望は他のユーザーにもスケールするのか？」を考えてみてから、改善対象にするのか、個社案件の参考情報に留めるのかを選ぶことが多いように思います。
開発の優先度はMRR以外でも測れる
山田：そこでちょっと難しいかなと思うのが、私が経験したことでは、「ユーザーや自分たちの利益になる」と証明しようとした場合、その指標がどうしても売上になってしまうことです。「MRRが大きいお客さまを助けられる」とか、「新規顧客を獲得できるオポチュニティが増える」みたいな考え方になりがちで。「よりユースフルになる」という観点だと、意外と説明しにくいんです。
プロダクト側で「ユースフルさの改善」を測れる基準は、あるのでしょうか？
宮田：非常に難しい論点で、僕もまだ解にたどり着いてはいません。僕らの中でも、特に「freee会計」といった大きなプロダクトについては、「あるべき品質とは何なのか」という議論を何回もして、実際に迷いながらもOKRなどに踏み込んで追ってはいます。具体例だと、競合他社を取り出してベンチマークすることが多いですね。
山田：Podcastでもおっしゃっていましたよね。「競合は重要な要素の一つ」だって。
宮田：はい。「あるべき品質」を考えると、同じような業界やテーマに対してプロダクトを提供している方々がいらっしゃるのであれば、それと比肩して遜色ないレベル感にまでUXやユーザビリティを機能拡張していく目標を掲げているチームもあります。
もうひとつ、概念的な話にはなってしまいますが、施策から直接的なビジネスインパクトにつなげてしまうと、山田さんがおっしゃったように、どうしても目の前のARRや新規獲得に行き着いてしまうので、その間に「ジョイント」を持たせるようにしています。
「機能拡張したおかげで、ユーザーへどんな価値が生まれるのか」と「その価値がどういうビジネスインパクトにつながるのか」というように考えています。直接的な利益につながることだけではなく、中長期的にユーザー価値を考え、提供すべき価値を言語化してから、それがビジネスインパクトにつながるのかというように進めていきます。
このやり方だと「今後はそもそもユーザー価値がないのにやるべきか」といった議論が出にくくなるストッパーとして役立ってくれるんです。
山田：重要な話ですね。CSとも通じるところがあって、僕はビビビッ！と来ました（笑）。CSも最終的にはお客さまの事業利益につながり、それが自分たちの事業利益をもたらすように働きかけないといけないのですが、その過程でユーザー価値が生まれ、長いスパンで利益を生み出していくということもよくあります。利益ばかりを追求してしまうと、そのあたりを見失いがちで。
宮田：そこですね。どうしてもビジネスサイドの方々にはノルマがあったりするので、ビジネス側に直結させるインセンティブがあると思うんです。一歩踏みとどまると、同じ方向を見ていけるはず。そこをお互いに擦り合せられれば良いチームになる気がしています。
山田：そこの究明が、SaaSにとっても意義は深そうですよね。
優先順位づけは各ファンクションが関与するとうまくいく
山田：先ほど聞きそびれたので伺いたいのですが、Backlogの優先的なポリシーを共有したり、説明したりって、そもそも必要だと思われます？
宮田：いや、これは「したほうがいい」と思っています。何なら一緒に優先度を考えるぐらいでもいい。
僕は「freeeプロジェクト管理」という新規プロダクトを担当していたのですが、その際はスコアカードみたいなものを作っていました。施策リストはユーザーフィードバックやプロダクトビジョンからもいろいろ出てくるじゃないですか。その優先順位づけがポイントになるわけですが、個々のプロダクトで達成したいことは、いろいろ出てくると思うんです。
大きな5つの判断基準としては、下記が挙げられます。
- プロダクトビジョンとの整合性
- 開発ボリュームの多寡
- MQLの増加
- 受注率の向上
- チャーンレートの減少
これら5つには、それぞれで対応する人がいます。プロダクトビジョンならPdMですし、開発ボリュームはエンジニア、MQLはマーケター、受注率はセールス、チャーンレートはCSですね。
そして、リストからそれぞれに施策を相対評価してもらうんです。
山田：それはすばらしいですね！
宮田：たとえば、「1点から10点で、何かしらを基準にして点数をつけてください」とお願いしてみる。それを総合点でソートすると、みんな納得感が持てる優先順位になります。
もちろん手法としては、このフェーズだとプロダクトビジョンに寄せたい、開発生産性を上げたいといった考えがあると思います。その場合は、それぞれの項目に対して重みづけをするといいでしょう。そうならば、それぞれのファンクションが意思を持って優先順位づけに関与できるじゃないですか。
出てきたものに対して自分の目線で議論できるし、みんながそれを見ながら議論していく土台になっていく。最終的にはPdMが決めますが、みんなの共通認識が持てていると納得感や安心感も醸成できるので、良い手法の一つだと考えています。
もちろんフェーズが違うプロダクトによっては、PdMがある程度は決めきらないといけないでしょうから、ケースバイケースではあります。ただ、僕自身は好きなやり方ですね。
山田：点数をつける人は役職が高い方なんですか？人選も大切そうだな、と。
宮田：僕は各ファンクションのリーダーにお願いしていました。あるプロダクトにおいて、それぞれのファンクションのマネージャー陣に集まっていただき、評価をもらうかたちです。やはりリーダー格に出ていただくと、担当ファンクションのこと、ユーザーからのフィードバック、プロダクトビジョンとの関係性といった点を網羅的に評価できるので、スムーズに議論が進むことが多いです。
山田：いや、すごいイノベーションじゃないですか、この方法！
宮田：アドバイザーで関わる先でも迷われる方が多くて、この方法を中心に伝えることが多いのですが、実際にウケもいいです。
山田：秘伝のタレみたいですよね。
宮田：はい（笑）。数値化されスコア化されているので、リーダーからメンバーに伝える際のコミュニケーションも楽になるというメリットもあります。
「やっぱり俺の目に狂いはなかった」と言いたい心理
宮田：逆に、CSの目線に立ったときに、どういう優先順位づけがなされていると納得感ありますか？
山田：CSの目線は半年や1年先を見ていることが多いので、中長期的に勝つ全体設計がなされているほうが、お客さまをエンゲージしやすいかなと。要は、短期と長期と分けてあるといいですね。
短期では「このボタンを押し間違えてしまう」「設定が奥深くにあって使いにくい」みたいな話は、できればスムーズに直してほしいところ。そういった部分と、長期的なロードマップを混ぜないでほしいのは第一です。混ぜてしまうと、キューの待ち行列に長期の部分が先に追加されてしまい、短期のものが後ろに追いやられがちで、お客さまと向き合うCSとしては不満になりますね。
あとは、CSとしても半期や年間ベースでお客さまとコミュニケーションを取る以上、プロダクトの成長を案内できたほうがよいので、将来性を感じさせるような機能開発のラインが引かれていると嬉しいですね。実は良いお客さまほど「今」ではなく「先」を見る傾向にあると感じています。
特にスタートアップのアーリーフェーズにあるプロダクトは、「競合も検討したけれど営業や社長さんの姿勢を見て」といった期待感で買ってくれることもある。1年後や2年後を説明できて、プロダクトビジョンが広がっていくような開発のラインを引いてくれると、CSとしても自社を「期待できる会社」だと伝えられます。つまり、長期的に夢を見させるようなラインを引いてほしいわけです。
宮田：なるほど。お話を伺っていると、僕らって結構スモールビジネス向けなので、CSMと一口に言っても、初期の導入支援に重きがあったりするんですね。山田さんのお話からするに、ユーザーと伴走してプロダクトもよくなるし、ユーザーへ価値も提供していくというリードタイム自体がとても長い印象を受けました。
ユーザーとCSが長期間で接していく中で注意すべきポイントや、ユーザーと接するうえで要望の変遷や変化を感じるところはありますか？
山田：それは明確で、アーリーフェーズはファン作りが大切ですが、それにつながるポイントとして、お客さまはプロダクトを買うときに「やっぱり俺の目に狂いはなかった」と半年や1年後に言いたいものなんです（笑）。つまり、ARR50億円くらいまでは、それを「言わせること」がファン作りにもプロダクトの後押しにも実は大事です。
それからレイトマジョリティあたりが入ってくるフェーズだと、「今」の完成度が求められてきます。お客さまにしても業務クオリティをどれだけ担保し、いろんなところから文句が出ないようにする思考になりますから。
レイトステージほど大企業出身者がマッチする
宮田：アーリーとグロース、もしくはレイトとステージが移ると、CSに求められるスキルセットも大きく変わりそうな気がしますが、どうなんでしょう？
山田：変わります。アーリーステージのCSはお客さまと共にプロダクトを作っていく感じなので、むしろ「切り込み力」みたいなものが重要です。
それがレイトになるほど、お客さまもエンタープライズが多くなってきますし、信頼感で買う方が増えていくので、ステークホルダーも複雑になります。レイトステージでは、ある意味でプロジェクトマネジメントの力量も問われます。お客さまへの説明や段取りといった、ビジネスとしての遂行能力ですね。レイトほど大企業出身者がマッチしていきます。
宮田：確かにその感覚、僕もありますね。新規プロダクトを作っていると、ユーザーインサイトをどれだけ取れるかに、プロダクトが成功するかどうかも左右されます。CSの方がどれだけユーザーに入り込んで深いインサイトを持って帰ってきてくださるかが大切で、僕らとしてもそういう人と一緒に仕事をすると楽しいものです。
ただ、レイトステージになってくると、僕自身が具体的なプロダクトを持ってCSの方と対峙したことはないのですが、プロダクトとCSは機能分化していって、それぞれでしっかりかっちりと進められるようになっていく必要がある気がします。
山田：レイトになっていくほどプロダクトは組織の仕組みとしてカバーしていく話になりやすいので、PdMやPMMが肝心になるのでしょう。
PMMでパフォーマンスが出せる人の共通点
宮田：アーリーステージにおけるCSとPdMの協業は「チーム一丸感」を作りやすいですし、先ほど僕が申し上げた「優先順位づけ」も一緒にできたりしますよね。でも、ある程度の規模の組織になったとき、CSとPdMの関係はどうあるべきなんでしょう？
山田：それは私もよく考えます。一つあるのは、PdMとPMMが生まれたことの大きさです。特にPMMは「確かにその機能は必要だ」と強く思いましたし、お客さまへのデリバリーが課題だったのに、その役割を担う人がいないことに改めて気づかされたというか。
「役割の細分化」という言葉が適するかはさておき、抜けていることに着眼して、ロールかフローを構築するトライをしてみるのが良いのではないかと思います。おそらく過去にはPMMという言葉ができる前から「PMM的な」仕事をする人は居て、いまはそれが認知されたから、よりワークするようになったという話なのかなと。
宮田：僕も3年前にSaaSの世界へ飛び込んだときに、The ModelなどSaaS周りの文献を読んで、あそこまでかっちりとオペレーションを組もうとすると大変だろうと思ったんです。理想的な姿はあれど、ビジネスサイドの全体感を見て足りないところを補強したり、場合によってはThe Model自体をカスタマイズしたりする発想を持った方々がいらっしゃると、組織の構築においてのスピード感が増すのだろうと思います。
僕がfreeeに入社した3年前くらいのタイミングでPMMができて、今だと5〜10人ほどいますが、それぞれで特殊能力が違います。プロダクトを使い込んで提案資料に落とし込むのが上手な人、プロダクトをローンチのタイミングで圧倒的なプロジェクトマネジメント能力を発揮する人など、山田さんがおっしゃったとおり、「微妙な間隙」を埋めてくださる方々が集まっているんです。
山田：PMMについて絡めて話すと、お客さまへのデリバリーという観点で考えると、PMMはビジネスサイドの出身者がいいんじゃないかと思っています。CSと噛み合うところはありますが、一方でタレンティッドなロールだなとも感じていて。
事例を見ていても、「好奇心が強い」というのが共通で必要だとしても、それ以外はいろんなバックグラウンドがあっていいのでしょう。宮田さんが今まで出会われた人も含めて、「PMMに合う人」にはどういう要素があると思いますか？
宮田：山田さんがおっしゃることには頷きつつも、僕個人としては、PMMの「プロダクトマーケティングマネジャー」という名称は、実際に手掛けていることがあまり合っていないような気もしています。実際にはビジネス全体のデベロップメントに近いのでは、と。
総論としては、広くビジネスのファンクションを経験したことがある方が最もフィットしやすいのではないでしょうか。特定のファンクションに特化しているよりも、俯瞰してものごとを見られたり、課題に入り込んで2週間や1ヶ月で成果を出せたりするような、コミットメントやスキルセットが求められている気がします。
毛色で近いものといえばコンサル出身者や経営企画などの企画職。そして、実際の推進をハンズオンで良くしたいという意欲が強い方がチャレンジすると面白いそうです。
山田：その感覚はすごくわかって、「首を突っ込みたがる人」が似合っていると思うんですよ（笑）。だけど、それだけではだめで。俯瞰できる能力や経験、そして現場へ行くのが好きという指向性ですね。PMMでパフォーマンスが出せる人の共通点だなって思うんです。
宮田：そうですね。整理してプレゼンするだけでは物足りず、書いたもので実際に変えたいとか、変わっていく瞬間を楽しめる人であれば、フィットしそうです。
大事だけれど悩ましい、ROIという指標
山田：話題は変わるのですが、ROIについても話してみたくて。
ROIと向き合う場面はSaaSでも多くあります。お客さまから求められるケースもあれば、営業トークとして必要なものもある。ROIに関して私も試行錯誤していますが、結局のところは「プロダクト価値とROIの関連性を突き止めるのがCSの役目だ」と思ったんです。
サクセスのユースケースなどを集め、ビジネスにおいて上昇、あるいは改善できた数値を突き止め、それを抽象化して、ビジネス的な価値に言語化していく。そして、最終的なアウトカムに対しての成果を説明できるようにするのが、CSの役割ではないかと。
プロダクト側も最終的にその価値を説明するのに、ROIに対する課題感があるのではないでしょうか？それを、どれくらいの強さで感じていて、突き止める意識を自分たちの責務として持っているのか。この点、宮田さんはどうお考えですか。
宮田：そこはグラデーションがある話かな、と思いました。プロダクトや事業全体が置かれているフェーズによっても変わるでしょうから。
プロダクト自体をよくしていきたいフェーズの場合は、山田さんおっしゃってくださったとおり、最終的なアウトカムの一歩手前を考えます。たとえば、使用機能の利用率などで判断するPMFの達成にキーリザルトを設置し、そこをビジネスとプロダクトサイドで高めていく場合です。
片や、グロースフェーズになってくると、明確なビジネスインパクトが求められ始めると思います。もう一歩踏み込んで、ユーザー価値は重要だし、避けては通れないけれども、その上でどういったビジネスインパクトにつながるのかまで、一連の流れでOKRを組めると、それぞれのファンクションのROIが見えやすくなってくるはず。より成果につなげられる目標設計になってくるのではないか、と思います。
山田：でも、そのマインドスイッチの切り替えって、意外と気づかないこともあるのかなと（笑）。僕も振り返ってみると、確かに「あそこで変えておけばよかった」と感じる場面もあるにはあるんです。きれいに切り替えられます？
宮田：いや、これは難しいですよ。どちらかというとトップマネジメントや経営レイヤーの意思決定事項の一つだと捉えています。なぜかというと、プロダクトをよくしていこうって、PdMがある程度はリーダーシップを取ったりもするじゃないですか。
でも、グロースしていこうってなったら、セールスとかCSMとかのビジネスサイドがリーダーシップを取っていくことになるものです。当人たちでそれをしようと思うと、自らリーダーシップを譲るとか、逆に引き取るようなことを主張しないといけません。
現場で対等な関係でそれができる方々は稀有でしょうから。状況を見て、もう一段上の方々が決めていくことが必要ではないかと。
山田：確かにそうですよね。泳いでいる本人は必死で、どこの海を泳いでいるかまではなかなか見渡せない。
宮田：こんなふうに言うと、「いやいや、もっと現場でやれんだろ」と思ったりもされそうですけれど、なかなかその意識を上げるのは難しいイシューの一つですよ。
ただ、サイクルはあると思うんですよね。プロダクトをよくするフェーズと、ちゃんとビジネスまでコミットしていくフェーズ。それが波になっているところから「今どこにいるのか」は考えるべきだとは思いますね、意思決定はできないまでにしても。
PMFの「一般的なサクセスの定義」は無い
山田：ありがとうございます。以前に、このALL STAR SAAS FUNDさんのメディアで「ライトサクセス／ディープサクセス」という考え方をまとめた記事を出したんです。
サクセスは実は2種類で、一つは現場が喜ぶライトサクセスと、もう一つは経営が喜ぶディープサクセスとがある。プロダクトを考えるときは、どちらかといえばディープサクセスを意識していくものですが、ライトサクセスを後押しする開発をしていかないと、プロダクト自身が支持されない期間が長くなり、セールスやCSがきついときが意外とある。
特に定着まで年数のかかるプロダクトはなおさらです。なぜなら、現場の支持を得るための機能開発は、プロダクトビジョンからすると枝葉に思われるから（笑）。相反するようなものにも感じますが、このあたりシームレスに両立させるためには、どのように考えればよいのでしょう？
宮田：山田さんのおっしゃってくださったフレームワークに則ると、経営層に刺さるべきものといえど、現場で意思決定する補助ツールになるといった、何かしらの意思決定につながらない限りは、ディープサクセスは勝ち得ないはずです。
けれど、それをやろうとすると、現場から上がってくる情報やデータを集めないといけないですから、その観点でライトサクセスが前提になってくる。では、ライトサクセスにまずはしっかり取り組めばいいのかというと、ここも一つの論点がありますね。
つまり、現場の方が使いやすいかどうかは、バイヤーとエンドユーザーが異なるので、意外と意思決定に直結しないケースも多かったりするじゃないですか。
山田：そうなんですよ……。
宮田：この論点は大きいですね。プロダクトリリース当初、売れないことには始まらないので、ライトサクセスする「さらに前段階」があるのかなと。それで、アーリーアダプターが将来性を見て一定数が買ってもらえたりする状態が作れて、リリース後の1年くらいはライトサクセス寄りでもいいと思うのですが、そこからはディープサクセスとバランス取りながら、プロダクトの価値の幅を広げていく必要があるだろうと感じます。
山田：確かに最初は「売れなきゃ始まらない」っていうのはそのとおり（笑）。
今の話からするに、最初はプロダクトの価値から始まって、使いやすくしていき、あとはディープサクセスのほうに重きを置きながらもスパイラルになっていくんですかね。
宮田：僕がPMFまわりでよく思うのは、PMFの「一般的なサクセスの定義」は無いということです。訴求するターゲットも提供するプロダクトも違うので、個々別々で考えるべきことです。そちらの定義を深堀りして「ないものねだり」をするよりは、「誰に対して、何についてのPMFを達成すべきなのか」を議論したほうが、よほど生産性が高いはず。
ライトサクセスとディープサクセスという発想も「誰に対して、どの機能まで使って価値を感じてもらうか」が一つの指標に入っていると思うんですけれど、その2軸ができると意外と共通認識ができて、プロダクトサイドとCSサイド、ビジネスサイドが、同じ議論ができやすいんじゃないでしょうか。その点、いかがですか？
山田：継続のための手法論や、一般的かつ学術的な計測のためのメトリクスをみんな求めたがるけれど、そうではなく、あくまで「自分たちにとっての」という観点が重要だと。
宮田：おっしゃるとおりです。どうしてもサクセスの現場やPMFを考えるうえで議論していると、特殊なケースを話してくれる人が多くありませんか？
山田：わかります。
宮田：「このお客さま、こんな感じで、こうやってサクセスしていると思うんです」みたいな話です。インサイトは多いですけれど、何回もやっていると議論が発散しがちになる。
「いや、僕らにとってサクセスしなければいけないターゲットユーザーは誰で、そのユーザーに対してどの機能まで使っていただいて、価値を感じてもらえるのか」を先に決めてしまうと、議論の生産性も上がります。まだ僕しか提唱していないのですが、続けていきたいですね（笑）。
山田：いや、私も応援しますよ、それは（笑）。
CSからPdMへの転身はもっと事例が増えていい
山田：この前、ALL STAR SAAS FUNDの神前達哉さんが「投資先にインタビューするときには、CSとプロダクト担当者が同じことを言っているかを絶対にチェックする」と言っていて興味深かったんです。
特にシード期ではトラクションもついてきていませんから、開発ロードマップがCS、プロダクト、セールスと一貫でアラインされているのかを見る。要は同じ目線で向かっているのか、そうでなければどこかに歪みがあるだろうと。
宮田：それは面白いですね。
山田：そうなんですよ。僕は、ちょっと怖さを感じました……（笑）。
宮田：事業側からすれば、そこまで見られているんだ、と（笑）。その目線が揃っている感じを見るのに、何かよい方法などあるのでしょうか。
山田：「会社が提供するサービスの一番のバリューは何だと思いますか？」という質問をしてみることだと言っていました。ここが似た言葉で説明されていれば、自分たちの強みや魅力を俯瞰的に捉えつつも、同じ方向を見ているかがわかりやすくなり、深堀りもできるそうですよ。
宮田：面白いですね。その視点だと、CSとPdMの人事交流とまでは言いませんが、CSからPdMにトランスファーしていただくような事例がもっと増えてもよさそうです。freeeだと、かなりCSとPdMは職種としての親和性が高いとも思っています。山田さん自身もPdMの経験があってからCSに携わっていらっしゃいますし。
山田：でも、例としてはとても少ないですよね。私もそれを信じている派なんです（笑）。
宮田：実際、CSは多くのユーザーと会い、導入支援でプロダクトのことを俯瞰的に知る機会も多いですから、「プロダクト知識＋ドメイン知識」という観点でも、PdMに転じてもすぐパフォームしてくださる方が多い印象を受けます。
さらにアドオンで見ているポイントだと、できたものをいかに導入するかという、プロジェクトマネジメントへのフォーカスよりも、「このプロダクトはもっとここを改善すれば導入しやすいはず」と、ユーザー視点で価値を思考できる人が、よりPdfMにきても成果を出しやすいでしょう。
山田：わかりますね。CSからすると、自分がお客さまに日頃していることを当たり前とは思わずに、「今はプロダクトに足りないことを導入支援でカバーしているけれど、そもそも機能としてあるべきではないか」といった考えになれるかが大事ですね。
宮田：僕らだと組織として大きいので、そういうチャレンジはしやすいですけれど、意外とシード期のスタートアップでもそういうチャレンジがあってもいいかな、と。
なぜかというと、バーティカルSaaSだとドメインに強い方が創業者になりやすく、業界に対する課題視がないと、創業にまで至らないじゃないですか。そこで勘案して「1人目PdM」を採用するという論点が出たときに、シニアなPdMを探そうとする人が多い気がするのですが、実はプロダクトリリース初期だと、ドメイン知識があってプロダクトを理解しているというスキルを優先したほうが、立ち上がりが良い気がするんです。
山田：まさにセールスやCSですよね。
宮田：はい。2人目、3人目になってきたタイミングで、シニアのPdM入れてちょっとシャキッとさせるのが、ストーリーとしてはいいのかなと。
山田：とてもわかります。いやぁ、今日は本当にお話しできてよかったです。
宮田：僕も非常に楽しかったです。もしかしたら、それこそPdMだけで何かを語り合うのではなく、部門間連携を念頭に職種を混ぜて話し合うほうが、時代に沿うのかもしれません。
山田：私が思うに、セールスでもCSでも一定の知見がある方は、やはりその領域だけに留まらないな、と。関連している部分がつながっていったり、違う目線でのインサイトがあったりするので、楽しいですね。
宮田：楽しいです。Backlogの優先順位や人事異動、それにKPIというテーマは、ファンクション間をつなぐハブになるじゃないですか。このあたりをテーマに据えると、会話も盛り上がりやすいのでしょうね。今日は話していて、とても面白かったです。
