「この機能を構築してください」、「この統合はどこにありますか?」、「競合他社はそれを行っていますが、なぜ私たちはそうしないのですか?」さらに悪いことに、これらのリクエストはすべて、おそらく 10 の異なるプラットフォームから送られてきます。
プロダクト マネージャーの日々は、社内外の利害関係者からの絶え間ない要求でいっぱいです。そして、現在のロードマップと 1 日の 5 杯目のコーヒーにすでに取り組んでいる場合、これらの終わりのない着信要求すべてについて考えを巡らすのは難しい場合があります。つまり、私たちは結局のところ人間です。
そして、これらすべての中で、目前の問題を解決し、製品の実際の問題を理解して全体像を見て、問題/機会が解決する価値があるかどうかを評価することになっています.しかし、困難な経験にならないようにするにはどうすればよいでしょうか?
そこで、構造化された思考が役に立ちます! PM としての構造的思考を確保するためのベスト プラクティスをいくつか見てみましょう。
Jasper Curry 氏によると、プロダクト マネージャーはしばしば意思決定疲労に悩まされます。なんで?単純に、私たちの仕事の 90% は正しい決定を下すことにかかっているからです。どの機能を構築しますか?いつそれを構築するのですか? … もっと。だからこそ、私たちが下すすべての決定に対して過度に積極的でなくても問題ありません。
リソース: Jasper Curry による製品管理における構造化思考
決定を下す前に、次の点に注意してください。
決定が可逆的である場合、それについてあまり深く考えなくても大丈夫です。ジェフ・ベゾスも、この手法を使用して意思決定を行っていることで有名です。彼は次のように述べています。これらの決定は、軽量プロセスを使用できます。」
最悪のシナリオを考えてみてください。間違った決定の結果が限られている場合は、それにあまり時間をかけないのが最善です。
たとえば、「サインアップ」リンクをボタンに変更する決定を下してみましょう。現在、この決定の結果が否定的であったとしても、簡単に元に戻すことができます.これは、これについて考えるのに多くの時間を無駄にする必要がないことを意味します。
一方で、会社のロゴを変更するという決定を下してみましょう。まず第一に、実行には多くのリソースが必要であり、会社への影響は非常に大きくなる可能性があります。 Uber がロゴを変更し、誰もアプリを認識できなくなったときのように。このような決定は、適切に検討する必要があります。
リソース: Brandon Chu による製品マネージャーとしての適切な意思決定
Google の PM である Madhur Chadha は、作成、キュレーション、消費という 3 つの C を使用して、PM の旅を整理し、体系化しています。問題は、これらのバケットに分離できます。
たとえば、WhatsApp をプラットフォームとして改善したい場合、何をしますか?
作成: WhatsApp を改善するために次のことを行う必要があります。
– より多くの人に WhatsApp に参加してもらう方法 – より多くの人に WhatsApp Pay を使ってもらう方法
キュレーション:キュレーションには、作成中のステップを達成する方法が含まれます。 – 青いチェック チャット オプションのオン/オフを切り替える
– 暗号化されたメッセージ – 他の決済アプリとの統合
– より多くの絵文字、ステッカー、GIF – WhatsApp 内のカスタム ステッカーと GIF
消費:消費は、ユーザーがこれらの機能とさまざまな配布チャネルをどのように消費するかです。
– ビジネスの支払い、モバイル リチャージなど
– さまざまなデバイスと表面
– グループチャットとブロードキャスト
これは、何をどのように行う必要があるかを分解するためのシンプルかつ効果的な方法です。そのため、圧倒されずに、必要な場所に注意を向けることができます。
リソース: Madhur Chadha による思考の構造化
やみくもに問題に飛び込む前に、プロダクト マネージャーは、解決策を見つけることよりも問題の枠組みを設定することが重要であることを理解する必要があります。あなたの視点から問題について質問することはできますが、問題の解決策はすべての顧客のユースケースに適合する必要があります。つまり、さまざまな視点から問題を理解するには、問題のさまざまなフレームを用意する必要があるということです。どうやってそれを行うのですか?
課題または問題の概要を部門横断的なさまざまな利害関係者に説明し、解決策を考え出すよう求めるのではなく、問題に関するさまざまな質問を考え出すよう求めます。
例: 2008 年、YouTube は Google に次ぐ第 2 位の検索エンジンでした。ユーザーが YouTube に存在しないコンテンツを探していることがすぐにわかりました。そのため、質問は次のとおりです。「ユーザーが何かを検索し、最良の結果が得られないことがわかっている場合、サードパーティの Web サイトに「リンク」する必要がありますか?」同社の半分は、検索したコンテンツにサードパーティのリンクを追加することを提案しましたが、残りの半分は、トラフィックをサイトから遠ざけるとコンテンツをネイティブにライセンスするのは難しいと主張して反対しました.
問題を「サードパーティのリンクを追加する必要があるかどうか」という枠組みではなく、「一貫性と包括性」のどちらかを選択する別の枠組みが作成されました。彼らは多くの企業を調査し、顧客は包括性よりも一貫性を好むことを発見し、この問題についても同じことを受け入れることに同意しました.彼らは、サードパーティのリンクを追加しないことにしました。 YouTube の外にリンクしないことは、彼らの中心的な原則の 1 つになり、他の一連の難しい決定を組み立てました。たとえば、クリエイターがさまざまなデバイスからコンテンツをオプトアウトする機能を削除し、サードパーティの埋め込みプレーヤーをすべて削除しました。
リソース:フレーミング問題の芸術
もう 1 つの課題は、同じ問題について非常に多くの質問があるため、それぞれの解決策を見つけるのが難しい場合があることです。これを行うもう 1 つの方法は、収集した質問のリストから、その回答が問題を効果的に解決する最も重要な上位 2 つの質問を選択することです。これにより、本当に重要な質問に集中して深く考えることができます。これらの質問に対する解決策を見つけてください。これら 2 つの質問に対する解決策は、他の質問にも同様に回答することがよくあります。
「問題を解決するのに 1 時間あれば、問題について考えるのに 55 分、解決策について考えるのに 5 分を費やします。」アルバート・アインシュタイン。
問題ステートメントは、目の前の重要な問題に集中するのに役立ちますが、これを行うと、潜在的な解決策も含めるように誘惑されます.アイデアは解決策を見つけることではなく、ターゲット ユーザーの立場に立って、彼らの視点から問題を考えることであるため、これを行うことを控えることが重要です。
問題文を見つけるための簡単な式は次のとおりです。
標準式:
(共感的な言葉を使って人を説明してください)
例: 当社の製品管理プラットフォームの使用を好む XYZ & co の Patty は、選択した顧客からのフィードバックを Excel シートにエクスポートして、エンジニアリング チームに送信し、同じ機能のさまざまな使用例について話し合うことができるようにする必要があります。
リソース: 製品管理ツールキット
これには時間がかかる場合があります。ユーザーにとって最も都合の良いときにインタビューをスケジュールし、忙しいスケジュールの合間に時間を割いてユーザーと話をすることはできますが、ユーザーの視点を提供するのに最適なのはユーザー自身です。だからこそ絶対に必要な投資です。
ユーザーが製品/機能を使用して、検証せずに特定のタスクを実行すると仮定することはできません。たとえば、ユーザーがタスク A、B、および C を実行できるように製品を構築しているが、ユーザーはおそらくタスク D を実行するために製品を使用したいと考えているとします。
リソース: Jobs to do by Alan Klement
5 なぜなぜ手法は、豊田自動織機の創業者である日本の実業家、豊田佐吉によって開発されました。 「なぜ」を5回繰り返すことで、多くの発見があり、問題の核心にたどり着きます。ユーザーが問題の説明を伝えたら、その理由を自問してください。 「なぜ」の答えが分かったら、もう一度「なぜ」を尋ねます。最後の「なぜ」に対する答えが問題の根本原因を説明するまで、これを続けてください。
リソース: Thaisa Fernandes による 5 つの理由テクニック
これらは、一部の PM が日常的に宗教的に従い、仕事を終わらせるための時間を確保するためのヒントとコツです。 1 日のスケジュールがどれほど事前に決まっているように見えても、PM は土壇場での会議やディスカッションに簡単に引き込まれてしまい、優先度の高いタスクに集中する余地がありません。
毎日のハイライト: 毎日完了する必要がある重要なタスクを 1 つ選びます。どんなに忙しくても、予定外の会議にどれだけ参加しても、あなたの目標は、その日のログオフ前にその 1 つのタスクを完了することです。
2 分/5 分のタスク: 5 分以上かかると思われるタスク ボード内のタスクは、タスク ボードに含めるべきではありません。これは単に、その日の最初の電話に出る前に、そのようなタスクを完了する必要があることを意味します.例: 会議のフォローアップ、会議のスケジュール設定、電子メールの送信などの小さなタスク。
これらすべてのタスクを完了するのは、特にタスク ボードに 100 個のものがあり、関係者がさまざまなプラットフォームで繰り返しフィードバックを提供し、エンジニアリング チームが何に取り組まなければならないかを知りたがっている場合などには、困難な経験になる可能性があります。
Zeda.io はオールインワンの製品管理ツールであり、日々の PM の苦労をすべて整理し、すべての利害関係者とその要求を 1 か所にまとめて、ロードマップを完璧に仕上げるのに役立ちます。そして最高の部分は?クレジット カードがなくても、今日から 1 か月間の無料トライアルを開始できます。