サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
2025年ランキング
note.com/ozyozyo
プロダクトマネジメントのご支援も数多くさせていただき、そのやり方の言語化も進みましたので動画にして公開しました。20分x6本+総集編です。 Youtuberの方と違って一本撮りで、動画の質としては低くお見苦しいところが多くあるかと思いますが無料コンテンツとして多めに見ていただけますと幸いです。 想いプロダクトの作り方に正解はないとおもいます。 ただ、他の方の作り方と自分の作り方を比較することで、自分の作り方の特性に気付いたり改善点に気付いたりするはずです。 この動画は、私の作り方を公開することでみなさんと議論をしたくてつくりました。議論の場として「プロダクト筋トレ」というコミュニティも作っています。6500人以上の方にご参加いただけてありがたい限りです。
今日改めて言語化できた「なぜの答え方」について。 🙆 3行でまとめる・どんなアイデアも素晴らしい。素晴らしい理由を説明するのは簡単 ・なぜ？を聞かれたときに、複数のアイデアの中からそのアイデアをなぜ選ぶのか？という視座で答えるとコミュニケーションが捗る ・高い視座の「なぜ」は戦略である 🥺 よくあるミスコミュニケーション上司「提案ありがとうございます。そのアイデアをやるべき理由は？」 部下「はい、競合には〇〇という機能があり、それが無いことが弊社のプロダクトが選ばれない理由になっているからです。」 上司「でも、いまは△△という別の機能開発を優先しています。その提案をやるべき理由は？」 部下「🥺🥺🥺」 この例のように、「なぜ」と言っても、 ・1つのアイデアをやるべき理由を説明できること ・全体を見る視座からそのアイデアをやるべきか理由を説明できること には差があります。「なぜ？」と
今日改めて言語化できた「失敗を独占しない」について。 🙆 3行でまとめる抱え込んでプロダクトマネージャーが糊になってはいけない 自分だけが失敗(=成長)機会を独占するのではなく、まわりの人にも失敗の機会を譲る ちょっとした失敗が起きても事業的に問題はないようにできる ⛰️ プロダクトマネージャーの石ころ拾いプロダクトを成功に向けてリードするのがプロダクトマネージャーの役割です。最大の価値を提案するために目指すゴールに旗を立て、最速で価値を届けるために誰かが躓きそうな石ころを拾って組織を縦に横に駆け回るのはとても大切なことです。 ⛳️ 旗を立てる VS 石ころ拾い一方で、毎日忙しいです。社内で日々発見される新たな問題の芽を積んでいるだけで1日が終わってしまい、本来時間を使うべき中長期的なことやユーザーを理解に手が回らないというのはあるあるです。 🥺 私たちは石ころに躓いて、学んできた最速
世の中にプロダクトや事業をうまくつくるためのフレームワークは多々あります。フレームワークを埋めて終わりにせず、もう一歩深めて肉厚にしたい。 ☠️ ペラペラなロードマップの例よくない例として、ペラペラなロードマップを書いてみました。 こういったロードマップは多くの新規プロジェクト説明用資料の最後に登場し、その後誰にも更新されることなく忘れ去られていきます。 ペラペラなロードマップなぜ良くないのか？🙅 時期以外の情報量がペラペラ 4Qの終わりにリリースをしFY26から営業開始することは読み取れますが、どんな戦略なのか、何が進捗すればロードマップ通りなのか？このロードマップの通りに進んだとしてそれが成功に向かったと言えるのか？という観点が抜けています。 🙅 仮説検証する想定になっていない ウォーターフォールであり、仮説検証する余地がありません。どの仮説にどの順番で向かうのか？という観点が抜け
※ 評価の話ではありません、事業の目標設定の話です 売上目標を組織におくと起きること売上を達成するために、組織の全員が一生懸命努力をします。 ・それぞれ別の方法で売上を上げようとして、結果的に発散してしまう ・売上をあげるための筋道が示されていないので、小さな施策しか打てない ・「売上をあげるには？」はイシューとして大きく、議論が発散して時間が溶ける ・ユーザー要望の大きいものの優先度があがり、中長期的な売上獲得ができない 中期的な売上獲得ができないプロダクトの例どうやって売上をあげるか？が、戦略どうやって売上をあげるのか？例えば、 ・今期は新規XXセグメントの開拓をする（XXセグメントでのシェア） ・一旦は売上を追わずに無料ユーザーを大量獲得する（無料ユーザー数） ・他にはない独自の強みを強化する（コアユーザー数等） … などなど、売上の上げ方を考えると、自ずと別の指標が見えてきます。
3行でまとめる権限をくれ〜と叫ぶより「私はこのフローで意思決定をしようとおもってます」というと、デキるやつっぽくて任せてもらえるよ 創業者から権限をもらえない問題いろいろな企業のプロダクトマネジメントを拝見させていただいて、モノづくりには2つのパターンがあることに気づきました。 1. ロジック後付けセンス型「こういうプロダクトが良いのではないか」というWhatの思いつきをそのまま形にする勢いのある作り方です。最初からぼんやりとターゲットに対する仮説はありますが売れてからのほうが、どうして売れたのかのロジックを強く意識します。 2. ロジックありき戦略型「この課題を解決したい」というWhyがあったうえで、その課題を解決するための最善の手段を探索する作り方です。最初からロジックありきで作り、売れた後にはそのロジックをより強化します。 創業者が 1. ロジック後付けセンス型 で、 任せたい相手に
Qiita Conference 2023で登壇の機会をいただきましたので、登壇内容を一部noteにもしておきます。登壇資料は最後に貼ってあります。 前提プロダクトマネジメントはUX、Tech、Businessの交差領域であり、各々の専門性が重なるというのが基本概念のはずです。（左）しかし、プロダクトマネージャーという職種が増えてきた結果、分業したままなんとかプロダクトマネージャーがその糊となって繋げている組織をみることがあります。（右） プロダクトマネージャーではなく、プロダクトマネジメントは各領域の専門家が集まるチームでやっていきましょう。プロダクトマネージャーはその旗を降る人であって一人でプロダクトマネジメントをするわけではありません。 エンジニアがプロダクトづくりを推進するためには、Tech x UXやTech x Businessの領域に積極的に手をだして重なりをつくっていきまし
👀 これは何？これは、今まで私が色々なところで書いてきたプロダクトマネジメント関連の記事のうち、プロダクトの抽象的な概念（CoreとWhy）に関するものをまとめたものです。 プロダクトに携わる方が、考えづらい抽象的な概念に対しても意見をより強く持てるようになることを願って書きました。 目の前の業務で手一杯になっているプロダクトマネージャーや、プロダクトの成長方針にモヤモヤし始めたエンジニアやデザイナー、職種を問わずプロダクトづくりに関わる方に読んでほしいと思っています。 ※ 長文になりすぎたので音声版もつくりました。同じ内容を話しているので音声のほうが聞きやすい方はご利用ください 📕 このnoteの使い方▶ 週2時間x8回で、既存プロダクトの根幹を再検討するプロダクトのCoreやWhyは重要度は高いにも関わらず緊急度が低いのでどうしてもまとまった検討時間を取れなくなりがちです。このno
「プロダクトビジョンを定めたい！」しかし、一人で考えても浸透しないし、人を巻き込んで抽象度の高い議論をするのも難しいし…という方に向けて、最近気づいたコツを言語化してみます。 ✅ 重要な議論ほど人数を絞る。MAX5人。「ビジョンは重要なので各部署から代表者を集めて…」などとしているとあっという間に大所帯になります。大所帯で議論はできないので、コアメンバーとレビューメンバーに分けて、議論はコアメンバーで進行しましょう。 リモートで実施する場合、議論の難易度が上がるのでコアメンバーはビデオを必ずONにして安定した回線を用意してもらいましょう。難しいメンバーはレビューメンバーになってもらいます。 ✅ 民主主義的な決定をしない！を共有する多数決での意思決定は最悪です。その会議の参加者の人数比率によって決まります。エンジニアとビジネスサイドの参加者のどっちが多いかで決めるのは意味がありませんし、意思
翔泳社さんが実施しているITエンジニア本大賞 2023の大賞候補に選ばれた6冊を拝読しました。どれも良い本で特別賞をとても迷ったので、すべての本についておすすめさせてください。ちなみに、私の特別賞は『エンジニアリングマネ－ジャ－のしごと』にさせていただきました。
『プロダクトマネジメントのすべて』共著者。 ▶ 相談: https://forms.gle/Wg1xwCD5gpsehfgq6 ▶ 運営しているプロダクトづくりコミュニティ: https://www.productkintore.org/
ロードマップやプロダクト指標（NSM）を設計するとどの単位でこれらを検討すればよいのか？という悩みを持つことがあります。今日は私の考えるプロダクトの分割についてです。 ※ 「プロダクト」の分割について記載しており、「チーム」の分割については触れません 機能でプロダクトを分割しないプロダクトが大きくなるにつれて検討事項が増えるので人を増やしてプロダクトを分割することを検討します。このときのアンチパターンは「機能」でプロダクトを分割してしまうことです。 機能でプロダクトを分割した末路: 蛇足のダソくんこの絵は極端な例となりますが、とても優秀な「ヒレ」機能の担当者がいると、「ヒレ」機能だけが華美になり結果としてプロダクトの全体価値を損ないます。 価値でプロダクトを分割するプロダクトを価値で分解するプロダクトは提案する「価値」で分割しましょう。ただ、分割するときに、それが大きな価値なのか、その大き
フレームワークの説明記事は多くあるのに、それを使ってどう思考しているのかを語る記事が少ないと思い、前回リーンキャンバスの記事を書いたところたくさんスキを頂いたので、調子に乗って続編を書きます。 今日は私が好きなバリュープロポジションキャンバス編です。以下、バリュープロポジションキャンバスをVPCと略します。 30秒で分かるVPC（VPCを知ってる人はスキップ👇）私はVPCはプロダクト開発の三種の神器だと思っているのですが、知名度が少し低めでもあるので、そもそもVPCとは？について解説します。VPCはその名前の通り、価値（バリュー）を提案（プロポジション）するキャンバスです。 上図がバリュープロポジションキャンバス(VPC)です。図にあるように向かって右側と左側に分かれていて、右側の丸はユーザーについて書く箱であり、「顧客の仕事」「ゲイン」「ペイン」に分かれています。 右側: カスタマープ
📢 今期はMAUを伸ばしましょう Aさん「ログインボーナスを配ろう！」 Bさん「キャンペーンでお安くして広告を打とう！」 Cさん「若者にとってもっと魅力的なプロダクトにしよう！」 Dさん「通知をたくさん送ってリテンションを上げよう！」 ユーザー「一回使って満足しました。もう使いません👋」 --- 完 --- 💣 問題: 軸のないプロダクトになり兼ねない 指標は、そのプロダクトが成功している状態を計測するためのツールです。MAUを指標においたことで、その成功が「月に1回以上つかうユーザーがたくさんいること」になってしまいます。どんな使い方で、どんな頻度で、どれくらいの時間、どの機能を、どんな人が、どんなシーンで使うかが含まれていないので、チームのメンバー各々が考える「良さ」を追求してちぐはぐになってしまう危険があります。 💪改善策: 「もう一歩具体的にする」プロダクトをつくる上で収益
私はPRD(Product Requirement Document)が嫌いでした。概念としてのPRDは好きですが、ドキュメントとしてのPRDが苦手、という話を聞いてください。 😭 PRDの嫌いだったところ① プロダクトマネージャーの仕事はPRDを書くことです、という誤解 実際に会社によってはそれをプロダクトマネージャーの主な責務にしているところもあるでしょう。しかし、私はプロダクトマネージャーの仕事は「何のPRDを書くのか？」を決めることであり、PRDを書く作業はプロダクトチーム全体で実施するものだと思っています。プロダクトマネージャーが書いたPRDの通りにプロダクトチームが動く組織は好みません。 ② これ1枚でほんまに全部書くんか？ PRDは「検討すべき項目がすべて検討されているか？」を問うフォーマットとして秀逸です。しかし、例えばPRDに「競合分析」や「市場分析」を記載することもあ
プロダクトチームの目指す姿プロダクトを作るチームには、Biz、User、Techの3つの柱が必要です。この3つを使って広義と狭義のプロダクトの両方を作ります。狭義のプロダクトとはソフトウェアやハードウェアなどの「モノ（アウトプット）」を指します。そして、広義のプロダクトとはそのモノを使って実現した状態（アウトカム）です。 Biz、User、Techの3つの柱には「課題発見」と「課題解決」の2つの方向性が違う力が含まれます。また、ビジョンの実現のためにプロダクトを一気通貫させ、この3つの柱をコントロールする力があると、チームとして働くことができます。 まとめると、プロダクトチームは以下の7つの方向で力を発揮出来ている状態を目指すといいでしょう。 7つの力が偏っていると起きること 大きな絵は書けるけれど、それを実現する力が弱かったり↑ プロダクトとしては綺麗でも、その課題を持っている人がいなか
プロダクトマネージャーとUXデザイナーの仕事は線引をすることが難しく、正解はないと思っています。プロダクトマネージャーがワイヤーを引くところまで担当する現場もあれば、アウトカムからアウトプットまで一貫してUXデザイナーが担当する現場もあり、様々なグラデーションが存在しています。そのグラデーションの具体⇔抽象のサンプルを作成しましたので、協業時のたたき台にご利用いただけますと幸いです。 例とするグラデーション フードデリバリープロダクトを例にして、「売上を上げる」という最終的な目標を達成するために「スタンプカード」という機能を実装する間のユーザー体験のグラデーションを取り上げます。 ① プロダクト指標を決める 売上を上げるための戦略が必要です。高級料理に特化するならプロダクト指標として単価を持つこともあるでしょう。今回の施策がプロダクト指標のどこに貢献するものであるのかを定めることが1つ目の
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
プロダクトマネージャーが責任を持つのはアウトプットではなく、アウトカムです。機能（アウトプット）を作って終わりではありません。「インタビューでユーザーが言っていたから」という理由だけでプロダクトに機能を付け加えるのもいけません。ユーザーの言いなりになるのではなく、ユーザーの期待を超えていく姿勢を持ちましょう！ このnoteの結論このnoteは、アウトカムとアウトプットの紐付けが難しいのであれば、OKRとNSMを活用してアウトカムを定義して、間にIssue Listを挟んでアウトプットの検討をするのがいかがでしょうか？という提案をするnoteです。 ■ このnoteで解決できるかもしれない課題 ・プロダクトが解決すべきIssueが多すぎて優先順位付がむずかしい ・PBL(=プロダクトバックログ)の優先順位に納得感がない、または、PBLに入っているアイテムに納得感がない ・抽象的なプロダクトの
ご興味をお持ちの方はこちらからご参加ください。 こんな方に来ていただきたいです ・プロダクトに携わるもしくは、携わりたい方 ・業務以外で、自己研鑽をされたい方 ・他者を尊敬し、自分と相手の成長のために行動できる方 背景エンジニアコミュニティは多くあるのに、WhatやWhyを考える方が気軽にやり取りできる場が少ないと感じていました。また、その課題感は私だけのものではなく、「プロダクトづくりについて相談できる場が欲しい」という声を何名かから頂いたため、Slackという形で始めたいと考えています。 筋トレ企画日々の議論に加え、勉強会なども開催しています。 ・輪読会 ・積読消化会 ・プロダクト関連の記事を共有する会 また、以下のようにプロダクトの立ち上げを練習する試みも実施しました。
フレームワークをただ埋めただけで終わらずに意味のある成果物にする肉厚シリーズ第4段はプロダクト指標について書きます。 🙅 ペラペラなプロダクト指標まずは、肉厚ではないペラペラなプロダクト指標を紹介します。これまでの肉厚シリーズ同様にフードデリバリープロダクトの例です。 KGIを売上とおいて、売上を達成するためのKPIツリーを構築し、その各要素を各部署のKPIと定めています。そして、そのKPIツリーの各項目をそれぞれの部署が担当していて、各部署全員が成果を出すと売上があがる仕組みになっています。 👿 なぜペラペラなのか1. ユーザー価値の向上を目指していないから このよくあるKPIツリーがなぜペラペラなのでしょうか。一言でいうと、「ユーザー価値の向上を目指していないから」です。プロダクトの成功の3本柱であるビジョン、ユーザー価値、事業収益であるにも関わらず、このKPIツリーの根にあるのは
1年間プロダクトマネジメントの体系化を頑張ろうとおもい、2020年はいろいろな記事を書きました。我ながら、今年いい感じにできたと思っている図解を振り返ります。普段は一回書いた話を何度も書かないポリシーなのですが、年末なので許してください🙏 1. 仮説のミルフィーユ プロダクトの仮説を4階層に分けて、高い所にある仮説に変更があるときには低い階層もきちんと見直しましょう、の図です。仮説以外でもプロダクトを捉えるときに、この4階層に分けておくと何かと便利です。 2. プロダクトのCore、WhyとWhatの関係仮説のミルフィーユの関係を別の図解に表したものもあります。プロダクトのCoreを元に発想できるWhyは無数にあって、Whyを元に発想できるWhatも無数にあります。例えば、「お腹が減った」というユーザーのペインを解決するためのソリューションはたくさんありますよね。その中でなぜおにぎりでは
肉厚シリーズ第3弾です🎉 「仮説のミルフィーユ」とはプロダクトを4つの階層に分解することを推奨しており、これを「仮説のミルフィーユ」と呼んでいます。この4つの階層はすべてプロダクトを作るときの仮説を表していて、上の階層にある仮説を検証して間違っていることが分かったときには、その下の階層の仮説はすべて考え直さなければいけない、という関係です。 プロダクトを考えるときには、上の階層での仮説が構築されているかを確認してください。例えば、プロダクトのHowであるUIデザインを考えるためには、プロダクトのWhyにあるターゲットユーザーやユーザーに提案したい価値の設計が終わっていなければいけません。（意外と、プロダクトのHowをCoreからWhatをおざなりにして進行してしまうことってありますよね） 肉厚の前提: プロダクトのCore〜Howが整合しているCoreからWhatまでの関係 もうすこしプ
仕事で年中記事を書いている人としては、アドベントカレンダーくらいゆるい話をしたいので「自称一流PMが一ヶ月本気でプロダクト作ってみた」をやって久々になんか作りたいって思ってます。誰か一緒に一ヶ月やりませんか？デザイン好きな人とかでプロダクトの立ち上げ筋トレしたい人とかいないかな。 https://t.co/i4bGCqPLo7 — 小城 久美子 / koshiro kumiko (@ozyozyo) November 7, 2020 参加にあたって、5つのルール 1. 一緒に筋トレをしましょう 各々伸ばしたいPM筋を持ち寄って、全員がプロダクトを良くする立場として議論をすること。 2. 仕事ではできないチャレンジをしましょう 筋トレが目的なので失敗などはなく、経験がないから仕事にできないタスクなどにも積極的にチャレンジする。 3. リリースすることをゴールとはしない 私は自己資金でこのプロ
たのしかった🎉 スタンフォードのPM講座？正規の学生じゃなくても受講可能な外部の人向けの講座がいくつか開講されていて、毎期プロダクトマネジメント関連の講座も用意されているようです。私が受講したのはIntelのプロダクトマネージャーさんが先生の講座です。お金払えば誰でも受講可能です。 ▼ 私が受講したのはこちら ▼ BUS 156 — How to Think Like a Successful Product Manager https://continuingstudies.stanford.edu/student/home 色々な単科をつまみ食いしている私、迷いに迷って秋期はスタンフォードのプロダクトマネジメントのクラスを取ってみることにした。グロービスより安い。英語わかんないけど心折れないようにがんばろう💪 — 小城 久美子 / koshiro kumiko (@ozyozyo)
リーンキャンバスが大好きなので、リーンキャンバスを書く時に私が気をつけているポイントを書いてみようと思います。 いつリーンキャンバスを書くのかについては5年前の私が書いていました😊 ペラペラなリーンキャンバスの例例として、最近どんどん市場を拡大している宅配系の注文アプリのリーンキャンバスを書いてみました。このリーンキャンバスは肉厚とは対局にあるペラペラです。 どこをどう改善すれば肉厚になるのか書いていこうと思います。 何のためにリーンキャンバスを書くのかフレームワークの使い方は自由です。みなさんの理由でリーンキャンバスを書かれると良いと思います。そして、私はリーンキャンバスを「プロダクトを俯瞰してパラメータ調節をするため」に書きます。 例えば、パラメータとしてプロダクトのWhyである顧客セグメントを少し絞ってみた場合、課題にはどのような変化があるか？その結果、プロダクトのWhatであるソ
ソフトウェアのプロダクトを対象としたNorth Star Metric（NSM）と呼ばれる指標の作り方を書きます。 🙅♀ CACがいくらが適切かといった具体的な話はありません 🙆♀ プロダクト指標(NSM)を考えるためのフローの話があります どうしてKGIがダメなのか(ダメではないです) プロダクトの成功とは、「ビジョン」「顧客価値」「事業価値」の3つのバランスが取れた状態です。KGIは一般的には売上など、事業価値に基づいて決定されます。例えば、KGIから派生するKPIツリー側でビジョンや顧客価値について手当がされていれば問題にはならないかもしれませんが、KGIだけをプロダクトとして追っていてはプロダクトの成功とは別の方向を目指すことになってしまいます。そのため、プロダクトの成功に直結した指標を作ることが必要なのです。 プロダクトと事業また、小さくリリースをして改善を繰り返し、品質
知見が溜まってきたので、プロダクトマネージャーに有用かもしれない講座たちを書いておきます。 1. [Udemy] プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management まず学ぶなら曽根原さんのUdemyからとりかかるのが全体的に学びを得られるのでとても良いと思います。全部で3講座も出されていて、受講者数の合計が2000人ほどいらっしゃる大人気講座です。日本語ですし、自分のペースで勉強することができます。 KPI編: https://www.udemy.com/course/practical_kpi/ PRD編: https://www.udemy.com/course/practical_prd/ 2. Product School 私は未受講なのですが、体系的にプロダクトマネジメントを学ぶにはこちらもとても良さそうです。オ
「ペルソナは一人に絞るべきか？」「作ったものの活用しきれていない」「私のプロダクトのペルソナは53万人います」といったお話をよく聞きます。 ペルソナの書き方は世の中にたくさんありますが、それをプロダクトづくりの文脈でいつどう使うのかというお話が無いように思い、私が思うペルソナ活用についてまとめます。 プロダクトの解像度を上げる「いつどのようにペルソナを使うのか」の話をする前に、プロダクトを解像度を上げて捉えたいです。私は下図のように、プロダクトをCore/Why/Whatと抽象度別に3つの階層に分割しています。 Coreはそのプロダクトで目指すべき世界観、Whyはなぜそのプロダクトをつくるのか(どんなユーザーをどう幸せにしたいか)、そしてWhatがその手段となるUIやUXです。 詳細は別noteがあるのでご興味持っていただいた方はこちらへ。 プロダクトのCoreを支えるペルソナCore、即
次のページ
このページを最初にブックマークしてみませんか？
『小城久美子 / ozyozyo｜note』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
