ミネムラ珈琲ブログ

AI画像Tシャツ屋/ITラノベ著者/さすらいのコーヒー屋/WEBサービス開発チームマネージャーの日記

Product Management Night Tokyo hosted by freee聴講した #pmnt_freee

さっきまで聴いていた。ちゃんとまとめる体力が今日は尽きているのでメモをほぼそのまま。

product-management-night-tokyo.connpass.com

SaaSの新規事業立ち上げに置いて重要なこと

  • 顧客にあって話す、セールスやる、CSやる、でマーケットと顧客の解像度を誰よりも高く持ってアップデートし続ける
  • 初期は細かい数字は水、定性的なフィードバック、数社とか10社とかなので
  • 立ち上げ期は売上目標やKPIは持たないように頑張る。持たないといけないときは期待値コントロール

SaaSにおけるプライシング

  • Pricingはむちゃくちゃ重要、1%変えると事業がめちゃくちゃ変わる。しかし議論が進んでいない。オーナーが不明瞭、PM/エンジニア/デザイナー/マーケ/Sales
  • 競合プロダクト/周辺プロダクト/自社プロダクト/ユーザーが感じる価値がアンカー
  • ヒアリングと実際の商談は異なる、ヒアリングのほうが高め
  • 国外の競合調査重要
  • パターンを分類して様々なタイプで30社程度

ちがいました、すいません。

B2Bにおけるプロダクト開発投資の考え方

  • 最も貴重な投資は開発投資、エンジニア/デザイナーのROIを最大化せよ
  • 一定規模以上の開発投資は仕様をまとめて開発投資の5年ROIをCFOまでレビューする。

割と恐ろしい感じがあるけど、それを経営まで含めて紳士にやる文化なんだろうなと感じた。

  • 人手による目先の利益創出ではなく、出口を考えちゃんとプロダクト化する。

逆にプロダクト化しすぎるってことはありそう

  • toCの保守的な利用者、リニューアルを嫌ったり、書類が必要だったり、決裁者・バックオフィスむけの要件を軽視しない
  • 大口顧客のカスタマイズ要求、想定通り使われずROI低など

Sansanでは開発優先度をどう決めているか

  • 意思決定の流れや仕組みの運用(リリース量?)。バラバラ/遅い/決められない。巨大プロダクトでチームごとにバックログがバラバラ。
  • バックログとバジェットのプロダクト単位で統一、バジェットを目的別に分ける

負債解消・中長期トピックで分けるの良さそう

  • issueの起案と優先度付、企画する側の人間は優先度を決めない。フェアな目線で決められる
  • クォーターをまたぐものは、クォーターでちぎらせる

”椅子職人の悲劇”を乗り越える、Squad開発の実践と課題

speakerdeck.com

  • 椅子職人の悲劇:過度な分業によるやりがいやモチベーション喪失。伸びてきたプロダクトにおいて、純粋にプロダクトに向かう以外の時間が多いぞ。
  • squad、乱暴に言えば立ち上げのときみたいな組織構造に戻す。特定のミッションにフォーカスして独自の目標を職能横断で作る。

さっきのsansanの事例と真逆だけど、どういうケースでsquadを採用すべきなのかというのはまぁケース・バイ・ケースだし、文化なんだろうな。

  • 組織図が戦略の形をする Pillar/squadモデル

これはよさそう。

  • 評価は職種divでやる

ユーザーから最も嫌われたプロダクトを人気プロダクトにするまでの地獄の2年半

病むな…