PdMが事業責任者になるためのファイナンスから考えるプロダクトで稼ぐ事業の全体観

BASE株式会社執行役員の柳川です。金融事業の事業責任者をしています。
私はエンジニア→PdM→事業責任者というキャリアを歩んできました。
現在は事業戦略、プロダクト戦略、組織戦略全ての責任を持ちながら、事業責任者を務めさせていただいています。
その経験をもとに、「プロダクトで稼ぐ事業の全体像」を書いてみました。

この記事の執筆のきっかけは、先日投稿された横道さんの記事です。プロダクト開発に携わる方は必見の記事なのでぜひ読んでみてください。

この記事を読んで

•  事業の中におけるプロダクトマネジメントのという文脈が補助線としてあった方がわかりやすそう

• なぜこんなにもプロダクトマネジメントを取り巻くあれやこれやは複雑になったんだろう

など考えまして、筆を取るに至った次第でございます。僕たちは何かを複雑に捉えすぎてるのではないか。事業に立ち戻れば本来シンプルなものなのではないか。そういった主張が含まれた記事になります。
記事名は狙ってしまいましたが、プロダクトマネージャー以外にも、プロダクト開発に携わる人全員に読んで欲しいです。

本記事は以下の記事の精神的続編です。

注意事項

プロダクト開発視点だけにフォーカスすることなく、プロダクトで稼ぐ事業全体の流れをできるだけシンプルに表すことが目的としています。
そのため細かい部分、特にそれぞれの専門分野から見たときに気になる部分あるかもしれません。ご容赦ください。

完全に自分の経験からのみ書いています。あの本で書かれているコレコレと違うとか、逆にパクリだとかもご勘弁ください。

従来の製造業の全体観

比較のためにあえて製造業の流れを書きます。

プロダクトで稼ぐ事業の全体観

変更点としては、プロダクト戦略が追加されていることと、設備投資と製造をプロダクト開発に変えました。
事業戦略と、プロダクト戦略は深く繋がっており切り離せないというのが重要です。

Webをベースとしたプロダクトはリリースした後の変更が容易です。
容易ですとは言ったものの、変更を前提にした戦略設計は難易度が高いです。それゆえにプロダクトマネージャーという仕事ができましたし、事業戦略を立てるタイミングで、プロダクト戦略を立てることが必要になりました。
リリースしてから改善していく戦略がなければ、Webサービスの良さは激減し、ライバルに負けます。

もちろん従来の製造業においても改善サイクル自体はありました。しかし出荷した商品を、実際のFBを受けて早く細かく改善できるというのは革命です。
革命ではあるが、そのメリットをうまく使えるかは、組織ごとに大きな差が出ます。それぞれの組織やビジネスモデルごとの固有のメソッドがあり、それに対応した上でプロダクトを改善して以下なればなりません。
プロダクトマネジメントが複雑になる理由はここにあると考えています。

あらゆる場面で得た情報を、あらゆるタイミングでプロダクト改善に利用できる。素晴らしいことなんですけど、とても難しいのです。

ゆえに、プロダクトマネジメントの専門家が出てくるわけですが、、、
事業戦略担う人とプロダクト戦略を担う人がなぜ同一人物にならないのか。これがこの記事の根底を流れるテーマであり、僕のプロダクト開発人生におけるテーマでもあります。

全体観の各フェーズ解説

まずは各フェーズの詳細を解説してみます。
大事なのはビジネスストラテジーと、プロダクト開発と、ビジネスグロースの各流れを捉えることです。
このフェーズ解説は長いので一旦読み飛ばしで戻ってきてもオッケーです。次のPDCAの章の方が重要度は高く、読みやすいと思いますので。

戦略組織組成(ビジネスストラテジー)

ビジネスストラテジーを担う組織を組成します。
ファイナンスをするための戦略を作る組織です。
厳密にはこの前にもファイナンスがあるよねという考え方もあります。
以下の職能が含まれます。　　　　

• 事業責任者

• (PdM)

• (BizDev)

事業戦略策定・プロダクト戦略策定

ファイナンスをするための戦略を策定します。
事業戦略とプロダクト戦略は表裏一体です。
事業責任者のみで策定できるのがベストだと考えますが、場合によってはPdMやBizDevと協力しながら策定します。
以下のようなキーワドが関係します。

• 市場調査

• 事業ビジョン

• 事業計画策定

• プロダクトビジョン

• プロダクトディスカバリー(大)

ファイナンス

資金調達です。
資金が調達できなければ事業はできませんし、プロダクトは作れません。
資金調達というと、企業する場合だけのアクションで、会社員には関係ないよと思うかも知れません。大間違いです。
新規事業を立ち上げるときはもちろん、新機能を作る時もファイナンスは行われています。何かをお金をかけて行うということそれ自体がファイナンスなのです。

開発組織組成

プロダクト開発をする組織を組成します。
ファイナンスしたゆえにできます。
以下の職能が含まれます。

• 企画(PdM?)

• エンジニア

• デザイナー

プロダクト開発

プロダクト開発です。プロダクトマネジメントの手法の多くはこのフェーズで利用します。
以下のようなキーワドが関係します。

• プロダクト開発

• プロダクトディスカバリー(小)

• プロダクト改善

• 要件定義

• プロダクトデリバリー

ここの説明を始めますと、めちゃくちゃに長くなりますので、横道さんの記事をぜひチェックしてください。
(ここも時間があればPdM/エンジニア/デザイナーなどの絡みを踏まえた上での関係性を説明する記事を書きたいところ)

運用組織組成(ビジネスグロース)

ビジネスグロースを担う組織です。
ユーザーの獲得もプロダクト運用の一部であり、マーケや営業も含めた上でプロダクトであるという整理にしています。
使ってもらうところまでがプロダクトです。総合的に設計しましょう。
以下の職能が含まれます。

• マーケ

• 営業

• カスタマーサポート

リリース

プロダクトのデリバリーです。
プロダクト開発においてはリリースは始まりにすぎません。
ゆえにファーストリリースをどの状態とするか、ここに技術が現れますし、それこそがプロダクト戦略だったりします。

獲得・運用

ユーザの獲得や運用です。
マーケや営業やカスタマーサポートがここに当たります。
獲得や運用自体のPDCAも大切ですし、ここで得た情報はプロダクト開発にも活用されます。

アカウンティング

プロダクトが生み出した売り上げやKPIなどの結果の集計です。
プロダクトの改善にも、次のファイナンスにも重要なフェーズです。
日時週次月次で、それぞれの数字を確認しましょう。
確認するためにも、事業系計画を立てることが重要です。
管理会計的な視点と財務会計的な視点、それぞれが絡み合った上で意味をなします。
ここの確認とちゃんと自分ごと化出来ていないPdMが多い。(柳川調べ)
100歩譲ってPL責任は持たなくてもいいけど数字は見る。気になった数字はちゃんとドリルダウンしてみる。せっかく毎月結果が出るんだからちゃんと見て生かす。でも結局PL責任持たないと真剣に見ないのよ、人間だから。

リリース前のPDCA

プロダクトで稼ぐ事業の全体観は、当然に一方通行ではありません。
あらゆる場面でPDCAが起こっています。
そのそれぞれを解説することが、全体のフローの理解を助けると考え記述します。

ファイナンスできる戦略を作る

ファイナンスができる戦略を作るのは大変なことなのです。社外でのファイナンスはもちろん、社内でのファイナンスも戦略立案とステークホルダーの説得が必要です。お金がなければ事業は始まらないので、お金を投資するに見合う戦略を作する必要があります。
それを成し遂げるにはどれくらいお金が必要で、そのお金がどれくらいになって返ってくるかの説明が必要です。理由もなくお金を出してくれる人はいませんし、会社も意思決定できません
でもこの説明難しいのです。ただでさえ難しいのに、プロダクト開発特有の不確実性が伴うとさらに難しい。
事業計画を書いては、プロダクトビジョンを書いては、事業ディスカバリーをしては、プロダクトディスカバリーをしてはの繰り返しです。

この検討フェーズのコストを下げるためには、プロダクト開発フェーズへの深い理解と、プロダクト開発フェーズが強力であることが大切です。
プロダクト開発の不確実性を必要以上に怖がってしまうと、このフェーズが無限に重くなります。

プロダクト開発してみたら目論見と違った

ファイナンスして、プロダクト開発したもののお金が足りなくなったり、開発をしている中で戦略の変更が必要なことが判明するなどが起こりえます。起こらないほうがいいんですが起こりえますのでここでもPDCAが起こりえます。

プロダクト開発

プロダクト開発の中では常にPDCAが起こります。
そもそも作りたいものが作れるのか、作ったもので価値提供できるのか、作ってみたらなんか違うかも、などさまざまなことが起こります。
プロダクトで稼ぐ事業の全体観のフェーズ全般で起こるPDCAの縮小版が起こっていると考えるのが良いでしょう。

リリース後のPDCA

リリース後もPDCAが回り続けます。これが、プロダクトで稼ぐ事業の全体観の特徴です。

獲得運用改善

出来上がったプロダクトをどのようにユーザーに届けるか、営業やマーケはまさにPDCAの連続です。また主にカスタマーサポートが担当する、ユーザからの問い合わせや、日々の運用などもやらながら改善していきます。
ここで進んだPDCAの結果がプロダクトに反映されることも多々あります。
ポイントはちゃんとアカウンティング工程でまとまった数字を見ること、それを起点にPDCAを回していくこと。リリースしたんだからちゃんと結果に向き合う！

プロダクト改善

獲得運用での改善成果や、プロダクト開発チームのプロダクトディスカバリー(小)などで出てきた課題をプロダクトの変更という手段を用いて改善します。
この部分のPDCAが従来の製造業の全体観と最も異なる部分であり、プロダクトマネジメント全体が複雑になる元凶でもあります。
リリースした後に改善が回せるということで、事前検討のコストも下がるし、うまくこの特性を使いこなせばプロダクトの完成度も向上します。逆にいうとここがうまくできなければ、ただ単にクオリティの低いものを生み出すことになるかもしれません。
プロダクト開発チームのスコープだけでプロダクト改善をしないということを示すために、以下のような図の書き方になっています。

戦略変更レベルのブラッシュアップ

戦略変更レベルのブラッシュアップや、新たなファイナンスが必要になることもあります。
この際に大事なのは、いかに実際のプロダクト運用の積み重ねで出た生の情報を活用するかということがあります。
このレベルのPDCAまでしっかり回せることが証明できると、ファイナンスまでの説明がやそれに伴う言語化や数字での説明が大きく踏み倒せます。

会社で働くなら事業のサイクルをしろう

資金を集めて、経営資源に変えて、価値を届ける、これが事業活動です。
上記のプロダクトで稼ぐ事業の全体観も、この事業活動の中身をベースに整理しています。
上記サイクルが起こることは株式会社においては不可避ですので、正確に把握しておく必要があります。

大事なのはこの前提を把握した上で、いかにアジャイルやプロダクトマネジメントの考えを活用してこの説明コストを踏み倒せるか。それができてこそ真にプロダクトマネジメントが機能していると言えるのです。
把握しなければ踏み倒せませんし、把握しているからこそ得られる「信頼」があります。「信頼」も踏み倒すための需要なファクターです。
というような話をここから下には書いていきます。ここからが本番です。

プロダクトマネージャーは戦略組織か開発組織か

色々な考えがあると思いますので、あえてスタンスをとります。プロダクトで稼ぐ事業の全体観においてはプロダクトマネージャーは、絶対的に戦略組織に属するべきと考えます。そこまで出来てこそ、ただの企画職との差がでますし、そこまで出来ていないのにプロダクトマネージャーを名乗るべきではないと考えます。

ですが、現状では世の中の多くの場面においては、開発組織に属するのではないでしょうか。しかしそれではプロダクト開発の特性を活かした事業推進はができないのではないでしょうか。

というスタンスをとった上で、僕が言いたいのは、開発組織に属するプロダクトマネージャーも戦略組織に徐々に変化しうる可能性が高いということです。
プロダクト開発においては小規模な戦略策定と実行が繰り返されています。この小規模な戦略策定と実行の繰り返し、これをしっかりイニシアチブを持って行うことで、確実に意思決定力がつきます。
プロダクト開発の範疇でPDCAをまわす経験を詰みながら、徐々に戦略組織に滲み出ることができると考えます。プロダクトマネージャーはプロダクトリーダーへの近道であると考えます。

それぞれの戦略を誰が決めるのか

ここも色々な考えがあると思いますので、あえてスタンスをとります。
個人的な考えでは、それぞれの戦略の責任を同じ人間が同じ時期に担うタイミングがあるべきと考えます。別々の人間がそれぞれの戦略の責任をそれぞれ追うと、つながりを理解するのが難しいのです。
それぞれの戦略の責任を同じ人間が同じ時期に担うのは、負荷としては相当高いです。なので簡単におすすめはできないですが、個人としてはやってみて良かったと感じています。
チームの力を借りながらも、全ての責任を持つトライはできるといいと考えます。

組織図はそれぞれの役割スコープを狭め集中させます。そしてそれが結果を出すために必要であることは否定しません。
ただ組織図の力は本当に強力なので、組織図が足枷になりスコープを越えるべき時に越えられないことは多々あります。越えるために仕掛けはたくさんありますが、ベストはそれぞれがそれぞれの守備範囲を入れ替えても機能するように準備しておく、その上で集中するためにスコープを分ける、なんだろうなと思っています。
正直ここは僕も色々試し中です。

事業戦略 -> PL責任

COOが担うこともあるかもしれませんが、立ち上げ期の組織においては、事業責任者が担うべきです。どのような事業を、どのような計画で進めれば大きくできるか。計画もするし、実際の数字成果に責任を持つことがスコープです。

• 事業戦略策定

• 事業計画策定

• 資金調達(ファイナンス)

• 予実管理(アカウンティング)

プロダクト戦略 -> プロダクト責任

CPOやCTOが担うこともあるかもしれませんが、立ち上げ期の組織おいては、事業責任者が担うべきです。何を作るべきかと、どう作るべきかと、それをいかにデリバリーできるか、安定して運用できるかがスコープです。

• プロダクト戦略策定

• プロダクトマネジメント

• エンジニアリング

• デザイン

組織戦略 -> 組織責任

CHROが担うこともあるかもしれませんが、立ち上げ期の組織おいては、事業責任者が担うべきです。どのような組織をつくれば、事業戦略とプロダクト戦略を実行できるかということがスコープです。いうまでもなく、事業戦略とプロダクト戦略双方に 深く繋がりがあります。

• 組織戦略策定

• 採用

• 評価

• 育成

• 組織運用

プロダクト開発だけでPDCAを回すな

プロダクトで稼ぐ事業においては、プロダクト開発チームの中に小規模ながらも全体のフロー、すなわち、戦略、実装、実行の流れがあります。ここで素早くPDCAを回す経験を積むことはプロダクト人材が事業を率いるプロダクトリーダーになる上で大事なことです。
しかし、だからと言ってプロダクト開発チームだけでPDCAを回していてはダメです。小さなPDCAになってしまいます。

プロダクトマネージャーがプロダクトで稼ぐ事業全体に目を向けてPDCAを回せるようになると最高だよなと思い、本記事を執筆しています。
プロダクトマネージャーはこのアドバンテージをうまく生かしてください。

中心にプロダクトマネジメントがある

プロダクトで稼ぐ事業においては、プロダクトマネジメントが必要不覚欠です。事業戦略の確かさは大事です。それに加えて、プロダクト戦略の確かさとプロダクト戦略の実行力も重要です。これらが綿密に絡み合うからこそユーザーの価値に最速に確実に届くのです。
これらのつながりを綿密に絡みあわせるには、プロダクトマネジメントがわかるリーダーが必要です。
これが僕がたびたび主張する、プロダクトマネージャーは事業責任者になれ、エンジニアは事業責任者になれという主張の背骨です。

背骨を通す重要性

事業は複数の人間で運営されています。
そしてそれぞれがそれぞれの得意領域を活かして活躍することが肝要です。
ですがそれは誰かが背骨を通してこそ力を発揮します。
事業全体の流れを把握した上で、事業責任者が背骨を通す。
それができると、自ずとそれぞれのメンバーも、全体フェーズのつながりを意識した上で価値発揮できるものなのです。
全体観がわかる人が誰もいない状態は非常に恐ろしいです。リーダーシップが不在の状態は非常に恐ろしいです。

プロダクト開発は複雑性への抗い

プロダクト開発は複雑性性との戦いです。アジャイルの考え方やプラクティスがそれを支援します。プロダクトマネジメントがわかるプロダクトリーダーの存在がそれをリードし、下支えします。
僕は、プロダクトで稼ぐ事業の全体観の全体がアジャイル的に進められると考えています。プロダクトマネジメントで磨いた複雑性に抗うスキルを、事業サイクル全体にも適用していきましょう。

少し思想的な話になります。
僕は説明できることや、言語化できることや、ましてや数字で現せることなんてたかが知れていると思うのです。
「説明はできないけど、そうなのだ」という感覚は非常に大事だと思います。多くの人が納得するように説明していく過程で大事なものが削ぎ落とされ凡庸な案になる、ということを経験したことがある方は多いのではないでしょうか。
アジャイルの考え方やプロダクトマネジメントの手法はある意味「説明を踏み倒す」ための手法だと考えています。なので、狭い意味でのプロダクト開発だけではなく、事業活動の全体でアジャイルを機能させたいのです。ここをうまく機能させるためにも事業の構造を理解する必要があります。踏み倒すために必要なのは詰まるところ「信頼」なんです。どうやって「信頼」を獲得するか。実績と説明の積み重ねになるのです。

説明コストを踏み倒すためにも、構造を理解したり、言語化にして説明に挑む必要がある。その結果として「信頼」を獲得する必要がある。一見矛盾したこの感じ、伝わるでしょうか。

本来分かり合えない人同士が、金という共通項でまとまる。それはそれで一つの正解でした。そんな正解がある中で、ネクストステップとして、僕は「信頼」に掛けたいのです。「信頼」を支える一つの思想としてのアジャイルやプロダクトマネジメントに賭けたいのです。
この思想はデジタル民主主義的なものに影響を受けています。

説明、言語化、数字全て妥協の産物なんです。(過激思想です)

まとめ

できるだけ全体のつながりを意識して記事を書きました。長くなりましたがいかがでしたでしょうか？

主張はシンプルで、プロダクト開発も、事業開発も
なんのために
なにを
どうつくり
どう運用するか
が共通項で重要です。重要ですし、言ってしまえばただそれだけ。

それだけとは言ったものの、それが難しいんですよね。全体観が捉えられていないと、分解できないのです。そして誰も綺麗に分解してくれないので、全体観を知りにいくのが結局早いのです。その時にこの記事を思い出してくれればと思います。

現在僕はプロダクトで稼ぐ事業の全フェーズに携わっています。なので広く浅く、しかしつながりは大事にするスタンスでのお話ができると思いますので、ご相談ありましたらご気軽にお声がけ下さい。

今後それぞれのフェーズを深ぼった記事も書きたいと思います。ぜひこの記事をスキした上でフォローしてお待ちください。
SNSでの紹介も大歓迎です！メンションつけてくださればコメントしますのでぜひ！

編集後記

この記事を書いた背景として、「Jカーブとかエクイティ投資とかおかしいだろ」っていう思いがありました。必要な方法ではあるけど、当たり前の状態ではないという認識を持つことが大事だと考えています。
「とにかく他はどうなってもいいからユーザー価値」という文脈は、Jカーブやエクイティ投資の影響を相当に受けていることを認識した方がいいのでないかという課題提示がしたかった。

• フェーズによって意思決定の基準が変わるのが当たり前

• ビジネスモデルによって解決策が変わるのは当たり前

要はエクイティ投資を受けている初期は、PL見えにくいけどちゃんと見ようよと言うこと。知らないうちにBSを見ているのです。スタートアップで働く皆様は。BSなんてわからんよと思うかもしれませんが、構造上縛り付けられてる。トップラインとBSばかり見てる。

この辺りをみんなの認知にしつつ、バチバチ真の食った議論や推進がしたいですね。
この記事の話ですね。