👀 これは何？これは、今まで私が色々なところで書いてきたプロダクトマネジメント関連の記事のうち、プロダクトの抽象的な概念（CoreとWhy）に関するものをまとめたものです。 プロダクトに携わる方が、考えづらい抽象的な概念に対しても意見をより強く持てるようになることを願って書きました。 目の前の業務で手一杯になっているプロダクトマネージャーや、プロダクトの成長方針にモヤモヤし始めたエンジニアやデザイナー、職種を問わずプロダクトづくりに関わる方に読んでほしいと思っています。 ※ 長文になりすぎたので音声版もつくりました。同じ内容を話しているので音声のほうが聞きやすい方はご利用ください 📕 このnoteの使い方▶ 週2時間x8回で、既存プロダクトの根幹を再検討するプロダクトのCoreやWhyは重要度は高いにも関わらず緊急度が低いのでどうしてもまとまった検討時間を取れなくなりがちです。このno

「プロダクトビジョンを定めたい！」しかし、一人で考えても浸透しないし、人を巻き込んで抽象度の高い議論をするのも難しいし…という方に向けて、最近気づいたコツを言語化してみます。 ✅ 重要な議論ほど人数を絞る。MAX5人。「ビジョンは重要なので各部署から代表者を集めて…」などとしているとあっという間に大所帯になります。大所帯で議論はできないので、コアメンバーとレビューメンバーに分けて、議論はコアメンバーで進行しましょう。 リモートで実施する場合、議論の難易度が上がるのでコアメンバーはビデオを必ずONにして安定した回線を用意してもらいましょう。難しいメンバーはレビューメンバーになってもらいます。 ✅ 民主主義的な決定をしない！を共有する多数決での意思決定は最悪です。その会議の参加者の人数比率によって決まります。エンジニアとビジネスサイドの参加者のどっちが多いかで決めるのは意味がありませんし、意思

「ペルソナは一人に絞るべきか？」「作ったものの活用しきれていない」「私のプロダクトのペルソナは53万人います」といったお話をよく聞きます。 ペルソナの書き方は世の中にたくさんありますが、それをプロダクトづくりの文脈でいつどう使うのかというお話が無いように思い、私が思うペルソナ活用についてまとめます。 プロダクトの解像度を上げる「いつどのようにペルソナを使うのか」の話をする前に、プロダクトを解像度を上げて捉えたいです。私は下図のように、プロダクトをCore/Why/Whatと抽象度別に3つの階層に分割しています。 Coreはそのプロダクトで目指すべき世界観、Whyはなぜそのプロダクトをつくるのか(どんなユーザーをどう幸せにしたいか)、そしてWhatがその手段となるUIやUXです。 詳細は別noteがあるのでご興味持っていただいた方はこちらへ。 プロダクトのCoreを支えるペルソナCore、即

翔泳社さんが実施しているITエンジニア本大賞 2023の大賞候補に選ばれた6冊を拝読しました。どれも良い本で特別賞をとても迷ったので、すべての本についておすすめさせてください。ちなみに、私の特別賞は『エンジニアリングマネ－ジャ－のしごと』にさせていただきました。

Qiita Conference 2023で登壇の機会をいただきましたので、登壇内容を一部noteにもしておきます。登壇資料は最後に貼ってあります。 前提プロダクトマネジメントはUX、Tech、Businessの交差領域であり、各々の専門性が重なるというのが基本概念のはずです。（左）しかし、プロダクトマネージャーという職種が増えてきた結果、分業したままなんとかプロダクトマネージャーがその糊となって繋げている組織をみることがあります。（右） プロダクトマネージャーではなく、プロダクトマネジメントは各領域の専門家が集まるチームでやっていきましょう。プロダクトマネージャーはその旗を降る人であって一人でプロダクトマネジメントをするわけではありません。 エンジニアがプロダクトづくりを推進するためには、Tech x UXやTech x Businessの領域に積極的に手をだして重なりをつくっていきまし

ロードマップやプロダクト指標（NSM）を設計するとどの単位でこれらを検討すればよいのか？という悩みを持つことがあります。今日は私の考えるプロダクトの分割についてです。 ※ 「プロダクト」の分割について記載しており、「チーム」の分割については触れません 機能でプロダクトを分割しないプロダクトが大きくなるにつれて検討事項が増えるので人を増やしてプロダクトを分割することを検討します。このときのアンチパターンは「機能」でプロダクトを分割してしまうことです。 機能でプロダクトを分割した末路: 蛇足のダソくんこの絵は極端な例となりますが、とても優秀な「ヒレ」機能の担当者がいると、「ヒレ」機能だけが華美になり結果としてプロダクトの全体価値を損ないます。 価値でプロダクトを分割するプロダクトを価値で分解するプロダクトは提案する「価値」で分割しましょう。ただ、分割するときに、それが大きな価値なのか、その大き

私はPRD(Product Requirement Document)が嫌いでした。概念としてのPRDは好きですが、ドキュメントとしてのPRDが苦手、という話を聞いてください。 😭 PRDの嫌いだったところ① プロダクトマネージャーの仕事はPRDを書くことです、という誤解 実際に会社によってはそれをプロダクトマネージャーの主な責務にしているところもあるでしょう。しかし、私はプロダクトマネージャーの仕事は「何のPRDを書くのか？」を決めることであり、PRDを書く作業はプロダクトチーム全体で実施するものだと思っています。プロダクトマネージャーが書いたPRDの通りにプロダクトチームが動く組織は好みません。 ② これ1枚でほんまに全部書くんか？ PRDは「検討すべき項目がすべて検討されているか？」を問うフォーマットとして秀逸です。しかし、例えばPRDに「競合分析」や「市場分析」を記載することもあ

機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針