#プロダクト筋トレ コミュニティに関連するnoteマガジン
「プロダクトづくりに関する知識を広げ、深め、身につける」ことを目的にしたSlackをつくりました。 ご興味をお持ちの方はこちらからご参加ください。 こんな方に来ていただきたいです ・プロダクトに携わるもしくは、携わりたい方 ・業務以外で、自己研鑽をされたい方 ・他者を尊敬し、自分と相手の成長のために行動できる方 背景エンジニアコミュニティは多くあるのに、WhatやWhyを考える方が気軽にやり取りできる場が少ないと感じていました。また、その課題感は私だけのものではなく、「
世の中にプロダクトや事業をうまくつくるためのフレームワークは多々あります。フレームワークを埋めて終わりにせず、もう一歩深めて肉厚にしたい。 ☠️ ペラペラなロードマップの例よくない例として、ペラペラなロードマップを書いてみました。 こういったロードマップは多くの新規プロジェクト説明用資料の最後に登場し、その後誰にも更新されることなく忘れ去られていきます。 なぜ良くないのか？🙅 時期以外の情報量がペラペラ 4Qの終わりにリリースをしFY26から営業開始することは読み取れます
※ 評価の話ではありません、事業の目標設定の話です 売上目標を組織におくと起きること売上を達成するために、組織の全員が一生懸命努力をします。 ・それぞれ別の方法で売上を上げようとして、結果的に発散してしまう ・売上をあげるための筋道が示されていないので、小さな施策しか打てない ・「売上をあげるには？」はイシューとして大きく、議論が発散して時間が溶ける ・ユーザー要望の大きいものの優先度があがり、中長期的な売上獲得ができない どうやって売上をあげるか？が、戦略どうやって売上
3行でまとめる権限をくれ〜と叫ぶより「私はこのフローで意思決定をしようとおもってます」というと、デキるやつっぽくて任せてもらえるよ 創業者から権限をもらえない問題いろいろな企業のプロダクトマネジメントを拝見させていただいて、モノづくりには2つのパターンがあることに気づきました。 1. ロジック後付けセンス型 「こういうプロダクトが良いのではないか」というWhatの思いつきをそのまま形にする勢いのある作り方です。最初からぼんやりとターゲットに対する仮説はありますが売れてか
Qiita Conference 2023で登壇の機会をいただきましたので、登壇内容を一部noteにもしておきます。登壇資料は最後に貼ってあります。 前提プロダクトマネジメントはUX、Tech、Businessの交差領域であり、各々の専門性が重なるというのが基本概念のはずです。（左）しかし、プロダクトマネージャーという職種が増えてきた結果、分業したままなんとかプロダクトマネージャーがその糊となって繋げている組織をみることがあります。（右） プロダクトマネージャーではなく、
👀 これは何？これは、今まで私が色々なところで書いてきたプロダクトマネジメント関連の記事のうち、プロダクトの抽象的な概念（CoreとWhy）に関するものをまとめたものです。 プロダクトに携わる方が、考えづらい抽象的な概念に対しても意見をより強く持てるようになることを願って書きました。 目の前の業務で手一杯になっているプロダクトマネージャーや、プロダクトの成長方針にモヤモヤし始めたエンジニアやデザイナー、職種を問わずプロダクトづくりに関わる方に読んでほしいと思っています。 ※
「プロダクトビジョンを定めたい！」しかし、一人で考えても浸透しないし、人を巻き込んで抽象度の高い議論をするのも難しいし…という方に向けて、最近気づいたコツを言語化してみます。 ✅ 重要な議論ほど人数を絞る。MAX5人。「ビジョンは重要なので各部署から代表者を集めて…」などとしているとあっという間に大所帯になります。大所帯で議論はできないので、コアメンバーとレビューメンバーに分けて、議論はコアメンバーで進行しましょう。 リモートで実施する場合、議論の難易度が上がるのでコアメ
翔泳社さんが実施しているITエンジニア本大賞 2023の大賞候補に選ばれた6冊を拝読しました。どれも良い本で特別賞をとても迷ったので、すべての本についておすすめさせてください。ちなみに、私の特別賞は『エンジニアリングマネ－ジャ－のしごと』にさせていただきました。 💻 技術書部門📕『競技プログラミングの鉄則』 よみやすい！わかりやすい！カラーで余白大きい！勝手な想像で幅優先探索とかをO(N)とか数式いっぱいでマニアックに語る本かと身構えていましたが、違います。 1つめのサン
ロードマップやプロダクト指標（NSM）を設計するとどの単位でこれらを検討すればよいのか？という悩みを持つことがあります。今日は私の考えるプロダクトの分割についてです。 ※ 「プロダクト」の分割について記載しており、「チーム」の分割については触れません 機能でプロダクトを分割しないプロダクトが大きくなるにつれて検討事項が増えるので人を増やしてプロダクトを分割することを検討します。このときのアンチパターンは「機能」でプロダクトを分割してしまうことです。 この絵は極端な例となり
「プロダクト筋トレ」という「プロダクトづくりに関する知識を広げ、深め、身につける」ことを目的にしたコミュニティを立ち上げて、1年で2293人になりました。コミュニティ運営のこれまでを私目線でまとめます。 💪🏻 「アジェンダ」のあるコミュニティづくりIT界隈には多くのコミュニティがあります。たくさん助けていただきました。しかし、私はどうしても「懇親会」が苦手でした。横のつながりは欲しいし、他の会社でどんなことをしているのかを学びたいけれど、ノーアジェンダフリースタイルラップバ
📢 今期はMAUを伸ばしましょう Aさん「ログインボーナスを配ろう！」 Bさん「キャンペーンでお安くして広告を打とう！」 Cさん「若者にとってもっと魅力的なプロダクトにしよう！」 Dさん「通知をたくさん送ってリテンションを上げよう！」 ユーザー「一回使って満足しました。もう使いません👋」 --- 完 --- 💣 問題: 軸のないプロダクトになり兼ねない 指標は、そのプロダクトが成功している状態を計測するためのツールです。MAUを指標においたことで、その成功が「月に1回
私はPRD(Product Requirement Document)が嫌いでした。概念としてのPRDは好きですが、ドキュメントとしてのPRDが苦手、という話を聞いてください。 😭 PRDの嫌いだったところ① プロダクトマネージャーの仕事はPRDを書くことです、という誤解 実際に会社によってはそれをプロダクトマネージャーの主な責務にしているところもあるでしょう。しかし、私はプロダクトマネージャーの仕事は「何のPRDを書くのか？」を決めることであり、PRDを書く作業はプロダク
プロダクトチームの目指す姿プロダクトを作るチームには、Biz、User、Techの3つの柱が必要です。この3つを使って広義と狭義のプロダクトの両方を作ります。狭義のプロダクトとはソフトウェアやハードウェアなどの「モノ（アウトプット）」を指します。そして、広義のプロダクトとはそのモノを使って実現した状態（アウトカム）です。 Biz、User、Techの3つの柱には「課題発見」と「課題解決」の2つの方向性が違う力が含まれます。また、ビジョンの実現のためにプロダクトを一気通貫させ
プロダクトマネージャーとUXデザイナーの仕事は線引をすることが難しく、正解はないと思っています。プロダクトマネージャーがワイヤーを引くところまで担当する現場もあれば、アウトカムからアウトプットまで一貫してUXデザイナーが担当する現場もあり、様々なグラデーションが存在しています。そのグラデーションの具体⇔抽象のサンプルを作成しましたので、協業時のたたき台にご利用いただけますと幸いです。 例とするグラデーション フードデリバリープロダクトを例にして、「売上を上げる」という最終
今月末でTablyでは正社員から業務委託に切り替えることになりました。 契約形態が変わっても関係する皆様は影響が無いような仕事をしてまいりますので、どうぞ、引き続きよろしくお願いいたします。 プロダクトマネジメントをよくするために、やったことTablyでは「プロダクトマネジメントがよくなるために私にできることを全部やる！」勢いでお仕事をしてきました。我ながら正解のない中で頑張ったと思うので関わった成果物を5つ載せさせてください。 🎉 1. プロダクトマネジメントクライテリ
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に
