Intercom の製品原則: 問題から始めて、より良い解決策を実現する

「私たちが解決しようとしている問題は…」

これは Intercom でよくある冒頭の言葉です。 製品レビュー、ロードマップ ミーティング、または製品担当者からの設計批評だけでなく、会社全体で。

これは、当社の製品原理を探求するシリーズの 8 番目の投稿です。 ここで、スティーブンは私たちのエンジニアリング原則「問題から始める」について説明します。

金曜日の午後の「Show and Tells」の儀式では、会社全体の人々が自分たちが取り組んできたことを実演し、それが彼らのプレゼンテーションを開く方法です - 彼らは問題を説明します. Intercom に新しく参加する場合、オンボーディング パックには最初の「インターミッション」が含まれます。これは問題ステートメントの名前です。 始めるときは、問題に焦点を当てることから始めます。

私たちは正当な理由で問題に執着します。

あなたの解決策は、問題を理解しているかどうかにかかっています。

ほとんどの会社は失敗します。 多くの企業が (特に初期の段階で) 失敗する理由の 1 つは、顧客に存在する実際の問題に対する説得力のあるソリューションを提供していないためです。

失敗したソリューションには、いくつかの一般的なパターンがあります。

• チームは最初から問題をよく理解していなかった
• チームは、問題の理解と、時間の経過とともに問題が解決策にどのようにマッピングされたかを継続的に更新できませんでした
• 問題は解決する価値がありませんでした – ニッチすぎるか、行動を促すほど緊急性がなかった可能性があります

多くの場合、企業は問題からすぐに飛びつき、気に入った 1 つのソリューションにたどり着きます。 彼らは時間、お金、エネルギーをこのソリューションに投資しますが、最終的に誰も実際に気にかけないことに気付くだけです.

「真に偉大な企業は、人々に何かを欲しがらせるよりも、人々が欲しがるようなものを作る方が簡単であることを認識しています。」

真に優れた企業は、人々に何かを欲しがらせるよりも、人々が欲しがるようなものを作る方が簡単であることを認識しています。 それが私たちが Intercom でやろうとしていることです。私たちは、対象となる顧客が経験する実際の問題を理解することから始めます。 単純なことのように聞こえるかもしれませんが、問題に焦点を当てることが非常に重要であるのに、それを実行する企業がこれほど少ないのはなぜでしょうか?

人々は解決策を考えるように配線されています

「問題を持ち込むのではなく、解決策をもたらしてください」というフレーズを誰もが聞いたことがあるでしょう。 私たちの脳は、常に目の前の問題を解決しようとしています。 しかし、お客様の問題を分解、調査、分析することに時間を費やさなければ、当社のソリューションは的を射ていないリスクがあります。 問題が見落とされ、即時の解決策が優先される理由のいくつかを次に示します。

「課題は、システム ビューを作成し、システムがどのように連携しているか (または機能していないか) を理解することです」

1. あなたの製品はシステムです

製品、会社、および顧客ベースが大きくなるほど、あいまいな問題を正確に診断することが難しくなります。

関係する要因はますます増えており、課題は、システム ビューを作成し、システムがどのように連携しているか (または機能していないか) を理解することです。 たとえば、製品の使用率が低い場合、それはなぜですか? それはユーザー エクスペリエンスや教育の問題ですか、不足している機能ですか、それとも何か他のことですか?

2. 問題定義が難しい

人々はしばしば、自分が抱えている問題を自分が望む解決策の形で説明します。 多くの製品チームはそこで立ち止まってそのソリューションを構築しますが、実際の問題は数層深く埋もれているため、通常は的を外しています。 優れた製品チームは前進し続け、その理由を問い続けます。

「問題の定義とは、あなたの頭から離れて彼らの頭の中に入ることであり、彼らが最初に説明することではなく、彼らの実際のニーズの根底に到達することを意味します。」

これは、感情的に難しく、時間がかかる場合があります。 それには、多くの顧客と何度も話し合い、新しい角度や新しい質問を掘り下げる必要があります。 それは、あなたの頭から離れて彼らの頭の中に入ることを意味し、彼らの実際のニーズの底に到達することを意味します - 彼らが最初に説明することではありません.

3. ソリューションは光沢があります

よりエキサイティングなのは、研究レポートか、新しい実用的なプロトタイプか? 私たちのほとんどは、新しいクールなものを見るのが大好きです。 レポートを読む時間はありません。 熟考して深い知識を得ることは、退屈で重要ではないと考えられることがよくあります。

Intercom では、華やかさよりもインパクトが重要であることを理解しています。 私たちは、その後の作業の強力な羅針盤になることがわかっている、素晴らしく書かれた問題文を見ると興奮します。

4. 目に見えるアウトプットと「進歩」への偏見

場合によっては、チームが数週間の作業を行って、解決すべき問題を明確に示す短く単純な段落のアウトプットを作成することがあります。 このプロセスを重視しない人にとって、アウトプットに基づいてその重要性を売り込むことは困難です。

実際の問題から離れている利害関係者は、「目に見える進歩」に向かう傾向があります。彼らは、問題が解決するかどうかに関係なく、解決策によって安心する可能性が高くなります。

それで、それが問題なら、解決策は何ですか？

「問題から始める」は、私たちの研究開発のコア原則の 1 つとして前面に出ており、その重要性を示しており、私たちが仕事をする際に常にそれを念頭に置いていることを示しています。 それはトリガーでもあります。 それは、私たち全員が活用できる具体的な期待とツールを活性化します。 Intercom で問題に優先順位を付ける方法のいくつかを次に示します。

問題に集中する許可を与える

Intercom ではプロセスよりも原則を重視しているため、アジャイル、リーン、またはその他の製品開発プロセスに従うかどうかに関係なく、この原則はどこに焦点を当てるべきかを示しています。

ほとんどの企業は、ソリューションの設計と構築に時間を費やしており、解決する必要がある問題の理解と優先順位付けにあまり重点を置いていません。 各チームに 100 単位のフォーカスが与えられた場合、多くの場合、次のように使用されます。

ほとんどの企業は、ソリューションの設計と構築に多くの時間を費やしています

ほとんどの企業は、ソリューションの設計と構築に時間の大半を費やしてから、顧客にベータ版をリリースします。 これは欠陥のあるアプローチであり、弱い問題理解に基づいてソリューションを構築することに大きく偏っていると私たちは考えています。 対照的に、Intercom での時間をどのように過ごすかについての大まかなガイドを次に示します。

Intercom では、問題の優先順位付けと改良に多くの時間を費やして、各ステージに均等に時間を割いています。

100 単位の 3 分の 1 は、何かを設計し始める前に費やされます。 この段階では、問題の優先順位付けと問題の定義に執着し、より多くのことを学ぶにつれて、問題の理解を継続的に再定義します。 プロセスの開始時にこの時間を費やすことで、何を構築する必要があるかを把握し、それをより迅速に顧客の手に届けることができます。

問題定義の期待を特定します

私たちの原則はすべて、規模や労力が異なる可能性があり、問題の定義に費やすべき一定の時間はありません。 プロセス全体を通して、1 時間、1 日、1 週間、または 10 週間を費やすことができます。 個人やチームがトリアージを行い、特定の問題に投資するための適切な取り組みを決定できるように、いくつかのガイドラインを使用します。

1. 問題と解決策の間を行き来しても大丈夫

Charles Conn と Robert McLean は、著書『 Bulletproof Problem Solving 』で、これを「問題と解決策の間のポーポイズ」と呼んでいます。 この 2 つの間を行き来することで、それぞれの理解が深まりますが、重要なのは、問題または解決策に対する自分の見方に夢中にならないことです。

「顧客とビジネスのニーズを同時に考慮しようとすると、混乱を招く可能性があります」

2. ビジネスの問題ではなく、顧客の問題から始める

顧客とビジネスのニーズを同時に考慮しようとすると、混乱が生じる可能性があります。 私たちは、これらの問題のビジネスへの影響を考慮する前に、意図的に顧客の問題に焦点を当てることから始めます。 解決しようとしているのがビジネス上の問題である場合は、それを顧客の問題に直接結びつけるようにしてください。

3. 誰がこの問題を抱えていて、何をすべきか?

顧客の期待と現実の間にギャップがある場合に問題が発生します。 あなたが期待している期待と経験、そして彼らが達成しようとしている結果を定義する必要があります。

4. 問題の深刻さに焦点を当てる

問題が影響している顧客の数と、その影響の深刻度は?

「あまりにも多くの場合、問題のステートメントは曖昧で高レベルです」

5. 衝撃を追う

Intercom では、問題定義プロセスの一環として、事前に成功指標を指定します。 これにより、問題を解決したことを確認するために注意すべき重要な顧客行動の変化を知ることができます。

6.具体的に

多くの場合、問題のステートメントは曖昧で高レベルです。 問題の定義において、解決策を見つけるのに十分なレベルの具体性に到達することが重要です。

7. 問題の範囲を絞り込む

多くの場合、問題には層があり、顧客や製品によっては、それらに触発されることがあります。 問題を分解して各次元に焦点を当てることは重要ですが、問題を解決策の選択肢にマッピングして、どれが最適かを判断できるようにすることも重要です。

誰もが共通の形式に従っていることを確認するためのガイドとしてテンプレートを使用していますが、このドキュメントには多くの場合、別の場所にある多くの背景調査が付随しています.

「プロセス中、そして最も重要なことには、出荷後にさらに学ぶにつれて、問題に対する考え方を更新します。」

問題定義は土台です。 そこから、私たちの原則がシステムとして連携して、問題から解決策へと私たちを動かします。 プロセス中、そして最も重要なことには、出荷後にさらに学ぶにつれて、問題に対する考え方を更新します。

私たちは問題に対してチーム全体でアプローチします

Intercom では、全員がさまざまな専門分野を持つ製品担当者です。 プロダクト マネージャーが問題の定義を担当している場合がありますが、すべての人は、直面している問題を掘り下げて理解し、実際に解決する責任を負う責任があります。

これは、問題定義へのアプローチを通知します。 これは、より多くの人々を調査に参加させ、インタビューや洞察を共有して共有理解を構築することを意味します。 このアプローチに適応してその価値を理解するには時間がかかる場合がありますが、ビルドの効率とソリューションの精度を向上させるために努力する価値は十分にあります。

Intercom のエンジニアリング チームは、問題から始めて、より思慮深く適切なソリューションを設計できます。 Intercom での働き方に興味がありますか? エンジニアリング チームの詳細をご覧ください。