Top Menu
Pocket

世界で闘うプロダクトマネージャーになるための本

感想

PM(プロダクトマネージャー)とはどういう仕事か?を考える材料になる本です。

プランナーやディレクター、プロデューサーのような立ち位置で仕事をしてきた方々なら必ず一度は考えたことがあるであろう「エンジニアリング」や「デザイン」のプロフェッショナルじゃない自分は、どういう価値をチームに提供すべきか?そして、今後キャリアをステップさせていく上でどういう経験を積むとよいのか?

僕のように「エンジニア」「デザイン」どちらのバックグラウンドも持たない自分は、世界基準で考えたときにどうしていくべきか?この本を読んだあとでも、やはりこの命題については正解は出ない。ただ、自分が今優先して学んでいくべき分野等はある程度明確になると思う。

僕個人で考えたときには、自分で将来事業をやる見込みがある中で、プロダクトマネージャーとして生を終える可能性は低いと思っているが、プロダクトマネージャーのような役割を全うできる能力は最も大事だと思っている。

この本を読んで、プロダクトマネージャーの役割は大きく4つに分かれる。

大きい役割としては、当然プロダクトの全責任を持ち、優れたプロダクトをリリースすること。

そのために必要な能力としては、

  1. 優れたプロダクトをリリースするためのあらゆるコミュニケーション
  2. 顧客を誰よりも理解していること
  3. 最適な優先順位をつけること
  4. 率先した雑用力

これらそれぞれのレベルをあげていこうと思うと、その中にコンピューターサイエンスのバックグラウンドも必要になってくるかもしれないし、顧客の声を的確に吸い上げる能力も必要になってくるかもしれない。

将来自分のやりたいこと、そして今の自分が持ち合わせてるカードによって、どの能力を磨きあげるかは結局自分次第なのだが、この本は少なくとも世界基準で見たときにプロダクトマネージャーになるためには「一般的に何が必要とされているか?」をある程度クリアにしてくれるという意味でとても価値ある本だと思う。

以下メモ


 

PMとは何か?

  • PMの職責とはチームが優れたプロダクトをリリースできるようにすること

PMの役割

  • PMになったらあなたは権限をもっていなくてもチームを率いる能力を身につけ、ビジョンと調査の裏付けをもってチームに影響を与えなくてはなりません。ほとんどの企業において、プロダクトマネージャーはとても尊敬されますが、エンジニアほどは尊敬されません。あなたが周囲の人々を監督する立場になったら、おそらく物事を成し遂げることの難しさを理解できるでしょう。なんといっても、プロダクトを実際に作るのはエンジニアです。あなたはエンジニアを味方につけなくてはなりません。

上位1%のPMと上位10%のPMは何が違うのか?

大きく考える

1%のPMは、現在、または現在の市場環境で利用可能なリソースに縛られません。大きくて、破壊力のあるチャンスを語り、そのチャンスを生かすための具体的な計画を立てます。

伝える

1%のPMは、反論や無視を受け付けない場面を作り出すことができます。データがあれば適切に使う一方で、実権を持つ人を説得するためにバイアスや信念、きっかけもうまく活用し、人員やお金などのリソースを出してもらってから、距離を置くこともできます。

単純化する

1%のPMは、20%の労力で機能やプロジェクトから80%の価値を得る方法を知っています。それを繰り返し実行し、何度もローンチをして、プロダクトやビジネスにおいて複合的な効果を達成します。

優先順位を付ける

1%のPMは、プロジェクトの順序を決める方法を知っています。すぐに得られる成功とプラットフォームへの投資のバランスをうまく取ります。攻撃的なプロジェクトと防御的なプロジェクトのバランスもうまくとります。攻撃的なプロジェクトは、ビジネスを成長させます。防御的なプロジェクトはビジネスを守ったり、障害物を取り除いたりします。

予測し測定する

1%のPMは、プロジェクトのおおよその利益を予測します。また過去の経験を活かし、比較可能なベンチマークを利用して、効果的にその予測を達成することができます。プロジェクトがローンチしたあとで、利益を測定し、そこで学んだ要因を将来の製品の優先順位付けと予測に役立てます。

実行する

1%のPMは、プロダクトを作り上げます。リリースのために必要なことはなんでもします。自分の役割はスコープに縛られていないことを認識しています。必要なら、人材を集め、ボタンを作り、ビジネスを開発し、問題を上にあげ、社内と相談し、他になんでもします。

技術的なトレードオフを理解する

1%のPMは、コンピューターサイエンスのバックグラウンドは必要ありません。しかし開発者の手間をかけることなくバックログをみて、機能の技術的な複雑をおおまかに理解する必要があります。開発者と協力して、適切な技術的なトレードオフを決めます。

良いデザインを理解する

1%のPMは、デザイナーである必要はありません。しかし優れたデザインを高く評価し、まあまあのデザインとは区別できなくてはなりません。デザインの担当者に対して違いを明確に説明するか、あるいは少なくともまあまあのデザインから優れたデザインに推し進めるための方向性を説明する必要もあります。

効果的なコピーを書く

1%のPMは、仕事をやり遂げるために必要な、簡潔なコピーを書かなくてはなりません。不要な言葉を付け足すと、価値が薄まってしまいます。時間とエネルギーを費やして、重要なコピーに使われる完璧な言葉を見つけ出すべきです。用が足りる程度の言葉ではいけません。

Amazon Leadership Principles

カスタマーへのこだわり(Customer Obsession)

リーダーはカスタマーを起点に考え行動します。カスタマーから信頼を獲得し、維持していくために全力を尽くします。リーダーは競合に注意を払いますが、何よりもカスタマーを中心に考えることにこだわります。

オーナーシップ(Owner Ship)

リーダーにはオーナーシップが必要です。リーダーは長期的な視野で考え、短期的な結果のために、長期的な価値を犠牲にしません。リーダーは自分のチームだけでなく、会社全体のために行動します。リーダーは「それは私の仕事ではありません」とは決して口にしません。

新たな方法を模索し、簡略化を図る(Invent and Simplify)

リーダーはチームにイノベーション(革新)とインベンション(創造)を求め、常にシンプルな方法を模索します。リーダーは状況の変化に注意を払い、あらゆるところから新しいアイデアを探しだします。それは、自分たちが生み出したものだけには限りません。私たちは新しいアイディアを実行する上で、長期間にわたり外部に誤解されうることも受け入れます。

適切なリスクをとり、正しく判断する(Are Right, A Lot)

リーダーは多くの場合正しい判断を行います。リーダーは強い判断力を持ち、経験に裏打ちされた直感を備えています。

最良の人材を採用し、育成する(Hire and Develop the best)

リーダーはすべての採用や昇進においてパフォーマンスの基準を引き上げます。優れた才能を持つ人材を見極め、組織全体のためにすすんで人材を活用します。リーダーはリーダーを育成し、コーチングに真剣に取り組みます。

最高水準の追求(Insist on the Highest Standards)

リーダーは常に高い水準を追求します。この水準は高すぎると感じられるかもしれません。リーダーは継続的に求める水準を引き上げていき、チームがより品質の高い商品やサービス、プロセスを実現できるように推進します。リーダーは不良を下流に流さず、問題を確実に解決し、再び同じ問題が起きないように改善策を講じます。

広い視野で構想する(Think Big)

狭い視野で考えてしまうと、大きな結果を得ることはできません。リーダーは大胆な方針と方向性をつくり、示すことによって成果を導きます。リーダーはお客様に貢献するために従来と異なる新たな視点をもち、あらゆる可能性を模索します。

行動へのこだわり(Bias for Action)

ビジネスではスピードが重要です。多くの決定や行動はやり直すこともできるため、分析や検討を過剰に行う必要はありません。計算されたリスクをとることも大切です。

倹約(Frugality)

私たちは、お客様にとって重要でないことには、あえてお金を使わないようにします。倹約の精神は、リソースを効果的に活用するための創意工夫、自立心、更に、発明を育てる源となります。スタッフの人数、予算、固定費は多ければよいものではありません。

自己批判もきちんと表明する(Vocally self critical)

リーダーは自分やチームの欠点や間違いを率直に認めます。たとえお互いが気まずい思いをする事があったとしても、問題や事実に正面から立ち向かいます。リーダーは常に自分たちを最高水準と比較、評価します。

周囲の信頼を(Vocally self critical)

リーダーは強い信念をもちつつ、真摯にいろいろな意見を受けいれ、誠実に耳を傾け、謙虚であり続けます。

自己批判もきちんと表明する(Vocally self critical)

リーダーは自分やチームの欠点や間違いを率直に認めます。たとえお互いが気まずい思いをする事があったとしても、問題や事実に正面から立ち向かいます。リーダーは常に自分たちを最高水準と比較、評価します。

メモ

  • 作るもののアイデアの源泉となるのは、顧客からのリクエスト、競合の分析、新しいテクノロジー、ユーザー調査、セールスやマーケティングのチーム、ブレインストーミング、より大きなプロダクトのビジョンなどです。
  • 技術的な経験はなぜ重要か?コンピューターサイエンスのバックグラウンドを持たない人の多くが、エンジニアとの関係を構築するのに苦労するからです。
  • エンジニアとお互いに敬意を払う関係を作ることができる、エンジニアリングにどれくらい時間がかかるか、直感的にわかる、色々仕事をこなし、自力でどうにかする。
  • 早い時期にチームを具体的に支援する。チームは大抵新しいPMにわずかながら疑いの目を向けています。PMになってすぐの時期にチームの支援に専念することで、チームの不安を拭い去ることができます。
  • チームをよくみて単調でつまらない仕事を排除したり、棚上げにしてきた(でもほんとうはやりたかった)調査をしたりしましょう。これは新しいチームで良いスタートを切り、好意をもってもらって今後のプラスにするための簡単な方法です。
  • 早い時期に転換点を迎えるためのもう一つのヒントは、人々に価値をみせることです。もしあなたがそこにいなければ起きなかったようなことをしているという事実を作るのです。
  • PMは顧客に関するエキスパートであるということです。
  • 優れたPMはみんなゴール指向です。やり遂げ、集中し、優先順位をつけることができます。優れたPMはユーザーのことを気にかけています。PMは自分のプロダクトを使います。仕様が完成したときが仕事の終わりではなく、現在のバージョンを隅から隅まで使います。全てが完了するまでしっかりとフォローするのです。

About The Author

kazuya.zbz

美味しいご飯と、写真を撮るのが大好きな26歳。福井→京都→US→Rettyという会社でディレクターをしたのち、現在は(一応)地球一周中のKazuya Yabu です。

Leave a Reply

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This blog is kept spam free by WP-SpamFree.

Close