#プロダクトマネジメント #書籍 #文献

Amazon : https://amzn.to/3qbcwPr

著者 : 及川卓也、小城久美子、曽根原春樹

感想

プロダクトマネジメント全体について体型的に知れるという点で非常に良かった

ソフトウェアエンジニアとしてはプロダクトの How の部分にはガッツリ関わっているが、プロダクトの Core、Why、What についてはなんとなくしかわかっていなかったので、それらを理解できた

特に、個人的にはプロダクトの 4 階層と Fit & Refine の概念を得られた点が大きな収穫

プロダクト開発において、「不確実性に対処するためにアジャイルに仮説検証を繰り返す」 というような思想は持ってはいたものの、プロダクトマネジメントの観点で具体的にどういうことをするのか、というのはぼんやりとしかイメージできていなかったので、それをイメージできた

プロダクトマネジメントだけでなく、社内でプロジェクトをやっていく時などにもこういう考え方は活用できると感じた

プロダクトマネジャーじゃなくとも、プロダクトマネジメントに関わる人は読んでおくと良い本

対象読者

プロダクトマネジャー (プロダクトマネジャーを目指す人から、既にその役割で働いている人まで)

プロダクトマネジメントに関わるエンジニア、デザイナー、マーケター、事業推進者

本書の構成

Part I 〜 IV : 基礎

Part I : プロダクトマネジメントの役割と目的

Part II、III : プロダクトマネジャーの具体的な仕事

Part IV : プロダクト特性の違いによって気をつけたいこと

Part V : プロダクトマネジメント組織やプロダクトマネジャー個人の成長

Part VI : プロダクトマネジャーとして知っておきたいビジネス、UX、テクノロジーの基礎知識

プロダクトマネジャーの仕事 : プロダクトを成功させること

プロダクトの成功を生み出すの定義 (本書での定義) : ビジョン、ユーザー価値、事業収益

プロダクトマーケットフィット (PMF)

プロダクトマネジャーの 2 つの役割

プロダクトを育てる

ステークホルダーをまとめ、プロダクトチームを率いる

カスタマーサクセス : サポートの枠を超えて能動的に働きかけるカスタマーサポート

本書におけるプロダクト

狭義 : プロダクトチームのアウトプットである成果物

広義 : カスタマーサポート部署や成果物を販売する営業部署も含めた部分 (≒ 事業)

プロダクトマネジャーとプロジェクトマネジャー

日本だと後者を PM といい、前者は PM または PdM

欧米では前者が PM で、後者は PJM

機能型組織とプロダクトチーム

やっぱこういうのが一般的なんだな

プロダクトの 4 階層 : Core, Why, What, How

See : https://productzine.jp/article/detail/114

1 つの階層の検討が終わり、次の階層に進むときには Fit & Refine

プロダクトマネジャーに必要な 6 つのスキル

プロダクトの 4 階層 : プロダクトの Core、Why、What、How → それぞれ 5 章から 8 章で説明

プロダクト方針の可視化 : リーンキャンバス

マイルストーン

プロダクトポートフォリオマネジメント (PPM) は 1970 年代に提唱されたものなので最近の IT プロダクトにはそのまま適用できない部分もある → 基礎知識として知っておく

誰をどんな状態にしたいか？

MVP (Minimum Viable Product)

バリュー・プロポジションキャンバス (VPC)

ターゲットユーザーと価値の組み合わせ候補を洗い出した後に、ターゲットユーザーについて想像を膨らませる

なぜ自社でやるのか

外部環境を分析

自社の強みと弱み : SWOT 分析、クロス SWOT 分析

ユーザーにどのような価値を提供するか？

ターゲットユーザーと価値の組み合わせの観点と、自社が提供できる価値の観点という 2 つの観点で検討が必要

マーケットインとプロダクトアウトの考えに近い

プロダクトの目指すべき価値の方向性を定めると、競合と代替品について考えられる

代替品 : 異なる市場で同じ価値を提供しているプロダクト

あくまで仮説なので、少なくとも 2 回のユーザーインタビューが必要

1 回目 : 想定したペインとゲインを持ったユーザーが本当に存在するのか？ ペインとゲインの見逃しはないか？

2 回目 : 固まってきたプロダクトが、ユーザーのペインとゲインを解決するのか、価値を提供できるのか

インタビュー結果をまとめる方法として KJ 法や親和図法がよく用いられる

インタビューすることで仮説が間違っていたことに気づいたら、(たとえスケジュールが厳しくても) 練り直すこと

例外として、調査コストが実装コストよりも大きくなる場合 (世の中に全くないプロダクトで、ユーザーインタビューしてもイメージしてもらいづらいものなど) には、PoC やベータ版としてプロダクトを作って検証すると良い

何をつくり、どのような優先度で取り組むのかを検討

ユーザー体験、ビジネスモデル、ロードマップを作成

ユーザー体験 (UX)

ユーザーを理解する必要

ペルソナの活用

ユーザーのゴールを知る

UX の文脈において、ユーザーのゴールを次の 3 つのレベルで理解することが推奨されている

1. 達成するもの (End goal) : プロダクトを使うことで何を成し遂げたいのか？

2. 感じるもの (Experience goal) : プロダクトを使う際に大切にしている感情やモチベーションは何か？

3. 人生に彩を与えるもの (Life goal) : ユーザーの人生において究極のゴールは何か？ そこにプロダクトがどういう影響を与えるか？

ユーザーの行動や期待値を知る

ゴールとメンタルモデルがわかると、ユーザーが特定の行動をとる理由を理解しやすくなる

プロダクトの機能には、それぞれ理由が必要 (ユーザーのニーズから機能に落とし込んでいく必要がある)

そのための有効な手法 : メンタルモデルダイアグラム

メンタルモデルダイアグラムではプロダクトの体験が点の状態 → 線にするためにカスタマージャーニーを設計

カスタマージャーニーマップ : カスタマージャーニーを時系列にそってまとめる

IT プロダクトの場合、カスタマージャーニーマップができたらワイヤーフレームを描く

言葉だけだと人によってイメージが違うので、UI や UX を簡易に表現する

ビジネスモデルもユーザー体験と同時に検討する必要

UX とビジネスモデルの仮説を構築出来たら、検証するためユーザーインタビューをする

提供価値がどの程度ならその UX を使ってもらえるか、という観点も重要なので、ビジネスモデルも含めて実施することが望ましい

どのような優先度で取り組むか

プロダクトの Why と What がしっかり定まっていれば、ステークホルダー間で納得のいくロードマップを作り上げられる

プロダクトがうまくいっているかの評価指標も重要

プロダクトの成功を定義するための指標 : KPI

プロダクトと事業が不可分になった現代において、従来の KGI / KPI でのプロダクトの成功を測定することは必ずしも望ましいとは言えなくなった

プロダクトを通して企業が実現したい目標が KGI ならば、そのためにプロダクトが実現すべき価値が継続的にユーザーに届いていることを計測する必要 → North Star Metric (NSM)

プロダクトの What の検討は以上 : 1 つ上の階層の Why との Fit & Refine をしよう

ここまではプロダクトマネジャーが主体で、次の階層の How は各専門家が積極的に牽引する

プロダクトの Why から What で検討したものについてどう実現するか？

プロダクトバックログを作る

プロダクトの Why と What を意識できるように、ユーザーストーリー形式がおすすめ

プロダクトバックログをプロダクトの What に沿って作るために有効な手法 : ユーザーストーリーマッピング

品質基準を定める必要 (バグ発生時の優先度判断などに利用)

外部にプロダクトの品質を明示する場合 : サービスレベル指標 (SLI) を明確にする

サービスレベル目標 (SLO) : SLI に対して具体的な目標を定めたもの

サービスレベル契約 (SLA) : ユーザーに対して保証するもの

プロダクトの開発と並行して、プロダクトをユーザーに提供する仕組みを整える必要 : Go To Market (GTM)

利用規約など

うまい事例 : Line の位置情報取得の案内

失敗事例 : リクナビ DMP フォロー

プライバシーに関して、プロダクトマネジャーが考える必要

プロダクトの価格決定

Willingness To Pay (WTP)

マーケティング施策の検討

リリース前に……

障害に備える

プロダクトヘルスチェックのためのダッシュボードがあると良い

当番エンジニア (PIC) をあらかじめ決めておく

他の役割との責任分担

DACI や RACI で責任範囲を明確にする

DACI : 意思決定者を明示する

RACI : タスクを完了する責任をもつ人を可視化する

正直あんまり違いがわからん……

プロダクトマネジャーはやり取りする相手が多いので、関係者間との相関や自分と相手の関係の強さなどを図示すると便利

プロダクトマーケティングマネジャー (PMM) との関係

他の機能型組織のマネジャー (例えばエンジニアリングマネジャー) との関係

責任範囲が異なることから、判断軸が異なることがよく起こる

人事評価は、プロダクトマネジャーと機能型組織のマネジャーが協力して行うべきもの

「プロダクトチームを率いる」 とは

リーダーシップはどの職種にも必要

内発的動機づけと外発的動機づけのバランス : 主には内発的動機づけを意識しつつ、外発的動機づけも考える必要

マネジメントスタイルの違いを理解する : トップダウンとボトムアップ

トップダウン : 極端だと、現場から意見が出てこなくなったりする

ボトムアップ : 極端だと、複数のプロダクトにまたがる取り組みがうまくいかなかったり、部署を超えた横のつながりが生まれにくかったりする。 サイロ化したりする

どんな組織でも組織の中の承認権限はプロダクトマネジャーにとって重要

稟議承認 (決裁) は適切な人が行えるか？ スピードを意識した承認プロセスか？ 多くの人が承認プロセスに入っていないか？

プロダクトマネジャーはミニ CEO と呼ばれたりするが、CEO とは違って権力や報酬を使ったリーダーシップをとれない

信頼、情熱、共感、論理が重要

プロダクトマネジャーがやるべきは、情報の透明化とチームビルディング

情報の透明化

プロダクトチームに権限を委譲するには、各メンバーが適切に判断するために必要な情報を持つ必要

プロダクトに関する情報はプロダクトチーム全員が受け取れる状態を作ることが望ましい

議事録の共有や、オンラインでのチャットを他メンバーも見れる場所でやるなど

プロダクトの全体像の可視化やロードマップの可視化、現在の進捗の可視化

プロジェクト・アリストテレスの話

心理的安全性の作り方

内製度の違い

理想はプロダクトチームは内製

ただし、採用が追い付かない場合など、アウトソースする必要もある

アウトソースの場合……

DACI による決定する事項ごとの役割の明確化はなおさら必要 (どこまでが自社でどこからがアウトソース？)

ドキュメンテーションの質 (社内だと通じることも社外だと通じない可能性)

実際に手を動かす人と窓口となる人が違う可能性もあるので、些細なこともコミュニケーションが大変になる可能性 → コミュニケーション密度をどう上げるか？

チームの発展度に応じたチーム作り : チーム状態の把握にはタックマンモデルが有効

プロダクトやプロジェクトの開始時にはキックオフミーティングを実施

目的は 3 つ

プロダクトやプロジェクトの目的や全体像の共有

特にチームのビジョンやミッション

チームメンバーが互いを深く知る

プロダクトやプロジェクトを始める前に必要な合意を得る

プロダクトコンセプトを共有するキックオフ

インセプションデッキ : プロダクトチームがプロダクトを自分ごと化してプロダクト志向を持つことができる活動

エンジニアと 「開発をどのように進行するか」 の認識をそろえるキックオフも必要

認識を合わせるべきこと : 開発手法、進行の流れ、見積りとバッファの扱い、完成の定義、プロダクトごとの特性、大まかな設計と担当者

共通の目標に向かう : OKR

ふりかえりは重要

手法 : KPT や YWT

自分の肩代わりになってステークホルダーの理解を促したり、プロダクトマネジャーの意思決定をサポートする

ドキュメント内の重要な要素

プロダクトビジョンステートメント

プロダクト戦略

プロダクトコンセプト

プロダクトロードマップ

プロダクト要件

プロダクト要件は PRD (Product Requirements Document) と呼ばれる形式でまとめることが多い

傾聴が重要

集団活動の進行のために、目的の明確化、目的遂行のためのメンバー選定、積極的な参加の促進、活動の流れの整理と制御などが必要

ミーティングは参加者の時間を奪う行為 → 会議はあくまで手段であり、期待する成果を明確にして、その成果達成のために最大限の努力をするのがファシリテーション

本質は、相手に理解してもらったり、共感してもらったり、相手の行動変容を引き起こすといったこと

環境に適合したプロダクトマネジャーのスタイルを考えるために、次の 4 つをおさえる必要

プロダクトステージ

ビジネス形態

ビジネスドメイン

技術要素

プロダクトマネジャーの視点

0 → 1 : イノベーター系プロダクトマネジャー

プロダクトを目に見える形にすることが最優先

プロダクトマネジャー自らが仮説構築と検証のサイクルを回す

1 → 10 : グロース系プロダクトマネジャー

かつてはグロースハッカーと呼ばれる人もいたが、短期的な視点に終始してしまって長期的なプロダクト開発からは遠ざかってしまったので、今ではそういう人はシリコンバレーにはほぼいない

現在では、グロース系プロダクトマネジャーと呼ばれる人がビジョンやミッションに沿ってグロースさせる

10 → 100 : タウンビルダー系プロダクトマネジャー

メインストリームとなったプロダクトが目指すべきは生活圏の制覇

終焉 : 終わらせることもプロダクトマネジャーの大事な意思決定

サンクコストバイアスに注意

BtoC と BtoB では振る舞いが異なる

BtoC では、プロダクトの価値をユーザーに理解してもらうことが重要

指標としてはユーザー継続率など : コホート分析が有効

収益を上げるために LTV も

プロダクトマネジャーとしては下記 3 点が重要

業界特有の商習慣への深い関心

ユーザーとユーザーのステークホルダーに対する想像力 : プロダクトを買う人と使う人が違うこともある

優先度の付け方のバランス

営業やカスタマーサポートからの要望をどこまで聞くべきか？ (狭い視野で語られる場合もある) → 外出し優先度付けがおすすめ

成功の指標

収益はあくまで結果

ユーザー継続率や顧客満足度 (NPS で測るなど) は重要

国内のみでの提供でも、グローバル視点は必要

プロダクト開発のサプライチェーン (IT 基盤の AWS もそう) をグローバルに調達可能になった

自身のグローバル展開の検討

グローバルの競合他社

グローバル展開を考える際の要素 : 言語、文化、顧客のニーズ、規制、競合、パートナーシップ、基盤

ドメイン知識を効果的に得る 4 つの方法

トレードオフを発見する

チーム全員でドメイン知識を理解するために

ランチ・アンド・ラーン (Lunch and Learn)

クラッシュコース (Crash course)

テックトーク (Tech Talk)、エキスパートトーク (Expert Talk)

ファイヤーサイドチャット (Fireside chat)

ファイブ・イン・ファイブ (5 in 5 : 5 questions in 5 minutes)

ハードウェアのプロダクトマネジャー

AI プロダクトマネジャー

AI 実現の手法の基礎は把握しておくこと : 教師あり学習、教師なし学習、ディープラーニングの用法とユースケース、データサイエンス、ビッグデータ基盤

プロダクトマネジャーやプロダクトマネジメントの概念が根付いていない組織

プロダクトマネジメントの必要性を訴えても理解されないかも

まずはプロダクトマネジメントの不在による課題に目を向けて、共感を得るところから

問題を浮かび上がらせるための質問

プロダクトに大儀とそれに基づく方針はあるか？

方針に従って、的確な、時として厳しい意思決定をしているか？

プロダクトは誰のどのような課題を解決し、誰にどのような価値を届けようとしているかなど、関係者全員が共通の目標を言えるか？

プロダクト志向組織へのステップアップ

プロダクトに関わるメンバー全員が、プロダクトの価値を理解して、ビジョンの達成とユーザー価値と事業収益の向上に邁進する

プロダクト組織へのステップアップに活用できる ABCDE フレームワーク

Awareness (認知) : 組織の意思決定層にプロダクトマネジメントの必要性を認知してもらう

Belief (信念) : 小さな単位で導入し、最初から最後まで任せる。 意思決定層に必要性を理解してもらう

Commitment (コミットメント) : 限定的なスコープで、適切な人をアサインし、コミットしてもらう

Diffusion (拡散) : 担当領域を増やしていく

Embeddedness (組込み) : 組織の隅々にいきわたらせる

プロダクトの 4 階層について、最初は core より why からやる方がやりやすいかもしれない

完璧な why を目指すのではなく、core や what の fit と refine を確認して広い視野を持つことを優先するように

プロダクトマネジャーになる方法は様々

ビジネス、UX、テクノロジーの 3 領域が必要

まずは自分が自信を持てる領域や実績のある領域を作る

W 型人材を目指す

必要な知識の深さ : 発言内容を理解できる、質問できる、コメントから視点を広げられる

6 つのスキル : 発想力、計画力、実行力、仮説検証力、リスク管理力、チーム構築力

採用は人事の仕事の中でも営業やマーケティングに近い : 自社のポジションを売っている

プロダクトマネジャーが関わるビジネス職は主に事業企画や営業

ビジネスの基本構造

利益 = 収益 - コスト

収益を拡大する手法として押さえておきたいもの : ネットワーク効果、フリーミアムとフリートライアル、クロスセルとアップセル

企業活動のコストは、会計上総費用と呼ばれる

総費用は固定費と変動費

おさえておきたい科目

2021 年時点で配慮すべき 3 点

ユーザー獲得コストの増加と Willingness To Pay の低下

ユーザー自己学習型プロダクトの台頭

プロダクト体験の優先度の変化

パートナーシップの構築

指標計測

代表的な指標

FTUX の重視

DAU と MAU

離脱率 (Churn rate)

AARRR モデルとファネル分析

ネットプロモータースコア (NPS)

データを集めるために

アクションの定義 : どのアクションを収集するか？ アクションの負荷情報は何か？

他者の知的財産を侵害しないことの確認と、自社のアイデアの特許化を検討する必要がある

知的財産の保護

ユーザーとの権利関係の明確化 → 利用規約に記載

協業時の権利関係明確化 → 秘密保持契約 (NDA)

ライセンスの扱い (オープンソースのライブラリなど)

UI デザイン、UX デザイン

ビジュアルの階層化 : 色、サイズ、深度、空間、近接によって視覚的な差異を作り出したもの

情報の構造 (Information Architecture) もプロダクトを使いやすくするためのポイント

マーケティング施策

メディアの種類

アーンドメディア (Earned Media) : ユーザー自身がマーケティングのチャネルになる

オウンドメディア (Owned Media) : 自社運用のメディア

ペイドメディア (Paid Media) : テレビ CM や Facebook などへの出稿、インフルエンサーの利用など

プライバシーポリシーと利用規約

個人情報の第三者提供などをする場合はプロダクトマネジャーが法務担当者に伝える必要

プライバシーポリシーを作るために、ユーザーの権利を知っている必要がある → 個人情報に関するユーザーの権利

プロダクトの品質

品質保証 (QA : Auality Assurance) : 品質に対する活動

どのバグを優先的に直すのかを決めるのがプロダクトマネジャーの役割

品質基準は、プロダクトの初期段階で議論して、チーム内で共有することが望ましい

人によって不具合かどうかの判断が違うと、チーム内のコミュニケーションが悪化しかねない

品質向上の判断基準においても、プロダクトの成功と同様、ユーザー価値の向上と事業収益の向上の 2 つの視点が必要

品質は、ユーザーニーズを満たせているかの尺度

ソフトウェアテストについて、プロダクトマネジャーも概要は把握しておくこと

組織の規模がある程度大きい場合は、QA 担当者や QA グループを置くとよい

QA 担当者を置く場合、QA 業務を QA 担当者だけに任せきりにしないこと

品質に対する責任はプロダクトチームのメンバー全員が負うべきもの

開発が進行するにつれて技術的負債が溜まっていくことを理解すること

定期的に技術的負債を解消する必要がある

エンジニアリングマネジャーと相談して決めるとよい

開発手法の基礎知識

アジャイル開発の手法

CI (継続的インテグレーション) と CD (継続的デリバリー / 継続的デプロイメント)

プロダクト開発の進め方はエンジニアリングマネジャーやプロジェクトマネジャーと議論する必要

プロジェクトマネジャーに委任するとしても、プロジェクトマネジメントについても知っておく必要

ソフトウェアの基礎知識

ソフトウェアが動く仕組み、ネットワーク、データベースの 3 つはソフトウェアプロダクトの根幹であるため最低限おさえておくこと

RPC と API

セキュリティインシデントへの対応

セキュリティバイデザインと呼ばれる手法

プロダクトの Core について

プロダクトの Why について

プロダクトの What について

プロダクトの How

ステークホルダーをまとめ、プロダクトチームを率いる

プロダクトマネジメント全般