プロダクト マネージャーのやること (完全な製品ワークフロー: プロダクト マネージャーが行うべき 25 のこと)

製品完成ワークフロー: プロダクトマネージャーがやるべき 25 のこと

製品の世界における数多くの永遠の疑問の中に、常に 1 つあります。それは、 「あなたは何をしますか?」です。

お祭りのときに親戚や友人からこのことについて聞かれたら、あなたはショックを受けるかもしれません。

インターネット業界に携わっていない人にとっては、この答えの適切さを判断するのが難しい場合がよくあります。テクノロジーについてあまり話すと、人々が理解できなくなるのではないかと心配です。あまり話さないと、管理者だと思われてしまうのではないかと心配です。上手に話せなければ、銀行の窓口のプロダクトマネージャーだと思われてしまいます。それでとても疲れを感じます。

この目的のために、著者はプロダクトマネージャーの完全なワークフローを要約し、プロダクトマネージャー独自のワークフローである少なくとも 25 の項目を整理しました。

以下の内容が皆さんのインスピレーションになれば幸いです。まずマインドマップはこちらです:

著者は、後続の最適化と製品運用の範囲を除いて、製品の完全なプロセスを 0 から 1 まで分類し、製品の分類、製品の設計、製品の実装という 3 つの主要な段階を取得しました。

3 つの段階では、製品マネージャーが少なくとも 25 の作業を行う必要があります。そうしないと、製品の有効性に大きな影響を与えます。詳しく見ていきましょう。

プロダクトマネージャーは、アイデアがどこから来たかに関係なく、アイデアを見つける必要があります。良いアイデアを思いつくには、マインドマッピングやブレーンストーミングのテクニックを習得し、柔軟で多様なアイデアを生み出して記録する必要があります。

需要に関しては、心理学やその他の分野の知識を活用してアイデアを明確な需要にまとめ、分析のために需要プールに入れる必要があります。

計画については、需要プール内の要件を洗い出し、既存のリソース環境下で実行することが適切かどうかを検討し、大まかな計画と作業負荷スケジュールを提示する必要があります。

製品が達成すべき目標と効果を示す必要があります。クールな機能だからという理由だけで何かを実行することはできません。何がそれをクールなものにするのかを見極める必要があります。

目標を設定した後は、それが抑制的なものか広範なものか、慎重なものかオープンなものかといった戦略も検討する必要があります。これらすべてについて私たちは考える必要があります。

目標と戦略を明確にした後、製品の定義を与える必要があります。製品の定義は、後の需要評価の中核となります。すべての要件と優先順位は、当社の当初の意図でもある製品定義に違反してはなりません。

これらのタスクを完了した後でも、短期間で解決するのが難しい問題や試行錯誤が必要な問題が必ず残ります。したがって、欠点を記録し、後の製品反復プロセスでそれらに焦点を当てる必要があります。

対象ユーザーとシナリオを踏まえて、一つずつ解決策を提案し、推論を行います。

シナリオを作成した後、ユーザーのビジネスプロセスを統合して整理し、各リンクの状況を全体として確認できます。

シナリオとプロセスを明確にした後、機能構造図を作成してください。ここでも、今度は計画に焦点を当てた激しい会議が必要です。

全体的な機能的なサイトマップを作成した後、ページ間のジャンプ関係と各ページの特定のコンテンツの概念的な計画を追加する必要があります。

ページの全体的なコンテンツと関係性を確定したら、コンテンツを改良する必要があります。現時点では、デザイナーがインタラクティブなドラフトを提供できるように、需要側やユーザーとつながり、各ページの実際のデータを取得するための調査を実施する必要があるかもしれません。

インタラクティブなドラフトが提出された後、関係者全員による確認が必要です。正解であれば、デザイナーにレンダリングとカットアウトが提供され、開発を開始する準備が整います。

フロントエンドに必要な要件、計画、要件定義書、レンダリングなどの資料を入手したら、スタッフ全員を集めてプロジェクトキックオフミーティングを開催してください。これは、要件が交換され、進捗状況がわかっていることを示しており、開発の遅延を回避するために非常に重要です。

開発の初期段階、特にスタートアップの場合は、ユーザー検証を行ってください。これは、試行錯誤を繰り返して方向の逸脱を避け、道に迷って大きな埋没コストを被らないための最も簡単な方法です。

検証後、いよいよリソース投資を確定します。不明確なポジショニングや規模の達成困難を回避するために、必ず上層部に確認してください。

すべて確認できましたら、カレンダーをご提供ください。これはプロジェクトの進捗状況の追跡にとってさらに重要であり、リーダーとユーザーに対する安心感としても役立ちます。後からのレビューにも大変役立ちます。

レポートは上記のすべてを通じて実行されますが、この段階では特にレポートが必要です。この段階での報告は、需要の表層を示すものであり、経営トップが重視する期待のポイントです。皇帝の剣を求め、その後の行動を円滑にするためには、十分に報告する必要があります。

開発段階に入った後は、プロジェクトの進捗状況を追跡し、作業負荷を調整して、後の受け入れ最適化のための時間を稼ぐ必要があります。

フロントエンドの開発が完了したらすぐにテストエンジニアが環境の準備と確認を行えるように手配し、デザイナーが時間内に最適化できるよう時間を確保してください。検査後、フロントエンドの修正を待つために問題の概要メールが送信されます。検査後、フロントエンド開発者と直接面談して各問題を確認し、開発者が明確に理解し、修正方法を理解していることを確認する必要があります。変更後はできるだけ早く承認し、複数回の検査を実施してください。

要件変更や要件ドキュメントをタイムリーに更新し、プロモーターが使用できる操作マニュアルや FAQ を準備してください。

フロントエンドの検査と承認に加えて、環境全体とデータ ロジックをテストおよびデバッグして、問題をタイムリーに検出して解決する必要があります。

これは私たちにとって最も重要な部分であり、各全体的な機能が UAT され、完了後に小規模で試用できることを保証します。そうでない場合は、オンラインになるまで棚上げになります。 UAT が適切に行われず、インタラクションに重大な脆弱性がある場合は、次のバージョンが修正されるまで待つしかありません。これは製品の評判に大きな影響を与えます。

公開する際は、コールドスタート計画からプロンプトまで、タイミングと戦略を検討し、すべてを考慮するようにしてください。そうしないと、クラッシュやパッケージング エラーが発生する可能性が高くなるため、リリース フェーズ中に徹底的なテストを行う必要があります。

これら 25 項目を整理した後、それぞれに簡単な専門用語と説明を付けました。

上記の質問には次のように答えられると思います。

プロダクトマネージャーとして、需要分析から発売までの全プロセスを担当しており、業務内容は20を超えるタスクに及びます。

インタビューのシナリオについては、対応する回答も提供できます。

前の会社では、2つのプロジェクトに携わりました。私はメイン編集者として全体的な要件ドキュメントを管理するだけでなく、プロジェクト開始段階でのユーザー検証やストームミーティングのプロモーションも担当していました...

かなりプロフェッショナルに見えませんか?

多くの場合、それを整理して具体的に表現していないため、自分が何をしたのかわからないことがあります。混乱したプロセスの中で、多くのコミュニケーションと表示が隠されていました。したがって、プロダクトマネージャーは仕事をうまくこなすだけでなく、うまく話し、うまく要約し、うまく報告する必要があります。そうして初めて、あなたの心の中にある輝く星空をみんなと共有することができるのです。

誰もがプロダクトマネージャー、WeChat パブリックアカウント「The Art of Product」のコラムニスト、ミスター・ピーナッツバター。金融業界のシニアプロダクトマネージャーであり、キャリアプランニングと自己啓発の分野で豊富な経験を持っています。 ERPや金融分野を中心に幅広い製品を取り扱っています。

この記事はもともと「Everyone is a Product Manager」に掲載されました。無断転載は禁止です。

タイトル画像はCC0ライセンスに基づいてPixabayから引用しています