ブログ

PMF前のプロダクトが顧客の声とどう向き合うべきか

TL;DR

PMF前のプロダクトでは、フィードバックの「量」よりも「どのセグメントの誰の声か」の方が重要です。ターゲットが定まりきっていない段階で全方位の要望に応えようとすると、結果的にどのセグメントにも刺さらない機能が積み上がります。少数でも狙ったターゲットに近い声を深掘りし、仮説検証の材料として使うのが実務的です。

プロダクトマーケットフィット(PMF)に至る前と後とでは、同じ「顧客の声」でも扱い方を変える必要があります。この記事では、PMF前のプロダクトが顧客フィードバックとどう向き合うべきかを整理します。

PMF前と後で、フィードバックの「使い道」が違う

PMF後のプロダクトは、すでに一定数の顧客がプロダクトの価値を認めて使い続けている状態です。この段階でのフィードバックは主に「磨き込み」のための情報で、機能の改善・拡張の優先順位づけに使います。

一方PMF前のプロダクトは、そもそも「誰の・どんな課題に」プロダクトが刺さるのかがまだ検証途中です。この段階でのフィードバックは、機能改善の材料である以前に、「想定していたターゲットは合っていたか」「課題の仮説は正しかったか」を検証するための情報として扱う必要があります。同じ要望リストを見ていても、見るべき問いが違います。

「全員の声に応えよう」とすると起きること

PMF前は特に、届く声の数自体が少ないため、届いた要望にはできるだけ応えたくなります。ですが、まだターゲットセグメントが絞り切れていない段階で幅広い要望に応えようとすると、結果的に「誰にとっても中途半端な機能」が積み上がるリスクがあります。

例えば、想定顧客ではないユーザーからの要望に応えて機能を作った場合、その機能自体はきちんと動いてもPMFの検証には直接寄与しません。声を無下にする必要はありませんが、「この声は、狙っているターゲットセグメントのものか」を毎回確認する習慣が、PMF前ほど重要になります。

少数の声を、狙ったターゲットのシグナルとして読む

PMF前は要望の絶対数が少ないため、件数による優先順位づけ自体が機能しにくいという事情もあります。10件集まってから判断する、というやり方は待っている間に検証の機会を逃します。

そのため、PMF前は「1件の声を深く読む」ことの比重が相対的に高くなります。誰が、どんな状況で、何に困っていて、なぜその機能を求めているのか。この背景情報を1件ずつ丁寧に拾うことが、件数の少なさを補う手段になります。「要望の数を数えても、優先順位は決められない」でも触れていますが、この考え方はPMF前ほど強く当てはまります。

深掘りのコストは、PMF前ほど惜しまない方がいい

要望を投稿してもらった後に「具体的にどんな場面で困りましたか」と追加で尋ねる深掘りのステップは、PMF後の成熟したプロダクトであれば任意の改善要素の1つですが、PMF前は検証の精度を左右する工程になります。

Feeduryはこの深掘りステップを収集フローの一部として持っており、投稿後にAIが背景に応じた質問を選択肢付きで提示します(回答は任意)。プロダクトの背景(対象ユーザー・解決している課題)を設定しておくと、その内容に沿った質問が生成される仕組みです。PMF前のように「1件の声の重みが大きい」段階ほど、こうした深掘りの仕組みが効きやすいと考えています。

「刺さった」をどう判断するか

PMF前の判断で難しいのは、「機能を作って反応が良かった」ことをどう確認するかです。件数の少なさから、単純な投票数の多寡だけでは判断材料として心もとないことが多いです。

実務的には、(1) 声を上げた顧客が実際にその機能を使い続けているか、(2) 同じ課題を持つ別の顧客からも同様の声が独立して上がるか、の2点を追うのが手堅いやり方です。ステータスをdoneにした後の顧客への通知や、その後の反応もあわせて見ていくとよいでしょう。

まとめ

PMF前のプロダクトにとって、顧客の声は「磨き込みの材料」である以前に「仮説検証の材料」です。件数の少なさを言い訳にせず、1件ごとの背景を丁寧に読み解く姿勢が、PMF後よりもむしろ重要になります。実際にフィードバックを集める仕組みがどう動くか気になる方は、デモボードで確認してみてください。

よくある質問

PMF前でも優先順位づけのフレームワーク(RICE等)は使うべきですか?

使ってもよいですが、要望の絶対数が少ない段階ではスコアの数値そのものより、個々の要望の背景を読み込む比重を上げる方が実務的です。フレームワーク一般の限界については「[機能要望の優先順位づけフレームワーク比較(RICE/Kano/MoSCoW)と限界](/blog/feature-prioritization-frameworks-rice-kano-moscow)」で整理しています。

声をくれた顧客が想定ターゲットと違う場合、どう対応すればいいですか?

要望自体を無視する必要はありませんが、対応の優先順位は下げて構いません。想定ターゲットとズレた声に応え続けると、検証したい仮説とは違う方向にプロダクトが広がってしまうことがあります。

フィードバックを集める仕組みは、PMF前から用意すべきですか?

早い段階から用意しておくメリットは大きいです。声を集める前の準備については「[顧客の声を集める最初の一歩:機能要望管理を始める前に整理すべきこと](/blog/feedback-collection-before-you-start)」で扱っています。