SaaSのプロダクトマネジメント、縦から見るか？横から見るか？
SaaSのプロダクトマネジメントはとても大変です 日々、多種多様な顧客要望を捌きつつ、中長期でのビジネスインパクトを出すための施策や技術的負債に対する難しい舵取りを求められます。 この記事では そもそもSaaSのプロダクトマネジメントで大事にするべき原則的な考え方をまとめることで、少しでもその助けになればと思います。 まずはSaaSには大きく分けると の２種類があります。 この２つにはそれぞれ考え方に違いがあるため、概要を説明しつつ、大事にするべきプロダクトマネジメントの考え方についてまとめていきます。 ※ここからは業務改善、効率化型のtoB SaaSをイメージして書いています 特定の業界に特化したSaaSのことです。 日本ではアンドパッド（建築業界）やコドモン（保育業界）などが有名かと思います。 Verticalの由来は、下記のように業界と業務をマトリクスで表現した時に、プロダクトのカバー範囲が垂直（Vertical）なものになるからではないかと思っています。 Verticalなプロダクトマネジメントで重要なのは です。
そもそもVertical SaaSが必要とされるのは、 などがあり、汎用的なプロダクトを導入しても効果が出づらい、そもそも導入ができないという背景があるからです。 なのでVertial SaaSでは が大切になってきています。 業界の特殊性への理解度がそのままプロダクトの品質に直結することが多いと思います。他業界では？と思われるような機能、表現こそが業界特有の課題を解決でき、価値が出てきます。 ちなみに網羅性についてはあくまで現在の話で、個人的な考えとしては１つのシステムで全てを網羅するのではなく、１つ１つが局所最適されたシステムを組み合わせて使うという方向にゆるやかに向かっていくと思っています。 複数のシステムを組み合わせて活用するための下記のような条件がありますが、徐々に整ってきていると感じています。 エンジニアでいうモノリスからマイクロサービスへという流れに少し似ていますね。
自律したチームがオーナーシップを持って判断することで、それが結果として速度、変化への対応につながるという訳です。 すでに、DX化が進んでいる業界、業種ではこの流れが徐々に始まってきており、基幹業務についてはポストモダンERPという概念も生まれています。 Vertical SaaSが必要とされる業界は基本的にやや遅れていることが多く、この流れがしばらく遅れて来るのではと予想しています。 というVertical SaaSをコアとしつつも、その周りに複数のシステムを組み合わせるような形になっていくのではないかと思っています。 特定の業務に特化したSaaSのことです。 SmartHR、freeeなどが有名どころかと思います。 Horizontalの由来は、プロダクトのカバー範囲が水平(Horizontal)なものになるからではないかと考えています。 業務としてメジャーなのは一定規模の会社には確実に存在するバックオフィス系（人事、会計）だと思います。一言で人事領域といっても、入社手続き、年末調整のようなどの企業でも必須の業務から、いわゆる組織活性化、採用支援など企業によってはmust haveでないものまで様々です。 Horizontalなプロダクトマネジメントで重要なのは です。 性質上、複数の業界の共通業務を切り取るようなプロダクトマネジメントになります。 避けなければならないのはHorizontalといいつつ、特定業界でしか使わないような機能を生み出してしまうことです。 最初これだけは、、、と思っても、一度やってしまうと高確率で二度目も起こるので下記のような構造に近づいています。 本来SaaSのメリットは、個社ごとで開発していたカスタマイズが必要なシステムを、まとめることで低価格で使えるというもののはずなのに、構造的な厳しさを抱えることになります。
一度プロダクトの中で枝葉が生えてしまうと、切り落としたり、まとめるのは中々に困難です。 あとは自分たちのプロダクトが何を解決するのかというスコープの明確化も重要です。
多くの場合、自分たちのプロダクトだけで業務は完結せず、前後に別の業務があり、他のシステムもユーザーは使っています。 ユーザーが困っている、ビジネス上のメリットがありそうだとしても、「このプロダクトで扱うものではないから」という判断が重要です。 ここまでVertical,Horizontalそれぞれの場合を見てみましたが、これらのベースが合った上で実際には下記のようになっていることが多いです。 最初このように見えているが、、、 実際はこう いわゆるユーザー、マーケットに対する解像度が上がるというやつです。 お客様の規模、業界の特異性など分けるための軸は様々ですが、実際には思っているよりはるかに細かいセグメントに分けて考えられます。
そしてそれぞれのセグメントで課題やTAM、ビジネス上のポテンシャルなどが大きく違っています。 その中で という具体と抽象の間を行き来しながら、解決すべき問題、自社のプロダクトのスコープ、ポジショニングを決めていくことが重要です。 つまりは ということで、縦*横でプロダクトのスコープを意識して考えることで
大抵の場合は下記のようにプロダクトのカバーする領域がまだらな状況になります 解像度が上がって突き詰めていくと、結局はVertical,Horizontal両方の思考を組み合わせることが多くなるなと感じています。 最初から解像度が高い状態はなかなか難しいと思いますが、リリースしてユーザーと接する中でファクトが見つかっていきます。中長期でこのような形になっていくと意識しながらプロダクトマネジメントするとチームの目線合わせ、いくつかの構造的な大失敗を防げるかもしれません 場合によってはプロダクトのスコープを変更すること、外から見ているとピボットに見える判断をすることもあります。
ピボットというとマイナスなイメージですが、解像度が上がった結果プロダクトのスコープが変わるのはある種当然で、健全なことだと思っています。 SaaSの縦と横のプロダクトマネジメントについてまとめてみました。結局は解決すべき課題、プロダクトのスコープが何より重要ということです。 CTOとしては、プロダクトのスコープが変わっていく中でしっかり追従していく、時には先を読み、コードベース、機能をデザインしていくことに非常に面白みを感じています。 定番になりますがエンペイは積極採用中です！ SaaS * Fintechという非常にアツい領域で、既存プロダクトを伸ばすことはもちろん、新規プロダクトの開発も水面下で進めています。 少しでも興味持っていただけた方は、ぜひぜひカジュアルにお話しましょう〜
はじめに
SaaSの種類
縦で見るVertical SaaS
横で見るHorizontal SaaS
縦と横の勘所
おわりに
エンジニアたった１人だけだったスタートアップが、CTO of the yearにノミネートされるまでの軌跡
この記事は CTO Advent Calendar 2021の25日目 です。
はじめに
エンペイというtoB Saas * FintechのスタートアップでCTOをしているhikoharuです。
保育園、学童などを中心に「月末にお月謝袋に現金を入れて子供に持たせて、、、」というレガシーな集金業務をキャッシュレスで効率化に行うプロダクトを提供しています。
創業期の１人エンジニア時代から、四苦八苦しながらも１年で10名以上のエンジニアを採用でき、本格的に組織としてワークし始めたので、その軌跡を振り返っていこうかと思います。
CTOになるまでのキャリアは？
- Webエンジニア（４年）
- PjM、EM（２年）
- PdM（２年）
- CTO
みたいなキャリアを歩んできました。
エンジニア時代に自分が作ったものは実は使われていない、必死こいて開発したが実はその時期にやる必然性はそれほどなかったなどを経験し、その辺りの問題を解決したり、興味を持ってやりたいことをやっていたら、CTOになっていたみたいなキャリアです。
PdM期間はほぼコードは書いていませんが、Sales,BizDev,CS,Marketingなど色々なバックグランドの方と仕事する経験はとても今に活きているなと感じています。
光栄なことにCTO of the year2021にノミネートいただいたり、
※登壇資料 CTO of the year2021_PMF後の危機、会社をエンジニアリングする | ドクセル
このようなイベントに登壇する機会をいただけたりもしました。
今年のチームの変化は？
思えば今年の最初は外注から引き継いだコードを、正社員としてエンジニアは私１人、副業、業務委託で7人くらいで何とか開発しつつ、シリーズA以降の勝ち筋の解像度を上げ、それに求められる技術戦略を描いているという状態でした。
一部の狭域マーケットでPMFの手応えがあったというのが救いでしたが、今振り返ってもなかなか綱渡りをしていたな、、、と思います
またシリーズA以前はステルス戦略を取っていたということもあり、カジュアル面談をやれどもやれども、今ひとつ響かないという状況が続き、なかなか辛いものがありました。 シリーズAを迎えて、ファイナンス面での大きな変化があったとはいえ、どう見ても開発ヤバそうな状態で飛び込んでくれた初期のメンバーの皆様には頭が上がりません。
そこから1年で1→11人まで採用を進めることができました。経路はほぼ100%リファラルです。
自分が誰よりもリファラルに本気で向き合うというのはもちろんなのですが、メンバーが積極的に採用を自分事として動いてくれたのが大きかったと思っています。直接的な紹介だけでなく、アトラクト、選考と色々な部分で良い影響が出ています。 もちろん採用がいかに重要かのメッセージング、大切な知人を紹介しても良いと思えるような様々な土台作りはそれなりにやっているのですが、まだまだ整えっていない部分が多く、その中でも主体的に動いてくれたメンバーには本当に感謝しています。
自分がハブとして立ち（全PRをレビューしていました）、全てをコントロールしていた業務委託中心チーム時代から比べると
自分の手から離れて、自分の認知も想像も超えて様々なものが生み出されていくようになっていくのは、本当に痺れるものがあります。
CTOやってみて何か変わった？
今年始めはCEOと私の２人だったのですが、営業、コーポレート、プロダクトなど各領域を管掌する役員が続々と入社してくれました。
そして、「CTOのチームメイトはエンジニアチームではなく、他領域のCxO,VP」という言葉を先輩CTOから聞き、これが変化の大きなきっかけだったなと思います
会社、事業に責任を持つ立場でいつつも、現場でエンジニアしていた時の経験に引っ張られ、チーム状況、目の前のプロジェクトをランディングさせることを重視しすぎていたな、今振り返ると近視眼的な考え方だったなと反省しています
あくまで会社をどうしていくかという高い視座に立って、全体像を広く深く理解した上で、自分とは異なるスペシャリストと議論しながら、自信の専門性である技術を活かしてバリューを出していくことが重要なんだなと、しみじみ感じました。
議論していくために技術的な知識はもちろん、他領域の実態把握、知識も必要なのでかなり難易度は高く、スタンス、考え方において大きなアンラーニングが求められました。
まだまだ出来ていないことも多いですが、スタートアップとしての急成長に振り落とされないように自分自身も成長していくとはこういうことなのかと、少しだけ理解できた気がします。
あとはCTOのコミュニティなど、社外の方との関わりも大きかったと思います。 社内だけに閉じていると、どうしても目の前の問題解決、日々生きることに必死になりがちなのですが
すでに十分成功しているように見えても、そこからさらに時価総額1000億、1兆を目指していきたい、Big Pictureを描いてハングリーにチャレンジしていきたいという話を聞いて、大きな刺激を受け、自分の視座も大きく上がったなと感じています。
来年の抱負、技術的な大きなチャレンジやりたい
技術的な何か大きなチャレンジを始めていきたいと思っています。何をするかはまだ全く決まっていないです。
なるべく小さな失敗と学びを繰り返しながら、大きなビジネス価値を生むポテンシャルのある１点を狙い打ちたいと思っています
振り返ると創業からこれまでは技術的、UX面で難易度が高いけれど１２０点を取れる可能性がある選択肢よりも、 手堅くコスパの良い８０点を取れる選択肢を多くの場面で選択してきました。
これは２０代にオーバーエンジニアリング的な失敗をしたり、持続困難になるのが目に見えているような進め方をして（または前任者から引き継いでw）、色々な失敗を経験したというのもあり、それを繰り返したくないという思いがありました。極力作り込まずに価値を届けるにはどうするかを重視してきました。
結果としてプロダクトとしては会社の規模に対して相当シンプルな状態を保てているという自信があります。
ただこれからは難易度が高くてリスキー、そもそも前例がなくできるかわからないというものも、数年先の未来を見据えて大胆な挑戦を行っていきたいと思っています。比較的簡単な課題をシンプルに解くだけではなく、複雑で難しい課題を腰を据えてテクノロジーで解決していくということにBetしていきたいと思っています。
逆説的ではあるのですが、より困難なチャレンジをしている方が事業、組織面でも逆に強みになってくるんだなと強く感じています。そして何より自分たちも楽しいですよね。
いきなり行うのは難しいと思うのですが、今年、組織作りをしつつ事業戦略と技術戦略をアラインし、会社として安定的なアウトプットを継続的に出せるということに注力した結果、上記を可能にするビジネス、エンジニアリングの土台が出来上がってきたと思っています。
おわりに
定番になりますがエンペイは積極採用中です！ SaaS * Fintechという非常にアツい領域で、上述のような大きなチャレンジができるのはもちろん、 マーケットについても興味深いポイントがあります。
我々はSMB中心のマーケットでいわゆるSales-Led Growth型のゲームをしており、
- Fintechの宿命として、審査、送金など社内の業務プロセスが非常に複雑
- SMB中心のマーケットなので認知〜プロダクト活用までのプロセスを型化する効果が非常に大きい
という特徴があります。
最高のプロダクトをユーザーに届けるために開発し続けるのはもちろんなのですが、プロダクトを届ける、活用してもらうというところもテクノロジーを活用して、リードしていきたいと思っています。オペレーションエクセレンスを実現することは会社として大きな優位性、独自性に繋がると感じています。
プロダクトだけではなく、より広く、抽象度も高い課題をエンジニアリングで解決していきたいという方には非常にエキサイティングな環境だと思います。
少しでも興味持っていただけた方は、ぜひぜひカジュアルにお話しましょう〜
プロダクトが進捗していないと感じた時の戦い方
この記事は Product Manager Advent Calendar 2019の18日目 です。
はじめに
Yamotty氏の素晴らしい記事に触発され、 ストラテジーと実装の一致を保つのが困難な状態、つまり プロダクトに関わる負債のせいで進捗しづらくなった時に どのように戦っていけばいいのかを掘り下げていきます。
早さが生まれる理由は「ストラテジーと実装が一致しているから」だと考えている。 逆に言うと、これらが一致していない場合、早さは生まれない。 正しい戦略が、組織や技術的負債のために実行されなければバツ。 逆に素晴らしいテクノロジーを扱えるチームがあったとしても、間違った戦略で活用してもバツ。
いわゆるプロダクトマネジメントは 「ストラテジーと実装の一致状態を継続させる」という機能なのだと思う。 狙うマーケットが変わったり、ストラテジーが変わればプロダクトが変わる必要がある。 プロダクトの原動力は人なので、人に納得性を植え付けるか、人を替える必要がある。
多くの場合、プロダクトのエンハンス、組織拡大していく中で段々乖離が大きくなっていき、
- プロダクトでの実現が事業戦略のスピード感に合わない
- 実現するために膨大なコミュニケーション、調整が必要
- そもそも一部では実現を諦めてしまうほど高コスト、高難易度なものになってしまっている
のような問題が顕在化していきます。
プロダクト作りにおける負債の種類
まずプロダクト作りにおいて、相対する負債の種類をカテゴリー分けしてみました。
技術的負債
説明不要。
これが貯まっていると開発速度が思うように出なくなったり、予期しないところに影響が出て保守性が低下していく
組織的負債
プロダクトを生み出すチーム、組織の負債。
機能開発したんだけどオーナー不在の状態になっていたり、特定の人がハブになっているなど あとは職種間で期待値があっていなかったり、二項対立が起きていたりいうことも含みます
関係者的負債
関係者（特に社外）の負債
特にtoBとかだと顕著で、特定顧客しか使わないであろう機能要望に対応せざるを得なくなったりとか、SaaSを導入するのに受託みたいな期待値になってしまうこと。
顧客以外にも、アライアンスを組んだパートナー、ベンダーに仕様をロックされていたり、投資家との関係性的に計画を思っていた通りに進められないということも
思想的負債
プロダクトの機能における負債
プロダクトの機能に哲学、思想が欠如している状態。この機能はこうあるべきというものがない。 ユースケースがないとも言えます。
プロダクトが成長して機能が増えていく中で起きがちで、 本来は分かれているべき機能が汎用的な１つになっていたり、逆のパターンもあったり、 これが貯まっていくと技術的負債と同様、スピードが落ち、保守性が低下していきます
負債の誕生
負債の生まれ方として、まずイメージしやすいパターンとしては
- 顧客的負債＆組織的負債
- 思想的負債
- 技術的負債
の順だと思います。
具体的には
1. 顧客的負債＆組織的負債
顧客の声が強く＆営業と開発の間に距離がある場合に起きがち。特定のユーザーだけの課題かつ、解決方法が本質的ではないようなものを必須で対応せねばならず、最悪だと交渉の余地なしみたいなことも、、
2. 思想的負債
長期的なプロダクトの方針を考慮したものではなく、短期的な目の前の問題だけを解決するような解決策になる
3. 技術的負債
プロダクト要件が長期的なストラテジーとずれているので、当然プロダクトを実現するためのコードにもずれが発生する
というもの
大体の場合はこうして最初の負債が生まれていきます。 リリースした瞬間には負債という認識がないこともありますが、エンハンスしていく中でゆっくり確実に乖離が大きくなっていきます。
影響し合う負債の恐ろしさ
そして、真に恐ろしいのが負債の発生は必ずしも上記の順番でなくとも起こるということです。
というのも作り手からすると、
「コードが悪くなるのは、思想が悪いから、思想が歪められるのは外部ステークホルダーの存在など制約条件が強いため、、、」
みたいな要件→実装と、一方通行に考えがちですが、
実際には要件を決める段階で
- 「技術的にこのやり方だと難しいと思ったから、、、」
- 「プロダクト要件を適切に判断できる人がないから、とりあえず早そうなやり方で実現した、、」
みたく、様々な時系列、カテゴリーの負債が相互に影響しあっています。
こうだったらまだやりやすいのに、、、
負債が積み重なった現実
というわけで、それなりに成長したプロダクトの負債は複雑に入り組んでいるため、 最もインパクトのある部分を特定して、効率よく進めるというのが極めて難しいです。
なぜならどの負債も向き合うのには相当の専門性が必要な中、それら全てを俯瞰して判断しなくてはいけないから
上流から下流に流れていくような一方向の依存であれば、最も上流の根本的な問題を特定して解決しにいくところですが、
このように相互に複雑に依存しあっている場合は目の前の問題を探索的に解決していきながら、依存関係を整理していく必要があります （地道に解きほぐして、解像度を上げつつシンプルにしていくイメージ）
ここからは銀の弾丸はないという前提で、進捗させていくためにどういうアプローチをすべきなのかをまとめていきます。
地道に負債を解きほぐしていく
組織の中で各負債と戦っていくポジションを図にするとこんな感じになります（toB SaaS寄り）
引用:Cultural Capital Theory in Software Engineering - Speaker Deck
基本的に自分のロールから離れた問題を扱うのは非常に難しいです。
理由はスキルセットの問題もありますが、コンテキストがわからないのと、日常でその問題に苦しめられるわけではないのでどうしてもオーナーシップが生まれにくいからです。
たまにバリバリ顧客と接する立場なんだけど、エンジニアのリテラシーに通じていて、 視座が高く俯瞰して見れるみたいなスーパーマンもいたりするが、あまり期待してはいけないなと
進め方としてはまず相手の立場、専門性をリスペクトしつつ、対話可能な状態にしていきます。この記事でいうところのリテラシーを身につけるという話がまさにそうです。
この複雑な問題を進捗させるには１方向からのアプローチではダメで、多様な職種が混ざったプロジェクトチームが必要になります。 その上で少しづつ自分たちが抱えている負債と、周辺の負債を俯瞰して見れるようにしていきます。
もし進めていっても、負債は無限に出てくるし、何から手をつければいいか全然わからんという時は 上図のちょうど中間に位置している、比較的どのポジションでも共通のコンテキストで話しやすい思想的負債、組織的負債から着手していくのが有効だと思います。
誰でも語れてしまう故の難しさはもちろんあるんですが、 組織、フローといった問題は変更というアウトプットが誰の目でも認識しやすいという利点があります。（もちろん結果として改悪になることもありますが、、）
こうして確実にアウトプットを出して進捗させていきつつ、そもそも異なる専門性を持ったメンバーが一緒に負債解消をしたという経験そのものが、さらに複雑な問題にアタックする土台になると感じているので、徐々に領域を広げて、他の負債に対しても取り組んでいくのがいいと思っています。
おわりに
0→1で新しいサービス作ったりするのも楽しいと思う一方で
ビジネスも会社も急成長する中、数年後にストラテジー通りに進められず身動きが取れなくならないように問題を予測し、 急成長に対応しつつも同時に未来に手を打つというのも非常に面白いんじゃないかと思う今日この頃です。
プロダクトマネージャーは積み上げる
プロダクトマネジメントピラミッドと勝手に呼んでいるこの図を自分なりに解釈してみたら、 新しい環境でプロダクトマネージャーをやり始める時の道標になったり、内省にも使えると思ったのでまとめていきます。
ちなみに原文の意訳、解釈というわけではなく、この図を見て思った自分なりの勝手な解釈を書いていくので、原文に興味がある方はスライドを直接ご覧ください
定義されているPdMの３つのスキル
この図ではPdMの３つのスキルが定義されています
それぞれ解釈してみると
PRODUCT
プロダクトに関する施策を企画、提案する力。機能開発だけではなく、UX改善、技術的負債の返済などプロダクトに関すること全てがスコープ
ANALYTICAL
プロダクトの現状を分析する力。ログやデータを定量的に分析することも、ユーザーインタビューなどで定性的な分析も含む
注意すべき点としてユーザーに関することは、基本的に皆やっていると思うのですが、それ以外にも会社、事業の方向性や技術的負債の状況などについても含まれるということ
いわゆるPdMトライアングルで定義されている、プロダクトを取り巻くユーザー、ビジネス、テクノロジーの状況について、解像度が高く理解できているという状態なのかなと思っています。
EXECUTION
施策を進捗させる力。直接手を動かすというよりは、いわゆる部門間の調整だったり、交通整理、間に落ちそうなボールを拾うことなど プロジェクトマネジメント的なニュアンスが強いと思います。
これが図上ではピラミッドのように積み上がっています。
PdMとして一貫してできることが大事
重要だと思うのは、これら全てを一貫してできるのがPdMやっていると言えるということ。
ANALYCAL,EXECUTIONのない状態の企画は、ただの思いつき、絵に書いた餅となりプロダクトのOutcomeにつなげることは難しいでしょう。 またいざ進めよう！となっても、チームに納得感を持たせて進めることはなかなか厳しいと思います。
EXECUTIONのない状態の分析はまるで実行に責任を持たず、現場感のないコンサルタントの意見のようになってしまうでしょう
はたまたEXECUTIONだけをやっているのであれば、ただの調整屋さんでPdMとはいえない状態だと思います。
「一貫してやるのとかどうするの？」と思うので、PdMとして新しいプロダクトを扱う時には、基本的には下から順に積み上げるということを意識してやっていくといいと思います。
よくある流れとしては、
- 前任のPMだったり、既存のコンテキストがすでにある施策を引き継いで、無茶振りだな、、、と思いつつも、いろいろな人の助けを借りながら進捗させていく。 ステークホルダーの課題をヒアリングして一緒に解決してあげたり、落ちそうなボールを拾ったりもする 徐々にクレジットが貯まっていく
→EXECUTIONをマスターした！
- 施策を進めながら、キャッチアップしていくと、漠然と次は自分でプロダクトをどういうものにしていこうかイメージが出来てくるので、データ見たり、ユーザーと会ったり、事業の全体像の情報を取りにいって、イメージを研ぎ澄ましていく プロダクトを取り巻くユーザー、ビジネス、テクノロジーの知識が付いてくる
→ANALYCALをマスターした！！
- 満を持して、プロダクトの企画をする。今まで貯めてきた知識、クレジットを使って、プロジェクトとしてドライブさせていき、プロダクトのOutcomeにつなげていく
→PRODUCTをマスターした！！！晴れて組織内でPdMと呼べるように
これの繰り返しだと思っています。
おわりに
昨今のちょっとしたPdMブームもあり、外部からいいPdM雇ったらすぐにイケてる企画が出てきて、プロダクトが進捗していくと思われる方もいるかもしれませんが、PdMとしてプロダクトを進捗させるというのは、積み上げが大事でもっと地道なものです。
またこれらを一貫してできるようになり、「よし企画してみよう！」と始めても ユーザーやデータ見て気づく想定違いなどはもとより、事業全体の戦略との整合性が取れなかったりなどで、リリースまで持っていける施策はごく一部です。
すでに走っている施策の調整などで忙殺されていく中でやらないといけないので、執念がないとPdMはやってられないとホントに思います。
どれくらいの速さで積み上げて、企画まで持っていけるかは、
- 組織や課題の複雑度
- 要求されるスキルセットと自分のギャップ
など大きく依存しますが、早くて１ヶ月、長いと半年くらいじゃないでしょうか。
自分でPdMやっていても、しっかり積み上げられてなかったなー、失敗したなーっと思うことも多いので、内省しながら、いいものを作っていきたいなと思っています。
PMがいなくてもプロダクトが成長していく世界とは
はじめに
プロダクトマネージャーは責任が大きく、やりがいがある一方で「自分がいないとプロダクトの成長が止まる」というプレッシャーに追われがちです。
組織として、PMなしでもプロダクトを継続的に成長させるにはどうすべきかを考えていきます。
多くの組織が抱える課題
多くの組織の課題としてBizサイド、Devサイドのコミュニケーションや期待値、納得感の問題というのがあると思います。
Bizサイド
- エンジニアリング、開発フローなどがわからず、バックログの管理をするのが難しい。大きな工数がかかる
- 期待してくれているほど開発者がオーナーシップ持ってくれない
- エンジニアからの事業、プロダクトに対して前のめりな提案がなくて、何かモヤモヤする
- 開発速度が妥当かどうか、わからない。何か遅いと感じる
Devサイド
- 事業、プロダクトとして何が価値で、どうなったら成功なのかがわからない
- なぜ、いつまでに開発するのかが腹落ちしてなくて、納得感がない
この手の問題は、２０人ほどのスタートアップから、１００人超えの企業まで本当にどこにいっても起きているな、、、と感じています。
こういう時に大体PMをDevの手前にロードバランサー的に置くことで一時的には解決します。
ですが、組織間のコミュニケーションのマイナスを０にする期待に対して、PMというロールを置いただけで、一時的に問題が解決しても、組織全体のケイパビリティとしては何も変わっていないという問題があります。 （そして大体PMが孤独で誰も苦労をわかってくれないため疲れて退職する、、、）
この問題に対して、組織として対応していくためにはどうすればいいか考えていきます。
PMなしでも回る組織にしていくためには
最初はPMに集約しますが、徐々にBiz,Dev含めた１つのチームとして課題発見〜機能リリースまでを継続的に行えるようになることが大事です。
これをしないと、待っているのはPMを挟まないと何も進まない、PMがボトルネックになる世界です。
前提として、そこそこコミュニケーションが取れている組織だと、PMがいなくても、
- プロダクト開発の優先度を決める
- なぜそれをやるのかを説明して納得感を醸成する
ともに５０〜６０点くらいは取ることができると思います （時々、優先度や期待値調整がずれて炎上したり。納得感のないまま開発が進んでコンディション悪化したりする）
PMが入ると基本的にここを１００点に持っていくことができます。
ただ、ずっと１００点を取り続けてもボトルネックになってしまうので、PMは自分なしでも、チームとして９５点くらいは取れるように持っていく取り組みをすべきだと思っています。
この辺りはチームを育てる、ピープルマネジメントのマネージャーとかとも共通する概念の気がしています。
マネジャーも同じで「私がいないと回らない」とか言っているうちは二流、いることでチームや組織の何かを一段上げるとようやく一流
— ohbarye aka 広島の粗大ゴミ (@ohbarye) 2019年4月24日
で、更にその上に、いなくなったあとに一段上がった状態をキープするように仕組みづくりや教育が出来てたら超一流という感じする
具体的に何をする？
シンプルなのですが、即効性があり効果的なのはとにかくステークホルダー間の対話を促すということ
雑に飲み会やイベントとかやったところで、求めている対話は生まれないので ゴールをプロダクトのWhy,Whatについて透明度高く議論できると置きます。
チームには
- マーケ得意な人
- P/L引くの得意な人
- 業務フロー詳しい人
- ユーザーインサイト引き出す人
など、色々な専門性を持った人がいるかと思います。 その中でプロダクトって特にToC向けとかだと、対話する場所としてちょうどいいんですよね。皆興味あるし、理解しやすく、意見も出しやすい。
これを実現するために、最初はPMが間に入って
Devに対しては
- ビジネスKPI
- プロダクトKPI
- ユーザーインタビュー
- ドッグフーディング
- CS、運用のフィードバック
といったビジネス、ユーザーの状況を
Bizに対しては
といったエンジニアリングを伝えていきます。
この時にただ事実を話す。データを見せるのではなく、PM主導でそれぞれの立場に合わせて翻訳した上で、解釈を付けて話すのが重要です。
そして互いに理解する取っ掛かりを作って、対話を促していきます。 （これをやるにはビジネス、ユーザー、エンジニアリングを広く理解している必要があり、結局プロダクトマネジメントトライアングルは大事ということですね）
プロダクトマネジメントトライアングルと各社の PM の職責と JD – Taka Umada – Medium
色々な組織の問題を見たり、聞いたりしていると、ユーザー、事業状況に詳しい人が知らない人を情報格差でマウンティングしやすい構造、それに伴って同じチーム内にも関わらず、発注者と受注者のような関係になってしまっていることが多いと感じます。
この状況から、それぞれが専門分野を持ちつつも、プロダクトのWhat,Whyという場所では、共通言語で会話していくようにしていきます
最終的な決定権はPMが持ちますが、PMの意見、決定に対しても立場問わずオープンに議論していけるようになったらゴールは近いです。
コツとしては１回で伝えようとせず、根気強く対話していくこと。 メインの業務の中で関わらない知識なので、内容よりもとにかく頻度が大事です。
上記以外にも
- Biz,PM,Devの関係の質が高く、期待値が合っている
- 事業上、どこに集中するかが明確になっている
- 開発リソースの配分が事業戦略に最適化されている
- プロダクトの成功が定義され、定性、定量で測定できている
…etc （それぞれが重厚なテーマなので、また個別で書いていきたい）
などの条件を揃えることができれば、PMなしでもプロダクト改善は進んでいくと思います。 プロダクト改善施策に関して、１００点は難しいとしても９５点くらいの決断は移譲してチームでやれるかなと思っています。
上記を私はプロダクトを改善するエンジンと捉えていて、PMはプロダクトだけでなく、このエンジンを作っていくことこそ重要だなと思います。
※注意
上記は事業が安定してきて、それなりに会社としてリソースに余裕ができてきた時の話です。 事業フェーズが進んでいくにつれて、１つ１つのプロダクト改善施策が事業、会社に与えるリスクは小さくなっていきます。
スタートアップなど、フェイズによってはプロダクトのWhatにおいて、１００点取り続けないと死ぬみたいな世界もあるかと思うので、そういうところは別かなと
チームに移譲できたら、PMいらなくない？
そんなことはないです。そもそも事業の注力領域やチーム編成も結構なスピードで変わっていく中で、上記をキープし続けるのが非常に難しい。 部分的、一時的にできるようになってから、完全に根付かせるまでは長い時間がかかるので、継続して取り組む必要があります。
そして何よりPMの役割って、すごく抽象化すると変化の仕掛けを作ることだと思っています。
プロダクトマネージャーはどう評価されるべき？元Google PM対談｜河合敬一×及川卓也 | キャリアハック
ビジネス、テクノロジー、ユーザーを俯瞰して見た時にそれなりの規模の組織、プロダクトって成熟してきているように見えても、どこかに局所的な１０倍の成長余地がまだきっとあるはずで、それを発見するのにPMのリソース使うべきだなと思います。
もう少し体系立てるとPMの施策には大きく
- バケツの穴を塞ぐ
- バケツそのものを大きくする
という２つの種類があると思っています。
（下記に非常によくまとめてくれている）
PMって何してんの？ プロダクト開発の４ステップ｜つるちゃん｜note
この中でチームが自律して行えるようにしていくのは、バケツの穴を塞ぐことまでで、バケツそのものを大きくするのは、何かしらの発想の転換、きっかけが必要だと思っています。
それは
みたいに、不確実性が高いところに腰を据えて一定時間かける必要があるなと
そういったところに常に自分のリソースを一定貼れるように、組織やフローなどを整えてプロダクトを改善するエンジンを作っていくべきなんだと思います。
プロダクトマネージャーはSlack（ゆとり）が大事
はじめに
プロダクトマネージャーをやっていると楽しい一方で、MTGや問い合わせ多くて、忙しすぎるという声をよく聞きます。
そこで本来集中すべきことは何かと、それを阻害する忙しさにどう対処するべきかまとめてみました。
PMの実態
組織内でPMが大変そうと思われる。周りからなりたくない職種と思われるのは危ないサインだと思います。
プロダクトマネージャーというとミニCEOと呼ばれたり、花形とか言われますが、実態としては割と忙殺されていて、職場でも「あの人すごいと思うんだけど、なりたいかと言われると、、、」 みたいに見られているのが多いんじゃないかと思います。
PMが忙しいパターンとそれぞれについて、どうやったらPMのゆとりを作れるかを考察します。
なお、自分がやって成果が出たというものばかりではなく やりたい or 改善中のものも含まれています
よくあるケースと処方箋について
PMが全部把握したいマンになっているケース
バックログのタスクの進捗は全部自分が把握していないと気がすまないし、MTGに全て参加しないと気がすまないタイプ とりあえずプロダクトに関わるから、、という理由でMTG参加依頼が大量に飛んでくる
一日がMTGとslackのメンションをさばくので気づけば終わっている、、、
処方箋
- まず意識としてPMは主役ではなく、支える存在だという自覚を持ちましょう。プロダクトの全責任を取る役割だとしても、全てをPMが知ったり、やる必要はありません。
- 組織内のPMの役割としてやること、やらないことを明確にしましょう
PMがタスク持ちすぎなケース
エンジニアに開発に集中してほしいばかりに、必要以上にエンジニアの仕事を巻き取っているケース
問い合わせだったり、プロジェクトマネジメントだったりがよくあるケース
処方箋
- 開発チームを自己組織化していくように働きかけていきましょう
- 開発チームとPMの期待値合わせをしましょう。本来は開発チームがやるべきタスクをPMがやっていると思っていても、その認識は双方で異なっているかもしれません。
- 危なくなったら、単一障害点になる可能性があると開発チームに話しましょう
PMがコミュニケーションのハブになっているケース
PMはロール上色々な情報が入ってくるし、元々コミュニケーションが得意な人が多い。そこで「あいつに言ったら、背景もわかっているしよしなにやってくれる」的な見られ方で必要以上にハブとして使われているケース
特にデザイナー、Biz、Devの間や、異なる職能の開発チームの間に入ることが多いと思います
処方箋
大体こういう問題が起きるのは職能別組織（サーバーサイド、クライアント、インフラなどで開発チームが分かれている。マーケ組織も別）になっていて、ドメインと組織の見え方が違う時に起きます。
なので事業部組織に移行することで、一定の効果を見込めるのですが、PMのコミュニケーションコストの問題は解決しても、他の部分でトレードオフがあるのと、何より時間がかかり、PMの力だけで何とかできる問題でもないので、ここではもう少し地に足着いた方法を説明します。
直接解決できるというものではないのですが、第一歩としてはPMの仕事、やりたいと思っていることを周りに理解してもらうということです。 いわゆる関係の質の向上ですね
PMってただでさえ何者なのか明確でなく、加えて事業、組織によって役割全然違うので、職種に対する周囲の理解のハードルが非常に高いんですね。
PMという職種に何を期待すればいいかが皆わからないので、結果として他の職種に期待できないことを依頼せざるを得ないみたいな構造になっているという仮説です。
なので
- PMは組織の中でどういう役割で、どうバリューを出していこうと考えているか
- 実際に日頃何を考えて、どういう仕事をしているか
を明確にして、理解を助けるだけでも改善の方向に向かっていくと思っています。（ここ検証中）
実際に今やっていること
- PMに関するドキュメント（ポエム的なもの）を発信していきましょう
- 自分の分報でも、作業用スレッドでもいいので、積極的に取り組んでいること、考えていることをslackなどで実況中継していきましょう。思考プロセスを全て文字に起こして、見てもらうのが大事
おわりに
プロダクトマネージャーはプロダクトの全責任を負う人 という言葉が拡大解釈されて、何でもプロダクトマネージャーに任せればいいやというのは危ないサインです。
プロダクトマネージャーは、おそらくプロダクトに関して一番必要な情報を持っていて正確な判断をできる確率が高いと思います。
そこに判断を寄せるというのはある種正しいとは思うのですが、
これはプロダクトマネージャーが単一障害点になる可能性があるのと、組織として各メンバーにオーナーシップが生まれにくいという構造をトレードオフとして選択しているとも言えます。
スタートアップなどで人数が少ないうちは良いと思うんですが、10→100フェーズで組織が50人とか超えてくると、このトレードオフは厳しいなと、、
とはいえサッカーとかだと成熟したチームでも、特定のキーマンにボールを集中させるということもあるので、組織によって最適解は異なるという話になってしまいますが
ちなみにこの記事が大変わかりやすいです
プロダクトマネージャーは攻守の要（ボランチ）だと思う - Quest PM
ただどんな状況でも言えるのが、プロダクトマネージャーやっていると情報集まってくるし、重要な決断をすることが多いので、ついつい全能感を感じがちで、「俺がいないとプロダクトの進捗が止まる」 みたいなこと思ってしまうことが多いです。
そういう時には自戒をこめて、下記を思い出すようにしています。
エンジニアがいないと何も作れず、営業がいないと何も売れない、デザイナーがいないとプロダクトはわけのわからないものになる。 しかしプロダクトマネージャーがいない世界では、みんながその隙間を埋め、なんとかやっていきます。 プロダクトマネージャーはいなくてもいいのです。 長い目で見ればプロダクトマネジメントが成否を分けますが、プロダクトマネジメントは、 ほかには合うところがなかった変わり者と不合格者の集まりです。 世界で闘うプロダクトマネージャーになるための本 より
あと、もう一つプロダクトマネージャーとして肝に命じておくべきことが
グロースしていく中でプロダクトも組織もどんどん形を変えていきます。それによってこれまで上手くいっていたものが、組織が大きくなって上手くいかなくなるといった問題が大量に起こります。
プロダクトマネージャーというロールは他に比べて解決策の引き出しがとても多いのが特徴だと思います。
だからこそ、同じことをずっとやっていてはダメで、常に余裕を持って新しい問題を探し続けていないと、プロダクト全体の進化が遅くなってしまうと思います。
プロダクトに対してオーナーシップを持って、何でもやるというマインドを持ちつつも、やらないことを増やしていく（チームを強くして、移譲していく）。そしてそのslack（ゆとり）で新しいフェーズの問題を見つけ、解決していくのがPMの重要なミッションなのではないかと
プロダクトマネージャーはプロダクトのWhat,Whyを扱い、プロダクトを作っていくが実は プロダクトを改善するエンジンを作ることこそが最も大事なのかもしれない
PMはスタートアップCEOに学べ！200枚超えスライドで贈る馬田隆明の白熱教室 | CAREER HACK
What,Whyを決めるというのはエンジンの中の１つの役割にすぎません。エンジンを設計して、どの部分をPM自身が担っていくかはとても重要なテーマです。
スタートアップがCTOを探すときに用意しておくべき、1つの質問とその答え
最近スタートアップをやっている知人から「今、CTO探していてて、、」と聞かれることが多いです。
大体フェーズはseed期で
- アクセラレーションプログラムでCTO見つけてきたら出資すると言われた
- 人脈で出資までは取り付けたがプロダクトを内製開発していきたい
- 受託で生まれたキャッシュで自社プロダクトを内製開発したい
みたいな状況がほとんどです。
スタートアップで技術アドバイザー的なことを副業でしているというのもあり、最初は現在の状況とか、どういったことがやりたいのか細かくヒアリングしていたりしたのですが、大体の場合、結局同じところに収束することに気づきました。 どこに収束するかというと
「そのエンジニアが、メルカリやクックパッドといった大企業ではなく、自分でサービスを作るわけでもなく、 あなたの会社でやる理由は何なのか？」
ということ
紹介を求めている以上は、これに対する解は欲しいな、、、と思います。 今エンジニアは超売り手市場なわけですし
主観が大分入ってますが、いくつか回答パターンとNG,OKをメモしておこうと思います。
NGな例
「エンジニアリング以外は僕が全部やるから、コード書くのに集中できるよ」
全部やったことがあるのかと聞きたい。メッチャ辛いし、そもそもできないと思う。さらに、仮にこれを魅力に感じるエンジニアがいたとして、おそらく趣向性がスタートアップ向きでないと思います。この体制で成功するのはなかなか難しいですね、、、
ビジネスモデルが〜」
本当に面白そう（もしくは画期的）と思ったなら、自分で個人開発なり、会社を作ってやります。あなたとやる理由にはならないかなと
「0から全部自分でプロダクト作れるよ」
個人で開発します。
OKな例
顧客接点がある
特定領域toBとかで決裁者の人脈があり、販路を確保できそうなケース。 大体顧客の深いところのニーズを捉えて、ヒアリングできる環境もできている。 プロダクトさえ作れば、とりあえずはお金を払って使ってくれるユーザーが確保できそうというのはとても大きいです。
人柄
これかよと思うかもしれませんが、結局はここが大事。 エンジニアリングができても、自分一人だと何かをアップデートするような大きなものは作れないだろうということは皆薄々わかっています。また一人だとモチベーションが続かないということも ユーザーの気持ちがわかる原体験があって、情熱持って一緒にやれる人はどんなテーマであれエンジニアからすると魅力的に映ります。
おわりに
スタートアップは何かしらの取っ掛かりがあることと、その可能性を信じて情熱を持って進んでいけるチームがある以外は、アイデアが素晴らしかろうが、マーケットがあろうが、あまり意味はないんじゃないかなと個人的に思っています。
現在、エンジニアはかつてない売り手市場 というわけで、周りに「〜なエンジニアを紹介して、、、」と聞く時には、一行でいいので
「メルカリやクックパッドといった大企業ではなく、自分でサービスを作るわけでもなく、あなたの会社でやる理由は何なのか？」
に対する自分が思う解を添えてみましょう。 メッセージ送る時も１行でもいいので、最後に添えると紹介率がアップするかもと思います。
