PM(PdM兼PMM)として意識している「事業上の"資産"を生み出す」こと

これは何?

株式会社LayerXで、バクラク申請とバクラク経費精算のPM(PdM兼PMM)をしているnumashiといいます。
最近meetyでカジュアルに会話させていただく方々から、LayerXのPMって何しているの?とよく聞かれます。
せっかくなので、実務も含めてよく聞かれることをまとめてみようと思います。なお、後述する実務部分の記載は、あくまで私(N=1)の話です。

PM(Tech PdM/PdM/PMM)と事業開発

私自身の話をする前に、2022年8月に読んだPMの役割に関連するお話で、わかりやすい&腑に落ちるなあと思ったことがあるので、2つご紹介します。

1. Pocochaさんのカルチャーデック:
プロダクトマネジメントトライアングルをTech PdM、PdM、PMMの3つの役割から記述していて、とても参考になります。

実際、LayerXでも、バクラク請求書のPdMはエンジニアも兼務しており、機能開発もやっています。このスライドでいうところの、TPdMの部分が強いメンバーも活躍しています。

2. estieさんのブログ:

PMとBizDevの違いを記載したブログです。

PMとBizDevの比較表がとにかくわかりやすいので、こちらも引用します。

スクリーンショット 2022-08-16 22.30.04
株式会社estieさんのブログより引用

meetyでも、PMって何やっているの?と聞かれたり、短期間でよく役割を混同されがちな職種に関する記事が豊富に出ているところを拝見するに、PMという単語に含まれる意味が、企業によって様々であるからだと思います。

また、自社としてもPMに関連するいくつかの発信の記事があるので、いくつかピックアップして載せておきます。主に開発と組織づくりの話や、そこに付随する開発ロードマップに関する発信をしています。一方、実務上何をしているか、どういうことを大切にしているかはまだなかった、かつmeetyでよく聞かれることがあったので、まとめてみようというのがこのnoteの趣旨です。

https://tech.layerx.co.jp/entry/product-market-mapping

ここから、私自身がバクラクのPdM兼PMM(以降、PMと総称)としてやっている内容を記載します。


お気持ち宣伝

meetyやってます。雑談大歓迎です。他社のPMの方(もちろんそれ以外の方も誰でもウェルカム)とも話してみたいので、お気軽にお話しませんか。このnote読まれた方は感想とかも聞いてみたいです。

宣伝終わり


LayerXのPMについて補足

LayerXでは、エンジニアとして入社後、PdMとなった人もいれば、入社時点からPdM兼BizDevとして活躍している方など、複数のケースで入社された方々がいらっしゃいます。
かくいう私は、SalesとしてLayerXに入社後、社内異動を経てPdMとPMMになり、2022/8時点で半年が経過しています。あくまで私自身の仕事内容ということで、普段やっている内容を書きます!

バックグラウンドと自己紹介

さっと前職からのキャリアを記載すると、2年半でいろんなことを広く浅くやってきました。新卒は大企業に研究開発職として入社し、ハードウェアエンジニアをしていましたが、転職し、株式会社グラファーにてBizDevをしていました。すごくいろいろなことをさせてもらいましたが、一貫して事業推進寄りのことをしていました。前職は非常に愛着があり、今でも個人としてとても応援している会社です。

その後のLayerX入社後はざっと以下の図のような形ですが、既存のプロダクトを担当するとともに、バクラク経費精算のリリースにも携わらせてもらっています。今はリリースして3ヶ月が経過し、PdMとしても、PMMとしても非常にやりがいある日々を過ごしています。

スクリーンショット 2022-08-16 22.07.06
直近2年半のキャリア

バクラクのPMとしてカバーしている領域

PMの役割ですが、基本的には「プロダクト戦略」と「Go to Market戦略」の2つで記述されると思います。
こちらの記述は、freee VPoPの宮田さんの著書である、ALL for SaaSを参考に作成しています。

なお、普段やっていることをこのnoteには伝えたいため、実装部分はやっていないことを示すために意図的にプロダクト戦略部分は、実務により近い「仕様検討」「実装」を盛り込んでいます。

スクリーンショット 2022-08-16 22.12.31
PMの役割のマッピング

ちなみに、今カバーしている範囲を図示すると、以下のようになります。バクラク申請とバクラク経費精算は、PdM兼PMMとして、私1名のみで現在回しているため、カバー範囲だけでいうと広くなります。(※広いだけで、深さはありません)

スクリーンショット 2022-08-16 22.14.39
紫色の内容がPMとしてのカバー領域

なお、事業計画部分はプロダクト単体で考えず、バクラクシリーズとして考える方がお客様の価値を考慮しやすく体験もよくなるため、意図的に外しています。Whole Productとしての事業計画を重視するには、全体を俯瞰する必要があるため、事業部長である牧迫さんが策定しています。
なお、実際には、プロダクト単体の目標も作るため素案は当然作成しています。ただ、現在地や成長曲線を引いて具体的なアクションを考えるための手段としてしか利用しておらず、やはり深さとしては浅いものになっていると思います。

「Go to Market戦略」の実務内容

プロダクト戦略については、なんとなく意味がわかりやすいと思いますが、Go to Market戦略はあまり詳細に記載されているものがないと思うので、少し補足のスライドを記載します。

スクリーンショット 2022-08-16 22.21.32
Go to Market戦略の中身

「これ全部・・・?やるの・・・?」みたいに思われた方もいらっしゃると思いますが、実務の深さとしては相当浅いです。実務上深い部分までは各チームにお願いをしています。
一方、細かい実務の粒度では、マーケティングの実例では、広告バナーの文言のレビューや案出し、ウェビナーの価値訴求の方向性決めたりしています。営業戦略部分では実際のお客様とのお打ち合わせもやります。

実態として専任のチームと比較して打席に立つ機会は圧倒的に少ないので、少ない情報から仮説を持ち、ビジネス上の無形資産を積み上げて各チームが動きやすいインターフェース(営業コンテンツやターゲット像等)を設計・周知・広報することと考えてます。

各種アクションに対する知見の深さは当然ながら各チームの方が詳しいので、リスペクトを持ちながら、バランスみつつレバレッジが効きそうなところを重点的に見たり、逆に知見が浅いからこその現状を疑う視点からあたらしい手段を検討する、というのが日々やっていることになります。

箇条書きになってしまいますが、より細かく日々の実務として行っている内容でいうと、以下のような内容を実際には取り組んでいます。

  • Marketing<>Inside Sales<>Field Salesまでのカスタマージャーニーマップの作成

  • カスタマージャーニーに沿った商談ファネルの策定

  • 商談ファネルの仮説検証

  • プロダクトマーケティングのための種々の施策。「誰に」「どんな価値を」「どのように届けるか」を手段ベースで洗い出し

  • ホワイトペーパーの作成

  • ウェビナーの設計・資料作り

  • オフライン展示会のレジュメレビュー、各種広告のバナーレビュー

  • Inside Salesのトークスクリプトのレビュー

  • Field Salesの商談ファネルの細かい設計

  • 営業資料作成や業務フロー作成などのコンテンツ作成

  • 商談分析(受注・失注・ターゲット分析等)

  • 事業計画の作成

  • 何度もPMFするための仮説検証・ペルソナ設計

  • パートナーチャネルの販売戦略の仮説検証

書いてみると本当に色々あるなあと感じました。
上記の内容は、全てではないですが、多くはBizDevやPMMという職種が担っていることが多いように感じます。

「プロダクト戦略」の実務内容

こちらは、よくあるPdMの役割に近いかと思います。実際の業務内容を箇条書きで記載します。

  • プロダクトビジョンの策定

  • 開発ロードマップの策定・社内周知:月次で事業部内に共有会を開いています。

  • 機能改善要望の棚卸:SalesやCSと協力しながら、機能改善要望の優先度の棚卸を行い、backlog化等をしています。大玉の機能の場合は、backlogとは異なるところにストックし、仕様検討を前倒しで行ったりしています。

  • 機能開発の意思決定:TechLeadと共同しながら、開発する機能の優先度を意思決定します。不確実性に向き合いながら、時には当初の予定を大幅に前倒しする意思決定が求められます。

  • 仕様の作成:PRDを書きます。同時に、ラフデザイン(Figmaを利用)をPMが書き、機能開発のWhatとWhyにデザイナー+エンジニアの持つHowの接合点を作ることで更に良い機能が作れないか、模索します。

  • プロダクト横断の仕様検討も多いため、他のプロダクトのPMとコミュニケーションを取りながら仕様の決定を行う場合もあります。

ちなみに、各種業務を進める上で、楽しいことを挙げると、仕様検討のプロセスかなと思います。
元々、LayerXはUIデザインのみを書き起こすプロセスを排除することで、デザイナーがときにはコードを書き、アイデアを具現化する体制でした。

https://tech.layerx.co.jp/entry/2022/06/24/092727

しかし、それだと機能が具現化される段階がかなり後ろ段階になってしまいます。
私自身がソフトウェアエンジニアリングのバックグラウンドがなく、文字だけのPRDだとエンジニアやデザイナーから溢れ出る多彩な解決策を拾いきれないことがわかり、私がとても悔しかったので、PMがラフなUIデザイン作っちゃうようになりました。
PMがWhatとWhyを決めてHowをエンジニアに任せるのではなく、実装内容も議論することでPMの決めたWhatとWhyが一段階磨かれることが多いのが特徴です。時には、設計やデータモデリングの話、デザインの話等も壁打ちを受けます。テクノロジーがコアにある会社なので、正直容赦ない環境とも言えるかもしれませんが、僕はテクノロジーに未来を賭けている人なので、すごい楽しいです。

小さなスタートアップの一員として大事にしていること

ここまで色々書きましたが、「え?それってBizDevの仕事では?」「PMMの仕事かも?」「PdMの仕事かも?」と色々なことを感じられたかと思います。
私の仕事の矜持は、ただ1点です。
何も成し遂げていないスタートアップの一員として、コーポレートミッションを実現できるためのビジネス上の"資産"を作ることです。
ここでいう"資産"とは、会計上の資産(例えば、ソフトウェア≒プロダクト)に限りません。"誰にアプローチすればよいか"といったターゲットを全メンバーが理解できる指針であったり、"どんなペインがあるか"、"お客様に相対するときに必要なアプローチ方法"であったりと、ビジネス上の無形資産と定義しています。

これがあるのとないのとで、各チームの動きやすさが変わります。つまりそういった"資産"を作れるだけで、組織としてレバレッジが効くのです。
そういった"資産"を作るために、お客様の問題を定義・特定し、どのようにそれを解決できるかどうかに心血を注ぎながら、N=1の課題から示唆を得て、N=100、1000、10000といった多数の共通の課題を解いていきます。社内ではこのプロセスを"検証"と呼び、アウトプットまたはアウトカムを"発明"と呼称しています。

結果として、その仕事内容は所謂BizDevなのかもしれません。PdMなのかもしれません。PMMなのかもしれません。お客様やマーケットに対するアウトカムが得られれば、私自身はこだわりがないのでなんでもいいのかなと思っています。

100名程度のスタートアップのPMのリアルが伝われば幸いです。

さいごに

採用情報を載せておきます!一緒に働いてくださる仲間を募集しています。


この記事が気に入ったらサポートをしてみませんか?