投稿元:
レビューを見る
今年のトップ5かも
やったことある人ならあるあるで頷ける内容ばかりだと思う
ドキュメントはコミュニケーションの手段。初版は1時間以上かけない は役に立つアイデアだった。
投稿元:
レビューを見る
紛れもなくプロダクトマネージャーに関する書籍だが、ここにはVPCもカスタマージャーニーマップもリーンキャンバスもない。プロダクトマネージャーのしごとは現場により千差万別であり、自ら考えアジャストし行動する必要がある。
「このプラクティスをやっておけばよい/やらなければならない」という呪縛は枷にしかならないため、あえて紹介していないのだろう。
人と人、組織と組織をつなぐようなコミュニケーションや、率直なフィードバックを受け止めるための心得。決して派手ではないが確かに必要不可欠なこれらの「しごと」は、プロダクトマネージャーだけでなく周囲の関係者も知っておきたい。
ビルドトラップ本と並んでおさえておきたい一冊だ。
投稿元:
レビューを見る
PFEにおいてのPDMというのも話題になっているので読んでみた。こういった具体的なロールが言語化されている書籍は、自分がそのロールでなくても事業や会社の中でそのロールの人と仕事をするのであれば、読んでおくと良いと思う。
参考になってとても良い。個人的には9章、10章、12章が良かった。4章、5章を読んでいると前職のことをいろいろとできていなかったことも思い出したりもした。
投稿元:
レビューを見る
プロダクト開発関係者にとって、この本は革命的!「正解は一つじゃない」とのメッセージが心に響き、フレームワークをただの鵜呑みにせず、真の問題解決の核心に迫ります。驚くべき「すぐれたプロダクトマネージャー」の特徴も網羅!各テーマごとのチェックリストは圧巻で、読むたびに新しい発見が。そして、付録の実践読書リストは、まさに宝の山!今すぐ手にとるべき一冊です!
投稿元:
レビューを見る
一ソフトウェアエンジニアとして、プロダクトマネージャーに期待することが非常にうまく言語化されていると感じた。
いくらエンジニアが横から口を出そうがプロダクトのアウトカムに責任を持てるのはプロダクトマネージャーであり、本書はプロダクトマネージャーがその責任を果たすための有益であろう記述がされている。本職のプロダクトマネージャーの方がどう感じるかは分からない。
本書は16章から構成されている。
1章 プロダクトマネジメントの実践 / 2章 プロダクトマネジメントのCOREスキル / 3章 好奇心をあらわにする / 4章 過剰コミュニケーションの技術 / 5章 シニアステークホルダーと働く / 6章 ユーザーに話しかける / 7章 「ベストプラクティス」のワーストなところ / 8章 アジャイルについての素晴らしくも残念な真実 / 9章 ドキュメントは無限に時間を浪費する / 10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち / 11章 「データ、舵を取れ!」 / 12章 優先順位付け:すべてのよりどころ / 13章 おうちでやってみよう:リモートワークの試練と困難 / 14章 プロダクトマネージャーの中のマネージャー / 15章 良いときと悪いとき / 16章 どんなことでも
それぞれの章の末尾には「チェックリスト」という形でその章の重要な主張が箇条書きでまとめられていて、要点の確認や振り返りに役にたつ。
2章では、プロダクトマネージャーに必要とされるスキルがまとめられている。
> プロダクトマネージャーは下記のことができる必要があります。
> ・ステークホルダーとコミュニケーション(Communicate)する
> ・持続的に成功するチームを組織化(Organize)する
> ・プロダクトのユーザーのニーズとゴールをリサーチ(Research)する
> ・プロダクトチームがゴールに到達するための日々のタスクを実行(Execute)する(p.18 プロダクトマネジメントのCOREスキル)
各項目の詳細は本文に書かれており、どれも納得感がある。
以降の文章では、プロダクトマネージャーに関する振る舞いや考え方について書かれている。
> 私たちの仕事はシステムを改善し、ビジネスやユーザーに対するアウトカムを継続的に改善し続けることです。(p.52 すべてがあなたのせいではない。アウトカムは意図より重要)
> デザイナー:デザインを4種類作ってみたんだけど、どれがいい?...デザイナーにプロジェクトのゴールにいちばん合っている選択肢は何かを尋ねることで、デザイナーに対するあなたの信頼を示すことができます。(p.67 過剰コミュニケーションの実践)
> ユーザーニーズが社内政治でかき消されないようにしましょう。ユーザーニーズを意思決定の指針にして、シニアリーダーとのミーティングでユーザーの視点を活かしましょう。(p.93 シニアステークホルダーと働く)
> 「業界トップ」企業のケーススタディのほとんどは、言ってしまえば、採用のためのプロパガンダです。(p.111 誇張を鵜呑みにしない)
> 制約と限界のなかでベストを尽くすところから始めるのが、結果として制約を取り���き、限界を超えるいちばんの道です。(p.114 現実と恋に落ちる)
> アジャイルはたった1つの規範的なルールに従うというものではなく、むしろ、価値観に沿ったプラクティスを設計し実行するものです。その価値観の中心にあるのは、人間の独自性と複雑性を受け入れることです。個人を心から尊敬することの意味は、肩書きや組織図を超えて現実に共に働く相手を理解することなのです。(p.129 アジャイルマニフェストに目を向ける)
上のような価値観は外野から強制すればそれこそ組織が壊れるだろうが、チームの一員としてサポートをする機会が持てたときのために共通の価値観を知っておくことには意味があるだろうと感じる。
付録にはプロダクトマネジメントの関連書籍が複数掲載されていて、本書を読んだ後に読んでみたいと思える書籍が並んでいる。
投稿元:
レビューを見る
読了後の納得感が強い。プロダクトマネジメントこそが実はHowの議論に終始してしまいやすいが、本質に迫り続けるだいじさが認識できた気がする。
投稿元:
レビューを見る
プロダクトをマネジメントする立場として、試したいと思える内容や、頭に入れたいと思える記事・書籍など、自分の考えを広げるのに役立つヒントをたくさんもらえたように思う。
また、その内容も、現実離れしたものはなく、確かにそうだよね、と思えるものが多かったので良かった。人にも薦めたい。
投稿元:
レビューを見る
プロダクトマネジメントについて、テクニカルな領域よりもコミュニケーションのあり方(会話だけではなく言葉にできること・できないことを伝えたり共有したりすること)に注目したもの。
理論よりも著者の経験に基づいて、的確な鋭さを持って面白く表現してくれている。
投稿元:
レビューを見る
プロダクトマネージャーという立場は難しい。
やることは決まっていないし、もう辞めたい、向いてない、能力がないなど、悩む人は多いと思う。
そんな曖昧な悩みに直接答えを出してくれるわけではないが、必要な行動指針を示してくれる本だと感じた。
根本的な解決方法が載っているわけではないが、どう振る舞うべきかが記されている。すごく新しい示唆があるわけではないが、忘れかけていたことを同じ立場で語ってくれる。
仕事前15分くらい読むとすこし前向きな状態で取り掛かれる、寄り添うビジネス書だと感じた。
投稿元:
レビューを見る
[読んだ理由]==================
勤務先のSlackで話題になっていたので、気になった
[読んだ後の感想]==============
「PdMとはこうあるべき」という、定義?原則?の様な話を期待していたが、少し違っていた。
「定義?原則?はあるけど、実際にはうまくいかない。じゃあどうするか」という、現実に即した話が多かった。
それ故に実践的であり、実際に使えるネタが多かった。
大事な事:
①信頼関係
「日頃からのコミュニケーション」
「心配事、懸念、不安を隠さない。弱みを見せる」
「好奇心(自分も、周囲も)」
「同期コミュニケーションのための準備・練習」
②プロセス/ゴール
「アウトプットとアウトカムのシーソー」
「組織化(自分が不在でも自走できるチームに)」
「小さく始めて、改善サイクルを早く回す」
[メモ]========================
■2章 プロダクトマネジメントのCOREスキル
コミュニケーションの行動指針は「心地よさより明確さ」です。
優秀なコミュニケーション能力を持つ個人が、みんな生まれつきの才能に恵まれたまとめ役というわけではありません。
どんなに知識やカリスマ性があっても、組織化スキルに書けたプロダクトマネージャーは、しばしばチームのボトルネックになります。
組織化スキルに書けたプロダクトマネージャーが効かれると嬉しい質問は「私たちは今何をすべきでしょうか?」です。
なぜなら、こういった質問はチームの日々の優先順位や意思決定に欠かす事の出来ない役割としてプロダクトマネージャーが位置付けられている証拠だからです。
これに対して組織化に優れたプロダクトマネージャーは「私たちは今何をすべきでしょうか?」という問いを、何かが上手く行っていない兆候と捉えます。
自分を技術系の人材だと思っていなくても「自分はエンジニアでは無いので、そういうのは全然わからないんです」とは言わないようにしてください。
自分にある学びと成長の能力を信じて下さい。
■3章 好奇心をあらわにする
守りの姿勢と距離を置く
プロダクトマネジメントの曖昧さやヒトやモノを繋げる性質を前提にすると、幹部の干渉からチームを守るにせよ、根掘り葉掘りの質問から自分の意思決定を守るにせよ、自分が一生懸命やった事を誰も理解や感謝してくれないのではという疑念から自分を守るにせよ、いずれにしても守りに入りがちです。
プロダクト関連のキャリアの中で学んだ厳しい教訓は、何かを守るためにするすべての試みは、実際には害になるという事です。
好奇心を広げる
好奇心を広げるための第一のポイントは、あなた自身がしつこくやって見せる事です。
「今はものすごく忙しいんだ:と言ってしまうのは、プロダクトマネージャーにとっては危険な宣告です。
同様に、同僚のやっている事に興味があるなら、他人の時間を貰うことをためらわないでください。
同僚から学ぶために費やす時間は、費やすべくして費やした時間だと自信を持ちましょう���
■4章 過剰コミュニケーションの技術
様々な環境で最適なコミュニケーションの量を正確に決める方法は無いので、失敗するならコミュニケーション過剰の方に倒しておく方が良いのです。
プロダクトマネジメントに十回があるとしたら、ベン・ホロウィッツの「Good Product Manager/Bad Product Manager」でしょう。
https://oreil.ly/z3688
やって欲しい事(さらには、やって欲しいと頼んでいる事自体)を曖昧にするのは良くありません。
責任回避で在り、「悪い奴」と思われずに結果を得ようとする受動的攻撃性の表れでもあります。
コミュニケーションはあなたの仕事。仕事をする事で謝罪してはいけない
コミュニケーションがプロダクトマネージャーの仕事です。他の人に、同じレベルのコミュニケーションを期待しない事です。
■5章 シニアステークホルダーと働く(ポーカーゲームをする)
最高のプロダクトマネージャーは、リーダーが正しい情報を基に意思決定できる様にします。
そして3章で説明したように、言い争いをするのではなく選択肢を提示し、リーダーがその意思決定に伴うトレードオフを前向きに理解できる様にします。
「上司は馬鹿だ」、もしくは、おめでとうーーーあなたはチームを壊した
この時は、これがチームからの信頼と尊厳を守りながら、ステークホルダーをなだめるのはこの方法しかないように感じます。
出も長い目で見るとこれは決してうまく行きません。
チームの所に行き「上司が馬鹿だ」みたいなことを言った瞬間に、実質的にはチームを壊します。
シニアステークホルダーからのどんな要求でも、全部気まぐれで合理的で無いとみなす様になるのです。
「大きな」ミーティングでシニアステークホルダーに何かを伝える場合は、絶対に驚かせない事です。
理由はたくさんありますが、新しいアイデアをグループの場で発表する前に、シニアステークホルダーに対して個別に説明するのが良いでしょう。
大々的なお披露目を避けてインクリメンタルに賛同を得る
私は新任のプロダクトマネージャーがやりがちな間違いをしていました。
つまり、すべてをまとめて「大々的にお披露目」して売り込むというマネをしてしまったのです。
社内政治の世界でユーザー中心主義を貫く
ユーザーが必要としているかをはっきり示せないものを作ろうとする提案は、そもそもすべきではありません。
■6章 ユーザーに話しかける(あるいは「ポーカーって何?」)
■7章 「ベストプラクティス」のワーストな所
ベストプラクティスに集中する事で、好奇心を失う。
プロダクトマネジメントを再現可能なベストプラクティスの適用に過ぎないと見くびってしまえば、厄介で予測不能で絶対に回避できない人間の複雑さを洗い流してしまう事になります。
組織の限界にチャレンジする価値が無いと言っているわけではありませんし、組織の制約や限界を批判せずに受け入れろと言っているわけでもありません。ただ私の経験では、製薬と厳戒の中でベストを尽くす事から始めるのが、結果として制約を取り除き、限界を超える一番の道です。
何のために問題解決しているのか?
実際に結果を出すために「ベストプラクティス」を探しているなら、先ずは必ず組織の具体的なニーズやゴールから始めましょう。
具体的なゴールが定まってから、ゴールの達成を助けるプラクティスについて考え始めます。
このようなアプローチを取らない場合、実現しようとする変化が理解されず、会議や抵抗を生み、最終的には失敗する事になります。
「ロードマップにお勧めのツールは?」⇒「どうやって会社の内部、外部に次に開発する機能を説明しているか?」
「プロダクトビジョンを描くのにどのツールを使っているか?」⇒「チームを動機づける為にどうやって未来のビジョンを共有しているか?」
「OKRをトラッキングするのに最適なツールは?」⇒「会社にとって重要な事と、そうで無い事をどうやって判断しているか?そして、どうやって伝えているか?」
起こり得る酷い事を全て包み隠さず認識し、文書に残す
心配事や懸念事項に対して率直に向き合ってみれば、学びが得られる多くの事に気が付きます。
全てを決定事項では無く、実験と捉える
「そう、そうなるかもしれない!これは実験だと考えて、何が起こるか数週間やってみよう」というだけで、新しい事を試す人たちを安心させられます。
「今やれること」ではなくて、「次にやれる事」にフォーカスする
まさに今やっているプロセスを変えたいという欲求にかられるのも分かりますが、チームが今やっている事を改善しようとしても、直近の仕事に追われている状況ではインパクトを出すのは難しいでしょう。
想定する期間をもうちょっと長くして、次のスプリント、ローンチ、プロジェクトで試せる新しいアイデアについて考える方が、インパクトを出せる事が多いのです。
■8章 アジャイルについての素晴らしくも残念な真実
アジャイルマニフェストの序文にも注目すべき点があります。
著者たちは、より良いソフトウェア開発のやり方を見つけ出そうとしているのであって、やり方は全て見つかったから悟りの浅い私たちに教えてくれるわけではありません。
アリスター・コーバーンの「アジャイルのこころ」を再発見する
https://oreil.ly/sUyhQ
・コラボレーションする
・デリバリーする
・内省する
・改善する
心から内省し改善する時間を取れるなら、どんな状態から始まってもそれなりに良い状態に行きつくはずです。
効果的なレトロスペクティブのやり方に特化して書かれた本は何冊かありますが、まずはエスター・ダービーとダイアナ・ラーセンの「アジャイルレトロスペクティブズ」"Agile Retrospectives "Pragmatic Bookshelfから読んでみることを強くお勧めしています。
「アジャイルについてインターネットで調べた時に見つかる図の様なアジャイル」ができないにしても、コラボレーションして、デリバリーして、内省して、改善するための機会は有りませんか?
■9章 ドキュメントは無限に時間を浪費する(そう、ロードマップもドキュメント)
問題はロードマップでは無く、それをどう使うか
ロードマップは約束では無く、戦略的���コミュニケーションのドキュメント
私が見てきた多くのチームがやっていた有益なステップの一つは、組織全体に展開されるロードマップドキュメントの先頭ページに入れる「ロードマップのREADME」を書く事です。
・ロードマップでどこまで先を見据えるか?
・ロードマップに「短期」計画と「長期」計画の区別が有るか?
・ロードマップには誰がアクセスできるか?顧客に見せるのか?一般に公開するのか?
・ロードマップはだれがどんな頻度でレビューするのか?
・ロードマップの変更はどう伝えるのか?どれくらいの頻度か?
・この先三か月のロードマップにとある機能があっとして、組織の誰が何を合理的に期待できるか?
・この先一年のロードマップにとある機能があっとして、組織の誰が何を合理的に期待できるか?
最初のドラフトは一ページで、作るのに一時間以上かけない
プロダクトチームに行けるペライチの価値については、あちこちで書かれています。
ジョン・カトラーの話(https://oreil.ly/FFzbq)
私は自責の念に駆られて、簡単な誓約書を書いてビジネスパートナーと共有しました。
「いかなるドキュメントや成果物でも、チームに共有する前に1ページ、1時間以上は使いません」
私は1ページ/1時間の誓いを onepageonehour.com というウェブサイトにしました。
テンプレートがある場合
人にテンプレートを生めるように依頼する前に自分で最低三回は必ず埋めてみる
チームや組織にとってロードマップが何を意味するか決めつけない様にしましょう。
ロードマップをどう使うかについて率直かつ明確な会話をするとともに、その会話をロードマップ自体と一緒に文書化しましょう。
■10章 ビジョン、ミッション、達成目標、戦略をはじめとしたイケてる言葉たち
開発内容や期日は何らかの方法で決めなければいけません。
アウトカムに具体性が無ければ、アウトプットに具体性が求められる様になります。
アウトプットに裁量を持ち柔軟に決めたいのであれば、チームはアウトカムを具体的に決めなければいけません。
これをアウトカムとアウトプットがシーソーに載っていると見立てる事も出来ます。
「ニーズの階層」が見えるかされた事で、チームは、自分たちの待ち状態を解消し前に進める為に一番重要な情報が見つけやすくなり、総合的に扱えるようになりました。
目に見える階層構造が整った事で、ロードマップや人員配置やプロセスに関する会話を保留し、全社的なゴールの理解を深めチームのプロダクト戦略を作る事に集中できました。
ゴールと戦略をできるだけ早い段階でチームと一緒に「試乗」しましょう。
実際にチームが良い意思決定をする助けになるかどうかを確認しましょう。
■11章 「データ、舵を取れ!」
■12章 優先順位付け:すべてのよりどころ
定期的に自分たちのプロダクトを使って、タスク全体やユーザージャーニー全体を通しでやってみる
あなたがユーザーの現実の中で生きている事を確認する1つの方法は、実際のユーザーの使い方に寄せて、普段から自分たちのプロダクトを使う事で���。
自社の機能を狭い範囲でテストしたりウォークスルーしたりするより、新しいアカウントを作って、特定の種類のユーザーやペルソナにとって一番重要な作業や流れを一通りやってみて下さい。
でもこれは緊急なんです!
・問題は何か?
・報告者は誰か?
・何人のユーザーに影響するか?
・この問題は収益の様な全社的なゴールにどう影響するか?
・この問題を半月放っておくと何が起きるか?
・この問題を半年放っておくと何が起きるか?
・この問題についてさらに議論したり、解決したりするときの担当は誰か?
志は大きく、スタートは小さく
プロダクトマネジメントは、自分の意思決定の正しさに最大限の自信と確信を持てるなどというぜいたくはさせてくれません。
この不快な現実を自分に有利なように使いましょう。
大きな計画や意思決定を分割して、フィードバックを貰って再評価し、必要に応じて方向性を微調整できる位小さくするのです。
■13章 おうちでやってみよう:リモートワークの試練と困難
「Remote Work Insights You've Never Heard Before」https://oreil.ly/LCohz
「物理的に一緒にいるチームよりもリモートチームの方が強い信頼関係を持ち、よりうまく働ける」
1996年にデブラ・マイヤー損が提唱した「すばやい信頼(https://oreil.ly/M7shY)」という概念です。
公的で長続きするチームという物理的、社会的な構造の中に居ない場合は、お互いに素早く信頼するという選択をする必要があるのです。
分散チームで働いているとき、特にグローバルで分散しているときは、自分の思い込みにたやすく陥ってしまいます。
地理的な場所、言語、文化を超えてコミュニケーションするには、弱みを見せる事と努力が不可欠です。
でも、その努力は常に価値があります。
分散チームの為の同期コミュニケーション:時間と空間を企画する
短く集中する
当時、リモートの同期ミーティングは、全て一時間を上限に仕様としていました。
それより長いミーティングは、いくつかの一時間セッションに分割して、それぞれに明確なインプット、アウトプット、ゴールを設定しようとしました。
準備と練習には三倍かける
高い価値のある同期時間をチームで一時間用意するには、準備と練習に三倍の時間が掛かると想定してください。
チームで一時間のロードマップ作製セッションを計画しているなら、前日までにカレンダーで三時間の時間を確保し、ロードマップセッションの最終的なアウトカムをどのようにするか、セッション内のステップをどう構成するかをしっかり考えて下さい。
同期サンドイッチには、3つのほぼ自明なステップがあります。
・ミーティングの一日前までには、事前に読む資料を非同期で送る。
自分の考えを纏める時間が必要な参加者も参加しやすくなり、グループ全体が手持ちのタスクや質問に向き合える様になる
・タイムボックスを設定した同期ミーティングをファシリテーション氏、判断を下し、ドキュメントを一緒に作成し、事前資料で説明された問題を解決する
・同期ミーティングから一日以内に、次のアクションを含むフ���ローアップを非同期で送る。
ミーティングの勢いをそぐことなく、ミーティングの参加者全員が、その時点ではほかの事をやっていたとしても、アウトカムを見て理解できる様にする
自分の同期サンドイッチを書き出すためのテンプレートは、https://oreil.ly/sJyti にあります。
非公式なコミュニケーションのためのスペースを作り、それを守る
自分のブレイクを忘れずに
効果的に同僚とコミュニケーションする時間とエネルギーを維持したいなら、先ずは自分が休んで充電する時間が必要です。
■14章 プロダクトマネージャーの中のマネージャー(プロダクトリーダーシップ編)
自分自身に課す基準は、自分がチームに課す基準
プロダクトリーダーが、やる事に圧倒されて忙しすぎて休みを取る暇がないとか、夕食後にPCの電源を切れない、と言ってくる場合に良く進める簡単なエクササイズが有ります。
それは、自分がやっている事を全て積み上げて、チームがゴールに到達するのに役立つ順序に並べる事です。
それから、実際の勤務時間中にまあまあ終わらせられる量の下に線を引くのです。
千の下にあるものは全部移譲するか、形を変えるか、単にやめるだけです。
優れたプロダクトリーダーは、小さなフィードバックループで仕事をします。
プロダクトリーダーはカレンダーが埋まっているような忙しい人が多く、それがチームとの会話の感覚を広げてしまう要因になってしまう事があります。
自分がプロダクトリーダーになった時、何年もかけてこう言った経験から学んだことは、「嫌な奴になるな」では無く「フィードバックが無いままで長期間放置するな」でした。
「忘れないでください。上手く行くやり方はこうです。ドラフトの作成に一時間以上かけてはいけません。数日以内にできたものを持ってきてください。一緒にレビューしましょう」
■付録A プロダクトマネジメント実践のための読書リスト
「マインドセットー「やればできる!」の研究」今西康子(訳)、草思社
・対象読者:頑張りすぎの傾向を克服し、間違っている事を受け入れ、新しい事を学ぶ方法を探しているヒト
・本書の第三章では、しなやかマインドセットを育てる事がプロダクトマネージャーとしての成功のカギになると説明しました。この本によって、自分がどのように何故硬直マインドセットになっているのかを理解するのに役立ちました。また、自分が賢いと感じたり、達成感を得たりする瞬間が、チームや組織に大きな損害を与えている可能性がある事を理解させてくれました。
投稿元:
レビューを見る
プロダクトマネージャーとして必要なソフトスキルや心構えのようなものが学べた。これだけきちんとまとめられた本は他にはないのではないかと思えた一冊。
コミュニケーション、体制や組織化、リサーチ、施策実行などを中心に、アンチパターンなどを示しつつ、正解のないプロダクトマネジメントをうまくやっていくために必須の話だった。
投稿元:
レビューを見る
良い意味でも悪い意味でも裏切られた本。
・ベストプラクティスと言われているものがそのまま使えるわけでもない。
・コミュニケーションの重要性と心構えが大半を占める
・日常でプロダクトマネジメントをしていて実践、感じていることが多々あった。
・何か新しいことを学んだ本というよりは、日々の泥臭い仕事をやっていくしかないということを改めて痛感した本。
---
14.1出世する
昇進の要望に対して
「シニアプロダクトマネージャー(次の職)の職責はなんだと思うか。あなたが思う職責の職務記述書を書き出してください。そして、現在果たせている責任とまだできていない責任に踏み出すための成長計画をまとめて一覧にしてほしい」
---
読書リスト
・プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
・INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
・マインドセット:「やればできる!」の研究
・スクラム現場ガイド スクラムを始めてみたけどうまくいかない時に読む
・OKR(オーケーアール)
・Lean Analytics
・ザ・アドバンテージ: なぜあの会社はブレないのか?
・ビジョナリーカンパニー2
投稿元:
レビューを見る
同様のテーマの本は多く出版されている。本書は、プロダクトマネージャーの仕事をやっていくのに必要な、具体的な知識や技術ではなく、実際にやっていくなかでのつらさ、困難さ、それをどうやって乗り越えていくのか、ということに重心をおいて書かれている。製品を開発していくなかで、意見の異なるチームの板挟みになったり、思ったような製品ができなかったり、ということが頻繁にある。そんな中で自分の中心をどこに置き、チームや上司と、壁を壊して、どのように粘り強く交渉していくか、ということだ。本書では、かっこいいフレームワークは出てこない。ハードスキルではなく、ソフトスキルに焦点をあてる。コミュニケーション、リサーチ、組織力、実行というスキルを使いこなしていくこと。プロダクトマネジメント以外にも当てはまる汎用性が高いことだ。