← エピソード一覧に戻る Episode 153 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 要望を集めるだけではロードマップは作れない
タカシ
皆さんこんにちは、タカシです。今日は SaaS プロダクトのフィードバックトリアージを扱います。顧客の声を大事にする会社ほど、逆に声をそのまま積み上げて roadmap が壊れる。この逆説が今日のテーマです。
ミカ
ミカです。なんだか怖いですね。顧客の声を聞くのは正しいことのはずなのに、聞き方を間違えると product がぶれるんですか。むしろ customer centric から遠ざかる感じでしょうか。
タカシ
そうなんです。トリアージとは、要望を採用するか否かを即決することではなく、まず種類を見分けることです。不具合なのか、導入障壁なのか、既存機能の改善なのか、新規投資なのか。ここを混ぜると判断が全部雑になります。
ミカ
今日はその仕分け方と、営業案件や大口顧客の依頼をどう扱うか、それから実際にどんな SaaS がうまく回しているのかまで、具体例つきで聞いていきたいです。
Chapter 2 基本 ― 機能名ではなく背景の問題を受け取る
タカシ
Intercom は feature request を三つに分けています。既存機能の不具合、既存機能の改善、新規機能要望です。これだけでも、全部を同じ backlog に積む危険をかなり減らせます。困っている理由が違えば、打ち手も当然変わるからです。
ミカ
たしかに、見た目はどれも要望ですけど、中身は全然違いますね。バグなら直すべきだし、既存機能で解けるなら案内の問題かもしれないし、新規機能なら戦略判断になる。ここを一緒にすると会話がかみ合わなそうです。
タカシ
さらに Productboard は、feedback を入れる人に必ず why を書かせるべきだと言っています。つまり、CSV エクスポートが欲しい、で止めない。監査対応なのか、役員報告なのか、顧客提出なのかを聞いて、solution の言葉を problem の言葉に翻訳するんです。
ミカ
なるほど。顧客はどうしても機能名で話しますもんね。でも product 側は、欲しい機能を受け取る人というより、達成したい job を読み解く人であるべきなんだ。ここを外すと、作ったあとに、なんか違うが増えそうです。
タカシ
その通りです。Intercom の problem statement の考え方でも、見るべきは顧客が欲しい outcome、その理由、現状の痛みです。feature 名だけで triage すると、要望を処理しているつもりで、実は問題理解を先送りしてしまいます。
Chapter 3 設計 ― バグと戦略投資を同じ皿に乗せない
タカシ
ここで大事なのが、仕分けレーンを分けることです。たとえば不具合、導入障壁、日常運用の改善、戦略上の新規投資、そして特定案件の個別要望。これらは価値の出方も緊急度も違うので、同じ優先順位会議で殴り合わせるべきではありません。
ミカ
よくあるのは、support から毎日上がってくる細かな痛みを全部直していたら、四半期が終わるパターンですよね。顧客満足には効いても、次の市場を取りに行く投資が止まる。経営としてはかなり悩ましいです。
タカシ
Productboard の prioritization guide も、support request や sales request だけで roadmap を決めるなとかなり明確に言っています。特に sales 起点の大口案件は、短期売上には効いても、理想顧客や core workflow から外れるなら distraction になりやすいんですね。
ミカ
つまり、営業から来たから無視、ではなくて、その案件が自社の勝ち筋と重なるかを先に見るわけですね。大きい案件ほど判断を誤ると product 全体を enterprise 個社仕様にしてしまう。ここは冷静さが要りそうです。
タカシ
ええ。トリアージの役割は、要望に順番を付ける前に、評価軸を正しい箱へ入れることです。bug は安定稼働の箱、導入障壁は activation の箱、個別案件は戦略適合の箱、と分けるだけで議論の質がかなり上がります。
Chapter 4 具体例 ― うまい会社は件数より文脈を集めている
タカシ
Intercom の顧客事例で Keen は、feature request と product question をタグで集約し、support conversation の解決時間を 60 パーセント削減、support 工数も 30 パーセント減らしました。しかも、価格や API 上限への質問が多いことから、新機能より情報配置の改善が必要だと分かったんです。
ミカ
それ、すごく示唆的ですね。要望が多いから build するのではなく、同じ質問が多いなら discoverability や案内の問題かもしれない。request を feature backlog に直送しないだけで、打ち手がかなり変わります。
タカシ
Canny の 2025 年事例では、Paces が loudest customer に引っ張られる運営から、private board と review cycle と scoring で回す運営へ変えています。Productboard も email、Slack、Salesforce を一元化し、segment や revenue と結びつけて見ろと勧めています。
ミカ
Pendo のやり方も面白いですよね。似た request が出たら新規カードを増やすより既存 request に顧客をひもづけて、さらに複数要望は slider で優先度を付けてもらう。全部大事です、を制度上できなくしているのが賢いです。
タカシ
そうなんです。良い triage は件数を増やす仕組みではなく、重複をまとめ、文脈を付け、誰のどんな痛みかを見えるようにする仕組みです。数える前に構造化する。この順番を守る会社ほど roadmap がぶれにくくなります。
Chapter 5 クロージング ― 要望管理ではなく経営判断の前処理
タカシ
最後にまとめます。フィードバックトリアージは、顧客の声を切り捨てる仕組みではありません。声を、公平に、戦略的に扱うための前処理です。feature 名ではなく背景の job を聞き、種類ごとに別レーンへ流すことが出発点になります。
ミカ
今日の話を自社でやるなら、起票テンプレートに、誰の要望か、何を達成したいのか、今の回避策は何か、売上や解約への影響はどれくらいか、を入れるだけでもかなり変わりそうです。会議の質が上がりそうですね。
タカシ
ええ。そして sales 起点の request は、大きさではなく戦略適合で見る。support 起点の request は、痛み止めと activation 改善を分けて見る。この整理ができると、顧客の声を聞きながらも product の芯を守れます。今日はフィードバックトリアージを取り上げました。ではまた次回。