プロダクトマネージャーとオペレーション（プロジェクト思考からプロダクト思考へ、業務効率を向上させる新しいアイデア）

プロジェクト思考から製品思考へ、業務効率を向上させる新しい方法

プロダクト思考を活動にどのように適用するかについては後ほど説明しますが、まずは次のストーリーを見てみましょう。

昨年の初め、ハワイの人々は突然、ミサイルがハワイを攻撃していると警告し、防空壕に避難するよう求め、これは訓練ではないと強調する警告テキストメッセージを受け取った。言うまでもなく、世間はパニックに陥ったが、実はこれは「誤解」だった。その日、ハワイ軍事緊急事態管理局の職員はミサイル警報システムをテストする必要があったが、テキストメッセージを送信する際に間違ったオプションを選択し、「警報をテスト」ではなく誤って「警報を送信」をクリックした。その結果、大きなパニックが起こりました。

ハワイミサイル誤報事件

このストーリーを運営者の視点で見ると、活動のステップに応じて活動ノードを設定し、各ステップの担当者を計画し、最終的にオンラインで活動のプロモーションを開始するという、全体が実は非常に馴染み深いものであることがわかります。すべては完璧ですが、ユーザーがイベントに参加する方法はもちろん、どこをクリックすればよいのかまったくわかりません。つまり、物語の中の「早期警戒テスト」と同じように、この活動は完全に失敗したのです。

私たちはしばしば、物語に出てくるミサイル早期警戒システムの計画者のように、最終的な実施の実際の結果を考慮せずに、活動を段階的に計画してしまいます。

これは単に「一歩間違えればすべてを失う」という問題ではありません。日々のプロジェクトでは、次のような同様の混乱に遭遇することがあります。

• 全体的な活動プロジェクトの会議では、設計者、プロモーター、さらには開発者がプロ​​セス内のバグを発見します。
• ユーザーはイベントへの参加方法がわからず、何度もガイドしてもらう必要があり、カスタマーサービスのプレッシャーが急激に増大します。
• 上司が突然、活動プロジェクトに関して質問を投げかけてきたが、どう説明すればいいのか分からなかった。
• 活動の効果を高めるためのヒントやコツをたくさん読んできましたが、実際にどのように活用すればよいのか全くわかりません。

実際、これらの問題が発生するのは、実際の結果よりも出力に重点を置く傾向があるためです。私たちは「プロジェクト思考」を使うことに慣れていますが、「製品思考」が欠けています。

いわゆる「プロジェクト思考」とは、結果に対して責任を持ち、結果の提供に重点を置くことを意味します。この考え方は、タイムライン、スケジュール、アクション プランなどを使用して作業をガイドすることで、仕事にマッピングされます。

プロジェクト思考を仕事の指針に適用する最も良い例の 1 つは、プログラマーです。コーディング作業の本質は実行レベルにあります。プログラマーは、製品要件と設計案に基づいて目標を達成する必要があります。この実装プロセスでは、作業負荷や技術的な問題など、多くの問題が制御可能であるため、時間と結果を事前に見積もることができます。事前に計画したスケジュールに従って、段階的に物事を進めていくだけです。

プログラムの作成から飛行機の製造、家の建設まで、このタイプの仕事の考え方は、アウトプットと結果の提供に重点を置いています。まず、プロジェクトの実施方法がすでにわかっていると仮定し、その仮定に基づいてタイムラインと実行計画を分割し、実行を開始する必要があります。

しかし、オペレーターが依然としてこのプロジェクト思考で作業する場合、多くの問題が発生します。

• 私はイベントの完全なスケジュールを計画し、人々に責任を割り当てましたが、毎回予期しない出来事が発生し、誰もスケジュールに従えませんでした。
• 店舗の売上を伸ばすためにイベントを企画しましたが、結局店舗の売上は伸びませんでしたが、コレクションの数は大幅に増加しました。
• 活動計画を作成しましたが、1 つのステップが遅すぎたため、残りのステップが時間どおりに完了しませんでした。

見つかりましたか？オペレーターとして、作業を段階的に実行することはできません。あなたの仕事は柔軟性に富んでいるので、新しいアイデアが必要です。

「プロダクト思考」とは何でしょうか?製品思考とは、すべての決定が「ユーザー主導」で行われること、ユーザーの悩みやニーズを発見すること、市場を効果的に判断すること、情報とリソースを統合すること、そして人間性を理解することを意味し、段階的なスケジュールによって決定されるべきではありません。

製品の考え方は、コンバージョン率、取引量、閲覧量、ユーザー数ではなく、ユーザー自身から始まります。先ほど述べた 3 つの問題に遭遇した場合、正しいアプローチは、まずスケジュールと当初想定していた計画を放棄し、代わりにすぐにプロジェクトの目標自体に焦点を当てて活動を調整することです。

つまり、下の図に示すように、計画の策定からアクティビティを実行するのではなく、目標とユーザーエクスペリエンスから計画を推測します。

製品思考意思決定マップ

プロダクト思考自体は、5つのキーワードにまとめることができます。次の 5 つのポイントに注意すれば、この新しいアイデアを最初に理解できるはずです。

1. ユーザー指向。ユーザーのニーズを理解し、ユーザーのニーズに基づいて決定を下す。
2. 単純な考え方。活動の核となるプロセスを把握し、不要なものを排除して、活動がスムーズに実行されるようにします。
3. 相手の立場になって考えてみましょう。活動プロセスをさまざまな側面や角度から考え、設計、開発、上司の視点からプロセス全体を見直します。
4. 効果的な思考。活動が目標を達成できるかどうか、また活動の有効性を高めるのに効果的かどうかを繰り返し確認します。
5. MVP テスト。アクティビティを開始する前に、テスト対象の少数のターゲット ユーザーを選択し、テスト結果に基づいてアクティビティを変更します。

これまで多くの概念的な事柄についてお話ししてきましたが、おそらくこれを読んだ後もまだ混乱しているかもしれません。大丈夫です。上記の内容の一部をよりよく理解できるように、例を挙げてみましょう。

独自のアプリと公開アカウントを持つ採用プラットフォームは、より多くのターゲットユーザーを獲得するための活動を組織する必要があります。利用できるリソースと制限は次のとおりです。

• 対象者：新卒者または卒業予定の学生
• 地域: 武漢地域
• 外部トラフィック: 1. 新規顧客を引き付けるための予算がほとんどありません。 2. 相互促進や交流などの活動は効果的ではない
• 内部トラフィック：1. ユーザー数が少なく、公式アカウントの閲覧数は1,000程度。 2. ユーザーグループは3つあるが、インタラクティブ性が非常に低い

さて、この場合、私たちは何をすべきでしょうか?

この活動に「プロジェクト思考」アプローチを採用すると、次のようになります。

1. 予算を決定し、広告を掲載できるチャネルと置き換え可能なチャネルをリストします。
2. 新卒者向けの就職フェアを企画し、有料または無料のさまざまなチャネルを通じてニュースを広めます。
3. 資料を作成し、オフラインの大学に滞在して活動を促進します。

しかし実際には、この伝統的なアプローチには、人材の浪費、効率の低さ、新卒者がプラットフォームに同意しない、予算が少なすぎるなど、多くの問題があります。そして最も重要なのは、活動の最終的な効果が非常に「宿命的」であることです。

新しいアイデアでもう一度挑戦してみましょう——

1. 市場調査。武漢の大学卒業生のデータを調べ、市場規模を調査し、規模の判断に基づいて活動の投資と時間を決定します。
2. ターゲットユーザー調査。グループまたは他のチャネルで、インタビューや調査を行う複数の卒業生を見つけ、このグループのニーズを特定し、キーワードを抽出します。
3. 新卒者のニーズに基づいた情報を見つけます。ユーザー調査によると、新卒者は「インターンシップ先をどうやって探すか」「面接に向けて何を準備するか」「関連情報を入手するにはどんなチャネルを利用すればよいか」「オファーの選び方」などの問題に非常に困惑していることがわかりました。
4. 競合製品を調査し、新規顧客獲得活動や販促チャネルの形態を決定します。競合他社の活動を調査し、卒業生の関心を引くトピックを提示して参加を促すために、その活動を「オンライン講義」の形で実施できるかどうかを判断します。
5. MVP テスト。事前に少数の対象ユーザーと講義を共有し、彼らの受け入れ度とフィードバックをテストします。
6. フィードバックに基づいてコンテンツを調整し、プロモーション チャネルを通じて正式にリリースを開始します。

調査、反復、テストを行って、運用効率を真に向上させます。

製品思考は、実際には基本的な能力であり、基本的な作業方法です。業務だけでなく、さまざまな場面で活用できます。 「すべてはユーザーから始まる」というプロダクト思考は非常にシンプルに見えますが、実際の活動実行過程でその考え方を変えることは実は非常に難しく、段階的な進歩が必要です。そして、今からこの認識を持ち始めると、それは良いスタートとなるでしょう。

この記事の冒頭のストーリーをもう一度見てみましょう。もしあなたがこのミサイル早期警戒システム プロジェクトの計画担当者だったら、ストーリーにある問題を回避するためにプロダクト思考をどのように活用しますか?

この記事はもともと @福鲁网络 によって Everyone is a Product Manager に掲載されました。許可なく複製することは禁止します。

タイトル画像はUnsplashより、CC0契約に基づき提供