低業績のチームは、顧客が何を必要としているかではなく、自分たちが何を解決したいかに基づいて問題を選択します。
記載されている意見は私個人のものであり、私の雇用主を代表するものではありません。
優れたデザイナーは、解決策ではなく問題に恋するものだと言われます。私もそう思う傾向があり、新規のお客様に最初にお願いするのは、彼らが直面している問題を説明することです。
数年前、ある顧客が私のところに依頼に来ました： 「当社のCEOが当社のプロダクトを使おうとしました。CEOが私たちのプロダクトを使おうとしたのですが、取引がうまくいかず、ステータスを見ることができませんでした。だから、顧客が自分の取引を追跡できるようにすることは、私たちが解決しなければならない優先的な問題です。」
すでにお気づきだと思いますが、彼らの声明にある問題とは、「ユーザーがこのツールを持っていない 」ということです。
言い換えれば、それは偽装された解決策でした。
しかし、私たちはその顧客のCEOを説得することができませんでした。彼はトラッカーがいないという問題に 「惚れ込んで 」しまったのです。2年間、メトリクスを動かすことなく問題を解決し続けた後、その顧客のチームは、私たちが最初の週に伝えたこと、つまり顧客の問題ではなくプロダクトの問題を解決しようとしていることに気づいたのです。
構築の罠への道はプロダクトの問題で舗装されている
ビルドの罠とは、組織が、それらが生み出す実際の価値よりも、機能の出荷や開発に重点を置いてしまうことです。- メリッサ・ペリ『ビルドの罠からの脱出』
顧客の最初の問題提起が、結果的にプロダクトの問題を定義することになったのは、今回に限ったことではありません。実際、私が目にする最初の問題提起の大半は、「この機能を追加したいので、その定義を手伝ってもらえないか 」といったものです。
これは、このようなチームが一般的にどのように組織されているか、つまり真のプロダクトチームとしてではなく、プロジェクトチームとして組織されていることから理解できます。チームにはアウトプットのゴールが与えられ、その範囲内でのみ意思決定が行われます。フォームファクターに関する決定は、通常、その顧客のCEOのような幹部ステークホルダーによってなされるため、彼らはフォームファクターにすぐに飛びつくのです。
このチームはステークホルダーから「トラッカーを作れ」と言われたため、「ユーザーはトラッカーを欲しがっている」がチームの努力の原動力となりました。あなたがニュースで目にしたことがある他の命令には、「ユーザーはチャットボットを望んでいる」、「ユーザーはダッシュボードを望んでいる」、「ユーザーはマウスへのサブスクリプションを望んでいる」などがあります。
基本的に、これらのチームが問うているのは、「顧客がどんなニーズを持っているか？」ではなく、「このプロダクトに欠けている機能は何か？」です。
彼らはプロダクトの問題を解決しているのです。
成熟度の低いプロダクトチームが成果目標に取り組んだとしても、状況が大きく改善することはほとんどありません。クエリ数やメール送信率といった虚栄的な指標が優位を占め、プロダクトチームは顧客に到達するための最も適切なチャネルを選択することができず、最も高度に計測されたフォームファクターに閉じ込められてしまいます。
ひとたびチームの仕事がプロダクトの問題として枠にはめられてしまうと、その枠を修正することは非常に難しくなります。いくらアイデアを検証しても、間違った方向に進んでいることはわかりません。
ユーザーはダッシュボードにどのような機能を求めているのか」と質問したとき、行間を読むのがよほど得意でない限り、「ユーザーはダッシュボードを必要としていない」と聞くことはないでしょう。
このような仕事は一般的にUX劇場として否定され、そしてそれは正しいのですが、経験の浅い実務家にとっては確かに研究のように感じられるかもしれません。結局のところ、PMは顧客と話し、フィードバックや機能のアイデアを集め、それをもとにロードマップを作成し、優先順位をつけたバックログを作成するのです。これ以上何を望むのでしょうか？
しかし、そのバックログから提供される機能は、すべてユーザーエクスペリエンスの腐敗に貢献するものです。なぜなら、それは「目標に到達できない」という顧客の問題ではなく、「機能が足りない」というプロダクトの問題を解決することを前提としているからです。
顧客の問題がチームを作り、プロダクトの問題がチームを壊す
作業グループが共有のゴールと、そのゴールを達成するための方法を確立したとき、それはチームへと変化します。- 真のチームワークと持続可能な品質文化への深い理解
プロダクトチームは、この間違いを犯していることに気づきません。なぜなら、この間違いは、PMが問題にアプローチするように訓練された、ストーリーとフィーチャーのやり方に組み込まれているからです。Marty Caganでさえ、「ユーザーの問題を解決しているか」を4つの大きなリスクの1つとは考えていません（「買ってもらえるか」が最も近いですが、まったく同じことではありません）。
その代わりに、ケイガンはUXデザイン（そのリスクをキャッチするのに最も適した機能）を「ユーザビリティ」のバケツに入れ、多くのPMがそれに従いました。
その結果、プロダクトチームでデザイナーが費やす時間の大半は、ゴールの問題ではなく、ツールの問題を解決することに費やされています。そして、すべてのツールの問題は、定義上、チームによって生み出された問題であることを考えると、それらの問題を解決することによる全体的なインパクトは極めて低いのです。
もちろん、デザイナーも同様に、顧客の問題よりもデザインの問題を解決することに罪悪感を抱いています。というのも、私たちの分野は、他のデザイナーのためにデザインするというインセンティブを中心に構成されているからです。
そして、ソフトウェア開発者にもこの現象があります。MVPを出荷することで顧客のニーズを知ろうとすると、ユーザー・エクスペリエンスの測定可能な改善を犠牲にすることで、興味深いコーディングの問題を少しずつ解決していくことにすぐに発展してしまうのです。
その結果、プロダクト三人組の3つの「足」がそれぞれ目標を設定し、それをめぐって争うことになります。優先順位付けのプロセスは、「これだけのプロダクトの問題を解決し、これだけの設計の問題を解決し、これだけの開発者の問題を解決する」という駆け引きに変わります。
皆が自分たちのために駆け引きをしている間、顧客に対する共感を発揮する時間は残されていません。 その結果、従業員や従業員と同じような生活をしている人々のために問題を解決するプロダクトの業界全体が出来上がってしまうのです。
プロダクトを忘れ、顧客に集中
「顧客のニーズから逆算することは、膨大な労力を必要とします。しかし、そうすることで、後でさらに多くの仕事を省くことができます。」 - ジェフ・ベゾス
この問題は深い。プロダクトは顧客にとって「望ましい」ものであるという枠組みが、20年以上にわたってプロダクト思考に影響を与えてきたのです。
現実には、顧客にとって望ましいプロダクトなどありません。顧客には望ましい結果があり、それを達成するためにプロダクトが役立つのです。そして、成功するプロダクト戦略は、最終的にどのレベルの成果で勝負するかを選ばなければなりませんが、ウィジェットレベルで勝負することを選択し、資金が尽きる前にプロダクトと市場の適合性を求めて空回りすることは、最も効果的でないレベルです。
プロダクトチームは、ステークホルダーが何を求めているかに基づいてアウトプットを予測するのではなく、ステークホルダーが何を達成したいと願っているのかから始め、その結果からバックキャストして 可能な道筋を描く必要があります。
そうすれば、機能に優先順位をつけるのではなく、柔軟性を損なうことなく、次のステップで実現可能な前進の道筋がどのようなものかを最もよく知ることができるのはどれか、という1つの賭けに出ることができます。 その結果、世界一セクシーなアプリにはならないかもしれません。私のチームが頑固な顧客を説得して最終的に構築したソリューションには、ウェブプレゼンスがまったくありませんでした。必要な情報はSMSで直接送りました。しかし、それは素早く構築でき、安価にテストでき、そして最も重要なことは、顧客のほとんどが見ることのないウェブサイト上のトラッカーよりもはるかに優れた情報を顧客に提供し続けることができたのです。
