ロードマップと顧客が対立する場合の対処方法

FabricLoop チーム著 · 2026年5月 · 4分読み

すべてのプロダクトチームが電話を受け取ります。重要な顧客が、ロードマップに乗っていないものを求めています。彼らは緊急にそれを必要としています。彼らは更新が依存することさえ示唆しているかもしれません。セールスチームはメッセージを2つの感嘆符で転送しています。慎重に構成された2つの計画サイクルにわたって構成されたロードマップが一方の側に座っています。顧客がもう一方の側に座っています。何をしますか？

これはエッジケースではありません。支払い顧客を持つすべてのプロダクトで定期的に発生し、その方法はあなたのプロダクト開発プロセスが実際にどのように機能するかについて多くを明らかにします。目標は常に「はい」と言うことではなく、常に「いいえ」と言うことでもありません — 呼び出しを行うための一貫した方法を持つことです。

"最悪の結果は最小抵抗の道です：不快な会話を避けるために「はい」と言い、その後、あなたが行うべきではなかった約束を履行するためにすべてを静かに優先順位付けします。"

顧客ロードマップ対立の決定フレームワーク

決定フローチャート：顧客リクエストvs。ロードマップ

このリクエストは1つの顧客から来ていますか、それとも複数ですか？

1つの顧客

この顧客はあなたのターゲットセグメントにとって戦略的に重要ですか？

いいえ

丁寧に辞退。リクエストをログに記録。構築しないでください。

はい

ロードマップの計画された結果と一致しますか？

複数の顧客

ロードマップの戦略的な結果に適合しますか？

いいえ

戦略ギャップを通知します。決定する前にチームと話し合ってください。

はい

それを加速させます。これは強い検証です — 前に進んでください。

「1つの顧客または多く」質問は最初のフィルターです

複数の顧客が独立して同じものを要求している場合、それは真剣に受け取る価値のある信号です — 特に彼らが問題を説明するのに同様の言語を使用している場合。それはニーズが実在し、広く普及している、個別ではないことを示唆しています。

1つの顧客の場合、計算は異なります。1つの顧客のニーズはあなたの市場を代表していません、たとえ彼らがあなたの最大のアカウントであっても。1つの顧客のための機能の構築は、時間がたつにつれて複合されるプロダクト戦略税です：各ワンオフ機能は複雑さを追加し、保守負担を作成し、より広い市場への製品の魅力を狭めます。

エンタープライズトラップ エンタープライズ顧客は通常、最も具体的なリクエストと最大のレバレッジを持っています。しかし、あなたの最大のアカウントのワークフローのためにあなたの製品を最適化することは、製品がどのように他の誰にも販売することが不可能になるかです。エンタープライズ固有のリクエストをカスタムワークとして扱う — ロードマップ入力ではなく。

関係を損傷することなく「いいえ」と言う方法

ダメージなしに顧客リクエストを辞退するための鍵は、リクエストではなく問題を確認することです。「私たちはそれを構築しません」は悪く着地します。「あなたがXをするのに苦労していることを理解しています — その問題をどのように考えているか、そしてあなたのロードマップ上にあるもの、同じニーズに対処する」はより良く着地します。

顧客は彼らが求めた正確な機能をめったに必要としません。彼らは彼らの根本的な問題を解決する必要があります。彼らにその道を見せることができれば — それが彼らが提案した機能でなくても — ほとんどの顧客がそれを受け入れます。他の方法でそれ以上の正確な仕様を受け入れることができないなら、それはあなたのプロダクトのための顧客の適合について重要なことを伝えます。

応答公式 問題を確認する →今すぐ構築しない理由を説明する →同じニーズに対処している構築内容を表示する →開発時にそれに参加し続けるように招待します。これは「いいえ」より5分長くかかり、はるかに多くの善意を保存します。

顧客が正しく、ロードマップが更新する必要がある場合

時々、顧客の対立はあなたの思考における本当のギャップを明らかにします。複数の顧客が計画していなかった何かを求めることは、ロードマップが何かを逃したというしるしです。正しい応答は彼らが求めたものに反応的に構築することではありません — 根本的な問題がロードマップに属するかどうか、そしてそうであれば、どこに属するかを調査することです。

この区別が重要です。顧客はしばしば問題についても正しいです。彼らはめったに解決策について正しくありません。彼らのフィードバックを使用して、バックログにコピーペーストするのではなく、問題の理解を更新してください。

FabricLoopが顧客シグナルを追跡するのにどのように役立つか 数ヶ月にわたって複数の顧客から同じリクエストが到着した場合、フィードバックが別のメールスレッドとCRMノートに住んでいる場合、パターンを見逃すのは簡単です。FabricLoopは1つの場所で繰り返しテーマを表示するため、「1つの顧客のリクエスト」が実際にはあなたがすでに5回「いいえ」と言う前のトレンドであるかどうかを確認できます。

この記事から得られる10のこと

顧客ロードマップ対立は日常的なものであり、例外的なものではありません。それらを処理するための一貫した方法を持つことは、個々の決定よりも重要です。
最悪の反応は会話を避けるために「はい」と言い、その後、補正するためにすべてを静かに優先順位付けします。
最初のフィルター：これは1つの顧客または多くですか？複数の独立したリクエストは同様の言語を調査する価値のある信号です。
単一の顧客のための機能の構築 — 大きな場合でも — は時間とともに複合するプロダクト戦略税です。
具体的なリクエストを持つエンタープライズ顧客はカスタムワークとして扱う必要があります、ロードマップ入力ではなく。
機能ではなく根本的な問題を確認するときにリクエストを辞退します。パス、パスのない「いいえ」をお見せください。
ほとんどの顧客は、正確な仕様が構築されていない彼らの問題を解決した必要があります。彼らに道を見せて、ただのいいえではなく。
顧客がその正確な仕様のみを受け入れることができる場合、それはそれらとあなたのプロダクト間の適合について何か重要なことを伝えます。
複数の顧客が本当のギャップを明らかにする場合、根本的な問題を調査します — バックログにコピー機能を貼り付けるだけではなく。
顧客は通常、問題について正しいです。彼らはめったに解決策について正しくありません。