サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
productmanager55.hatenablog.com
ありがたいことに、こちらのestieさんの記事に、自分が6年前に書いた記事を引用していただきました。 www.estie.jp いい機会なので、6年前の自分の考え方が、時を経てどう変わったのかを棚卸するために、この記事を書いてみることにしました。 引用していただいた記事はこちら productmanager55.hatenablog.com この記事をChatGPT先生に要約してもらった内容がこちら プロダクトマネージャー(PM)に求められるスキルや考え方は多岐に渡り、出身背景も様々である。 組織や市場によって求められるPMの役割やスキルは異なる。例えば、アメリカでは技術力を持つPMが求められ、中国では新たなニーズを見つけ出す能力が求められる。 PMの役割は一概には言えず、組織内で求められる役割を理解し、自身のスキルと照らし合わせて目指すべき姿を定義することが重要。 組織の「視力」を理解す
こちらはプロダクトマネージャー Advent Calendar 2021 の21日目の記事です。 なんと10ヶ月ぶりのブログ投稿となってしまいました…! 久津(ひさつ)と申します。現在はGLOBISで法人向けプロダクトのPMをやっており、これまでのキャリアでエンジニア→プロジェクトマネージャー→プロダクトマネージャーという順で経験を積んできております。 この記事では、プロダクトマネジメントに活きるウォーターフォールプロジェクトマネジメントの経験について書きます。現在プロジェクトマネージャーで今後プロダクトマネージャーへのジョブチェンジを考えられている方、既にプロダクトマネージャーだがプロジェクト推進で悩まれている方の参考になればいいなと思っております。 プロダクトマネジメントとプロジェクトマネジメントの違い これについては説明されている記事や書籍が腐るほどあるので割愛します。こちらの記事が
こちらはプロダクトマネージャー Advent Calendar 2020の21日目の記事です。 改めまして久津と申します。今年の6月からグロービスでPMをやっております。 はじめに 「PMにはどのようなスキルが求められるのか」 「PMになるためには何から学べばいいのか」 こういった話をよく聞きます。若手のエンジニアからよく相談されたりもします。その際に自分なりに「まずドメイン知識を学ぼう」とか「ユーザーの声を聞きに行こう」などアドバイスはするのですが、毎回自分の口から発しているアドバイスに自分自身が腹落ちしないというか、芯を食っていない気がしていました。 PMのスキル定義には、有名なプロダクトマネジメントトライアングルや、エンジャパン岡田さんがこの記事で定義した「PM SkillChart HEX」があります。 note.com これらの定義は良く整理されてて素晴らしいと思いますし、内容に
こちらはGLOBIS Advent Calendar 2020の10日目の記事です。 グロービスには今年の6月にジョインし、早いもので半年が経過しました。現在は特定のプロダクトのPMというより、プロダクトの裏側を整える系のプロジェクトをいくつか動かしています。 そんな私は、社内で「可視化おじさん」と名乗っております。 以前の記事でプロダクトマネージャー(以下PM)がキャッチアップする際に「様々な構造の可視化が大事だよ」と書きました。実際にそれを実践してどんどん可視化しまくった結果、お褒めのお言葉をいただくことが多かったので、調子に乗って名乗ってみました。 というわけで、次に可視化おじさんが可視化を試みようとしているのは「PMの意思決定ロジック」です。この記事では、PMの意思決定ロジックの可視化によるメリットなどを書いていきます。 プロダクトマネージャーの意思決定とは PMは様々な種類の意思
はじめに 以前「プロダクトマネージャーの転職活動記」を書きましたが、その続編となります。実際に転職をして3ヶ月ほど経ち、それなりに良いスタートを切れたと思っています。 そんな中で、上司や同僚から「キャッチアップが早いね」とか「3ヶ月でよくそこまで把握してますね」とよく言われることに気づきました。あまり自覚はなかったのですが、実は高速キャッチアップが自分の得意技みたいで、それが良いスタートに繋がりました。 これが自然と身についた理由は、リクルート時代にプロジェクトマネジメントに特化した組織に属していて、組織やプロダクトが既に存在している状態から立ち上がったプロジェクトに参画するケース、つまり「新しい環境でゼロからキャッチアップをする」機会が人に比べて多かったためだと思います。その後プロダクトマネージャーとしても1回の出向、2回の転職をしているので、単純に場数が多いんですね。 というわけで、新
はじめに 前提:経歴 前提:転職活動を始めた経緯 準備:企業選びの軸を言語化する 準備:自分のスキルや成果を言語化する 実施:転職サービスを選ぶ 躓き:面接が通らない…! 問題:Why/WhatとHowに一貫性がない 問題:プロセスのアピールになりがち 再開:内定3社 おまけ:よく聞かれた質問 はじめに 2020年6月に株式会社CAMPIFREを退職し、株式会社グロービスに転職しました。 今回が3回目の転職なのですが、組織によって役割が異なるプロダクトマネージャーとしての転職には独特な難しさがありました。 そんな中、こちらの記事が非常に参考になりました。 note.com というわけで、自分の経験も誰かの役に立てばいいなと思い、転職活動記を残します。 前提:経歴 自分の過去の経歴はざっくりこんな感じです。 Javaエンジニア(4年) インフラエンジニア(3年) プロジェクトマネージャー(4
これは何か 行動経済学をプロダクトマネジメントに活かすために、人の様々な行動パターンやバイアス、そしてその活用方法を自分なりに整理したものです。 ※記事の最後に参考にした文献を記載しています。 ※とてつもなく長いのでブックマークして必要な時に参照するのがオススメです。 ※今後も日々更新・追記していく予定です。 インデックス 更新履歴 行動経済学とは何か プロダクトマネジメントとどう関係するのか 前提:システム1とシステム2 人は選択の機会を欲しながら意思決定を避ける 人は集団に左右される 人はすぐに思いつくものに左右される 人はイメージに左右される 人は感情に左右される 人は損をすることを嫌う 人は所有物を過大評価する 人は後から辻褄を合わせる 人はピークを評価する 人は状況を評価しない 人は相対的にしか評価できない 人は全体を無視し一貫性を追い求める 人は難しい問題を回避したがる 人はお
この記事はEngineering Manager Advent Calendar 2019の19日目の記事です。 久津(@Nunerm)です。CAMPFIREでプロダクトマネージャーをやっていて、CAMPFIRE Ownersという融資型クラウドファンディングのサービスを担当しています。 この記事では、エンジニアとステークホルダーの間で情報のINとOUTをコントロールする際に気をつけていることをまとめます。組織によってベストプラクティスは異なると思いますが、何かの参考になれば幸いです。 前提:情報はオープンにするべき 「情報のコントロール」とは情報を意図的に隠すことではありません。例えばSlackでのDMやプライベートチャンネルの利用率が高いと、情報の非対称性によって属人化が進み社内政治が蔓延ります。 ※ EOF2019で登壇されていた@tokorotenさんの「チャットコミュニケーション
この記事はProduct Manager Advent Calendar 2019の15日目の記事です。 久津(@Nunerm)です。CAMPFIREでプロダクトマネージャーをやっていて、CAMPFIRE Ownersという融資型クラウドファンディングのサービスを担当しています。 今日は自分が実践してる「プロダクトマネージャーの思考整理」に関する話を書きます。日々忙しいプロダクトマネージャーの頭の中のデフラグの手助けになれば幸いです。 プロダクトマネージャーには考えることがたくさん このアドベントカレンダーでも度々引用されている「INSPIRED第2版」では、プロダクトマネージャーの責任を 可能性を評価し、何を作って顧客に届けるのかを判断することだ。 (INSPIRED第2版より引用) と定義しています。 「可能性を評価する」「何を作って届けるか判断する」と簡単に書いてありますが、実際にこ
medium.com こちらの「プロダクトマネジメントに関する教訓」の記事がPM界隈で少し話題になってます。 これに関して、とある日に会社のメンバーから というおねだりをもらいました。英語苦手なのに… というわけで、せっかくだから解読した結果をここにまとめます。そのまま翻訳するのは許可が必要な気がするので、あくまで自分の解釈と意見を書く形にしました。(間違ってたらごめんなさい) 1.MVPはユーザーセグメントを絞って作るべし 1.Being Minimalistic- Identify a target user base don’t be greedy for every possible user segment. Segments are not just demographics but can be a mobile user, a desktop user, a college
久津(@Nunerm)です。 今回はプロダクトマネジメント(以下PdM)ではなくプロジェクトマネジメント(以下PjM)の話を書きます。 PjMにおいて大事なのは「基準を作ること」だという話です。 余談:PdMとPjM いきなり余談ですが、よく「プロダクトマネジメントとプロジェクトマネジメントは違う」という話をよく聞きます。(違いについてはこちらの超わかりやすい記事にお任せします。) 元々プロジェクトマネージャーをやり、その後プロダクトマネージャーにシフトした自分としては、PdMとPjMの「どちらか」ではなく、両方できる人が強いと思ってます。PjMはプロジェクトのリスクを減らし効率的に進めるための武器なので、プロダクトマネージャーにとってはプロダクトが達成したい世界への最善の道筋を見つけることに役立ちます。逆にPdMの視点を持っているプロジェクトマネージャーは、事業戦略や優先度を把握している
久津(@Nunerm)です。 前回記事に引き続き、今回もNewsPicksアカデミアの及川ゼミの講義や懇親会からの学びをアウトプットします。 今回はプロダクトマネジメントにおける「優先度付け(プライオリタイゼーション/トリアージ)」についてです。 PMにとっての優先度付けとは 個人的には優先度付けはPMにとって最も重要な役割の1つだと思っています。 以前も別の記事で紹介しましたが、メルペイのPMの丹野さんがProduct Manager Conference 2018にて「PMの役割」を以下のように説明しています。 この「①事業目標を達成する打ち手を導き」の中に「優先度付け」が含まれていると思っています。 事業目標を達成するための案はステークホルダから様々なものが出てきます。例えばBtoCサービスの事業目標が「売上を昨対比で2倍」だとしたら、セールスは「新機能を作ろう」と言い、マーケターは
久津(@Nunerm)です。 「日本のPMといえば?」という問いに高確率で名前が出てくるであろう人といえば。 及川卓也さんですね。 この度その及川さんから「プロダクトマネジメントの極意」を伝授いただける機会に恵まれました。NewsPickアカデミアのゼミです。 newspicks.com 決して安くない受講料のゼミの30人の枠に対して60人の応募があったそうで、日本でもプロダクトマネジメントを学ぶ必要性に迫られている人が増えてきているんですね。 というわけで、この記事では初日の講義での学びである 「PMは技術力やドメイン知識をどこまで持つべきなのか」 の考察を書きます。 PMは技術力やドメインに詳しくあるべき? PMの役割には色々な定義がありますが、メルペイの丹野さんの言葉を借りると以下のようになります。 このうち①を実現するためには、PMがその事業が属するドメイン(領域)を理解する必要が
久津(@Nunerm)です。リクルートでPM/EMをやってます。 この記事は、Product Manager Advent Calendar 2018の23日目のエントリーです。 今回は「プロダクトマネージャーは『組織の視力』を把握するべきだ」という考えを書きます。 今いる環境でPMに何が求められるのか? 「プロダクトマネージャーの役割とは何か?」 これはPM界隈では常に問われる疑問です。 PMに求められるスキルや考え方は多岐に渡っていて、実際に活躍されているPMの方々が持っている武器も様々です。(エンジニア出身の人、マーケター出身の人、デザイナー出身の人…) また組織やマーケットによっても求められる動きや成果は変わります。 プロダクトマネージャーカンファレンス2018で登壇されたのBaiduのPMのChenさんという方のプレゼンでも「アメリカと中国で求められるPMのスキルが違う」というお
久津(@Nunerm)です。リクルートでPM/EMをやってます。 この記事はEngineering Manager vol.2 Advent Calendar 2018の15日目の記事です。 普段このブログではプロダクトマネージャーに関する記事を書いていますが、エンジニアリングマネージャーも担っているので、この記事ではEM人格で語ります。 さて、エンジニアリングマネジメントにまつわるエピソードには様々なものがあります。ゼロからチームを作り上げた話、初めてEMになって試行錯誤した話、新しいやり方を装着しようとして失敗した話などなど… 今回は私は「ボロボロのチームを立て直した話」を書きます。このシチュエーションと似た経験をされた方がどれくらいいるのかわからないですが、何かしらヒントを得ていただけたら幸いです。 ※なおこの話はリクルートの話ではありません。とある別の企業での話ですのあしからず。
プロダクトマネジメントを進めるにあたって、チーム作りは非常に重要な要素です。 私は以前崩壊寸前のアプリ開発チームの立て直しを命じられ、プロダクトマネージャー兼開発ディレクターとしてジョインしました。 前任のマネージャーが「支配型」のタイプで、細かいところまで指示をしミスをしたら叱責をする。反発しようもんならさらに叱責をする。そういう状況で開発を続けてきた結果、エンジニアメンバーのモチベーションがどんどん下り、さらにどんどん辞めていき、プロダクトの品質も悪化の一途を辿っていました。 私は1年弱試行錯誤して何とかようやくチームらしいチームにすることができました。その立て直しの際に重要視したのが「心理的安全性」ですので、簡単に紹介したいと思います。 心理的安全性とは? 心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪
プロダクトマネージャーのイベントに参加してきました! POStudyやpmconfなどのコミュニティのイベントは何度か参加したことはありましたが、このコミュニティは初めて。 1.「インタラクション設計/開発を兼務したプロダクトマネジメント」 by 冨樫さん(AWA株式会社) 冨樫さんはアプリエンジニア→デザイナー→プロダクトマネージャーという経歴から、「インタララクション設計とプロダクトマネジメント併用することによるメリット」を話していただきました。 結論から言うと 「サービスの本質を捉えた一貫性のあるプロダクトデザインができる」 とのこと。 つまりプロダクトマネジメントにおいてサービスやプロダクトの本質(解決すべきジョブ)を見極めて、インタラクション設計にてそれを具現化する。しっかり本質がわかっているので、機能ごとにブレることなく一貫性を保てる。 というわけですね。 AWAの例でいうと、
このページを最初にブックマークしてみませんか?
『productmanager55.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く