製品ライフサイクル：製品機能の旅

これは、製品志望者が製品管理の世界に参入するのを支援することを目的として私が書いている5部構成のシリーズの4番目の投稿です。

前回の投稿では、プロダクトマネジメントの志望者が企業内または一般的なキャリアの軌跡を理解できるようにすることを目的として、プロダクトマネジメントの分野を4つの部分に分けました。 この投稿では、プロダクトマネージャーの役​​割が何を含むかについて、プロダクトマネジメントの志望者が360度の視点を得るのに役立つ、アイデアから放棄までのプロダクト機能のライフジャーニーについて説明します。

T –30日

必要性は発明の母であると言われています。 これは文字通り、製品機能の誕生が関係している場合です。 それはすべて、ある程度の不快感から始まります。
会社の一部の従業員は、日常業務の1つを達成することに不快感を覚えています。おそらく、ユーザーベースが増加し、古いプロセスではそれを管理できなくなっている可能性があります。 会社の一部の幹部は、Excelシートを見て、たとえば、製品のキャンセルが多いために、会社があまりにも多くのお金を失っていると考えています。 あるいは、競合他社が製品機能を立ち上げて、顧客がその会社の製品を離れる原因になっている可能性があります。 マーケティングコンバージョンファネルを見ている人は、特定の段階で高いドロップオフに気づき、それを最適化することで四半期目標を達成できると感じました。 または、一般的な問題に対する顧客からの苦情が多いことから、先週調査したユーザーの大多数が新機能を要求していることまで、100の異なる理由が考えられます。 重要なのは、それはすべて、ある程度の不快感から始まります。

現在、この不快感はプロダクトマネージャーに通知されています。 あるいは、プロダクトマネージャーが最初に気付く人かもしれません。 これは、新機能の誕生につながる可能性のある一連のイベントを開始するポイントです。

T –25日

プロダクトマネージャーが問題の説明を熟考する時が来ました。 彼は行って、不快感を報告した顧客または内部の利害関係者、そして実際にそれを経験している人々と話します。 すべて単一の目的で–彼が「ルート」問題ステートメントを特定したことを確認すること。 この段階が軽視されているか、プロダクトマネージャーがこれに十分な時間を費やしていない場合、生まれた製品の機能は壊れやすく、歪んでいて、すぐに終わりを迎えます。
プロダクトマネージャーは、主要な問題ステートメントを特定すると、それを解決する価値があるかどうかを判断します。 不快感は本当に大きなものですか、それとも誇張されているのでしょうか、それとももっと悪いのでしょうか。 それを解決することは、実際に顧客や会社に大きな価値をもたらすでしょうか？ それを解決すると、顧客や会社に重大なペナルティが課せられませんか？ プロセスを少し調整するか、製品の変更を必要としないアクティビティを通じてこの問題を解決する方法はありますか？たとえば、ベンダーの変更、既存のベンダーからのより良い価格の交渉、問題を解決するためのサードパーティソフトウェアの入手、採用追加の従業員、コンテンツ、グラフィック、召喚ボタンなどの変更？

基本的に、製品の変更を伴わない方法から同様の付加価値を得る方法があれば、それが追加または削除を意味するかどうかにかかわらず、製品の何かを変更することよりも優先されます。 プロダクトマネージャーが、問題の説明を解決することで大きな価値がもたらされ、製品レベルの変更により、製品レベル以外の変更よりもはるかに多くのROI（時間、お金、労力v / sの価値を考慮する）が得られると確信すると、新しい製品の特徴が植えられています。

T –15日

プロダクトマネージャーが以前に経験を積んでいる場合は、その経験に基づいてソリューションを提案する可能性があります。 ただし、それがすべての場合に最適なソリューションであるとは限りません。
問題の説明に高度な技術的解決策が必要な場合、プロダクトマネージャーは開発者やエンジニアリングマネージャーと同じことについて話し合い、最善の方法についてアドバイスを提供します。 ソリューションでデザインレベルの変更が必要な場合は、UXリードに相談することができます。 プロダクトマネージャーとUX担当者がデザインスプリントを整理し、その機能の実際のユーザーに好評なソリューションを選択する可能性があります。 問題が完全にビジネスに関連している場合があるため、上級管理職からの賛同が必要です。
したがって、ソリューションを完成させる方法は複数あります。 しかし、そうなると、プロダクトマネージャーは、その理論上のソリューションをアクティブな製品機能に変換する責任があります。

T = 0（製品機能の誕生）

特定のソリューションが特定されると、プロダクトマネージャーは、関連するチームと協力して、ソリューションの基本的な概要をハッシュ化します。 ソリューションのプロトタイプが含まれる場合と含まれない場合があります。 特定のCTAをユーザーに表示するタイミングなどについて「if-then」条件が記述された基本的なExcelシートである場合もあります。
プロダクトマネージャーは、関連するPRD（製品要件ドキュメント）にソリューションを言葉で表現します。 機能が小さい場合は、既存のPRDの段落である可能性があります。 機能が非常に大きいため、適切に詳細化するためだけに完全なPRDが必要になる場合があります。 PRDは関連するチームによって実行され、プロダクトマネージャーは、機能に関して幅広いコンセンサスが存在することを確認します。

T+15日

小さな機能は、フリーズするのに1日もかからない場合があります。 大きな機能は、場合によっては、全員が成功するまでに30日以上かかることがあります。
これが開発者に新生児機能が導入される時間であると言うために平均15日かかりましょう。 プロジェクトに取り組んでいる開発者に5W（What、Why、When、Where、Who）とテストケース（リリース後に機能がどのように動作するか、または動作しないか）が通知される適切な設計とPRDハンドオーバーが行われます。 。
エンジニアリングマネージャーとともに、テス​​トの開始時に開発が終了する時期、報告されたバグが修正される時期、および最終リリース日が定められた機能の適切なリリーススケジュールが決定されます。 次に、タイムライン全体が測定可能なスプリントに分割されます（通常は15日間）。 開発者が満足すると、開発が始まります。

T+30日

スプリント1が終了します。 製品機能の一部が展開されています。 まだ顧客向けではないかもしれませんが、ほとんどのチームは今日、ソフトウェア開発のためにアジャイル手法に従います。つまり、段階的かつ反復的に構築します。 そのため、6か月で大きな機能を構築して一度にリリースするのではなく、すべてを独立した部分に分割します。これらの部分は、それ自体で機能し（一連のユーザーストーリー）、すぐに確認して繰り返すことができます。
プロダクトマネージャーは、プロジェクトに取り組んでいる関連するエンジニアリングマネージャーとの毎日のスクラムミーティングとディスカッションを通じて、リリースタイムラインが順調に進んでいることを確認します。 遅延が発生した場合は、それに応じてタイムラインが調整されるか、リリースが予定どおりに行われるように機能の一部が削除されます。 各スプリントの後、進捗状況は会議でプロダクトマネージャーと関連する利害関係者に提示され、承認後にリリースされます。
UpGradの製品管理プログラムの1年間

T+x日

'n'回のスプリントの後、開発は完了し、機能全体が終了します。 完全にリリースされた場合にのみ、お客様がこの機能を使用できるようにする必要はありません。 スプリント1自体の終わりにリリースされて以来、彼らはそれを使用している可能性があります。 後続の各スプリントサイクルリリースは、機能をより堅牢にし、意図したものに近づけるだけです。
機能の起動はそれ自体が芸術であり、スキップする多くの手順が含まれます。多くのドラムと胸を叩いた後、機能がリリースされたことが世界に宣言されたと想定します。 これは、CEO自身が新しいローンチについて話している本格的なプレスリリースのように複雑な場合もあれば、この機能を使用する特定の部門にメールが送信され、おそらくそもそも。 機能が公開されたので、この機能にMr.Featureという名前を付けましょう。

T+y日

最終リリース後も、問題が発生することがあります。 かつてはすべて光沢があり価値があったフィーチャー氏は、もはや同じではない可能性があり、それには複数の理由が考えられます。 製品サイクルのこのフェーズは、製品のサポートに関するものです。 ある晴れた日、別のリリースが行われ、Mr。Featureが意図しない方法で実行された（別名バグが発生した）か、Mr。Featureに依存する別の機能が削除され、バグのある動作が発生した可能性があります。 また、機能が作成されたときに、それを使用するユーザーの数を過小評価したか、すべてのユースケースを計画していなかったため、機能がこれらの多くのユーザーまたはユースケースにスケールアップできなくなった可能性もあります。

これは、定期的なレビューでテストチームによって報告されるか、機能を使用しているときに発見したばかりのチームメンバーによって報告されます。 顧客向けの機能の場合、これらの苦情は製品の実際の顧客からのものであり、カスタマーエクスペリエンスチームを介して製品マネージャーに伝達される可能性があります。

プロダクトマネージャーはバグの根本原因を理解しようとし、優先度に従って、次のリリースサイクルの修正をスケジュールします。優先度が高い場合、または後続のスプリントである場合は、現在のスプリントに追加できます。 バグが修正されてリリースされた後、プロダクトマネージャーとエンジニアリングチームのおかげで、フィーチャー氏は、改革された形であるにもかかわらず、別の日を見るために生きています–フィーチャー2.0氏。 称賛！

T+z日

すべての良いことは終わらせなければならないと言われています。 悲しいことに、それは、そのバージョンが何であれ、Mr。Featureにも当てはまります。おそらく、Mr。Feature 9.263.75です！ つまり、フィーチャー氏は長く幸せな人生を送ってきたということですが、今や道の終わりはここにあります。
さまざまな理由が考えられます。 フィーチャー氏の必要性を完全に冗長にする新機能が登場しました。 これも極端なことかもしれません。たとえば、この機能はユーザーに付加価値をもたらしているものの、もはや経済的に意味がないと会社が判断したようです。

理由が何であれ、フィーチャー氏のサービスはもう必要ないということがプロダクトマネージャー（または彼が議論を開始する人）に伝えられます。 さて、これは悲痛なことですが、プロダクトマネージャーには、フィーチャー氏を休ませておく義務があります。 その前に、Mr。Featureを使用していたユーザーに特定の日付から利用できないことを通知するなど、いくつかのことを確認する必要がありますが、Mr。Featureを削除する前に、新しい機能は正常に機能しています。機能氏がいなくなると、フローが影響を受けます。

それでは、フィーチャー氏にRIPを言う時が来ました。 製品管理のキャリアでは、これを複数回行う必要があります。 ただし、ある機能の終わりは別の機能の始まりであり、サイクルが続くことを忘れないでください。 これが製品管理ライフです！

世界のトップ大学からオンラインで製品管理コースを学びましょう。 マスター、エグゼクティブPGP、または高度な証明書プログラムを取得して、キャリアを迅速に追跡します。

あなたのための注目のプログラム： デュークCEからのデザイン思考認定プログラム