キレッキレなPMは他と何が違うのか？ シリコンバレーのPMが重視する「Step Change」という視点
キレッキレなPMは他と何が違うのか？ シリコンバレーのPMが重視する「Step Change」という視点 シリコンバレーのプロダクトマネージャー達に見る、 覚悟を決めたPMは何が違うのか？ #1/4 酸いも甘いも経験してきたシリコンバレーのプロダクトマネージャー 曽根原春樹氏：みなさんお集まりいただきまして誠にありがとうございます。初めましての方も、またお会いできましたねの方も、ご無沙汰しています。曽根原です。今年も「PMカンファレンス」に戻ってきました。 今回はテーマが「覚悟」ということで、どんな話をしようかなと思っていたのですが、みなさんにとって刺激的な話になるといいなと思って、それでこのタイトルに決めたわけですね。「シリコンバレーのプロダクトマネージャー達に見る、覚悟を決めたPMは何が違うのか？」ですね。 本題に入る前に、僕のことをぜんぜん知らないという方もいらっしゃるかもしれないの
pmconf 2023 プロダクトと事業を無限にスケールするための最強のロードマップの作り方 / The Greatest Roadmap for Unlimited Scaling your Business and Products
プロダクトマネージャーカンファレンス 2023 Track A 15:35~ LIVE 50min プロダクトと事業を無限にスケールするための最強のロードマップの作り方 https://2023.pmconf.jp/session/zBfEEEcp 近年、多くのプロダクトマネジメントに関する書籍が執筆され、日本でもプロダクトマネジメントが定着しつつある。特に課題発見からMVPローンチ、PMFまでのプロセスは、アジャイル開発関連の書籍の拡充あって、充実してきていると言える。一方で、一度PMFを迎えたプロダクトを更に進化させるためのロードマップの作り方については、未だ確立した方法論があるとは言えず、世界中で議論が続いている。本セッションでは、従来のロードマップの課題と近年議論されている対策を振り返り、その上で、プロダクトと事業を無限にスケールするための新しい考え方を導入し、状況に合わせて変更可
プロダクトマネージャー必読！吉羽龍太郎が教える4つのCOREスキル | ITエンジニア向けのトレンド情報
プロダクトマネージャーとして成功するための道を模索するあなたに贈る成長ガイド。理想と現実が交錯する厳しいフィールドで、どのようにスキルと視点を磨き、チームやプロダクトをリードするのか。その秘訣を詳細に解説します。 この記事は、2023年9月5日発売 『プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド』共同訳者の吉羽 龍太郎氏 による connpass勉強会 を再編集し、記事化したものです。 すべてにおいて「銀の弾丸」は存在しない 「 ◯◯の成功事例やベストプラクティスを教えて欲しい」と頻繁に質問されます。最先端の調査研究や他社の輝かしい成功事例を聞きつけると、手当たり次第に導入したくなることを「シャイニー・オブジェクト症候群」と呼びますが、人間の心理として十分に理解できる一方、まずはすべてにおいて「銀の弾丸」が存在しないことを冷静に受け入れましょう。 ベストプラクティス
プロダクトマネージャーになって気づいた4つのルール エンジニア時代の私に伝えたい、プロダクトマネジメントをする上で考えたいこと
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで小城氏が登壇。続いて、小城氏がエンジニアからプロダクトマネージャーになって「このスイッチが必要だった」と感じたものを4つ紹介します。 なぜ「ゲームのルールを理解する」ことをしなければいけないのか 小城久美子氏：ではさっそく「ゲームのルールを理解する」から始めていきましょう。 （スライドを示して）先ほどもちょっと言いましたが、なぜゲームのルールを理解しなければいけないかというと、自分の発言のハードルを下げるために、今どうなっているか、何が大事にされているかを理解しなきゃいけないと私は思っているんですね。 例えばSlackひとつを例にとっても、スタートアップの会社はけっこう
「良いものを作れば広まる」は嘘ではないが真実でもない まつもとゆきひろ氏が語る、“30年”の経験の中で感じたこと
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここでプログラミング言語Rubyの生みの親であるまつもとゆきひろ氏が登壇。まずは、「成功するソフトウェア」における「成功」について話します。 Rubyは30年間生き延びたソフトウェアプロダクト まつもとゆきひろ氏（以下、まつもと）：それでは発表をさせてください。「成功するソフトウェアの作り方」と題しまして、Rubyのまつもとが発表します。先ほど「Heroku」の発表がありましたが、私は元Herokuなので、すごく懐かしく聞いていました（笑）。 （スライドを示して）こんなアイコンでふだん活動しています。 英語圏ではMatzという名前を使っています。Rubyを作った人として知られ
ChatGPTでstep by stepもロールプレイもやめたらプロダクト開発で使える精度になったよ｜MRYY
プロダクトマネジメントのコーチをしています。プロダクト開発の中でもGPT4を使うケースが増え、相談されることが増えてきました。 ChatGPTのGPT4を用いた際の、専門家として信用できる精度で推論させるための工夫の一部を紹介します。精度が必要な専門職かつ中級者向けになると思います。「機密情報の入力をどうさけるか」といった運用の話は今回はしません。 やったことと起きたこと一通り論文を読んで試したり、試行錯誤しました。 その結果、専門家として業務レベルで使える程度のものができるようになってきました。 クライアントのプロンプトを添削する仕事も増えつつあります。副作用として、日本語なのに日本語と感じられない自然言語に目覚めてきました。この片鱗についてお話しします。 分かったこと分かったこととして、精度を業務レベルで用いるためにまずはじめにとりくむことは下記です。 ・接待モードを切る ・指示の質が
マイスキルマップでエンジニアとしての己を見つめ直す - yigarashiのブログ
最近テックリードのロールを手放し、働き方がEMに近づいた。折に触れてEMになりたいと言ってきたが、だからと言って最初からうまくできるわけもなく、ここ1ヶ月くらいは悶々としながら過ごしている。特に今回困ったのは、自分の現在地がぼんやりしていて漠然と据わりが悪い感触に苛まれている点だ。もう少し課題や方向性を精緻にして、自信を持って前進できる環境をつくりたい。その一環としてマイスキルマップを作ってみたので紹介する。 マイスキルマップへ至る思考 自分が大事にしている心構えのひとつに「練習していないことはできない」というのがある。十を知るには十を聞き、繰り返し実践することでしか一人前にはなれないという、ごくごく当たり前のことだ。この心構えでひとつひとつ丁寧にやっていくのが、ここ5、6年の自分の強みだと思っている。 しかしこの心構えを維持するのは簡単ではない。何かができるようになると、自分の能力のイメ
デスクレスSaaSの未来、カミナシの賭け｜諸岡 裕人(カミナシCEO | SaaS)
昨日、カミナシはシリーズBで30億円（エクイティ25億円・デット5億円）の調達を発表しました。事業をピボットしてから約3年、この期間で40億円を超える資金調達をすることが出来ました。 この調達に至るまでの、シリーズA後を振り返ると、長期的なプロダクト戦略について考え続けた時間だった気がします。今回、この先、カミナシはどこへ向かうのかについて書きます。 前半はAll-in-One Productの話。後半はHRTechの話を。一番伝えたいことは最後に書いています。興味ある部分だけでも読んでもらえると幸いです。 オフィスワーカーの進化の歴史自分たちはどこへ向かうのか？ その答えを探すために、何から考えようかと思っていたところ、とても良い先行事例があることに気づいた オフィスワーカーの働き方の変遷だ。 人の働き方の本質的な進化というのは、現場もオフィスも一緒であり、同じような道を辿るのではないか
PLG型SaaSのマーケティング事例 BtoBの「定石」が通用しないケースへの適応 | LISKUL
2023年現在、スタートアップ・SaaS領域周辺では、ZoomやSlackを急成長させたといわれる「PLG※」への注目が集まっています。 しかし、現時点で、国内のPLG型SaaSのマーケティングに関する取り組み事例は、あまり公開されていません。 本記事では、国内PLG型SaaSとして例に挙げられることも多い、中小企業向け業務管理システム「board」での約5年間にわたるマーケティング支援の取り組みの一部と得られた学びを紹介します。 結論としては、これまで筆者が取り組んできたBtoBマーケティングにおける定石が通用せず、全く異なる施策が有効となりました。 「board」というプロダクト固有の文脈に依存する部分も多いため、どこまで参考になるものか疑問も残りますが、少しでも役立つ部分があれば幸いです。 ※PLGとは：Product-Led Growth（プロダクト・レッド・グロース）、「プロダク
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ
こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ
プロダクトの非機能的な改善の工数をどう確保するか - yigarashiのブログ
プロダクトの非機能的な改善をビジネスの中でどのように進めるかは、多くのチームが頭を悩ませる課題であると思います。本記事では私が最近考えていることをまとめてみようと思います。主に自社プロダクトの継続開発を想定した議論をします。 前提 まず非機能改善について議論する上で、重要な前提がふたつあると思っています。 ひとつは、我々は常に共通の目標を持っているということです。プロダクトのミッションや期の目標のことです。ビジネスサイドの人もエンジニアも、そうした目標を達成するためにそこにいることに違いはありません。機能開発も非機能的な改善も、見ている時間軸が多少違うことはあれど、この目標を達成するための手段です。それらが一見対立するように見えるのは影響を与える指標が違うからです。 もうひとつは、非機能改善に「やらない」という選択肢はないということです。システムにはデフォルトで滅びる方向に力が加わっていま
プロダクトマネージャーに「事業開発やってほしい」は期待過多 PM採用におけるミスマッチ解消を狙う、佐々木真氏の挑戦
プロダクトマネージャーに求められる本質、事業成長に貢献するための具体的な心得についてディスカッションをするイベントが、株式会社フライルの主催で開催されました。今回のゲストは、SaaSやアプリ、Web3など幅広い領域で、長年プロダクトマネジメントに携わり、プロダクト開発コミュニティ「PM Club」の運営をしている佐々木真氏。プロダクトマネージャーに必要なスキルや考え方を語りました。全5回。2回目は、佐々木氏がPMスキルの言語化に挑戦している理由について。前回はこちら。 「課題を特定する」ためにPMがやるべきこととは？ 財部優一氏（以下、財部）：「課題を特定する」というのは、具体的にプロダクトマネージャーはどんなことをするべきなんでしょうか？ 佐々木真氏（以下、佐々木）：例えば、「プロダクトを作る」と一口に言っても考えることがけっこういっぱいあるんですよね。まずは、ユーザーを決めなければいけ
プロダクト開発チームの分断に立ち向かう - yigarashiのブログ
先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。 実際問題、真に興味を持つのは大変 現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。 ここにエンジニアが越境して興味を
“世界を変えるプロダクト”はカリスマCEOでなくても作れる 「働く人のやる気を出すプロダクトビジョン」5つのポイント
『ラディカル・プロダクト・シンキング』のエッセンスを紐ときつつ、米国におけるプロダクトマネジメントのトレンドや、プロダクトマネジメントを成功に導くための考え方を探る「プロダクトマネジメントで本当に大切なこと」。ここで著者のラディカ・ダット氏と監訳者の曽根原春樹氏が登壇。続いて、正しくプロダクトビジョンを作るためのポイントを紹介します。前回はこちらから。 正しくプロダクトビジョンを作るための5つのポイント 曽根原春樹氏（以下、曽根原）：じゃあこのプロダクトビジョンですが、正しくプロダクトビジョンを作るためにはどんなポイントがあるかを本書では説明しています。 インパクトあるプロダクトビジョンを作るために必要な要素はなにかというと、全部で5個あります。 まずはwhoです。どのユーザーの世界を変えたいのかということです。先ほど総花的なプロダクトという話から戦略肥大の話をしましたが、ラディカさんが説
人の出入りがある前提でチームをどう設計するか？ 信頼残高が足りない組織が、持続可能性を高めた「仕組み」
「プロダクトマネージャーカンファレンス 2021」は、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨することを目的に開催されるイベントです。ここでユニファ株式会社の山口氏が登壇。続いて、信頼残高の構築と人の出入りがある前提のチームの設計について話します。前回はこちらから。 信頼残高が足りない問題の分析 山口隆広氏：人はなんとかなりました。次は組織と信頼残高を積むというところで、まだまだ終わりません。 でもどうしようと。信頼残高が足りないという問題があって、とはいえ課題も把握しなければいけないと思ったので、少しショートカットしようと思いました。 もともと組織にいて、信頼残高がものすごく高くて、ファシリテーション能力も高いメンバーがいたので、その人にいろいろ聞いて、1on1してきてほしいという話をしました。もちろんそのメンバーが密告者みたいな扱いをされると申し訳ないので、ある程度匿名
Amazon RDS Proxy が BASE にもたらした期待以上の導入メリット - BASEプロダクトチームブログ
はじめに 基盤チームでバックエンドエンジニアをやっている松田（ @tadamatu ）です。 以前にCTO川口が当ブログ内で公開した以下の記事があります。 devblog.thebase.in 新規接続の限界 BASE のアクセス量の伸びは凄まじくこの構成でも接続エラーが発生するようになってしまいました。 ピーク時に秒間 2 万もの新規接続が primary インスタンスへ行われているといった状態です。 この記事が公開されたのが約２年前で、当時100万程度 だったショップ数は170万を超え、我々はまだまだ伸ばしたいと考えています。 これは、ショップ数の伸びとともに、指数関数的に増えていくユーザのアクセスを捌く必要があることを意味します。 ブログ公開当時、我々はさまざまな検討の末、以下のような対策を取りました。 残された手段は primary のインスタンスに対しての接続数を如何にして減らす
Agile and Requirement : アジャイルな要件定義について考える
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
Firebase Analyticsで始めるプロダクトの効果検証の取り組み - ANDPAD Tech Blog
ANDPADチャットチームでエンジニアをしている椎野(@taikishiino)です。 前回、5000万件越えのRDS大量データをFirestoreに移行する勘所 という記事を書かせていただきました。 tech.andpad.co.jp その後、グロースのための施策にも徐々に注力できるようになってきました。 今回は効果的にグロースさせていくための効果検証の仕組み作りの取り組みについて紹介していきます。 効果検証 どんな方法で Firebase Analytics ログイベントについて どのようにイベント設計したか パラメータルール どのように可視化したか 画面内の機能導線タップ総数の割合 対象画面の各機能導線のタップ数/UU 対象機能導線のタップ数/UU この先の話 効果的な仮説検証へ 施策リリース前段階でのニーズ検証 さいごに 効果検証 主な効果検証の目的は以下の2つです。 リリースした
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Shin Sasaki on Twitter: "Figmaの歴史はプロダクト開発者にとって学びの宝庫だった📝 1. 初期コンセプト「ブラウザ上のフォトショップ」は不発 2. 当時の常識は「1人かつオフライン」 3. 機能を絞りUIデザインに特化し成功 4. 他ツールからシェア… https://t.co/F9dyeR8Gbv"
