タグ: キャリア

プロダクトマネージャー、シニアプロダクトマネージャー、プロダクトディレクターの違いは何でしょうか？

私が新米プロダクトマネージャーの頃は、自分とシニアプロダクトマネージャーの何が違うのか、全く分かりませんでした。

私は仕様書を書き、彼らは仕様書を書きました。

この記事は、「The 3 Stages of a Product Manager’s Career」を著者の了承を得た上で翻訳したものです。この記事の内容をより幅広く、深く学びたい場合は、この記事の著者であるJackie Bavaroによる『世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~』をご覧ください。

著者: Jackie Bavaro
翻訳者: 渡辺圭祐

私は次のリリースで何を作るべきかを1ページで書きましたし、彼らもそうしました。

プロダクト責任者が送る戦略文書も、より広い範囲（機能ではなくプロダクト）の仕様書に過ぎないように思えました。

だから、キャリアアップは一直線だと思い込んでいたのです。キャリアガイドに書かれているレベル別のスキルのグリッドを見ると、みんな同じ仕事とスキルを持っていて、ただ習得のレベルが違うだけだという考えが強くなっていました。私は、リード、GPM(グループプロダクトマネージャー)、プロダクト責任者、そして最終的にはCEOに昇進するまで、プロダクトを出荷することでどんどん上達すると思っていました。

これは非常に誤解を招きやすいメンタルモデルです。私は、シニアプロダクトマネージャーやプロダクト責任者が行う他のすべての仕事を見逃していました。彼らの仕事のほとんどは、私が招待された会議の外で行われたのです。私がアサナのマネージャーだったとき、多くの部下が同じような誤ったメンタルモデルを持っていることに気づきました。

プロダクトで成功するために何が必要なのかを理解したかったのです。シェラヤス・ドーシ(Shreyas Doshi)のスコープ／インパクト・マトリクスは、まさに私の心に響くものでした。キャリアを積んでいくと、仕事ができるようになることもあれば、範囲が広がることもあります。しかし、範囲が広がれば広がるほど、また初心者に戻ってしまいます。新しい仕事は得意ではないし、それを実感することもあります。

でも、範囲が広がるというのはどういうことなのでしょうか。ただ単に、より大きなチームを任されただけなのでしょうか？調べていくうちに、差別化できるのは所有するプロダクトの範囲ではなく、昇進することで手にするまったく新しい責任（とそれに伴う期待）であることに気づきました。実は、ステージが上がるごとに、「偉大であること」の定義全体が変わってくるのです。

プロダクトのキャリアには、3つのステージがある。

3本の矢印が重なった図。前半はプロダクトの出荷、25％から75％はプロダクト戦略、後半は組織的な卓越性をカバーする。

プロダクトの出荷

最初のステージは、プロダクトの出荷です。ここでは、発見、定義、デザイン、開発、出荷、報告という、日々のプロダクトライフサイクルの仕事が行われます。

このステージで、優れたプロダクトマネージャーは、顧客を喜ばせ、ビジネス目標を達成するプロダクトを出荷します。

あなたがインターン、アソシエイト・プロダクトマネージャー(APM)、PM1、PM2であるならば、おそらくこれがあなたの仕事の全てでしょう。プロダクトの出荷がだんだん上手になっていくでしょう。しかし、ある時点で停滞し始めます。プロダクトセンスや分析力、実行力を高めるだけでは、シニアプロダクトマネージャーにはなれません。なぜなら、シニアプロダクトマネージャーになると、仕事の内容が変わるからです。

プロダクト戦略

シニアプロダクトマネージャーになると、新たな責任を担うことになります。これまでは、何をやるかを指示されるだけでした。新しいビジネスチャンスを見つけ、それを勝ち取るためのプランを組み立てるのが、あなたの責任です。これまで通り、お客様に喜ばれるプロダクトを出荷し、目標を達成する必要がありますが、今度は自分が目標を設定することになるのです。

この段階で、優れたPMは、プロダクトがマーケットで成功するための勝利の戦略を考え出すのです。

シニアプロダクトマネージャーやリードプロダクトマネージャーになると、プロダクト戦略がどんどん上手になります。ピープル・マネージャーになれば、部下にとって最高の上司になろうとするかもしれません。しかし、ディレクター（特にシニアディレクター）に飛躍しようとすれば、また仕事の内容が変わってくるでしょう。

組織の卓越性

第3ステージのあなたの仕事は、優れたチームを作ることです。一人のプロダクトマネージャーとしてできることを超えて、組織が勝つための戦略を立て、勝つためのプロダクトを出荷できるように、人を雇い、指導し、プロセスを設定することがあなたの責任です。

そして、あなたの下に強力な組織を作ることは、仕事の半分に過ぎません。残りの半分は、会社の他の部分に対する戦略的アドバイザーになることです。このステージでは、他のエグゼクティブと一緒に会議に出席します。自分の組織を代表することもあれば、会社のことを考える賢い人の一人として同席することもあります。他の会社のリーダーとの関係や信頼関係は非常に重要です。

このステージでは、優れたプロダクトリーダーは、成功したプロダクトを大規模に出荷し、会社全体の強力な戦略的アドバイザーとなることで、会社の成功に貢献します。

最後に

プロダクトマネジメントは1つの仕事ではなく、3つの仕事です。この業界では、昇進するにつれて、役割や成功の形がどれだけ変わるかについて、あまり明確には語られてきませんでした。

キャリアアップを目指すのであれば、自分がどのステージにいるのか、次の昇進はステージ内なのか、ステージをまたぐものなのかを知ることが重要です。

ステージ内での昇進を目指すのであれば、それは本当に自分の技術を向上させることなのです。より速く、より少ないミスで、より良い結果を出せるようになるまで、「今やっていることを続ける」のです。同僚からのフィードバックは、自分の改善点を的確に指摘する傾向があるので、注意してください。

次のステージへの昇進を目指すのであれば、より意識的に行動する必要があります。新しい職務にシフトし始めると、現在の職務で出来の悪い仕事をしていると感じることがよくあります。自分が戦略に集中できるように、プロジェクトマネジメントの一部をリードエンジニアに譲るかもしれません。会社全体にとって正しいことをしようとするあまり、直属の上司の一人を怒らせてしまうかもしれません。上司や上司の同僚と協力して、次のステージに進むために最も重要なフィードバックを得てください。

各レベルで昇進するために必要なことをもっと詳しく知りたい場合は、『世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~』に、例を挙げて章立てしてあります。

フォローして最新記事をチェック！

• Twitter
• Facebook
• LinkedIn

この図をご覧になったことがある方もいらっしゃるでしょう。プロダクトマネジメントが多様なスキルセットの交差点であることをエレガントに示しています。

そのシンプルさゆえに、この言葉はプロダクトマネジメントのミームとして最も成功を収め、プロダクトマネジメントという学問にとって良い影響を与えてきました。

昔、若いPMの卵であった私は、この言葉によって、学習の幅を広げるために構成する必要があることに気づきました。しかし、どこに焦点を当てるべきかということについては、教えてくれませんでした。私はすべてを学ぼうとし始めましたが、今にして思えばそれは間違いでした。

この3つの円についてすべてを学ぶには、この地球上に十分な時間はありませんので、この図が役に立つとしても、結局は非現実的なものになってしまいます。

それよりも、その交点を構成するものが何であるかを知る方がずっと役に立ちます。

この交差点は、私がMVPM（Minimum Viable Product Manager）と呼んでいるもので、効果的なジェネラリストプロダクトマネージャーになるために役立つ一連のスキルや知識を定義しており、ほとんどすべての問題に取り組むことができる人たちです。

MVPMは、決して、効果的になるためにそのスキルを習得する必要があることを意味するものではありません。それはこれから始める人にとって非現実的であり、逆効果です。その代わりに、この本は、存在しないプロダクトマネジメントのコースのシラバスのようなものと考えてください。

▼本記事の内容

1. テクノロジー
   • 1. スタック
   • 2. システムアーキテクチャー
   • 3. データモデルとそのAPI
   • 4. 注力すべきではない分野
2. ビジネス
   • 1.プロジェクトマネジメント
   • 2. インパクトのモデル化
   • 3. データ収集と分析
   • 4. 注力すべきでない分野
3. ユーザーエクスペリエンス
   • 1. プロダクトのデザインパターンを知る
   • 2. ユーザー・エクスペリエンス・リサーチの実行方法を知る
   • 3. アイデアをプロトタイプ化する方法を知っておく
   • 4. 注力すべきでない分野
   • MVPM

テクノロジー

1. スタック

エンジニアが「スタック」と呼ぶのは、プロダクトに機能を提供する（つまりプロダクトを動作させる）ために使用されるテクノロジーのレイヤーのことを指します。お客様がランディングページを開いた瞬間から、アカウントを削除するまでの間、スタック内のテクノロジーがすべてを処理します。

最速の学習方法 – エンジニアに頼んで、スタックを高レベルで説明してもらう。各技術の名前を書き留めておく。これらの用語を素早くググれば、選択した各技術の高レベルの利点とトレードオフ、およびそれらがどのように調和して動作するかを学ぶことができます。簡単にウサギの穴に落ちてしまうので、ハイレベルなものにとどめておきましょう（検索キーワードに「トレードオフ＋メリット＋対(trade offs + benefits + vs)」を追加してください）。

どうすればより良いPMになれるのか？– エンジニアが何かを構築する方法について議論しているとき、専門用語が部屋中に飛び交います。スタックを知っていれば、少なくともそれについていくことができますし、時間が経つにつれて、スタックのどの深さを指しているのか理解できるようになります。一般的に、スタックの中で触らなければならない層が多いほど、あるいは層が深いほど、変更はより複雑でリスクの高いものになります。これを知ることで、問題を解決するための別の方法を再度検討するようになるかもしれません。

2. システムアーキテクチャー

スタックがどのような技術を使用しているかを表すとすれば、システム・アーキテクチャは、それらの技術がどのように構成され、プロダクトを提供するために連携しているかを表します。スタックが主に生の技術的能力であるのに対し、プロダクトのアーキテクチャは顧客が意図する動作を設計に取り入れるものである。

最速の学習方法 – エンジニアにアーキテクチャを描くように頼む。このような答えが返ってくるでしょう。

まず、慌てないことです。システムの各コンポーネント（ボックス）が何をするのか、説明してもらってください。あるものはインターネットのリクエストを処理し、あるものは「ビジネスロジック」を収容し、さらにあるものは保存されるデータを保持します（シリンダー）。

次に、信じられないかもしれませんが、これはあなたにとって非常に有益なことです。

アーキテクチャを理解すると、プロダクトをシステムのように考えるようになり、それは一般的にエンジニアも同じように考えるでしょう。システム内の各コンポーネントが全体にどのように寄与しているかを理解することで、より良い意思決定やトレードオフを行うことができるようになります。

一般的に、システムの中で最も接続の多い部品は、データや機能を依存しているものが多いため、変更が最も複雑になります。ビルドを完了するために変更しなければならないコンポーネントが多ければ多いほど、依存関係も増え、プロジェクトの実行は困難になります。

大企業では、扱うコンポーネントの数は、対話が必要なチームやグループの数と同義であることが多く、プロジェクトを実行するために必要な調整も多くなります。

3. データモデルとそのAPI

データモデルは、プロダクトが使用する情報を整理し、その情報の断片が互いにどのように関連しているかを標準化するものです。「情報」とは、ユーザー、プロダクト、クレジットカードなどのことを指し、これらを総称して「エンティティ」と呼びます。これらのエンティティは、特定の構造化された方法で互いに関連付けることができます。例えば、ユーザーは多くのプロダクトを持つことができますが、クレジットカードは1つしか持つことができません。

データモデルは、特定のエンティティが特定のコンポーネントに「住んでいる」という点で、システムアーキテクチャと密接に関係しています。ユーザーモデルはコンポーネントAにあり、商品データもそうかもしれませんが、クレジットカードはその機密性から、コンポーネントBに置かれます。しかし、その中でどのユーザーがクレジットカードを保持しているかを知る必要がある場合、データを共有するためにコンポーネントAからコンポーネントBに接続する必要があります。それはより難しく、それを達成するためにAPI（アプリケーション・プログラミング・インターフェース）が必要になります。

APIはデータモデルの上に構築され、任意の2つのコンポーネントが互いに会話し、その基礎となるモデルに関する情報を交換する方法を表します。重要なのは、APIによって外部のコンポーネントと対話できるようになることです。GoogleマップからUberを呼び出すとき、GoogleマップアプリはUberのコンポーネントと会話しているのです。ほとんどのアプリケーションには、パブリックAPIとプライベートAPIがあり、それぞれインターネット上の誰でも使えるものと、指定した人だけが使えるものがあります。公開APIを知ることは、あなたのプロダクトが外部とどのように相互作用できるかを理解するために重要です。

最速の学習方法 – まず、パブリックAPIについて理解することに集中すべきです。これらは通常簡単に見つけることができ、多くの場合、あなたのウェブサイトの開発者向けドキュメントに掲載されています。それらを見たとき、コードを見ることになるので、あなたのバックグラウンドによっては、それが怖かったり、そうでなかったりするかもしれませんが、ドキュメントが中途半端であれば、それは関係なく、問題なく読むことができるはずです。APIを研究することの良さは、APIが基本的なデータモデルのほとんどを表していることが多いので、一石二鳥であることです。

どうすればより良いPMになれるのか？– データモデルを知ることは、より良いプロダクトを作るためにどのような情報を利用できるか、そしてその情報にアクセスすることがどれだけ難しいかを知る能力を拡大します。APIを知ることは、パートナーやサードパーティの開発者があなたのアプリケーションから取得できる情報の種類を理解し、どのような種類の統合が可能かを理解することを意味します。ソフトウェアの拡張性は、最も価値のある特性の1つであり、他のプロダクト（あなたの顧客が毎日使っている可能性のあるプロダクト）とうまく連携できることは、すぐにテーブルステークスとなりつつあるのです。

4. 注力すべきではない分野

プログラミング。誤解しないでください、私はプログラミングが好きですし、より良くするのに役立ちますが、高度に技術的なプロダクトでない限り、効果的なPMになるためにプログラミングは必要ありません。もしあなたがPMとしてコーディングをしていることに気づいたら、実際にレバレッジの高い仕事をしているのか、他に何をすべきなのか、自問自答する必要があるかもしれません。とはいえ、少なくとも1つのアプリを作り、本番環境に出荷した経験は、非常に価値があり、楽しいものだと思います。

ビジネス

1.プロジェクトマネジメント

退屈ですよね。私も嫌いですが、本当に大切なことです。プロジェクトをうまく運営できなければ、良いPMになることはできない。その通りです。

最速の学習方法 – これは難しい。効果的なプロジェクトマネージャーになるには、多くの経験と時間が必要です。本を読めばいくらでもわかるが、結局は人間の行動の問題なのです。一緒に仕事をすることになる様々な性格について学ぶには時間がかかりますし、どのようにアプローチするかについてのアドバイスも、その人の性格に左右されることが多いのです。

とはいえ、学習曲線を加速させるために投資できるソフトウェア特有のものがいくつかあります。

1. プロダクト開発の基本を理解し、チームと共感できるようにする。バージョン管理（Git）、共同プログラミング（GitHub）、品質保証プロセス、そして、いつどのようにコードがユーザーにデプロイされるのかについて、高いレベルで学ぶことができます。
2. ソフトウェアチームを悩ませる一般的な問題と、それを解決するために他の人々が開発したプロセスについて学ぶ。アジャイル、スクラム、カンバンといったものを目にすることがあるでしょう。自分の会社が使っているかどうかに関わらず、それらのアプローチの背後にある哲学を学ぶことには価値があります。
3. 会社での意思決定を理解し、ステークホルダーをマッピングする。ステークホルダーとは、顧客、上司、チームメンバーの上司、他のPMのことです。プロジェクトがどのような状況、方向性で進んでいるのかを、ステークホルダーが気にするレベルで全員が把握できるような方法を見つける（これも自分で見つける必要があります）。

どうすればより良いPMになれるのか？– チームとより多くのことを成し遂げられるようになり、人々はあなたと一緒に働くことを楽しむようになる。なぜなら、誰もが管理の悪いプロジェクトを嫌うからです。

2. インパクトのモデル化

測定されないものがうまくいくことはほとんどありません。すべてのプロダクトは、ユーザーの成長、機能の採用、収益など、最終的な成功に結びつく定量的な目標を持っている必要があります。

あなたのチームが次に作ることができる最も高いレバレッジのものを議論しているとき、そのプロダクトがこれらの測定基準でどのようにダイヤルを動かすかのモデルを開発できることが重要です。

最速の学習方法-スプレッドシートを使うときが来たのです。良いモデルは、2つのことを明確に示しています。

プロダクトのユニットエコノミクスと、それを生み出す仮定

• 新規顧客の獲得にいくらかかるか？
• プロダクトの提供にはどれくらいの費用がかかるか？
• コンバージョンは目標の針路をどれだけ変えるのか？

予測される影響とそれを生み出す前提条件

• このプロダクトは今後1年間でどれだけの効果をもたらすか？次の3年間は？
• このプロダクトを強化し、サポートするために何人の従業員が必要か？
• コスト削減、インフレ、競争などの市場原理を長期的にどのように考慮するのか？

どうすればより良いPMになれるのか？– プロダクトのモデルを構築することは、直感的な仮定をテストし、プロダクトが十分な可能性を持ち、それを実行する価値があることを確認するための素晴らしい方法です。また、ステークホルダーが納得する形でプロジェクトを正当化したり、他のプロジェクトとの機会損失を簡単に比較できるようになるため、仕事もやりやすくなります。

3. データ収集と分析

迅速な意思決定を行うためには、独自にデータを収集することが不可欠です。なぜなら、分析に携わったことのある人なら誰でも、インサイトはデータの反復的な探索によって得られるものであり、自分で考えた完璧なレポートではないことを知っているからです。

また、重要な時にデータに基づいた意思決定を行う能力も低下させます。ほぼ毎日、あるシナリオでプロダクトがどのように振る舞うべきかという決定が飛び込んできますが、決定をサポートするデータがあれば、あなたとあなたのチームは正しい方向に向かっていると自信を持つことが簡単にできます。

最速の学習方法 – 目標はデータの独立性。SQLクエリーを書く必要があるか、ドラッグ＆ドロップのインターフェースを使うかは、会社のデータインフラに依存します。それが何であれ、利用可能なツールを学ぶために投資する必要があります。ググってみてください。

どうすればより良いPMになれるのか？– データに簡単にアクセスでき、それを快適に利用できれば、より多くのデータを利用でき、より反復的な作業ができるようになります。次に何を作るかを検討しているときでも、発売したプロダクトがどうなっているかを見ているときでも、データを重要なインプットとして意思決定に利用する反射神経が身につき、その結果、より良いプロダクトが生まれるのです。

4. 注力すべきでない分野

経営学部の出身者から言わせてもらうと、戦略的なビジネスケースや3年計画など、MBAの成果物を作って時間を浪費しないでほしいのです。私はそれをデタラメとまでは言いませんが、ソフトウェアで成功するための方法ではありません。ビジョンを理解し、それを達成するために解決すべき問題を見つけ、それを解決するための仮説を立て、実際の顧客とできるだけ早くそれを検証する。同じことを繰り返す。

ユーザーエクスペリエンス

1. プロダクトのデザインパターンを知る

ほとんどのプロダクトは、計画的かどうかにかかわらず、時間の経過とともにデザインパターンを発達させます。パターンとは、プロダクトの中で同じビジュアルやインタラクティブなコンポーネントを一貫して使用することです。ボタンのテキストはすべてフォントサイズ25px、フォームのフィールドは3つ以内、エラーが発生するたびに爆発音を鳴らし、ユーザーに詳細をメールで通知する、これらはすべてパターンです。

プロダクトのパターンを知ることは、ユーザーがプロダクトをどのように頭の中でマッピングしているかを理解し、時間をかけて効果的に新機能を与えるには非常に重要です。いつもは「新しい機能を追加する」という緑色のボタンをユーザーに与えているのに、今回は「あなたの心を揺さぶる」というオレンジ色のボタンに切り替えたら、ユーザーは混乱するでしょう。

プロダクトが成長するにつれ、パターンの一貫した使用はさらに重要になります。なぜなら、パターンを使用することで、チームは互いに独立して作業しながらも、まとまりを感じるプロダクトを構築できるからです。

デザインパターンはまた、スタイルガイドやコンポーネントなどのテクニカルパターンと調和して開発されるのが一般的です。

最速の学習方法 – デザイナーは、これらのパターンを熟知しているはずですし、スタイルガイドへのリンクも教えてくれるはずです。また、フロントエンドエンジニアに相談すれば、パターンライブラリへのリンクを教えてくれるでしょう。

どうすればより良いPMになれるのか？– 簡単に言うと、パターンに基づいてプロダクトを設計することは、はるかに簡単で迅速です。パターンによって、あなたのチームが過去に行った設計上の決定、つまり、顧客にとって使いやすいプロダクトを実現するための決定の上に立つことができるのです。もし、既存のパターンを壊す必要があるのなら（もちろんそうする正当な理由もありますが）、プロダクトの長期的な健全性のためにそれが必要であるという正当な理由を用意しておいてください。

2. ユーザー・エクスペリエンス・リサーチの実行方法を知る

PMは顧客の声であることが前提です。ユーザーを理解しなければ、優れたプロダクトを作ることはできません。一人の人間に直接インタビューすることから、何百万ものユーザーの行動を定量的に分析することまで、優れたリサーチの基本を理解することは、あなたの仕事にとって不可欠なことなのです。

最速の学習方法 – 効果的なリサーチは非常に大きな分野なので、ウサギの穴に行かせるのではなく、次のことを理解することに集中することをお勧めします。

• サンプルサイズと統計的有意差の計算方法を理解する。
• サンプルを正規化する方法と、それがなぜ重要なのかを理解する。
• 調査やインタビューにおいて、偏りのない、誘導的でない質問をする方法を理解する。
• 結果を統合し、誤った結論を出さないようにする方法を理解する。

どうすればより良いPMになれるのか？– 一貫して頻繁にプロダクトを顧客にテストすることで、プロダクト開発における当て推量（およびリスク）の多くを取り除くことができます。プロジェクトが始まる前から、解決しようと考えている問題が本当にあるのかどうかを検証するために、テストを行うべきです。デザインと開発の段階では、プロダクトのデザインが使いやすく、顧客の問題を解決する可能性が高いかどうかをテストする必要があります。リリース後は、解決したかった顧客の問題が解決されたかどうかを検証する必要があります。

3. アイデアをプロトタイプ化する方法を知っておく

プロトタイピングとは、アイデアを効果的に表現するためのビジュアルモックアップを作成できることを意味します。プロトタイプは、以下のことを実現するのに十分なものでなければなりません。

プロダクトコンセプトを明確に伝える

プロダクトの体験を口頭や文章で伝えることは非常に困難です。プロトタイプは、人々が見ることができ、できれば対話できるもの（コードなしで可能）であれば、10倍以上の効果があります。

これには2つの理由があります。第一に、顧客が実際に操作するものという観点からプロダクトを明確にしなければならないこと、第二に、人間は本来視覚的に考えるものなので、プロトタイプは、チームの全員が同じ言葉で話し、それぞれの視点を効果的に伝えることができるように、競争の場を平準化するためです。

デザインの遅れや欠落がある場合、チームのブロックを解除する

多くのプロジェクトでは、プロダクトのデザインが開発に先行していることが重要です。デザイナーが「開発の先を行く」ことを心がけるのは、開発者が特定の方向性でプロダクトを作り始めると、その切り替えコストが格段に高くなるためです。

プロダクトデザインの多くは反復的で、開発と並行して行われるため、挫折（例えば、ユーザー調査によってデザインが効果的でないと判断された場合など）があると、デザインはすぐに遅れをとることになります。そんなときこそ、PMは腕まくりをしてリードデザイナーの「デザインインターン」となり、エンジニアが開発を続けられるよう、ピクセルのプッシュやモックアップの出荷をサポートしなければならないのです。

最速の学習方法 – これを正当化するために時間を費やすことはしませんが、Sketchを使い始めるといいでしょう。

どうすればより良いPMになれるのか？– プロトタイプを作成し、自分の考えていることを人に見せることで、相手が理解していると思い込むのではなく、自分のアイデアに対してチームからより良いフィードバックが得られるようになり、誤ったコミュニケーションによって無駄な労力を費やすリスクを減らすことができるのです。また、たまには実際に目に見えるものを作ってみるのもいいものです。

4. 注力すべきでない分野

優れたビジュアルデザイナーであることにこだわらないことです。洗練されたインターフェイスを作る能力は、プロダクトデザインという深い技術を学ぶためにキャリアを積んできた人にとっては、冗長で無力なものです。あなたがデザインに精通しているのであれば別ですが（もちろん、そういう人もいます）、おそらくあなたは自分が優れていると思っているだけで、実際は最低なのです。

MVPM

このようなことを学ぶことを矮小化したいわけではありません。簡単なことではありませんし、多くの時間がかかるので、少しずつ取り組んで、学ぶことを楽しんでください。この記事が、あなたが優れたプロダクトマネジャーになるための探求において、少しでも効率的であることを願っています。

他におすすめの記事はこちらです。

プロダクトマネジメントのブラックボックス

7 Heuristics for being a Product Director

The Time Value of Shipping

Brandon Chuの他の記事を読む👀

👉 Brandon Chu

フォローして最新情報をチェック！

• Twitter
• Facebook
• LinkedIn