「プロダクトマネージャー(以下 PdM)を目指しているのだけど、、」 と尋ねられる機会が増えてきたので
自身が PdM として日々奮闘する中で、役に立ったなあと思う体験と学習をまとめました
※ 筆者は、10 ~ 30 名規模のチームでの、ソフトウェアサービスの立ち上げに携わる経験が多かったので、そのバイアスが掛かっております
プロダクトマネージャー の責務
PdM の仕事は主に以下のようなものがあります
4W1H に Do まで入っているのでカバー範囲は多岐にわたります
有名な PdM である曽根原さんのプロダクトマネジメント入門講座では以下のように PdM の責務を語っています
- why/what : 何をつくり、なぜつくるのかを定義する
- who/how/when : 誰と、どうやって、いつやるかを関係各所と決める
- do : プロダクトライフサイクルを見極め優先順位をつけて、実行することの意思決定し続ける
また、名著 Inspired第2版では以下のことを開発チームにもたらす責務が PdM にはあると言われています。
- 顧客に関する深い知識
- データに関する深い知識
- 自分たちのビジネスとステークホルダーに対する深い知識
- 市場と業界に関する深い知識
いろいろな切り口があるなかで、責務の分類は難しいのですが、本記事では以下のように分類します。
PdM の責務を満たすために必要な 体験と学習 を恣意的に分類してます
- 顧客が欲しがるものをつくる
- ビジネスとして成り立たせる
- ソフトウェアをチームで開発する
- 進捗しやすい状態をつくる
- データを活かす
- ドメイン知識を得る
個々の 体験と学習 はわかりやすくするために以下のように目印を付けておきます
🍖 : 実践して体験すること
📖 : 書籍を読んで学習すること
📌 : サイトをみて学習すること
プロダクトマネージャーをやる上で役に立った体験と学習
1 顧客が欲しがるものをつくる
PdM はプロダクトの市場性に責任を持ちます。「これを作れば、顧客に受け入れられ、売れる」ことの最終責任を持つということです。
確かに B 向けのプロダクトでは、長年の関係性から顧客が欲しがってなくても売れてしまうことはありますが、これは偽のプロダクトマーケットフィットの可能性をはらんでいます。最終的には、顧客が欲しがらないものは市場からは退場せざるをえません。
顧客の声を聞かずに作成されるプロダクトのほとんどが「知りうる限り最も費用のかかる方法でアイディアを検証する」道をたどっている可能性が大きいです。
1.1 顧客にささるプロダクトを見つけ出す
- 🍖 なにかしら1つのプロトタイプを作り友人に見せて意見をもらう
- 🍖 デザイナーの方のデザインプロセスを見せてもらう
- 🍖 web サイトを企画してターゲットユーザーにフィードバックをもらう
- 🍖 ターゲットユーザー 10 名にインタビューしてみる
- 📖 inspired
- 📖inspired第2版
- 📖 SPRINT 最速仕事術
- 📌 プロダクトマネジメント入門講座
1.2 顧客に届ける
- 🍖 自作した Web サイトを Google 広告/FB広告 等の手法で広告出稿して反応をみる
- 🍖 自分の SNS でシェアしてみる
- 🍖 顧客と対面で使ってくれそうか反応を聞いてみる
- 📖 世界基準で学べる ESSENTIAL DIGITAL MARKETING
2 ビジネスとして成り立たせる
「この Web サービスを 1 分使ったら 30000 円プレゼント。対価も個人情報もいただきません。アクセスも一度きりで結構です。提供元は大手上場企業」というサービスがあったら使う人はたくさんいるかもしれません。顧客は欲しがりそうです。しかし、もしこれだけのサービスだったら続けていくことはできません。
どういうものがビジネスと成り立つのかを PdM は心得ていなければなりません。
「こうやったら利益がでるんだな」「こうやったら会社として継続できるんだな」という体験を幅広い選択肢で持つことは、プロダクトの幅を広げることにもなります。
また、大きな財務的な戦略を知っておくことも重要です。「いつのタイミングで、どのくらいの量のヒト・モノ・カネを、プロダクトに投資できるのか」を常に把握する必要があります。
2.1 対価をもらう仕事をする
- 🍖 友人の仕事を有料で手伝う
- 🍖 メルカリで商品を売ってみる
- 🍖 自分が企画した商品を提案して、売ってみる
2.2 意思決定を(疑似)体験する
- 🍖 経営者になる
- 🍖 経営者の近くで働く
- 🍖 視座が下がっていることに気づき上げる体験をする
- 🍖 資金調達(デット、エクイティ)を行う or サポートする
- 📖 HARD THINGS
- 📖 起業家はどこで選択を誤るのか
2.3 儲けるとはどういうことかの引き出しをつくる
- 🍖 実際に儲かっているビジネスの情報を収集する
- 🍖 上記の情報の中で信憑性が不明なものに関して、仮設を立てた後、実際はどうかインタビューしにいく
- 🍖 上場企業の目論見書を読んで、儲かる理由を理解する
- 📖 ビジネス脳の作り方
- 📖 サクッと起業してサクッと売却する
- 📖 起業3年目までの教科書 はじめてのキャッシュエンジン経営
2.4 会計の基礎を理解する
2.5 法務面で失敗しない
- 🍖 契約書を作ってみる
- 🍖 弁護士とやり取りして規約を作成してみる
- 🍖 自社の内部統制担当者/セキュリティ担当者担当者と話して、懸念点はなにかを把握する
- 📖 ビジネス契約書の見方・つくり方・結び方
2.6 ビジネスの土台となる考え方を身に着ける
3 ソフトウェアをチームで開発する
ソフトウェアを用いたサービスの開発は、たくさんの専門性の上に成り立ちます。
1 つの Web アプリの作る上でもたくさんの要素技術があり、UX/UI、ドメイン知識、マーケティング、データ分析、商習慣などたくさんの
「多岐にわたる専門性を 1 人が保有することは稀」であり「専門性が異なる人々の協力が必須」が求められるソフトウェアサービスの開発では、専門家のチームを作りながら、プロダクトを作り上げることが必須です。
PdM には専門家ぞろいのチームをまとめ上げるスキルが求められるのです。
個人的には、ソフトウェア開発の PdM は「どのような技術スタックでもいいので 1 人で Web サービスを開発した経験がある」ほうが良いと思っています。できればチームで。ソフトウェアの開発に特化した概念が多いので、それ以外のビジネスの体験では直感的に理解できないものが多いからです。
PdM になってからでも良いので「どのような技術スタックでもいいので 1 人で Web サービスを開発」はぜひやっておきたいとこです。
3.1 チーム開発の基礎を知る
- 🍖 開発チームに入る
- 🍖 開発チームと協力してタスクを完遂する
- 🍖 何かしらチームのバージョン管理ツールにコミットする
- 🍖 採用要件を決めて、採用を実行する
- 📖 チーム開発実践入門
- 📖 アジャイルサムライ
- 📖 Lean と DevOps の科学
- 📖 エンジニアリング組織論への招待
3.2 開発の基礎知識
- 🍖 開発を手を動かしながら一緒に勉強できる仲間をつくる
- 🍖 定期的に技術的な相談ができるように友人にお願いする
- 🍖 なにかしらの言語で CLI のプログラムを書いてみる
- 🍖 上記の CLI プログラムをリファクタリングしてもらう
- 🍖 上記の CLI プログラムを Web アプリにする
- 🍖 何かしら Web アプリつくって公開する
- 🍖 テストを書く
- 🍖 aws アソシエイトアーキテクトとる
- 📌 WEB DEVELOPER ROADMAPをみて技術の全体像をつかむ
- 📖 各言語別で初心者は読んでおけと呼ばれている本を 2 ~ 3 冊読んで手を動かす
- 📖 オブジェクト指向でなぜつくるのか
- 📖 達人に学ぶDB設計 徹底指南書
- 📖 プロになるためのWeb技術入門
- 📖 安全なWebアプリケーションの作り方 第2版
- 📖 webを支える技術
- 📖 リーダブルコード
- 📖 クリーンアーキテクチャ
3.3 チームをマネジメントする
- 🍖 チームのリーダーを経験する
- 📖 新板 はじめての課長の教科書
- 📖 頑固な羊の動かし方
- 📖 チームが機能するとはどういうことか
- 📖 コーチング・マネジメント
- 📖 影響力の武器
4 進捗しやすい状態をつくる
「進捗させるのはプロジェクトマネージャーの仕事では？」と思われる方もいらっしゃるかも知れませんが、個人的には、実務的には完全に分離することができないものだと思っています。
市場性は動的に変化し、大抵の場合タイムリミットがあるので、市場への投入タイミング、アップデートのタイミング、露出のタイミングなどはプロダクトが顧客や市場に受け入れられるかに跳ね返ってきます。
進捗の管理を委任することはできるかもしれませんが、最終的な進捗は PdM の責任です。
4.1 プロジェクトマネジメントを学ぶ
- 🍖 成果物と期限が明確なプロジェクトマネジメントを 1 つ以上する
- 🍖 社内からヒト・モノ・カネ を交渉して調達する
- 🍖 社外からヒト・モノ を交渉して調達する
- 📖 外資系コンサルが教えるプロジェクトマネジメント
4.2 ステークホルダーに説明する
- 🍖 MTG のファシリテーションをする
- 🍖 キックオフ MTG を主催する
- 🍖 既存顧客 からのクレームに対応する
- 🍖 既存顧客 にレポートを出す
- 📖 社外プレゼンの教科書
- 📖 マッキンゼー流図解の技術
4.3 権限を委譲する
- 🍖 自分の専門性内が強い領域で、成果と期限を明確にして、仕事を任せてみる
- 🍖 自分の専門性内が弱い領域で、成果と期限を明確にして、仕事を任せてみる
5 データを活かす
どうしても人間である以上認知バイアスがあります。そして、統計処理を頭の中でやるには人間の脳には限界があります。
PdM はデータを利用して意思決定を行う機会がたくさんあるでしょう。
最終的に自分でデータを集計しないにせよ、データ分析ができる範囲を知り、データ分析計画を設計できることは有効です。
5.1 データ分析の全体像を知る
- 🍖 データ分析の担当者になる
- 📌 これからのデータ分析担当者に求められる知識と勉強方法
- 📖 データ解析の実務プロセス
5.2 データから洞察を得る
- 🍖 分析計画を立ててみる
- 🍖 データが取得された背景情報を理解する
- 🍖 立てた仮設をデータでサポートしてみる
- 🍖 自分で作成したグラフを使って人に説明してみる
5.3 データをいじる
- 🍖 SQL を使ってみる
- 🍖 RDB の設計をしてみる
- 🍖 表計算ツールでは難しい処理をプログラムにやれせてみる
6 ドメイン知識を得る
PdM が開発チームに提供する重要なものの 1 つです。なぜ、このプロダクトをつくるのか、データで証明できないトレードオフが生じたときにどう意思決定するのかなど、ベースになるのはドメイン知識でしょう。
6.1 形式知を手に入れる
- 🍖 ググりまくる
- 📖 基本が書いてある本を読む
6.2 暗黙知を手に入れる
- 🍖 そのドメインの専門家から話を聞く
- 🍖 インタビューしまくる
- 🍖 顧客と同じ体験をしてみる
4, 5, 6 をメインに追記予定です