新製品導入 (NPI) プロセス

Principles - Processes - Categories - GitLab the Product - Being a PM - Leadership

コンテキスト

GitLab で製品やサービスをローンチするには、幅広いチーム間の調整が必要です。製品をスムーズにローンチすることは、顧客への価値提供、ポジティブな顧客体験の確保、そして当社の財務目標を達成するためのポジショニングにおいて重要な部分です。新製品を市場に投入する頻度が高まるにつれて、新製品導入（NPI）プロセスを効率的に管理する能力はますます重要になります。新しい製品オファリング、サービスオファリング、または SKU を効果的にローンチするためには、フェーズに分けて発生する一連のステップが必要です。

既存の製品セットとティアに機能をローンチする場合、NPI プロセスに従う必要はありません。既存のマネタイゼーションオプション（free、premium、ultimate）にきれいに収まる機能は、リリースマイルストーンへローンチする通常の運用手順に従います。

フェーズの概要

1. NPI 計画: チームとステアリングコミッティー（SteerCo）がスコープと要件を定義し、他の優先事項に対する NPI プロジェクトの優先順位付けに合意する
2. プロジェクト実行とローンチ: チームは独自のプランに基づいて作業し、他者に影響する意思決定とステップで緊密に連携する
3. フィードバック: 貢献したチームがレトロを行い、将来のイテレーションで NPI プロセスをどう改善できるかを評価する

このプロセスを使う基準

製品、サービス、または SKU が NPI プロセスに適しているのはどのような場合か？

1. 新しい製品またはサービスを構成する場合（つまり、既存の製品ティアや既存の SKU にきれいに収まる機能だけではない場合）
2. 新製品ではなくても、新製品、新サービス、新 SKU と同程度に運用上複雑な場合（例: カスタムシステム設定または収益処理を必要とする新しいパッケージ、ビジネスモデル、または SKU）
3. 数十のチームの労力を投資する価値があるほど財務的または戦略的に重要な機会である場合
4. プロセスは、製品、サービス、または SKU が重要な対外発表やイベントに関連付けられており、運用面での優秀さを確保したい場合にも適用可能です

NPI プロセスを開始する準備ができているかどうかをどう判断するか？

NPI プロセスを開始するには、DRI は次のことを伝える必要があります:

1. 何を ローンチするか: 製品機能、サービス権利、その他
2. なぜ ローンチするか: 価値提案、戦略的価値、財務的機会の規模（財務が詳細なモデルを構築していなくても、何らかの財務的正当化は必要）
3. 誰を ターゲットにするか: 理想的な顧客プロファイル（ICP）とターゲット市場
4. いつ ローンチする必要があるか: 内部要因（例: Field のブラックアウト期間、月／四半期／年末の財務決算、静粛期間など）または外部要因によって生じるタイミング要件
5. ローンチできる状態であること: 製品開発がプロセスを開始するのに十分に進んでおり、GTM チームが必要な時間枠で作業するのに十分な帯域があること

製品やサービスが基準を満たさない場合はどうなるか？

考えられる経路:

1. SteerCo はより多くの情報が必要 → 提案を DRI に返送する
2. SteerCo は製品／サービスが適していることに同意するが、チームに能力がない → DRI と E-Group とともに問題解決する（ローンチの優先順位付けとシーケンス、リソースの再割り当て、ローンチスコープの調整）
3. SteerCo は製品／サービスが NPI プロセスに適していないと考える → DRI と E-Group と議論する

NPI プロセスの更新に関する注意

私たちは NPI プロセスを積極的にイテレーションしています。#npi-process-working-group Slack チャンネルを使って作業をフォローしたり、フィードバックを共有したりできます。これは進行中のプロセスへのアクティブな変更であるため、元のプロセスの指示はこのページの下部に残しています。改訂された NPI プロセスが最終決定されたら、このセクションは削除されます。

フェーズ 1: NPI 計画

このフェーズは、NPI プロセスが部門横断的ステークホルダーと正式にローンチする前に行われます。

ステップ 1: 製品またはサービスの詳細を書き出す

DRI は、NPI Planning Info Sheet（テンプレートは未確定、確定次第リンク予定）に基づいてビジネスプランを作成し、ローンチする特定の製品またはサービスをどのように定義したかを伝える必要があります。この時点ではすべての詳細が揃っていない場合があります。このリソースを出発点として活用し、プロジェクトの過程で部門横断的に解決する必要があるものをあなたとステークホルダーが理解できるようにしてください。

理想的にはこの時点で価格構造を既に知っているはずですが、もしそうでなければ、Pricing Committee との会話が必要です:

1. Justin Farris の EBA に連絡して Pricing Committee（現在 Sean Hall と Justin Farris）との時間を予約する
2. Pricing は製品またはサービスのブリーフをレビューし、1 週間以内に明確化のための質問でフォローアップし、推奨に到達するために必要な適切なレベルの調査を提案します。
3. Pricing チームは、当社のプロセスと価格設定原則に従って必要な調査を実施します。オファーの複雑さと潜在的な市場規模に応じて、この調査は数週間から数か月かかる場合があります。
4. Pricing チームは、製品／サービスがどのビジネスモデルを持つべきか（例: 固定料金、サブスクリプション、消費型、アドオン、新ティア）を推奨し、オファリングに考慮すべき価格点または範囲を推奨します

ステップ 2: NPI SteerCo と会い、ローンチプランの整合を得る

DRI／ビジネススポンサーとプログラムマネージャーは NPI SteerCo と会い、NPI Planning Info Sheet に含まれる情報を提示します。

NPI SteerCo は、提案された機能またはサービスの NPI プロセスを完了するための利用可能なリソースがあるかどうかについて助言します。場合によっては、特定のプロジェクトの優先順位レベルに合うのに十分なリソースがないかもしれません。その場合、ビジネススポンサーと NPI SteerCo が協力して E-Group にエスカレーションし、さらなる方向性を求めることが重要です。

SteerCo と会うには、Natalie Pinto または Lee Work に連絡してください。次のミーティングに追加してもらえます。

ステップ 3: 製品／サービスまたは SKU をローンチするための DRI とプログラムマネージャーをアサインする

NPI SteerCo によって承認されたら、プロジェクトには DRI とプログラムマネージャーの両方が必要です。DRI は機能またはサービスの戦略を推進し、主要なビジネスオーナーです。これは新しい製品、サービス、または SKU を要求する人物です。この人物は、初期のビジネスプランの提供と、ローンチがビジネス目標を満たすことを保証する責任があります。

プログラムマネージャー は、NPI プロセスに必要な複数の並列ワークストリームを調整し、指揮します。プログラムマネージャーは Product 部門からアサインできます。Professional Services チームは、Professional Services の SKU 追加または変更をプログラム管理できます。場合によっては、DRI とプログラムマネージャーは同じ人物かもしれません。

ステップ 4: プランをステークホルダーに伝える

NPI SteerCo がプロジェクトに GO サインを出したら、残りのステークホルダーを整合させる時です。リマインダー: 純新規 SKU を提供するには多くのステップが必要です。これはプロセスのためのプロセスではありません。複数の NPI プロジェクトを通じて、この種の作業は、プロセスにおける明確なコミュニケーションと透明性なしには効率的に完了できないことを学びました（NPI は 制限アクセス の場合があり、その場合、詳細はすべてのチームメンバーにオープンではなく、知る必要のある人々のみに開示されます）。

プログラムマネージャーは、組織全体の関連ステークホルダーの取り組みを調整し、特定し始める必要があります。プロジェクトをキックオフするため、できるだけ早く次のミーティングを開催することをお勧めします:

1. ステークホルダーキックオフ（プロセス重視）: プロセスをローンチするための NPI ステークホルダー全員とのミーティング: タイムライン、マイルストーン、成功の姿、予想される課題の概要を共有する。
2. 製品レビュー（製品重視）: プロダクトマネージャーがすべてのステークホルダーチームに概要を提示する。これはステークホルダーキックオフよりも深掘りであり、製品により焦点を当てる。GTM チームはこの情報を追加のデューデリジェンスと明確化に使用し、独自の戦略とロードマップの開発を開始するインプットとして使用する。（例: Deal Desk は、使用境界、非標準ステップの承認プロセスなどに関する質問があるかもしれません）

これらのミーティングは、組織のさまざまなステークホルダーと主題専門家（SME）がリスク／問題を遅らせるのではなく早く提起する機会です。SME はまだあなたが答えられない質問をするかもしれません。それはプロジェクトの後半でさらに議論する機会です。ステークホルダーにとっては、今後数週間／数か月で何が期待されるかを理解する機会です。

同期ミーティングは GitLab の理想的な働き方ではないことは認めますが、複雑な部門横断的プロジェクトの場合、同期チェックポイントなしに意思決定を行いチームを整合させ続けることは難しいことがあります。これらのミーティングを「推奨だがオプション」として取り組むことをお勧めします。プロジェクトリードは独自の判断で、特定のミーティングがプロジェクトに必要かどうか、また、より大きなチームの一部のメンバーにとってオプションにできるかどうかを決定できます。

ステップ 5: ロジスティクスを整理する

プログラムマネージャーは、チームが成功できるように準備されていることを確認する必要があります。次のリソースは価値がありますが、必須ではありません。次のリソース／情報へのリンクを含む Single Source of Truth (SSOT) を作成することをお勧めします:

1. プロジェクトエピック（またはグループ／プロジェクト、プロジェクトに適したものなら何でも）
2. Slack チャンネル
3. 定期ミーティング（プロジェクトに合うケイデンスで）
4. 定期的な非同期更新のプラン
5. プロジェクトマイルストーン／タイムラインの定義
6. プロジェクトプランナー

フェーズ 2: プロジェクト実行とローンチ

NPI プロジェクトのこのフェーズは、一般的にステークホルダーチームによって扱われます。彼らは自分のタスク／ニーズの主題専門家であり、それに応じて作業を管理することを信頼できます。これらのステークホルダーは、自分の機能に必要な関連成果物を作成します。例: GTM プラン、マーケティングメッセージとビジョン、パートナープラン、イネーブルメント資料、セールス予測、ホスティング／インフラコスト、サポート／PS コストを含む粗利益率予測など。

プログラムマネージャーと DRI は、定義されたタイムラインに対して作業が順調に進むようにチームと継続的に協力する必要があります。プログラムマネージャーはまた、必要に応じて意思決定と問題解決を促進するためにチームと協力する必要があります。NPI プロジェクトは非常に複雑である可能性があり、チームは定期的に課題を議論する必要があります。

重要な注意: プロジェクトのパラメータを劇的に変える意思決定にチームが時折遭遇することがあります。その場合、プログラムマネージャーと DRI には、長期プランに現実的にアプローチすることをお願いします。ステークホルダーが変更を考えるとプロジェクトを時間どおりに完了できないと言うなら、プランを調整する必要があります。

将来的にこのセクションには、チームが一緒に使い、コラボレーションするための詳細なプロジェクトプランテンプレートが含まれます。これはより広範なチームのためのアクション重視になります。

フェーズ 3: フィードバック

新機能またはサービスがローンチされたら、ビジネスオーナーとプログラムマネージャーは レトロスペクティブ を開催する必要があります。これにより将来の NPI プロジェクトへの情報提供を行い、イテレーションと改善を続けることができます。

チームはまた、必要に応じてローンチ後に顧客の視点／フィードバックに関するインプットでフォローアップする必要があります。

ページのソースコードを見る - ページの編集 - please contribute.