小城久美子 / ozyozyo

エンジニア出身のプロダクトマネージャー。いいプロダクトをつくるための話を書きます。 ▶…

小城久美子 / ozyozyo

エンジニア出身のプロダクトマネージャー。いいプロダクトをつくるための話を書きます。 ▶ 相談: https://forms.gle/Wg1xwCD5gpsehfgq6 ▶ 運営しているプロダクトづくりコミュニティ: https://www.productkintore.org/

マガジン

  • プロダクト筋トレ

    • 35本

    #プロダクト筋トレ コミュニティに関連するnoteマガジン

最近の記事

  • 固定された記事

プロダクトをつくるひとのSlackをつくりました #プロダクト筋トレ

「プロダクトづくりに関する知識を広げ、深め、身につける」ことを目的にしたSlackをつくりました。 ご興味をお持ちの方はこちらからご参加ください。 こんな方に来ていただきたいです ・プロダクトに携わるもしくは、携わりたい方 ・業務以外で、自己研鑽をされたい方 ・他者を尊敬し、自分と相手の成長のために行動できる方 背景エンジニアコミュニティは多くあるのに、WhatやWhyを考える方が気軽にやり取りできる場が少ないと感じていました。また、その課題感は私だけのものではなく、「

    • 目標が売上だと、考えづらくないですか?

      ※ 評価の話ではありません、事業の目標設定の話です 売上目標を組織におくと起きること売上を達成するために、組織の全員が一生懸命努力をします。 ・それぞれ別の方法で売上を上げようとして、結果的に発散してしまう ・売上をあげるための筋道が示されていないので、小さな施策しか打てない ・「売上をあげるには?」はイシューとして大きく、議論が発散して時間が溶ける ・ユーザー要望の大きいものの優先度があがり、中長期的な売上獲得ができない どうやって売上をあげるか?が、戦略どうやって売上

      • 権限がほしいなら、意思決定のフロー図を書き出す

        3行でまとめる権限をくれ〜と叫ぶより「私はこのフローで意思決定をしようとおもってます」というと、デキるやつっぽくて任せてもらえるよ 創業者から権限をもらえない問題いろいろな企業のプロダクトマネジメントを拝見させていただいて、モノづくりには2つのパターンがあることに気づきました。 1. ロジック後付けセンス型 「こういうプロダクトが良いのではないか」というWhatの思いつきをそのまま形にする勢いのある作り方です。最初からぼんやりとターゲットに対する仮説はありますが売れてか

        • エンジニアが推進するプロダクトマネジメント | Qiita Conference 2023

          Qiita Conference 2023で登壇の機会をいただきましたので、登壇内容を一部noteにもしておきます。登壇資料は最後に貼ってあります。 前提プロダクトマネジメントはUX、Tech、Businessの交差領域であり、各々の専門性が重なるというのが基本概念のはずです。(左)しかし、プロダクトマネージャーという職種が増えてきた結果、分業したままなんとかプロダクトマネージャーがその糊となって繋げている組織をみることがあります。(右) プロダクトマネージャーではなく、

        • 固定された記事

        プロダクトをつくるひとのSlackをつくりました #プロダクト筋トレ

        マガジン

        • プロダクト筋トレ
          35本

        記事

          16時間でプロダクトに自信が持てるドリル💪 ※1.5万字

          👀 これは何?これは、今まで私が色々なところで書いてきたプロダクトマネジメント関連の記事のうち、プロダクトの抽象的な概念(CoreとWhy)に関するものをまとめたものです。 プロダクトに携わる方が、考えづらい抽象的な概念に対しても意見をより強く持てるようになることを願って書きました。 目の前の業務で手一杯になっているプロダクトマネージャーや、プロダクトの成長方針にモヤモヤし始めたエンジニアやデザイナー、職種を問わずプロダクトづくりに関わる方に読んでほしいと思っています。 ※

          16時間でプロダクトに自信が持てるドリル💪 ※1.5万字

          プロダクト系議論をチームでするときのコツ

          「プロダクトビジョンを定めたい!」しかし、一人で考えても浸透しないし、人を巻き込んで抽象度の高い議論をするのも難しいし…という方に向けて、最近気づいたコツを言語化してみます。 ✅ 重要な議論ほど人数を絞る。MAX5人。「ビジョンは重要なので各部署から代表者を集めて…」などとしているとあっという間に大所帯になります。大所帯で議論はできないので、コアメンバーとレビューメンバーに分けて、議論はコアメンバーで進行しましょう。 リモートで実施する場合、議論の難易度が上がるのでコアメ

          プロダクト系議論をチームでするときのコツ

          ITエンジニア本大賞2023 大賞候補全部読みました

          翔泳社さんが実施しているITエンジニア本大賞 2023の大賞候補に選ばれた6冊を拝読しました。どれも良い本で特別賞をとても迷ったので、すべての本についておすすめさせてください。ちなみに、私の特別賞は『エンジニアリングマネ-ジャ-のしごと』にさせていただきました。 💻 技術書部門📕『競技プログラミングの鉄則』 よみやすい!わかりやすい!カラーで余白大きい!勝手な想像で幅優先探索とかをO(N)とか数式いっぱいでマニアックに語る本かと身構えていましたが、違います。 1つめのサン

          ITエンジニア本大賞2023 大賞候補全部読みました

          プロダクトを分割してマネジメントする

          ロードマップやプロダクト指標(NSM)を設計するとどの単位でこれらを検討すればよいのか?という悩みを持つことがあります。今日は私の考えるプロダクトの分割についてです。 ※ 「プロダクト」の分割について記載しており、「チーム」の分割については触れません 機能でプロダクトを分割しないプロダクトが大きくなるにつれて検討事項が増えるので人を増やしてプロダクトを分割することを検討します。このときのアンチパターンは「機能」でプロダクトを分割してしまうことです。 この絵は極端な例となり

          プロダクトを分割してマネジメントする

          1年で2293人規模のコミュニティになった話

          「プロダクト筋トレ」という「プロダクトづくりに関する知識を広げ、深め、身につける」ことを目的にしたコミュニティを立ち上げて、1年で2293人になりました。コミュニティ運営のこれまでを私目線でまとめます。 💪🏻 「アジェンダ」のあるコミュニティづくりIT界隈には多くのコミュニティがあります。たくさん助けていただきました。しかし、私はどうしても「懇親会」が苦手でした。横のつながりは欲しいし、他の会社でどんなことをしているのかを学びたいけれど、ノーアジェンダフリースタイルラップバ

          1年で2293人規模のコミュニティになった話

          プロダクト指標がMAUだけなのはおすすめしません🙅

          📢 今期はMAUを伸ばしましょう Aさん「ログインボーナスを配ろう!」 Bさん「キャンペーンでお安くして広告を打とう!」 Cさん「若者にとってもっと魅力的なプロダクトにしよう!」 Dさん「通知をたくさん送ってリテンションを上げよう!」 ユーザー「一回使って満足しました。もう使いません👋」 --- 完 --- 💣 問題: 軸のないプロダクトになり兼ねない 指標は、そのプロダクトが成功している状態を計測するためのツールです。MAUを指標においたことで、その成功が「月に1回

          プロダクト指標がMAUだけなのはおすすめしません🙅

          プロダクトマネージャーが書いたPRDの通りに機能をつくる?

          私はPRD(Product Requirement Document)が嫌いでした。概念としてのPRDは好きですが、ドキュメントとしてのPRDが苦手、という話を聞いてください。 😭 PRDの嫌いだったところ① プロダクトマネージャーの仕事はPRDを書くことです、という誤解 実際に会社によってはそれをプロダクトマネージャーの主な責務にしているところもあるでしょう。しかし、私はプロダクトマネージャーの仕事は「何のPRDを書くのか?」を決めることであり、PRDを書く作業はプロダク

          プロダクトマネージャーが書いたPRDの通りに機能をつくる?

          プロダクトチームと、その成長

          プロダクトチームの目指す姿プロダクトを作るチームには、Biz、User、Techの3つの柱が必要です。この3つを使って広義と狭義のプロダクトの両方を作ります。狭義のプロダクトとはソフトウェアやハードウェアなどの「モノ(アウトプット)」を指します。そして、広義のプロダクトとはそのモノを使って実現した状態(アウトカム)です。 Biz、User、Techの3つの柱には「課題発見」と「課題解決」の2つの方向性が違う力が含まれます。また、ビジョンの実現のためにプロダクトを一気通貫させ

          プロダクトチームと、その成長

          PMとUXデザイナーのグラデーション

          プロダクトマネージャーとUXデザイナーの仕事は線引をすることが難しく、正解はないと思っています。プロダクトマネージャーがワイヤーを引くところまで担当する現場もあれば、アウトカムからアウトプットまで一貫してUXデザイナーが担当する現場もあり、様々なグラデーションが存在しています。そのグラデーションの具体⇔抽象のサンプルを作成しましたので、協業時のたたき台にご利用いただけますと幸いです。 例とするグラデーション フードデリバリープロダクトを例にして、「売上を上げる」という最終

          PMとUXデザイナーのグラデーション

          Tably最終出社なので成果物をまとめました💪

          今月末でTablyでは正社員から業務委託に切り替えることになりました。 契約形態が変わっても関係する皆様は影響が無いような仕事をしてまいりますので、どうぞ、引き続きよろしくお願いいたします。 プロダクトマネジメントをよくするために、やったことTablyでは「プロダクトマネジメントがよくなるために私にできることを全部やる!」勢いでお仕事をしてきました。我ながら正解のない中で頑張ったと思うので関わった成果物を5つ載せさせてください。 🎉 1. プロダクトマネジメントクライテリ

          Tably最終出社なので成果物をまとめました💪

          ロードマップに機能を書くべからず

          機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に

          ロードマップに機能を書くべからず

          アウトカムにつなげるIssue管理 - OKRとKPI(NSM)とPBL

          プロダクトマネージャーが責任を持つのはアウトプットではなく、アウトカムです。機能(アウトプット)を作って終わりではありません。「インタビューでユーザーが言っていたから」という理由だけでプロダクトに機能を付け加えるのもいけません。ユーザーの言いなりになるのではなく、ユーザーの期待を超えていく姿勢を持ちましょう! このnoteの結論このnoteは、アウトカムとアウトプットの紐付けが難しいのであれば、OKRとNSMを活用してアウトカムを定義して、間にIssue Listを挟んでア

          アウトカムにつなげるIssue管理 - OKRとKPI(NSM)とPBL