この記事はNeural Group Advent Calendar 2025の17日目の記事です。
はじめに
ニューラルグループでBtoB SaaSのプロダクトマネージャーを担当している窪田です。
エンジニアとしてキャリアをスタートし、その後PdM（プロダクトマネージャー）、BizDevというロールを行ったり来たりしながらさまざまなプロダクトに関わってきました。
全体的にはBtoBのプロダクトが多く、ステージとしては基本的に0->1、1->10という新規立ち上げやグロースフェーズでの関わりが多いです。
最近ではPdM（プロダクトマネージャー）という職種も認知されるようになりましたが、まだ業界での認識が確立されていないためか、「プロダクトマネージャーとは何か？」といった定義に関する記事が多く、具体的なプロダクトマネジメント業務やノウハウに関する情報はまだ少ないように感じます。
本記事は、ファーストリリースは達成したものの、PMF(プロダクトマーケットフィット)に向けてどのようにグロースさせていけばよいか悩んでいる方に向けて書きました。
もちろん、プロダクトマネージメントにおいて正解や最適な方法は存在しません。
しかし、プロダクトマネージャーとしての立場から、どのようにして戦略的にフィードバックを生み出せば良いのかについて、一例を紹介します。
※PMF(Product-Market Fit):プロダクトが市場のニーズを満たし、持続的な成長が可能な状態
こんな人向け
- 新規プロダクトをこれから開発するエンジニア
- プロダクトマネージャーのキャリアをスタートしたい人
- スタートアップでプロダクトの0->1を狙っている事業責任者など
なぜフィードバックが重要なのか
そもそもなぜプロダクトへのフィードバックが必要なのか？
BtoC(一般消費者向け)、BtoB(法人向け)プロダクト問わず、最初にリリースした機能だけでそのまま成功することはありません。
初期にリリースした機能はあくまで最低限のニーズに当てたものであり、リリース後に仮説検証を繰り返しながら機能を足したり減らしたり、時にはピボットしながらPMFを目指していきます。
特にBtoBプロダクトのようなマーケットイン型のプロダクト（市場の顕在化したニーズを満たす）は、顧客の業務に深くフィットした機能をアップデートすることで、継続率（リテンション）や顧客満足度（エンゲージメント）を高めていくことができます。
もちろんBtoCにおいても、ターゲットユーザの利用状況や欲求を上手く拾い上げて、素早くプロダクトへ反映することでシェアを拡大させることは、プロダクト戦略上とても有効です。
しかし、一口にフィードバックといっても大小様々なフィードバックがあった場合、どのように取捨選択して優先順位をつけながら開発していけばいいのでしょうか。
勝てるプロダクトを作るためには受け身の姿勢ではなかなか有効なフィードバックは生まれません。
良いフィードバックとは必ずしも既存ユーザからの評価だけではありません。
既存のユーザの声だけ拾って開発していたら、将来顧客になってもらえる可能性がある市場を見過ごしてしまい、局所解に陥ってしまう可能性があります。
それだと既存の顧客の満足度は確かに上がりますが、マーケットが広がっていきません。
それでは、どのようなフィードバックがあるのか、その種類と、どのようにして戦略的にフィードバックを生み出せば良いのかについて説明していきます。
戦略的に良いフィードバックを生み出す方法
そもそも良いフィードバックというのはなんでしょう。
それは 事業・プロダクトの成長につながるフィードバック です。
良いフィードバックを生み出すために、まずはどのようなフィードバックがあるのか整理します。
The Lean Product Playbookでは、プロダクトとマーケットをどのようにフィットさせていくべきかが説明されています。
簡単に説明すると、ピラミッドの下に「ターゲット顧客」と「満たされていないニーズ」が土台としてあり、その上にプロダクトレイヤーがそれぞれ「バリュープロポジション（独自の優位性）」「機能群」「UX（ユーザ体験）」として定義されています。
土台にマーケットがあるように、マーケットから様々なフィードバックを受けながらプロダクトを適合していくイメージです。
ポイントはピラミッドで表現されている通り、下の階層の方がより重要度が高いということです。
逆に言えば、下の階層を飛ばして上の階層に注力すべきでないとということになります。
このピラミッドを元にフィードバックの階層（レベル）をカテゴライズしたのが次の図になります。
フィードバックを整理する際、そのフィードバックはどのフィードバックレベルのものかを意識しましょう。
マーケットレベルのフィードバックなのか、それともユーザの業務やユースケースレベルのフィードバックなのか、もしくはユーザビリティ（使い勝手）レベルのフィードバックなのか。
このようにそれぞれのフィードバックをカテゴライズすることで、取り組むべきアクションに優先順位をつけることができるようになります。
当然プロダクト開発においても、マーケットレベル > ユーザレベル > ユーザビリティレベルの順でリソースを配分しましょう。
よくやってしまいがちなのが、マーケットレベルのフィードバックを意識せずに、ユーザビリティレベルの改善ばかりに集中してしまうケースです。
マーケットにフィットしていないのに、ユーザビリティの改善ばかりやっていても、いつまで経ってもPMFには到達できません。
とはいえ、足元の不具合やユーザビリティを全く無視すれば良いというものでもありません。
要はバランスです。
よく私がチームに説明する表現として バケツ擦り切れ方式 と呼んだりします。
アジャイル的にやっていたら、スプリントなどある程度決まったサイクルで開発していくと思いますが、プロダクト戦略上重要な玉（競合との差別化だったり、大手導入のためのキラー機能だったり）を先にバケツへ入れて、隙間に小粒な機能や改善系を詰めていくイメージです。
リソースという限られた資源を何にどれくらい使うのかを慎重に考えてください。
では、フィードバックのカテゴリーが整理できたところで、実際にどうやって戦略的にフィードバックを生み出せるのかについて、いくつかのアプローチを紹介します。
今回紹介するアプローチはBtoBプロダクト寄りですが、BtoCプロダクトでも読み替えて応用することができます。
一つずつ説明していきます。
① 市場からのフィードバックを生み出す
プロダクトのビジネス価値を高めるという観点で一番重要になるのが市場からのフィードバックです。
特にプロダクトの初期やPMF前の場合、どこの市場の誰の課題を解決するのかを決めなければなりません。
事業戦略とも密接に絡むため、営業やマーケターなどのビジネスサイドと連携する必要があるでしょう。
いくつかアプローチ例を紹介します。
- 営業の商談からフィードバックをもらう（受注・失注分析）
- 市場調査（ターゲット顧客の属性分析や業務分析など）
- 競合調査（直接の競合だけではなく、ターゲット顧客の周辺課題を解決しているサービスなども含めて）
中でも商談からのフィードバックは必ずリストにまとめて管理しておきましょう。
受注に貢献した機能があった場合は、その機能の品質向上にフォーカスしたり機能拡張していくという判断ができますし、逆によく失注の原因になる機能がもしあれば、追加することで受注率を上げることができるかもしれません。
他にも市場調査や競合調査を行うことで、有効な機能開発の仮説を立てることができます。
仮説を立てる際は、必ずその機能を開発することで 課題を深く解決できるか（顧客エンゲージメントが向上するか） と、 解決できる対象が広がるか（マーケットが拡大するか） という観点で検討しましょう。
営業やビジネスサイドとの優先順位の認識として機能要望シートや課題管理表などを作成して、それを基に優先順位を議論しましょう。
私がよくやるのは、機能要望を企業ごとに管理して、どの企業がその機能を要求しているのか 、またその機能をどれくらいの企業が要求しているのかといった数を見たりします。その顧客特有の課題なのか汎用的なニーズなのかをできるだけ定量的に判断できるファクトを積み上げます。
ただそれだけだと、機能Aと機能Bがそれぞれ別の顧客から要望された時、どちらを優先するのかを判断するのが難しいです。
そのため、各要望について比較できる項目を追加します。
例えばよく使うのが、受注確度、導入時期、売上単価など、なるべくビジネス観点で比較できる項目で判断します。
全ての顧客の要望に応えられたらハッピーですが、時間とリソースの制約がある以上、最短で最大の成果を上げるために何を拾って何を捨てるべきなのかを判断する必要があります。
あと大事なことは、その顧客が自社が本当に追うべき本当のターゲットなのか冷静に見極めることです。
メインのターゲットじゃなければ拾わないか、捨てるという判断も必要です。チームで議論してその判断軸を持っておければ意思決定のスピードを上げることができるのでおすすめです。
そのリストを定期的にビジネスサイドと議論することで、その正しいターゲット向けの機能なのか、1社だけの個別ニーズではないのかといった議論ができ、ビジネスと開発の認識が合致した質の高いロードマップにしていくことができます。
② ユーザからのフィードバックを生み出す
次に取り組むべきは、既存もしくはターゲットユーザからのフィードバックを集めることです。
ユーザの課題をプロダクトが想定通りに解決しているかどうかをチェックします。
直接ユーザへのインタビューやヒアリングを通してフィードバックを集めますが、必ずフォーカスすべきターゲットを定義してから実施しましょう。
ターゲットがズレると間違ったフィードバックを取り込む危険があります。
ユーザからのフィードバックを集める方法はたくさんありますが、いくつか代表的な例を挙げます。
- NPSスコアを収集する
- ユーザインタビューを実施する
- モニターを募集する
- フォーカスターゲットを定義し、メインユースケースからロールプレイを行う
多くの手法で、既存のユーザにインタビューを行うパターンが多いと思いますが、深く利用状況を確認・観察したい場合は、モニターという形で協力してくれるユーザを募るという方法もあります。
社外で見つけられない場合は、社内でユースケースを定義してロールプレイを行うことで有効なインサイト（洞察）が見つかる可能性もあります。
ユーザインタビューに関してもっとテクニカルな手法を知りたいという方は、専門書などを参照することをおすすめします。
このフェーズのポイントは、ユーザーがメインのタスクを遂行する際に、 不足している機能がないか 、または 必要ない無駄な機能はないか という観点でチェックすることです。
このプロセスは、長期的なエンゲージメントやリテンションといった指標に効いてきます。
③ ユーザビリティに関するフィードバックを生み出す
ユーザからのフィードバックレベルが顧客の課題を正しく解決できているかだとしたら、ユーザビリティはストレス（負荷）なく解決できているかという観点になります。
機能同士の導線から、ボタンの配置などのレイアウトまで、プロダクトが提供する全てのユーザ体験（UI/UX）について最適化していきます。
以下にいくつか例を挙げます。
- ユーザビリティ（UX）テスト
- 社内ドッグフーディング
- 外部のUX評価
ユーザビリティ（UX）テストは、実際にユーザがプロダクトを使用しているところを観察し、つまづきや不具合が発生しないかどうかをテストします。
特にサービス立ち上げ期は、UXバグも多く、ユーザーのメインのタスクに対して最適化できてないことも多いです。
なので、なるべく使っている状況を実際に見せてもらって、意図通りの操作をしているか、ユーザーが迷っていなかったかどうかを深く観察し、それに基づいて改善していく進め方がおすすめです。
ユーザを巻き込むコストが高い場合は、社内で試しに使用してみて（ドッグフーディング）改善点を洗い出すという方法もあります。
また、UXの専門家に依頼して、改善点を見つけていく というアプローチも有効です。
ユーザビリティテストの手法なども多くの書籍や記事で紹介されているので、そちらを参考にしながら試してみることをおすすめします。
ビジネスと開発を巻き込んだ開発フロー
では具体的にどのような流れで業務に落とし込めば良いのかについて、チーム内での開発フローのイメージを紹介します。
以下の図のように、各開発項目についてアイデア（起案）→優先順位付け（やるやら、いつやるか）→検証（必要があれば）→開発といった流れをイメージして、ファシリテーションしています。
バックログがどこで生まれて、どこにストックされ、どのように開発に落ちるのか
またそれぞれのステップで、誰を巻き込むか、営業・事業オーナー・CSなどを決めて、必要なタイミングで必要なメンバーで会議を開くことで、ロードマップや優先順位の精度を上げることができます。
もちろんチームのメンバーやフェーズに合わせてアジャストさせて行きます。
重要なのは各バッグログ（開発すべき機能）がどこから生まれて、どこで合意されて開発に落ちるのかというフローを管理することです。
PdMとして一番避けるべきは、その機能をなぜ開発するのか説明できないこと です。
個人開発なら全ての意思決定は自分で完結しますが、チームや組織だとそうはいきません。
事業責任者、企画、デザイナー、営業、CSなど様々な人たちと共同で開発していきます。時にはコンフリクトする場面も発生します。
そうなった時に、なぜその機能を開発するのかを合理的に説明できることが大事です。
開発規模が大きくなると、「あれ？その機能なんで開発してるんだっけ？」といった認識の齟齬が発生しがちです。
関係者や規模が増えてくると必ず発生するので、なぜその機能を開発することになったのかは後から追えるようにしておきましょう。
まとめ
いかがでしたでしょうか。
今回はプロダクト開発において、良質なフィードバックをどのように集めれば良いのかという観点で具体的なアプローチも交えて紹介しました。
全体的にBtoBプロダクト向けの内容になっていますが、基本的な考え方はBtoCのプロダクト開発でも同様だと思います。
もちろんプロダクトの性質や使えるリソースによっても取るべきアクションは変わってくるので、仮説検証を回しながら自社やチームに合ったやり方を模索してみてください。
今回の内容が少しでもお役に立てたら幸いです。