さっきまで聴いていた。ちゃんとまとめる体力が今日は尽きているのでメモをほぼそのまま。
product-management-night-tokyo.connpass.com
SaaSの新規事業立ち上げに置いて重要なこと
- 顧客にあって話す、セールスやる、CSやる、でマーケットと顧客の解像度を誰よりも高く持ってアップデートし続ける
- 初期は細かい数字は水、定性的なフィードバック、数社とか10社とかなので
- 立ち上げ期は売上目標やKPIは持たないように頑張る。持たないといけないときは期待値コントロール
立ち上げ期は細かい数字は見ない、売上目標やKGIも極力持たない、腹落ちする感じがある #pmnt_freee
— ミネムラ珈琲@ITラノベ『転生したらスプレッドシートだった件（技術評論社）』著者 (@minemura_coffee) 2020年9月9日
SaaSにおけるプライシング
- Pricingはむちゃくちゃ重要、1%変えると事業がめちゃくちゃ変わる。しかし議論が進んでいない。オーナーが不明瞭、PM/エンジニア/デザイナー/マーケ/Sales
- 競合プロダクト/周辺プロダクト/自社プロダクト/ユーザーが感じる価値がアンカー
- ヒアリングと実際の商談は異なる、ヒアリングのほうが高め
- 国外の競合調査重要
- パターンを分類して様々なタイプで30社程度
FreeeのSaaSにおけるプライシングって、まさにこれの話になるんだろうか？ #pmnt_freeehttps://t.co/fqJAIE9Jxh
— ミネムラ珈琲@ITラノベ『転生したらスプレッドシートだった件（技術評論社）』著者 (@minemura_coffee) 2020年9月9日
ちがいました、すいません。
B2Bにおけるプロダクト開発投資の考え方
- 最も貴重な投資は開発投資、エンジニア/デザイナーのROIを最大化せよ
- 一定規模以上の開発投資は仕様をまとめて開発投資の5年ROIをCFOまでレビューする。
割と恐ろしい感じがあるけど、それを経営まで含めて紳士にやる文化なんだろうなと感じた。
- 人手による目先の利益創出ではなく、出口を考えちゃんとプロダクト化する。
逆にプロダクト化しすぎるってことはありそう
- toCの保守的な利用者、リニューアルを嫌ったり、書類が必要だったり、決裁者・バックオフィスむけの要件を軽視しない
- 大口顧客のカスタマイズ要求、想定通り使われずROI低など
Sansanでは開発優先度をどう決めているか
- 意思決定の流れや仕組みの運用（リリース量？）。バラバラ/遅い/決められない。巨大プロダクトでチームごとにバックログがバラバラ。
- バックログとバジェットのプロダクト単位で統一、バジェットを目的別に分ける
負債解消・中長期トピックで分けるの良さそう
- issueの起案と優先度付、企画する側の人間は優先度を決めない。フェアな目線で決められる
- クォーターをまたぐものは、クォーターでちぎらせる
チームがたくさんある巨大プロダクト関わったことがないのであんまりわからんけどいろいろ大変そうではある #pmnt_freee
— ミネムラ珈琲@ITラノベ『転生したらスプレッドシートだった件（技術評論社）』著者 (@minemura_coffee) 2020年9月9日
”椅子職人の悲劇”を乗り越える、Squad開発の実践と課題
- 椅子職人の悲劇：過度な分業によるやりがいやモチベーション喪失。伸びてきたプロダクトにおいて、純粋にプロダクトに向かう以外の時間が多いぞ。
- squad、乱暴に言えば立ち上げのときみたいな組織構造に戻す。特定のミッションにフォーカスして独自の目標を職能横断で作る。
さっきのsansanの事例と真逆だけど、どういうケースでsquadを採用すべきなのかというのはまぁケース・バイ・ケースだし、文化なんだろうな。
- 組織図が戦略の形をする Pillar/squadモデル
これはよさそう。
- 評価は職種divでやる
ユーザーから最も嫌われたプロダクトを人気プロダクトにするまでの地獄の2年半
- Salesforce for outlook、スマホ前の時代。
- 1日の半分が不満対応
病むな…
