先日下記のイベントに参加してきたので、このイベントで感じた自分の気づきをザーッとまとめたnoteです。
使用されたスライドを撮影しましたが、使っていいのか迷ったので一旦テキストのみでお届けします。（引用箇所が大雑把ですがイベントで得た言葉）

プロダクトマネジメントは広域
・開発企画・評価
・スクラムチームのPO
・PO・CPOとの連携
・プロモーション施策 etc

まだまだ全部着手できているわけではないが、これらのことを取り組む必要性は自分の中でぼんやり感じていた。なので、あとは活動するのみ。

プロダクトマップを作ろう
マップの軸：プロダクトと事業、ビジョンとニーズ

プロダクトに機能追加をする際にどんなものを追加すべきか、複数ある場合はそのような優先度をつけるのかなど、判断をする上でプロダクトマップが1つあると自分自身でも決めやすいし、周囲にも共有しやすい。

設計レビューでは「絶対やってほしいこと何か？」を忘れず、それに基づいた判断をすること

デザイン（プロトタイプ）が上がってくるとそのモノの出来栄えなどに気が行ってしまい、本来の目的を見失いやすくなると思う。
なので「これは何を解決するために取り掛かりだしたのか？」を忘れないように。
忘れないようにするためには、取り掛かる前に仮説と検証方法・期待する結果をドキュメントとして残した上で取り掛かると良いかも。
地味な作業なので、後回しにしがちになりそうなところが注意ポイント。

機能追加のプロモーションはどうする？

ここは正直見事に漏れていたと反省。
作るだけでなく、それを告知してユーザーに使ってもらい、フィードバックを得ることまでが「機能リリース」

プロダクトマネージャーに必要なこと
・プロダクトを○○したい(愛、情熱)はスタートとしては大事
・しかし、理想と現実をちゃんと区別し、冷静に目指したいゴールに向かって必要な判断をする

ただ理想に向かって単純に突っ走るのではなく、理想を見据えながらも現実問題をしっかり捉えて、冷静な判断が必要。

プロダクトマネージャの成長について
■抽象的に捉える力
　・個別の課題の本質を捉える
　・増大するバックログ整理
　・プロダクト課題と組織課題を関連付ける
■言語化能力
　・プロダクト課題の言語化
　・タスク優先度の判断説明
　・デザインモックで課題を具体的に
　・開発背景をエンジニアに共有

「デザインモックで課題を具体的にする」はツール利用など事前に習得しておかないといけないことがあるので、ツール学習必要。

プロダクトマネージャーの責任
・プロダクトコンセプト作成＝目に見えないブランド資産形成
・開発＝投資。投資判断しつつ、ブランド資産を構築し事業に貢献すること
・しかし開発チームはお金ではない
・1つ1つの判断での説明義務がある。目的や判断基準を言語化し、チームを組み立てていく。

自分の役割は「関わる人が自由に動き回れるグランド整備」という考えが自分の中であり、とても納得できた。
グランド整備としての「投資判断」「説明義務」をきちんと果たす。

数字＝組織がスケールした時の共通言語
少人数の時は信頼関係や空気感などで共通意識は持ちやすい（ブレが少ない、修正しやすいとも言える）
人が増えるほど、ブレは大きくなり通じ合えなくなる→数字で会話

数字での会話はいきなりは始められない。
なので、少人数のうちはひたすらにプロダクトを作り上げることに集中した方が良いが、徐々に人が増え始めそうなタイミングから数字を意識し備えておくと良い

プロダクトの成長・成功が自分の成長・成功
→プロダクトの成長に必要なことをすべてに取り組む

明瞭すぎて。。どんどんやっていこ。行動して結果出す。

身を置く環境によって、身につくスキルは異なる(身につけられないスキルもある）
→自分が何を目指してるのか、何が得意なのかの棚卸し必要

これは全ての人に言えること。
自分はどうなりたいのか・そうなるために何か得意なスキルはあるのか・無い場合はどう手に入れるのか…とどんどんと出る。
こういう意識が無いと、漫然と日々を過ごしてしまい時間だけを消費してしまい、もったいない。

現時点では、自社プロダクトを有名にして「アレ作った」と言いたい。

※togetterのまとめも高速で作られていました。