mizzsugar’s blog

日々感じていることや学んだことを書きます。エンジニアリング以外にも書くかもしれません。

pyconf2022の感想

プロダクトマネージャーのカンファレンス「pmconf2022」をオンライン視聴したので感想をざっくりと。 2022.pmconf.jp

全体的な感想

プロダクトマネージャーの仕事の一部を担い始めたので初参加してみましたが、どのセッションも学びが大きかったです。各現場で問題となっていたこととそれに対する取り組みや、プロダクトマネージャーのキャリアの歩み方の体験談などが紹介されていました。 どの話も「その苦しみ・辛さめっちゃわかって、アアア…!(苦痛な叫び)」とも「取り組みがすばらしすぎて、アアア…!(感嘆)」となりました。

プログラミング言語と違ってプロダクトマネージャーは横の繋がりを得にくく、プログラミング言語と比較すると最近注目され始めた分野でノウハウが溜まっていないので オンサイト交流会参加したかったなあと 発表内容を聞いてから思いました。

気になった登壇

『組織として』顧客を理解するインタビュー習慣の作り方

  • 毎日インタビューが行われており、しかもそれに職務関係なくエンジニアやデザイナーでも参加できるという取り組み。
  • 2人組でインタビューし、インタビューを数行のインタビュースナップショットに協力してまとめる運用。インタビューをまとめるのが楽になり、心理的ハードルがさがった。
  • インタビューで得た知見が属人化せず、チームや組織の共通理解に。
  • インタビューのハードルが下がったことでインタビューが習慣化され、インサイトがプロダクトに反映されるまでのリードタイムが圧縮された。 speakerdeck.com

今日から始める「実例マッピング

  • 「実例マッピング」とは、機能に対するユーザーの使い方の具体例を意識的に集め、備えるべき要件を導くワークショップ。
  • 作ってみてから不具合があることや要件不足に気づく問題を解決。
  • 要件定義の段階で要望に現れないユーザーの使い方が拾えないこと、要件レビューの段階で実際に作るべきものとのズレが見つけられないことが原因。
  • 要件の文書を書いてレビューしてもらう運用だと、「要望とズレた内容が書かれていないか」に気を取られて「これで要望を満たせるのか」の確認は難しい。
  • Alp社だと、プロダクトマネージャー、開発メンバー、CSなどのビジネス職メンバーでワークショップを行い、30分ほどで終わるとのこと。
  • 要件を作るために実例や疑問を上げることが求められる。要件の文書レビューのように書いた内容に収まった議論で終わり漏れが出来てしまうのを防げる。 speakerdeck.com

アウトカム最大化のためのプロダクト開発と組織

  • チームが意思決定権を持ちアウトカムに責任をもつことによって、アウトカムの最大化を図った。
  • POとデザイナーが仕様を作り各開発チーム(機能チーム・基盤チームと技術領域で分けていた)がそれにそった開発をする運用だと、社内受託的な開発になってしまい、チームがアウトカムに責任を持ちにくい状態になってしまった。
  • 仕様策定・リリース・検証の責任を一貫して担えるクロスファンクショナルなチームに移行。チームはPdM・デザイナー・フルスタックエンジニアで構成。
  • POは作りたい体験の優先順位を決め、チームに割り振る。この時、仕様の詳細度は低い状態で渡す。
  • チームでCPF・PSF・SPFを達成するための最小アウトプットを考え、不確実性を下げて仮説を明確にする。その後プロダクトを作り、立てた仮説に対しての検証を行い、チームで振り返る。
  • 仮説を立てる段階から巻き込むことで、チーム全員が当事者意識を持つようになりアウトカムが最大化する。 speakerdeck.com