この記事の3行要約
- セールスからの顧客要望だけを鵜呑みにすると、ロードマップが自転車操業化し長期戦略との整合性が崩れる。顧客が口にする解決策と真の課題は必ずしもイコールではなく、定量×定性データで本質を検証する必要がある
- セールスとPdMの衝突を防ぐには、一方的なロードマップ提示ではなく定期的な共有会議で一緒に優先度を検討する。要望の背景と期待効果を整理し、決定プロセスを可視化することで信頼関係を構築する
- 特定顧客の声だけを優先すると他顧客とのバランスを損ねる。使用状況ログやサポート問い合わせ件数と、ユーザーインタビューの深堀りを組み合わせ、売上やKPIへの影響度を共有しながら判断する
セールスとPdMのよくある衝突パターン
BtoB領域のプロダクトマネジメントでは、顧客最前線に立つセールスチームから機能要望が次々に上がってくることが日常茶飯事。
- 「この顧客がこう言っているから早く機能を作ってほしい」
- 「競合がやっているからうちも対応すべきだ」
などの声が直接プロダクトマネージャーに届きます。
こうした要望は顧客とのリアルな接点から生まれているため、全く無視するわけにはいきません（僕自身もセールスの方々を尊敬しているので超絶大事にしたい意見です）。
一方、PdMとしては以下のような悩みを常に抱えると思います。
- 「本当にすべての要望に応える必要があるのか？」
- 「どの顧客の声を優先すべきか？」
- 「その要望を実現することでどの程度のインパクトがあるのか？」
この際に起こる衝突パターンとして典型的なのは、「スピード優先のセールス vs. 機能の妥当性を検証したいPdM」という構図。セールスサイドは「今すぐ」の受注や契約のために機能リリースを急ぎますが、PdMはロードマップ上での優先度や開発リソース、さらにユーザーインタビューを通じた本質的な課題確認を重視します。
結果的に
- 「なぜ作れないのか」
- 「ユーザーが望んでいるのになぜ止まるのか」
などの不満がセールス側から噴出し、チーム内の摩擦が生まれるわけです（ここまで明らかな摩擦は中々ないと思いますが）。
なぜ、顧客要望をそのまま作っては”いけない”のか？
セールスの声といえども、顧客要望を言われたとおりに実装してしまうと、ロードマップが自転車操業状態になり、長期的なプロダクト戦略との整合性が崩れてしまいます。
これはBtoBでもBtoCでも同じ。特定の顧客の声だけを優先すると、他の顧客ニーズとのバランスを損ねる可能性が高まります。さらに、要望自体が本当に顧客の「真の課題」に即しているかどうかを検証しないまま開発を進めると、不要機能の乱造や、継ぎはぎだらけのUI・UXにつながりがちです。
実際、僕自身も累計700名以上のユーザーインタビューをこなしてきた経験から言えるのは、「顧客が本当に欲しいと口にしている解決策」と「実際に課題を解決するために有効なソリューション」は必ずしもイコールではないということです。
顧客は自分の課題を一部しか認識していなかったり、過去の経験や使い慣れた他社製品のイメージを基に要望を出したりします。そのため、要望を鵜呑みにするのでなく、必ずユーザーヒアリングや定量データで課題の本質を捉える必要があります。以下の記事でも触れたように、むやみに作った機能がのちのち大きな負債になるケースは多々あります。
営業チームを巻き込むロードマップ共有会議の流れ
そこで、ロードマップ作成時にセールスチームをうまく巻き込むことが重要。つまり、セールスからの要望を聞いてPdMが考えるのではなく、セールスと一緒に考える、のです
多くの場合、PdMが一方的にロードマップを提示すると「一部の要望が無視された」「いつ対応してもらえるか分からない」といった不満が募ります。そこで、ロードマップ共有会議を定期的に開催して、セールスの声を正式な形でヒアリングしつつ優先度を一緒に検討する場を作ることがポイントです。
具体的には、以下の流れをおすすめします。
- 事前にセールスから顧客要望をシートやツールに集約してもらう（要望の背景や期待効果を整理）
- PdM側でプロダクト戦略・ロードマップの大枠を提示する（ミッションやOKR、KPIなど）
- セールスが持ち込んだ要望の優先度を一緒に検討し、「実装時期」や「優先度の理由」を明文化する
- 合意に達しなかった場合は、次回に持ち越す or 定量データ・顧客インタビューを追加で実施し判断する
- 結果を社内Wikiや共有ドキュメントにまとめ、誰でも見られる状態を保つ
このように会議のプロセスを明確にすることで、「会議の場に参加すればしっかり話を聞いてもらえる」という安心感をセールスへ与えられます。PdMが「黙って判断するのではなく、オープンなルールで合意形成をしている」ことを示すことが、セールスとの信頼関係を醸成する最初のステップになります。
また、このときに大事なポイントとしてセールスばかりにPdMのプロセスに協力してもらうのでなく、営業に同席してそのセールスの成果Upにも全力で協力しましょう。
定量×定性で説得：データと顧客インタビューをセットに
セールス側の「この機能がなければ契約取れないんだ」という切羽詰まった声を受け止めながらも、PdMとしては機能開発の優先度を慎重に見極める必要があります。その際に有効なのが、基本ですが定量データ×定性データでインパクトを特定すること。
例えば「実際にどの程度の顧客が同じ要望を抱えているのか？」を使用状況のログやサポート問い合わせ件数で把握し、加えてユーザーヒアリングで背景を深堀りしていきます。
PdMはこの組み合わせを使って「その要望がどの程度、売上増や顧客満足度向上に直結するか」を検証し、セールスと共有して議論材料にするわけです。特にBtoBの場合、契約金額の大きい顧客1社の要望がビジネス的に見れば優先度が高い場合もありますが、実はその課題は真のユースケースではなく独自要件という可能性も大いにあります。そこを「定量的な利用実績」と「定性的なインサイト」の両面から見極めるのです。もし定量データと定性データが食い違う場合、その理由をさらに深掘りして判断を修正する必要もあります。
参考情報
- John Smith (2020) “Coordinating Cross-Functional Teams in B2B Product Development”, Journal of Product Innovation Management
- Marty Cagan (2018) “INSPIRED: How to Create Tech Products Customers Love”
- Eric Ries (2011) “The Lean Startup”
- Harvard Business Review (2019) “How to Align Sales and Product Development for Better Outcomes”
今日から実践できるアクション
- 「セールス要望登録シート」を作成し、背景・期待効果をセットで入力してもらう
- ロードマップ共有会議を定期開催し、決定事項を社内Wikiなどで可視化する。
- 定量×定性データを用いた優先度判断を徹底する。必要に応じて追加のユーザーインタビューやサポートログ解析を実施する。
- 失敗事例から学ぶために、過去のリリースで生まれた機能の利用状況を追いかける。セールスからの要望がどこまでビジネス成果に結びついたか検証し、今後の開発指針に反映する。
Q&A
Q1: セールスに「とにかく今すぐほしい」と強く言われたらどう対処すべき？
A1: まずは感情的にならずに「なぜ今すぐが必要なのか」を丁寧に確認することが大切です。顧客との商談タイミングや契約クロージングの期限など、セールス側の事情を明確にしてもらい、その上で可能な妥協点を探るとよいでしょう。必要であれば一部機能の先行提供や、プロトタイプでの暫定対応などを提案し、合意形成を図ります。
Q2: セールスチームがロードマップに興味を示さず、会議にも来てもらえない場合は？
A2: 「ロードマップ共有会議」がPdMの自己満足になっていないか見直しましょう。あくまで、セールスが得られるメリット（自分たちの声が反映される、顧客への提案に根拠をもてるなど）を明示する必要があります。場合によっては経営層からメッセージを出してもらい、参加の重要性を周知することも効果的です。
Q3: 特定の大手顧客の要望ばかり優先すると、プロダクトが歪まないか心配です。
A3: 大口顧客の声を取り入れることはBtoBの宿命ですが、それが他の顧客価値を損なうなら注意が必要です。そこで定量的な利用割合や、他顧客にも共通する課題かどうかをチェックし、優先度を決めます。大型顧客向けの要望を実装した際には、同じ機能が他顧客にも応用できないか工夫してみましょう。
コメント