プロダクトマネージャーのしごと
はじめに
“すべてを理解できた人などいない、ということに気づいている組織の数が十分に増えた結果であると私は考えています。またここ2年の経験から、「これさえやればうまくいく」という宣言が、それまでよりはるかに絵空事に聞こえるようになったとも考えます。世界はすごい速さで変化していて予測はできないというのは、かつては使い勝手のいいただの決まり文句でしたが、今では経験にもとづく現実であると実感するようになりました。”
「こうすれば必ずうまくいく」は詐欺だが、「これをすれば必ずマシになる」というテクニックはあるね。それを基礎というのだけど
キャリアの初期には、この多くは開発ペースが速く職務定義が緩いせいで起きることで、スタートアップで働くのにはつきものだと思っていました。でも、さまざまな規模や種類の組織にコンサルティングやトレーニングを提供するようになって、同じようなパターンを目にしました
これだけキャリアのある人でもこのように思うのか
「プロダクトマネジメントがうまくできているか」なんて考えても実はCxOでさえそんなに影響力がない、と書いていて、であれば影響力があるのは誰なのか?と思った
そんなことを考えても無駄だってことなのだろうかmactkg.icon
第1章
プロダクトマネージャーは「作る」よりもファシリテーション・コミュニケーションが多い。どれだけ専門知識を持っていても他のメンバーの協力が必要で、それぞれ野心・疑問・制約を抱えている
「プロダクトマネジメントとは?」考えたところで、定義するのはとても難しい。ただ、どんなひとか説明ができる。
会社によってさまざまである。
ADPR: Ambiguously Descriptive Product Roles(曖昧に書かれたプロダクト関連の役割/「プロなんとか」)
プロダクトマネージャーには直接的な権限はない。チームに対して有害なエンジニアはプロダクトマネージャーが解決すべき問題だが、自分だけでは解決できない。やることは、全部やる必要がある
どんな人がプロダクトマネージャーになるのか?それは会話のハブになる人である。専門知識がある人だったり、「デザイン思考」が得意な人とかでもない。
プロダクトマネージャーのバッドパターンは面白かった。不安から守りに入った結果、各々よくない行動をする。
わかるなー。「俺の存在意義って何?」って思うよねmactkg.icon
第二章: プロダクトマネジメントのCOREスキル
プロダクトマネージャーは全てのスキルと知識を持っているのではなく、連携を生み出すことが得意なのが大事
相手がどんな人であろうと。
CORE
ステークホルダーとCommunicate
心地よさより明確さ
心地悪さは明確さの欠如
とてもわかる。こういうポイントを逃すと後で後悔するので、その場で会話できなくても後で話したほうが良いmactkg.icon
持続的に成功するチームをOrganize
コミュニケーションの流れを工夫する
自分がいなくてもよくする
プロダクトのユーザーのニーズとゴールをResearch
ユーザーがどうプロダクトを使うか?ではなくて、ユーザーの現実世界にどうプロダクトが適合するのか?を理解するべき
プロダクトチームがゴールに達成するための日々のタスクをExecute
作る
適切に発想し優先づけする
別に技術以外でも勉強してできるようになったりするでしょ?それと同じようにちょっとした文言変更は自分でやったらいいじゃん。という趣旨のことを書いていてよかったmactkg.icon
今のアプリチームの開発リーダーとして、俺はAndroidはそれほど詳しくないけれどもなんとか仕事はできていて、チームメンバーが優秀なのもあるけどそれでも仕事ができているのは何か近いところがあるのかもとは感じた。間接的にアウトカムを出す
第3章: 好奇心をあらわにする
興味を持って知ろうとすることで、相手とのコミュニケーションをやりやすくする
相手の考え方、言葉ではなす
最近何をしているか知らない人の仕事を知りに行っただろうか?mactkg.icon
しなやかマインドセット
何かを守るためにする全ての試みは実際には害になる
わかるmactkg.icon
エンジニアとしては、そうしてしまっている人からチームを守る、というのが1発目にあるケースもありそうだけど
チームへのコミュニケーションの工夫はテクっぽいけど面白い。「なんで」は普通によくないから、バリエーション持って置けるといいですよね
第4章: 過剰コミュニケーションの技術
当たり前なことでも確認しておくといいことがあるよね
「大きなミーティングで不都合な情報をあげる」というコラムよかった。
特にCEOの「わかった。知らせてくれてありがとう。」
単刀直入に言え
やってほしいことを曖昧にするのは良くありません。責任回避であり、「悪い奴」と思われずに結果を得ようとする受動的攻撃性の表れでもあります。
アウトカムが重要
失敗を自分の失敗にしたらチームから学習の機会を奪うことになる
チームと一緒にシステムそのものについて考えよう
「良い意図であることを前提とする」「全力を尽くした前提で会話する」だとabuseできる問題
意図にフォーカスするのではなくて結果にフォーカスする
「このシチュエーションで期待したアウトカムを得られているのか?」
これまだしっくりきていない。難しい mactkg.icon
「よさそう」をやめる
選択肢を提示してステークホルダーに積極的に参加してもらい、消極的な反応で終わりにならないようにしてもらう
これは面白い
「レビューお願いします」というよりも「どちらが良いですか?」とか
受動的攻撃性が度々出てくるけどちゃんと理解したいmactkg.icon Commitする。しないならできない理由を教えて。(それを解決したい!)というのはわかりやすい
普段黙っている人にしゃべってもらうチャンス