プロダクト・イネーブルメント - What、Why、How、When、そしてブロッカー
この記事は、以下サイトの機械翻訳です。
プロダクト主導の文化をスタートさせるには、プロダクトを社内に普及させるためのプロセスである「プロダクト・イネーブルメント（有効化）戦略」が必要です。そう、社内でプロダクトの認知度を高めることです。この記事では、Why、How、Whenといったプロダクトイネーブルメントの101の要素と、プロダクトイネーブルメントを行う上でよくある障害についてご紹介します。
なぜプロダクトイネーブルメントが重要なのか？
お客様への対応を担当するプロダクトサポートグループがあっても、プロダクトの深い知識を必要とする質問には答えられないことを想像してみてください。
そのような質問はすべてプロダクトマネージャーに回されます。お客様の数が増えれば増えるほど、質問も増えていきます。プロダクトマネージャーはこれらの質問に答えるのでしょうか、それとも次の機能の構築に取り組むのでしょうか？
組織内のさまざまなグループに、プロダクトに関する関連情報や実際にプロダクトを使った経験を提供することで、彼らは自分の仕事をよりよくこなすことができ、あなたはコア機能である、より優れた、より競争力のあるプロダクトの構築に集中することができます。
しかし、単に成果物やプロダクトへのアクセスを社内の誰もが利用できるようにするだけでは不十分で、適切なタイミングで適切なコンテキストで利用できるようにすることも重要です。
いつ、どのようにして社内グループを有効にするのか？
プロダクト開発のライフサイクルのさまざまな段階で、さまざまな社内グループに働きかけることで、効率的かつタイムリーにイネーブルメントを行うことができます。ここでは、社内グループをイネーブルメントする方法をいくつか紹介します。
- ロードマップの計画時には、営業、マーケティング、アカウントマネジメントの各グループを巻き込んで、今後の展開を把握してもらう。また、プロダクトマネージャーは、これらのグループからのフィードバックを受け取ったことを確認し、優先順位付けの思考プロセスを説明することで、現在の顧客と見込み客の両方に伝えることができるようになります。
- スプリント期間中に行われるアーキテクチャのレビューに、技術グループ（生産管理、SRE、実装サービス）を参加させ、既存のプロセスへの潜在的な影響を認識させる。プロダクトの技術的な側面に精通するために、トレーニングやデモ環境を構築し、これらの環境を常に最新の状態に保つようにする。これにより、プロダクトをサポートするために必要なスキルセットや帯域幅についての情報を得ることができます。
- 新機能のQAにトレーニングチームやプロダクトサポートチームのメンバーに参加してもらい、フィードバックを募る。多くの場合、トレーナーは、類似プロダクトのユーザーであったり、現在のユーザーと同じビジネス機能を果たしていたりする人たちです。
- 通常のドキュメントを更新－プロダクトガイド、ユーザーガイド、リリースノートなど。これは、ビジネスの定義やプロセスがどのように変化し、その結果、プロダクトの機能更新や新機能の必要性が生じるかを把握する方法として、チームメンバーの助けになります。また、各機能にまつわるコンテキストも確立されます。これらの成果物を常に最新の状態にしておくことは、組織の他のメンバーがプロダクトマネジメントグループと同じ見解を持っていることを確認する上で非常に重要です。
プロダクトイネーブルメントのブロッカーとなるものは何でしょうか？
これまで説明してきたことに従っていれば、特にゼロからプロダクトを作っている場合には、素晴らしい生活を送ることができるでしょう。しかし、多くの場合、忙しい組織の中で半成熟のプロダクトを扱っているかもしれません。ここでは、あなたが直面する可能性のある最も一般的なブロッカーを紹介します。
- 他のチームがプロダクトに精通していないため、プロダクトに関する基本的な質問に頻繁に答えなければならない。
- ドキュメントが更新されていない。
- 技術的負債が多く、技術チームは修正作業に追われているため、あなたのセッションに参加したがらない。
- データやプロダクトに関する重要なコンセプトが頭の中にあり、それがユーザーガイドに記載されていない場合がある。
成功への道
残念ながら、銀の弾丸のようなものはありません。ここでは、どのようなことに時間を割くことができるかをご紹介します。
- エンジニアリングチームがオペレーションをより強固にする
- プロセスを再構築し、冗長性や混乱を取り除き、クラウドのコストを削減する。
- リリースのデプロイを宣言する前に成果物が更新されていることを確認するため、JIRA に制約を設ける。
- QA をエンジニアリングからプロダクトに移行
- 他のチームがトレーニングやデモ環境をセットアップできるよう、リリースサイクルに時間を割り当てます。
- トレーニングからのフィードバックをバグとして記録し、回帰テストケースを改善することで、プロダクトの堅牢性を高めます。
- プロダクトのコンセプトドキュメントを公開する。このドキュメントには、データの出所、概念的なERD、企業スイートに含まれるプロダクトの場合は、自社で開発した異なるプロダクト間の特定の相互作用に関する情報が含まれる。
プロダクトイネーブルメントを無視すると、プロダクトに関して組織が完全に機能不全に陥り、そこから負のスパイラルに陥ることになります。イネーブルメントが効果的であるためには、具体的で、適切で、タイムリーでなければなりません。
プロダクトマネージャーは、新規顧客にプロダクトを販売したり、既存顧客のライセンスを更新したりするために、他の組織のサポートを必要としています。そのための最初のステップは、組織がプロダクトについての知識を持っていることであり、その結果、市場のニーズの変化に対応したプロダクト開発に集中することができます。
Twitter始めました🐣
LINEで「海外プロダクトマネジメント情報を機械翻訳」の新着投稿を受け取れます📬
Discussion