プロダクトは画面の外で決まる: 需要仮説とサポート体験をつなぐ設計思考

Hatched by tttt

May 19, 2026

1 min read

0 views

89%

「売れるかどうか」は機能ではなく、代替手段との比較で決まる

新しいプロダクトが失敗する理由は、機能が足りないからではない。もっと厄介なのは、顧客がすでに持っているやり方に勝てないことだ。人は新しいものが好きなのではない。今よりラクで、今より安心できて、今より成果が出るなら、はじめて乗り換える。

ここで重要なのは、比較対象が競合製品だけではないことだ。紙のメモ、Excel、メール、口頭での引き継ぎ、サポート担当への電話、導入支援の打ち合わせ。顧客はいつも、こうした「現実のやり方」と比べて新しい提案を判断している。

つまり需要仮説とは、単なる市場の有無ではなく、顧客の行動を置き換える仮説だ。「この製品は便利です」では弱い。「今のやり方より、このほうが明らかにましだ」が必要になる。Spotifyが勝てたのは、音楽再生機能が優れていたからだけではない。買う、管理する、探す、持ち歩く、更新する、という一連の手間をまとめて軽くしたからだ。

製品は機能で買われるのではない。既存のやり方をどれだけ穏やかに、しかし確実に破壊できるかで選ばれる。

需要はプロダクトの中ではなく、顧客の「仕事」の中にある

需要仮説を立てるとき、多くの人は「この機能が欲しい人はいるか」と考える。だが本当に見るべきなのは、顧客が片づけたい仕事である。例えば、営業担当がやりたいのはCRMを操作することではない。受注確度を上げ、見込み顧客を取りこぼさず、上司に説明できる状態を作ることだ。

この視点に立つと、競争相手の定義が変わる。CRMの競合は他社CRMではなく、スプレッドシートや個人の記憶、そして「まあ大丈夫だろう」という運用慣行かもしれない。医療現場なら、競合は別の医療ソフトではなく、紙カルテと電話確認と人海戦術だろう。教育分野なら、競合は学習アプリではなく、先生の経験則と配布プリントかもしれない。

ここで見落とされがちなのが、需要は使う前に証明されるのではなく、使っている途中で試されるという点だ。顧客は初回の購入だけでなく、導入、定着、活用、継続の各段階で「このやり方は本当に楽か」を判断する。だから需要仮説は、最初のクリックではなく、継続的な行動変化まで含めて考えなければならない。

このとき役立つのが、具体的な質問だ。たとえば「最近いつ、今のやり方で困ったか」「そのとき何を代わりに使ったか」「その代替案にどれだけ不満があったか」。こうした問いは、抽象的な好意ではなく、実際の摩擦を浮かび上がらせる。

需要の強さは、熱意の大きさではなく、代替手段への不満の強さで測るべきだ。

しかし、顧客の不満はサポート窓口で終わってしまう

ここで話は少し厄介になる。せっかく需要があっても、顧客が実際に使い始めた瞬間、製品の価値は機能一覧ではなく、接点の総和で評価されるからだ。導入が難しい、初期設定がわかりにくい、エラーの意味が不明、期待した成果が出ない。こうしたつまずきは、顧客の頭の中では一つの体験として記憶される。

多くの組織では、サポートや導入支援は「製品の外」に置かれる。しかし顧客から見れば、外ではない。問題が起きたら相談する相手も、使い方を教える相手も、製品の一部として認識される。エンタープライズソフトであれば導入支援チーム、家具なら組み立て支援、消費財なら返品対応やFAQ。これらは周辺業務ではなく、体験を完成させるためのインターフェースだ。

この事実が示すのは、需要と定着の間に深い溝があるということだ。顧客は「欲しい」と思っても、使い始めて初めて、サポート体験を通じて本当の評価を下す。逆に言えば、プロダクトの価値は画面の中だけで完結しない。問い合わせが増えるほど、体験全体の設計ミスが露呈する。

ただし、ここには危険な落とし穴がある。サポートやコンサルティングがうまく機能しすぎると、プロダクト改善の圧力が弱まることだ。使いにくい製品ほど支援が必要になり、その支援が収益や評価を生むなら、組織は「直す」より「支える」方向に引き寄せられる。これは短期的には合理的に見えて、長期的には顧客体験を腐らせる。

支援が儲かる組織は、しばしば製品を簡単にする動機を失う。ここに、顧客満足を蝕む静かな逆説がある。

本当に強いプロダクトは、問い合わせを減らすプロダクトである

この二つのテーマを重ねると、ひとつの強い結論が浮かぶ。需要仮説の検証と、サポート体験の設計は別問題ではない。むしろ同じ問題の前半と後半だ。前半は「そもそも誰が乗り換えるのか」、後半は「乗り換えた人が続けられるのか」である。

ここで役立つ見方がある。プロダクトを「機能の集合」ではなく、摩擦を移動させる装置として捉えることだ。顧客は既存のやり方で何らかの摩擦を払っている。新しいプロダクトは、その摩擦を消すか、少なくとも見えやすく、管理しやすく、安くする必要がある。

例を挙げよう。iTunesで曲を1曲ずつ買う行為は、所有感はあるが管理が面倒だ。Spotifyはその摩擦を「購入」という単位から「検索して聴く」という単位へ移した。結果として、音楽を持つことより音楽を流すことに価値の中心が移った。これは単なる機能改善ではない。顧客の仕事の再定義だ。

サポート体験も同じである。問い合わせが多い組織は、しばしば「サポートを強化しよう」と考える。しかし本当に必要なのは、問い合わせの原因を分解し、プロダクト側で吸収できる摩擦を減らすことだ。たとえば、同じ質問が繰り返されるなら、FAQの追加だけで終わるべきではない。UIの曖昧さ、用語の不統一、オンボーディングの欠落、設定順序の誤りまで疑う必要がある。

この意味で、サポートは単なる後始末ではない。市場のリアルタイム観測装置だ。顧客がどこで迷い、どこで諦め、どこで怒るのかが、そのまま記録されるからだ。優れたプロダクトマネージャーは、ここで初めて真実に触れる。会議室で考えた理想より、問い合わせログのほうが正直だからだ。

需要仮説とサポート設計をつなぐ、ひとつの実践フレーム

両者を統合するには、プロダクトを次の四層で見るとよい。

代替手段
顧客はいま何で問題を解決しているか。紙、Excel、電話、他社製品、あるいは何もしないことか。
乗り換え理由
なぜ今のやり方より良いと思うのか。速さ、安心、再現性、コスト、見栄え、説明責任のどれか。
初回体験
導入直後に摩擦なく価値へ到達できるか。設定、理解、成功体験までの距離は短いか。
継続体験
困ったときに、サポートやコンサルを含めて前進できるか。それとも問い合わせが負債化するか。

このフレームの良いところは、需要を「買う前の興味」だけで終わらせないことだ。代替手段に勝つだけでは不十分で、顧客が最初につまずいたときに、再び旧来の方法へ戻らない構造を作る必要がある。つまり、需要仮説の本当の検証は、購入ではなく戻り率と問い合わせ内容に現れる。

たとえば、新しい業務ツールを導入したのに、ユーザーが結局メールと表計算に戻るなら、それは需要がなかったのではない。需要はあったが、初回体験か継続体験で摩擦が勝ったのだ。逆に、サポートへの問い合わせが減っているのに継続率が高いなら、製品が顧客の仕事に本当に馴染んでいる可能性が高い。

この視点を持つと、KPIの意味も変わる。売上だけでなく、問い合わせ件数、問い合わせの種類、初回解決率、再問い合わせ率、FAQの利用率などが、需要の質を示す指標になる。数字は単なる運用指標ではなく、顧客がどこでつまずいているかの地図になる。

Key Takeaways

需要は「機能があるか」ではなく「今のやり方より良いか」で測る。 競合は他社製品だけでなく、Excelや紙や口頭運用も含まれる。
サポートとコンサルは製品の外部ではなく、体験の一部。 顧客は問題解決の過程まで含めてプロダクトを評価する。
問い合わせはコストではなく、摩擦のデータ。 同じ質問が多いなら、FAQ追加だけでなく、UIや導線そのものを疑う。
本当に強いプロダクトは、支援を増やすのではなく、支援が不要になる方向へ進む。 支援を手厚くするほど、製品改善の動機が弱まる罠に注意する。
需要仮説の検証は購入で終わらない。 継続利用、再問い合わせ率、旧来手段への戻り方まで見て初めて、真の需要が見える。

プロダクトとは、顧客の現実を書き換える提案である

プロダクトを語るとき、私たちはつい画面、機能、UI、ロードマップに目を奪われる。しかし顧客が本当に向き合っているのは、もっと生々しい現実だ。やりにくい作業、曖昧な責任分担、問い合わせ先の不明瞭さ、失敗したときの不安。製品の価値とは、その現実を書き換えられるかどうかで決まる。

だから、優れたプロダクト思考は二つを同時に見る。ひとつは、顧客が今どんな代替手段で仕事を片づけているかという需要の問い。もうひとつは、その顧客が詰まった瞬間に、どんな接点が救済ではなく摩擦になっているかという体験の問いだ。この二つは別々の専門領域ではない。どちらも、顧客の現実をどれだけ深く理解できるかという一点に収束する。

最終的に問うべきなのは、こういうことだ。この製品は、顧客に新しい操作を覚えさせるためのものか。それとも、顧客の仕事の仕方そのものを、今より少しでも賢く、軽く、安心できるものに変えるためのものか。その答えが曖昧な製品は、たいてい長く愛されない。だがその答えが明確な製品は、機能を超えて習慣になり、サポートを超えて信頼になる。