PM memorandum

Product Managementにまつわる記事をポストします。twitter: @kyosu_ke

崖から飛び降りながら、組織をつくってはいけない

これはなにか

振り返ると2019年は、組織やその地固をした1年だったと言える。

ハード部分としては、データを適切に扱うためのELTパイプライン、データマートの整備、分析環境の構築など、中長期で事業推進を行うに足る、地固を行った。

一方で、ソフト部分としては、組織に時間を投資した1年だった。

その中で、組織の急拡大とその弊害について考える機会が多かった。 今回のポストでは、その点について記述する。

なぜ組織は急拡大を目指してしまうのか

理由はいくつかある。パッと思いつくだけでも

  • 短期で売却によるExitを目指しているので、中長期での組織への影響よりも短期での成長・バリエーションに、創業者の興味関心が強い
  • 急拡大するマーケットでシェアを一気に広げないと負けてしまうドメインで戦っている場合
    • ex.伸びが顕著でプレイヤーがどんどん出てきている市場、勝者がまだ決まっていない新興市場かつWinner Takes All型でデファクトスタンダードを取らないと負けてしまう市場 etc..
  • 「ファンドの償還期間」というビジネスモデルの末端に組み込まれた結果、一定の期間でのExitに対してプレッシャーがかかる

といったものが上げられる。

これらの条件のどれかに合致する場合は、程度の差はあれども組織の急拡大を目指していく方向になるのではないかと思う。

組織の急拡大による弊害

LinkedInの創業者、リード・ホフマンは「起業とは崖から飛び降りながら、飛行機をつくるようなものだ」と言っている。

事業の判断や起業するかしないか、といった点では確かにそのとおりだが、こと組織づくりや採用に関しては、崖から飛び降りながら行ってはいけないと感じている。

飛行機を作るのは、組織やその構成員であるヒトだ。組織やヒトが盤石であれば、崖から飛び降りながらでも飛行機は作れる。 しかし、組織やヒトがしっかりしていない状況で、飛び降りながら組織も飛行機も作る、というのは相当難易度の高い曲芸である。

実際、組織の急拡大による弊害というものがある。

質的な急拡大による弊害

質的な急拡大とは、CxOのようなエラい人が急にパラシュート人事で降りてくるパターンだ。

しかもその人は現場メンバーは会ったこともなければ、知らされてもおらず、当日急に登場し、CxO然とし始める。

適正・能力・組織文化へのFIT感があればよいが、ないと最悪だ。 現場と執行レイヤーの長であるCxOとの間の信頼は作れず、連携は取れず、そのCxOは孤立し、結果機能しなくなる。

さらにそのCxOが政治屋だと地獄である。 メンバーとは連携が取れていないが、自分を採用した経営陣に対しては良いレポートしか上げず、結果正しい情報が経営に行き届かなくなり判断ができなくなる。

量的な急拡大による弊害

量的な拡大とは、実行の手が必要で、目標採用数の達成が絶対とされた採用活動を行い、ヘッドカウントを増やすパターンだ。 この場合、採用のハードルが下がることが考えられる。

採用基準の低下と言っても、いくつか種類があるし、ときには意図的に下げるということが有効な場合もある。 その中でも特にカルチャーFIT面での妥協が一番組織を壊す。 これまで築いてきた組織文化の基盤が崩れるからだ。

組織文化への投資を優先する

質的な急拡大・量的な急拡大どっちにおいても、組織カルチャーへのFITが大切だと考えた。

その観点からドクターズプライムでは、採用面に関して短期利益の追求よりも、中長期的に続く組織の強さを作ることを優先した。

粘り強くそこに投資することが出来たのは3つの理由がある。

  1. ペインが強く、顧客の財務基盤が盤石な業界であった
  2. 先にユーザーを集めてあとからマネタイズする投資専攻型モデルではなく、受益者負担型モデルで、投資をした翌月から収益を上げることができるビジネスモデルであった
  3. 作らないものづくり」によって、外部株主を招かずに、初期の仮説検証を行うことができた

blog.kyosu-ke.com

これらは突き詰めると、

  • きちんと顧客の課題を解決して、毎日収益を上げること
  • ステークホルダー全員が短期的な事業成長よりも、盤石な組織を作りに投資する方針に賛成していること。

この2点に尽きる。

やってきたこととやらなかったこと

中長期的に続く組織の強さを作るために、2019年にやってきたこととやらなかったことがある。

  • やってきたこと

    • 人事評価・等級制度の策定
    • カルチャーコードの作成
    • バリューの作成・再定義
    • インターンからの正社員登用
    • インターン&副業中心の組織体制の継続
  • やらなかったこと

    • バリューが固まる前の中途採用
    • CxOの採用
    • マネージャーの採用
    • 外部資本の組み込み・エクイティでの資金調達

1人目の社員を採用したときから人事評価・等級の制度を整えた。 面倒だから、事業優先だから、まだ必要ないから、色んな理由で数十名まで作らない会社も多いと思う。

一方、人事評価は会社からのメッセージなので、組織としてなにが正しいか、会社として何を評価するのかを明確にして指針を立てることを我々は重要視した。

また、バリューが決まりきるまで、一定期間一緒に働いていない人の採用を行わないことにした。 その時点で、華々しいトラックレコードを持つスーパープレーヤーの採用をすぐには行わないことが決まった。

そして、インターン&副業中心の組織体制の継続および、インターンからの正社員登用を推進していく方針を決めた。

短期的な成長 < 中長期的な組織の強さ

こうして、短期的な成長を求めるがゆえに組織の破壊を導く恐れのある採用を行わないことを決めていった。

自分たちはたまたま運良く、ペインが強くて顧客の財務基盤が盤石なドメインで、受益者負担型のビジネスモデルで事業を展開し、「作らないものづくり」によって、中長期的な組織の強さに投資する意思決定をすることが出来たと思っている。

組織への時間的投資を行った2019年を通じて、組織拡大をしても壊れないための準備が出来てきた。

2020年からは本格的に組織拡大をして、人員的にも事業にドライブをかけていきたいと考えている。

採用やってます!

興味を持っていただいた方はコチラからご連絡ください!

とりあえず話を聞いてみたいという方は TwitterのDMを開放しているので、お気軽にどうぞ!

作らないものづくりで進める、非エンジニアPdMの仮説検証

これはなにか

2019年も、あと残すところ2日という所まで来ました。 個人的には、2019年1月末を最終出社としてメルカリを退職し、中高の同級生である田(でん)と創業した株式会社ドクターズプライムへのフルコミットを開始した、転換点となる年でした。

このポストでは振り返りとして、ドクターズプライムを始める上で、初期から大切にしていた仮説検証の進め方、「作らないものづくり」について書きたいと思います。

3年前の再会

本題に入る前にすこし昔話を。 実はこのDr.'s Primeという事業は、今から3年半ほど前にさかのぼった、2016年5月に田と再開したことをキッカケに始まっています。

私がメルカリに入社したのが2016年の7月なので、実はメルカリに入る前から行っていた事業になります。

チームのバックグラウンドとしては

    • 聖路加国際病院(救命救急医)
    • メドレー(Sales)
    • CyberAgent America,Inc.(Producer)
    • サイバーエージェント(Director/Project Manager)
    • メルカリ(Product Manager)

という構成で、創業チームに技術的バックグラウンドがありませんでした。

医療業界へのパス、セールスの経験は田が持っていて、プロダクトマネジメント、仮説検証の経験は私が持っている。しかし技術バックグラウンドがなく、ものが作れないというのがチームの課題でした。

作らずにどうやって検証するか

このチームでどうやって、サービスを展開し、仮説検証を行っていくか。

そのひとつの形が「作らないものづくり」でした。

「作らないものづくり」とは、必要最低限の開発、ないしは開発を行わない状態で仮説を検証し、検証できたあとに作り込む進め方を指します。

具体的には既存のwebサービスなどを組み合わせて、検証を進めます。

Dr.'s Primeでは、Google Spreadsheet, Google Form, Gmail, Google Apps Script, LINEグループ, LINE@等を利用しました。 HTML, CSSは書きましたが、これも今ではSTUDIOあたりを使えば不要そうです。

プロダクト開発・製品ありきで考えるのではなく、検証したい仮説とその証明ありきで考えることに重きを置いていました。

初期のDr.'s Primeの構成

具体例があったほうがわかりやすいので、実際に初期のDr.'s Primeの構成を見てみましょう。

Dr.'s Primeは医師と病院をつなぐ、非常勤救急医の採用マッチングプラットフォームです。 簡略化した、サービスの利用フローは下記です。

f:id:kyosu-ke:20191230233718j:plain

シンプルなTwo Sided Platformのフローです。

これを実現するにあたって、初期のMVPとして、メインループにあたるフローのみを次のような構成で作りました。

f:id:kyosu-ke:20191230234450j:plain

  1. 求人の投稿:
    • 病院担当者がGoogle Formsで求人情報を登録
  2. 求人の掲載:
    • スタッフが手作業で応募フォームに転記(運用でカバー!)
  3. 閲覧・応募:
    • iframeで応募用Google Formsを埋め込んだwebページから医師が応募
  4. 応募の通知:
    • 応募が入るとGoogle Apps Scriptが応募テーブルを読み、Gmailを病院に送信
  5. 採用の判断:
    • 病院は採用を判断し、求人案件別の専用メアドに採用する/しないのメールを送信
  6. 採用の通知:
    • Google Apps Scriptで採用判断のメールをパースして読み解き、医師に結果を通知

このように、入力のインターフェースをすべてGoogle Formsに寄せて、そこから自動転記されるGoogle Sheetsをもとにデータベースを作っています。 そのGoogle Sheetsデータベースに対して、Google Apps Scriptで読み書きして、Gmailを出力のインターフェースとして利用者に通知を行います。

また、この図を見ればわかる通り、Google Sheets, Google Forms, Gmail, など非技術者でも直感的に扱えるものを中心に構成されています。 Heroku, HTML, CSS, Google Apps Script, Basic認証などは少し学習する必要はありますが、ググったりProgateを一周やる程度の学習コストで済みます。

サービスを展開する上での機能と利用ツールをマッピングすると下記のようになります。

  • 静的ページのホスティング: Heroku
  • 静的ページの作成: HTML, CSS
  • 入力インターフェース: Google Forms
  • データベース: Google Sheets
  • サーバー・バックエンドシステム: Google Apps Script
  • 認証: Basic認証
  • 通知: Gmail

シンプルなマッチングプラットフォームであれば、これらでMVPは成立します。

当然、色んな面で突っ込みどころは満載なんですが、ベータである状況をご理解頂いた、特定の方を対象としたMVPであれば検証は十分進められます。

この「作らないものづくり」で検証を進めて、一定のトラクションを確認することが出来たため、安心して本格的な製品開発に入ることが出来ました。

そのビジネスってスケールするの?に答える

なぜ「作らないものづくり」を選んだか、ということを考えると、理由がいくつかあります。

  • 初期のチームにエンジニアリングの能力がなく、ありものでなんとかするしかなかった
  • 保守的なので、きちんと市場ニーズがあって、サービスとして成立することを見極めてから進めたかった

このあたりが主な理由です。 しかし、それだけではありません。

新しいサービスを立ち上げる際には、スケールに耐えうるシステムを考える前に、そもそもそのビジネスってスケールするの?という問いに答えなければいけません。

どんなに立派でモダンなアーキテクチャでスケールするシステムを作ったとしても、ビジネスがスケールしなければ、それらは無用の長物になってしまうからです。

その問いに答えるために、自分たちにとって一番最適な進め方がこの進め方でした。

作らないものづくりの利点

作らないものづくりで仮説検証を進めてきて、よかったなと思った点は下記でした。

  • 創業チームに開発力がなくてもすぐに仮説検証が始められる
  • 仮説検証のサイクルが早くなる
  • 提供価値が受け入れられることが証明できてから作るので無駄がない
  • ファイナンス的な負債を負わずに仮説検証ができる

4点目はチーム内に開発力があれば問題にならないので、状況によりけりなのですが、私達にとってはとても大きなことでした。

これによって、エンジェルラウンドやシードラウンドで一定比率の株式を放出することなく仮説検証ができ、サービスを本格展開することが出来ました。

作らないものづくりが合わないケース・欠点

一方で、作らないものづくりが合わないケースや、マイナスになる点も勿論あります。

(人間には、自分の決定や仮説をサポートする証拠ばかりを集めてしまう、確証バイアスというバイアスがあります。私の論も多分に確証バイアスを含んでいるでしょう)

  • サービスの種類やサービスのコアな提供価値によっては、ちゃんと作らないと検証ができない場合がある
  • 創業チームに開発力がある場合は、作ってしまったほうが逆に早く検証ができる場合もある
  • 技術的な負債が残る可能性がある

勿論すべては状況によりけりなので、「これこそが唯一至高の仮説検証・MVP作成方法である」とは言いませんが、少なくとも当時の私達にとっては最善の手法だったと思います。

まとめ

ここまでをまとめると、下記の3点になります。

  • 「作らないものづくり」とは既存のツールやwebサービスを組み合わせて、仮説を検証する進め方である
  • スケールに耐えるシステムの前に、そもそもそのビジネスってスケールするの?という問いに答えなくてはならない
  • 作らないものづくりによって、仮説検証のサイクルを早められる場合がある

一方で、チームの保有する能力によっては普通に作ったほうが早く検証できるので、自チームの状況を見極めて、最速の方法で仮説検証を行うのが良いと思います。

採用やってます!

興味を持っていただいた方はコチラからご連絡ください!

とりあえず話を聞いてみたいという方は TwitterのDMを開放しているので、お気軽にどうぞ!

フォーカスを明確にするPMF仮説のマッピング

これはなにか

PMF仮説の検証を進める上で、各仮説の状態を見える化する方法を記したものである。

先日、この記事を読んで、自分の事業はどうだろうと考え、実際に当てはめて作ってみたところ、次の一手を決める指針になったので筆を執った。

なお、この記事は新規サービスの運営者や、それを検討している方に見てもらうことを想定して書いている。

そもそもPMFとはなにか

PMF(プロダクト・マーケット・フィット)は様々な記事で語り尽くされているので、この記事ではその説明に多くを割かない。

他のよりわかりやすい記事を引用して説明に替える。

スタートアップにおいて最も重要なPMFの図り方と達成方法

PMFの定義として頻繁に挙げられるのが、「顧客を満足させる最適なプロダクトを最適な市場に提供している状態」です。

真のプロダクトマーケットフィット(翻訳)

顧客は、あなたがプロダクトを作るのと同じぐらいのスピードでプロダクトを購入する - あるいは、あなたが多くのサーバーを追加するより早くユーザーが増加する。ユーザーからの収益があなたの会社の当座預金口座に積み重なっていく。あなたはできるだけ早くセールスとカスタマーサポートのスタッフを雇おうとしている。

PMF(プロダクトマーケットフィット)とは?事例から学ぶ、PMF達成の測り方とその方法

人々が欲しがるものを作ること (ポールグレアム) 市場を満足させるプロダクトで、正しい市場にいること (マークアンドリーセン) スタートアップのプロダクトに共感する、広範囲の顧客を見つけた状態 (エリックリース)

PMF仮説とはなにか

PMF仮説とは「『これらの仮説が正しければ、PMFが実現する』と事業者が考える仮説群」のことだと私は理解している。

ざっと調べた限りでは明確な定義は見つけられなかったので、上記の理解は私の解釈である。

上記の理解に基づき、PMF仮説はどういった型で表現されるかというと、下記のような形式で表せると考えている

「◯◯であれば(すれば)、△△はxxするはずだ」

より形式化すると以下のようになる。

[条件]を満たす場合、[ステークホルダー]は[期待する行動]をするはずだ」

こういった仮説が、ステークホルダーおよび、それらに期待する行動の数だけ存在すると考える。

これらの仮説群のことをPMF仮説だと、私は解釈した。

なぜこれが大切なのか

なぜ仮説をマッピングするかというと、仮説群を列挙しただけでは、どの順番でどこから着手すべきなのかが明確でないからだ。

実際に、この手順でマッピングを行ったところ、複数あるPMF仮説の状況の可視化とプライオリティが明確になった。

以降、実際にマッピングの方法を記述する。

PMF仮説をマッピングする

f:id:kyosu-ke:20190504143700j:plain
PMF仮説マッピングの例。仮の事業をマッピングしてみる

チャートの2軸

縦軸に重要度、横軸に進捗度を取り、PMF課題をマッピングする。

  • 縦軸: 上にいくほど重要度が高く、下にいくほど重要度が低い
  • 横軸: 右にいくほど検証の進捗が良く、左にいくほど進捗が悪い

ポスト・イットにPMF仮説を記載

各ポスト・イットには、先程の「◯◯であれば(すれば)、△△はxxするはずだ」の形式で、PMF仮説を記載する。

ポスト・イットには下記の3つの要素を含める

  • PMF仮説: 「◯◯であれば(すれば)、△△はxxするはずだ」の形式でポスト・イット1枚につきPMF仮説を1つ記載
  • KPI: PMF仮説の検証を表現するKPIと目標値を定義する
  • ステークホルダー: ステークホルダー別にポストイットのカラーを分ける

どうマッピングするのか

以下の手順でマッピングを行う。

  1. 2軸を用意したチャートを作る

  2. PMF仮説をポスト・イットに書き出す

  3. 重要度・進捗度に応じてマッピングする

複数名でこの作業をする場合、2までを各自で行ったあとで共有し、PMF仮説を絞り込むのが良いだろう。 またその場合、以下のステップを挟むことで、ポジションや声の大きさに引っ張られずに、重要度と進捗度の認識を揃えることができる。

2-1. 絞り込んだPMF仮説ごとに、重要度・進捗度について10段階評価で、同時に数字を言い合う

2-2. なぜその数値にしたのかを議論

2-3. 合意が取れた重要度・進捗度をポスト・イットにメモ

重要度と進捗度の精度について

マッピングを進めていくと、重要度と進捗度の精度の良し悪しに頭を悩ませるかもしれない。

しかし、ここでの目的は「どの順番でどこから着手すべきなのか」つまり優先度の決定であるため、厳密な精度は不要である。

また、ANDREESSEN HOROWITZの12 Things about Product-Market Fitの#8でも書かれている通り、PMFはそんなに明白なものでなければ、一度実現すれば終わりではなく、市況に応じて追い求め続けなければならないものである。

よって厳密な精度で測ること自体はそこまで重要ではない。

もちろん、雑でいいと言っているわけではなく、こだわりすぎて足を止めても仕方がないという話である。

どう使うのか(各象限の意味合い)

マッピングした結果、下図のようなチャートが出来上がるはずである。

f:id:kyosu-ke:20190504134108j:plain
実際に自社でやってみた図。各仮説は非公開

第二象限(左上)の、重要度が高く、進捗の悪いPMF仮説を真っ先に取り組んで行けば良い。

実際にいま取り組んでいるテーマが第三象限以外の場合は、そのテーマは重要じゃない可能性がある。

第三象限以外のPMF仮説は言うなれば下記のような仮説群と言い換えられる。

f:id:kyosu-ke:20190504141523j:plain
マッピングの各象限の意味合い

  • 重要度が高く、進捗も良い、第一象限(右上): もう十分な仮説
  • 重要度が低く、進捗の悪い、第三象限(左下): あとでよい仮説
  • 重要度が低く、進捗が良い、第四象限(右下): やらなくていい仮説

これらの象限の意味合いを踏まえて、この章の冒頭のPMFマッピングの例を見てみると、PMF仮説1, 2がもっとも注力すべきものとわかる。

f:id:kyosu-ke:20190504143700j:plain
再掲: 章の冒頭のPMFマッピングの例

また、青色のポスト・イットのステークホルダーと黄色のポスト・イットのステークホルダーの、PMF仮説の重要度と進捗度を比べてみると、黄色のステークホルダーのほうが全体的に重要度が低いが、検証の進捗が良い状態であることがわかる。

この場合であれば、黄色のステークホルダーに割くリソースを、青色のステークホルダーにドラスティックに寄せても良いかもしれない。

このように、マッピングを使うことで、注力すべきポイントがわかり、体重の乗せ方を考える参考にすることができる。

まとめ

  • PMFを目指す中で、サービスはいくつかのPMF仮説を検証していく
  • PMF仮説は複数ある場合が多いと思うが、ただ羅列するだけは少ないリソースをどこに集中すべきかを見失いやすい
  • PMF仮説を、シンプルな重要度と進捗度の2軸でマッピングすることによって、それらの状況の可視化とプライオリティ付けに役立つ
  • 重要度が高いが進捗の悪い、最重要PMF仮説に注力すると良い

株式会社メルカリを退職しました

これはなにか

いわゆる、退職エントリと言うやつである。

先日、約2年と6ヶ月の間勤めた株式会社メルカリの最終出社を終えた。

多大なる感謝と濃密すぎる2年半で、めっちゃ長文になったけど、ご勘弁を。

目次

  • なぜメルカリに入ったのか
  • メルカリでなにをしたのか
  • メルカリで得たもの
  • 内側から見たメルカリ
  • では、なぜ辞めるのか?
  • なぜそれをやるのか?
  • ぐちゃぐちゃした思いの中で、ひとつ明確に言えること
  • 最後に

なぜメルカリに入ったのか

メルカリに入る前は、サイバーエージェントで一貫してゲーム畑のPMをやっていた。

SFでのアメリカ支社の立ち上げ→大型ソシャゲタイトルの運用→自社IPタイトルの新規リリースetc.と、いろいろと経験を積ませてもらった。

きっかけはBizDevのミートアップだった。「ちっちゃいベンチャーヤマト運輸と提携、ってどんなマジック使ってんのよ?」くらいの、ほぼ冷やかしと言っても過言ではない気持ちで参加したミートアップだった。

そこから「業務理解のための面談」を重ねて、気がついたらオファーを頂いていた。

元ウノウ・ジンガ→某チケットフリマの創業メンバーの友人が、最後のひと押しとして「今のメルカリには今しか入れないよ」的な、何かを言っているようで何も言っていないような、しかし僕にぶっ刺さった深イイ言葉をくれて、決断した。

とはいえ、自分のジャッジなので、そこは自分で考えて決めており、当時のノートを見返すと、こんなことを考えつつ、US市場に再挑戦するための意思決定していた。

f:id:kyosu-ke:20190214220345j:plain
よくわかんないけど、いろいろ考えた風味

当時、新卒採用時に自分をアメリカ配属にしてくれた担当役員の方が退任されており、海外市場へ向けたサービスに挑戦する機会は減っていた。

帰国してからは、「まずは地力を上げて、いつか来る大リーグでのバッターボックスに備えよう」という気持ちで一生懸命素振りをしていた。

しかし、当たり前のことだが、素振りをしていても、大リーグでホームランを打つことはできない。

その理由はシンプルで、打席に立っていないからである。

メルカリでなにをしていたのか

メルカリでもまた、US担当→JP担当→話題のメルペイ関連業務と、大変にいろいろな機会を頂き、最終的にメルカリUSで9ヶ月、メルカリJPで1年と9ヶ月の期間を過ごすことになった。

それぞれのステージで、これまでのモノの考え方が、いい意味で覆される経験をし、躓くたびに、「なにくそ」という気持ちとともに知的好奇心、探究心が満たされる2年半だった。

アサインは念願のメルカリUS

転職時の思いもあり、もちろんメルカリUSのアプリを担当するプロダクトマネジャーとしてメルカリに入社した。

f:id:kyosu-ke:20190214025824j:plain
入社初日に撮ったエントランス。タイプロゴが旧ロゴ

当時はほとんどのリソースをUSアプリに振り切っており、僕も東京オフィスから、USアプリを開発するチームへの配属となった。

余談だが、入社の翌日にメンター兼上長がKR0案件(全社プライオリティトップの超重要案件)にアサインされ、「明日から1ヶ月アメリカ出張になったから、あとよろ!」って感じで放置プレイ セルフOJTの機会をいただき、これがGO BOLDか(そうじゃない)と思ったことを覚えている。

メルカリUSでは、検索周りの改善、オンボーディングの改善、アプリの下タブ化(ハンバーガーメニュー→タブバー)、ホーム改修、ファセットを利用した絞り込み検索など、様々なチャレンジをさせてもらった。

この頃は今以上に技術の「ギ」の字もわかっておらず、多くのひとに迷惑をかけながら仕事をさせてもらい、根気よく教えていただいた結果、今の自分がある。

f:id:kyosu-ke:20190214024830j:plain
JP アプリの下タブ化に先行すること丸2年、USは下タブ化されていたのだ

メルカリJPへの異動

そこからJPへの異動が決まり、メルカリチャンネルの0→1の立ち上げ、スマートフォンに特化したカタログ出品や、検品業者を挟んだ新取引スキーム「あんしんスマホサポート」、決算説明会で取り上げられたカテゴリーグロース戦略の一端を担うなど、ここでもあげるとキリがないほど機会を頂いた。

特にメルカリチャンネルは上海出張から帰国するやいなや、企画→デザイン&仕様策定→開発→ QA→リリースまで含めて全行程2.5ヶ月でリリースしており、タレント起用の大型プロモーションも仕込んであり、スピードもクオリティも求められるプロジェクトだった。

f:id:kyosu-ke:20190214010844p:plain
※本当に最高のプロジェクトだった

引用元: 本日夜10時~「ガイアの夜明け」でメルカリの舞台裏に密着! #メルカリな日々 2017/10/10

また、スマートフォンのプロジェクトでは、自分の未熟さから、企画から0スタートをしなおすという失敗もあり、学びが多かった。

もともと、個人最適を突き詰めたい宗派に属しているのに、なぜか全体非最適が許せない性格で、障害対応やら、組織の狭間におちるルーズボールを拾って過ごしていたら、社内に関わる人も増えてきて、気づくと最後の9ヶ月はマネジャーとして過ごしつつ、メルカリ本体の数字を伸ばすチームと、メルペイをメルカリに組み込むチームのマネジャーを兼務していた。

ここでも見える世界がぐっと広がり、自分でも施策を持ちつつも、チームのスループットを上げる思考に時間を割くようになった。

メルカリでのマネジメントの経験を通じて、当然様々な学びを得ることができたが、書けないことも多いのと、さらにものすごく長くなるので割愛。

メルカリで得たもの

USチーム、JPチーム両方での経験を通じて、この記事であげたような、プロダクト・サービス・カスタマーに向き合う姿勢を学んだ。

kyosu-ke.hatenadiary.jp

このブログでの発信含め、これらはほぼ全てメルカリで得たものと言っても過言ではない。

日々発生する、BIチームとのやりとりからは、どうKPIを扱い、どう課題を設定し、解決策にアプローチするか、といった問題解決の基礎的な部分を学んだ。

このBIチームと問題解決を通じて、その考え方をINPUTし、また別の課題でOUTPUTしてフィードバックを得るというループはPdMにとっての最大の福利厚生であったと思う。

特に、この記事のお二人にはめっちゃ学ばせてもらった。メルカリでこの2人と働くと、企画者としての第三の目が開眼するので超絶オススメ。

一緒にモノを作る大切な仲間である、エンジニア、デザイナー、QAのみなさんからは、ものづくりの楽しさ、お客様に触っていただけるモノを世に出すことの、苦しみ・喜び・楽しさを教えてもらった。

f:id:kyosu-ke:20190214025131j:plain
ほんとに愛しかない。

また、プロダクトチームの良さがフォーカスされて伝わりがちだが、むしろそれ以外のPR, CS, リーガル, 人事, BizDev, マーケ, ファイナンス その他のコーポレート部門の仕事こそ神がかっていて、「プロダクト以外の面でのサービスの伸ばし方」のベストプラクティスを学べたのは今後の大きな資産である。

内側から見たメルカリ

人材のブラックホールと呼ばれているだけあって、各職種でトップクラスのプロプレイヤーがたくさんいる。 そういった人たちと働くのは本当に楽しく、吸収するものが非常に多い。

本来USをやりたかったのでJPに異動になったとき「転職時の本来の目的とズレるし、モチベーション続かないのでは…」と一瞬危惧したのだが、そんなものは全くの杞憂で、非常に楽しく学び続け、気づいたらUSへの拘りは小さくなっていた。

それくらい、毎日が楽しいのである。

組織の特徴として、よく挙げられる点だが、やはり下記は外せないし中から見ててもそのとおり。

  • 風通しがよく、積極性と論拠がしっかりあれば、のびのびとなんでもやれる空気がある
  • プロダクトを愛し、お客様のほうを向いている人が多い
  • 年齢層も比較的高めで、落ち着いて仕事に集中できる
  • 働き方もフレキシブルで、子持ち家庭にとってかなり働きやすい

控えめに言って最高な環境だった。

では、なぜ辞めるのか?

なぜそんな最高の環境にいながら、辞めるのか。

ズバッと一言で理由を言い切るのは難しいのだが、次の挑戦として、医療ドメインでVertical SaaSを提供する会社、株式会社ドクターズプライムを友人と共に創業した。

救急車のたらい回しをなくすサービスで、救命救急の領域で病院と医師をつなぐ橋渡しを行う、SaaSプロダクトを提供する。

医療領域のバーティカルSaaSで、プロダクトの類型としては、マッチングプラットフォームに分類される。

広義での医療系スタートアップはたくさん出てきているが、「医療」と一口に言っても、ドメインをよく見ると、DNA解析、創薬、ヘルスケア、予防医学、遠隔診療、電子カルテ、診断領域と切り口は様々である。

救急救命の現場もまた、解決すべき課題が多く、構造的な問題により、失われている命があることは否定できない。

なぜそれをやるのか?

ソーシャルゲーム → CtoCマーケットプレイスと来て、なぜ救命救急のSaaSを創業するのか?

うまく言葉がまとまらないのだが、いくつかの理由がある。

2人の祖母の死と病

先週末、母方の祖母の三回忌があった。

2年前の2017年の2月、アメリカ出張中に、母から電話で話したいという旨のLINEが来た。

当時SF市内にあったオフィスで、ユーザーインタビューを終えた後に電話をかけると、母方の祖母が亡くなったと聞かされた。

急遽、帰国して最後の別れを告げた。

そのときに、人はいつか死ぬ、という当たり前のことを理解した。

また、時を同じくして、大学を卒業するまで一緒に暮らしていた父方の祖母が胃癌の宣告を受けた。

僕にとっては追い打ちをかけるような、急な知らせで、最終的に彼女は胃の殆どを切除し、情報の非対称性と無力さを強く感じた。

この経験に、人の死、命の有限さ、それを前にした無力さを突きつけられた。

パートナーの存在

一緒に会社を創業したパートナーがいる。

代表取締役を務める彼は、当時通っていた中高一貫校の同級生である。

青春時代を共に過ごし、のちに聖路加国際病院という、救命救急で有名な病院の救命救急リーダーを務めた後、医療系ベンチャートップセールスとしてビジネスの現場に立っていた。

彼と久しぶりに再開し、会話を重ねる中で、気兼ねせずに率直に話ができる間柄でありながら、自分のプロダクトを作りサービスを運営していく知識・経験と、彼の医療ドメインの知識とセールスの経験が、お互いに補完し合える関係性であることに気がついた。

僕は自然にしていると、他人を意識し、気を遣い、萎縮して、忖度してしまうような人間なので、ナチュラルに遠慮・気兼ねせずに思ったことが言える関係性には非常に助けられている。

メルカリでの体験と着想

最後に、メルカリでの経験も、この意思決定に影響を与えており、背中を押されている。

「モノを欲しいと思う【需要】に対して、モノを渡して対価を得る【供給】を、【直接マッチ】させる」というメルカリの仕組みを抽象化して考えると、救命救急の分野にも応用ができることに気がついた。

メルカリというサービスの企画・運営経験が、自分のプロダクト・サービスの輪郭をはっきりさせてくれたと言える。

また、運良くメルカリ上場の瞬間に立ち会えており、全員が一体感をもって生み出す、その熱量を目の当たりにして、このような組織と瞬間を自分たちの手でも作りたい、と感覚的に思ってしまったことも、この決定に少なからず影響を与えている。

ぐちゃぐちゃした思いの中で、ひとつ明確に言えること

入社の前からその先まで、とりとめもなく、長文を書いてしまい、ほぼ自分史みたくなってしまったが、メルカリは掛け値なしに素晴らしい環境で、先日リリースされたメルペイをはじめとして、仕込んでいる種もあり、これからも輝く場であり続けると思う。

「それでもなぜ辞めるのか?」という問には、きれいに回答できないのだが、ここまで述べてきたような色んな思いが綯い交ぜになって、こうなっている。

そんな中でも、明確にひとつ言えるのが、僕自身も30歳になり、3人目の子供が生まれようとしている中で、「はっきりとした形で世の中に対してポジティブな変化を起こすこと」を、自分自身に対して求める気持ちが強くなっているということだ。

世の中の構造を変え、人々の生活をより良くすることで、子どもたちの世代に対して、自分自身に対して、「自分たちの手で、世の中をより良い方向に変えた」と誇れる仕事をしていきたいと思っている。

最後に

一緒に働く仲間を募集しています!

職種としては、フロントエンドエンジニア、バックエンドエンジニア、デザイナーを募集しています。

サービスの状況としては、ベータ版としてローンチしているモバイルwebを中心に、プロダクトの磨き込みをしており、一通りの機能が整った段階でiOS/Android等のネイティブアプリを展開していく予定です。

すでに数十の病院さまと、数百の医師の方々にご参加頂いていて、現場のニーズも強く、手触り感のあるかたちで順調な滑り出しをしています。

技術スタック的にはこんな感じです!

Frontend

  • TypeScript
  • React
  • Almin
  • Sass
  • Webpack
  • Jest
  • Prettier
  • Yarn
  • Netlify

Backend

Programing Language

  • Go

Public Cloud

Logging, Analytics

  • Stackdriver Logging
  • BigQuery

Other

  • Serverless

少しでもピンと来た方は、まずは副業からでも良いですし、とりあえずお茶・寿司・肉でもOKですし、インターン募集しています。

そのほかの職種についても随時募集しているので、下記twitterのDMか、採用情報ページまでお気軽にご連絡ください!

twitter: @kyosu_ke

与えてもらった機会と、関わっていただいた皆さんすべてに本当に感謝しています。

めちゃくちゃお世話になりました!

こういう会社を作りたいと思える、最高の会社でした!!

ありがとうございました!!

f:id:kyosu-ke:20190214011820j:plain
メルカリでの最後の一枚

ものづくりのプロトコルの作り方と大切にしている29の価値観

これはなにか

プロダクトを作るにあたって私が大切にしている29個の価値観を列挙したものだ。

経験上、チーム内でものづくりの前提となる価値観が揃っていると無駄な議論が減り、物事が進みやすい。 私は「ものづくりのプロトコルを合わせる」という表現を使うが、これが合っていると、ものづくりが非常にスムースになる。

この記事ではどうやって、この「ものづくりのプロトコル」の作り方と、事例として私が大切にしている価値観を、自分用のメモがてら書き出した。

ものづくりのプロトコルの作り方

価値観の抽出の仕方

自分が大切に思う価値観を抽出する前提条件として、下記の目線で書き出している。

  • 自分の中で当たり前となっているものもすべて書き出す
  • プロダクトの定義は、プロダクト≒サービスとなるような広義の意味とする
  • プロダクトそのものでなくても、プロダクトに関係する領域であれば、広く書き出す
  • チームや組織のあり方は扱わない

ブラックボックスになっている価値観を可視化し、判断基準をあわせることが目的なので、言うまでもないように思えることのほうが、むしろ大切である。

また、組織論を含めると「プロダクトの意思決定の基準となる価値観」からズレてしまうため、扱わない。

どう決めるかよりも、決定の基準を揃え、スムースなプロダクトづくりを行うための「value」を揃えることが重要である。

※行動規範・判断基軸になるという意味では、組織におけるvalueの位置付けに相似する

すり合わせ&プロトコル

チームメンバー各自の大切にしている価値観を書き出し、すり合わせを行う。

人数規模によっては、中心人物の価値観をベースに、メンバーの声を聞きながら加筆修正を加えていく形でもよいだろう。

ゼロから立ち上げ、これからチームメンバーを集めるフェーズの場合は、先にチームで大切にしたい価値観を定義しておくことで、ミスマッチが防ぎやすくなるだろう。

プロダクト作りで大切にしている29の価値観

最後に事例として、私が大切にしている29の価値観をあげる。一度ですべて書きあげられるものでもないと思うので、今後メンテナンスしていきたい。

粒度やスタイルなど、作成の事例として参考になれば幸いである。

ユーザーファースト

  • 01. ユーザーにメリットのないアクションを取らせない
  • 02. マーケティング活動もユーザーメリット有りきで考える
  • 03. 運営・開発の都合をユーザーに押し付けない
  • 04. ユーザーに考えさせない
  • 05. ユーザーが受け身でも完結できるようにする
  • 06. とにかくシンプルに、わかりやすく直感的に
  • 07. 論理的な正しさ < ユーザーの感情面での正しさ
  • 08. ユーザーの期待値をコントロールし、ユーザーの期待を裏切らない
  • 09. 規約やルールで縛らず、自然とそうしたくなる仕組みを
  • 10. ユーザーに会いにいく

分析や狙いどころの考え方

  • 11. 穴の空いたバケツに水を入れない
  • 12. すべては検証
  • 13. 分析は意思決定を行うためにある
  • 14. 主観と客観を分離して考える
  • 15. ファクトの上で議論する
  • 16. 相関で短絡せずに因果をさぐる
  • 17. データで証明された命題の成立理由を言語化する
  • 18. Vanity Metrics < Actionable Metrics
  • 19. Squeeze Toyの概念: ひとつずつフォーカスする

施策の考え方

  • 20. オペレーションありきの成立は成立ではない、仕組み化する
  • 21. オペレーションは尊いが、オペレーションに逃げるのは悪
  • 22. 小さく検証してから仕組み化する
  • 23. すべての方針や仕様に狙いを持つ
  • 24. ソリューションを考えるのはユーザーの仕事ではない
  • 25. 成功するか学習するか
  • 26. まず最速で価値提供して、プロダクトの価値を感じてもらう
  • 27. 最小単位でリリースして、とにかく届けてフィードバックを得る
  • 28. 体験としての早いは正義
  • 29. 仕様のひとつひとつに優先度をつけ、いつでも切れるようにする

まとめ

ステークホルダーの多いプロダクトづくりでは、前提の価値観が揃わないことによる無駄なコミュニケーションや議論が、プロダクトの速度を落としていく。

この枠組を利用して、意思決定の前提となる価値観を可視化し、すばやくユーザーに価値を提供していきたい。

PdM職の細分化 3つのロール

これはなにか

Product Manager Advent Calendar 2018の16日目の記事です

この記事は、定義が曖昧なPdMという職種の役割を、構造的に分解した記事である。

ソフトウェアエンジニアに様々なサブカテゴリーがあるように、PdMも細分化されたサブカテゴリーがあると考えており、本記事ではPdMのサブカテゴリーを構造的に分解する。

なお、ハード面への言及に限定し、リーダーシップなどソフト面については扱わない。

誰に向けたものか

この記事はこんな方に読んでもらうことを想定している。

  • PdMらしき仕事をはじめた駆け出しの企画職
  • PdMを育成する立場になった新任マネジャー
  • 役割に合うPdMが採りたい採用担当者

解決したいことと目的

この記事では、職種としての全体像が不透明なことに由来する、下記を解決することを目的としている。

  • PdMという職種にどんな方向性があるかわからなく、将来設計やキャリアの指針が定まらない
  • いまの業務が全体のどこに位置するかわからなく、徒労感がつのる

前置きが長くなったが、本編に入る。

PdM職のロールマップ

PdMをロール別に3つのサブカテゴリーに分解し、企画のバリューチェーンの上流から下流までマッピングすると、下記の図のようになる。

また、ここでは企画に関連する他専門職種についても、その相対的な位置を示している。

f:id:kyosu-ke:20181216110857j:plain
横軸に3種のロールをおき、縦軸に企画の進行過程をとる

ロールは3種あり、詳細は次項目以降で詳述する。

企画のバリューチェーンは、調査分析〜リリースするまで、企画の流れを上から下にマップしたものである。

また、企画のバリューチェーンについては下記の記事に詳しく書いている。興味のある方はこちらからどうぞ。

kyosu-ke.hatenadiary.jp

また、役割を便宜上3つの職種ラインに分けているが、実際の現場では複数の役割を兼ねて働くことのほうが多いため、一人のPdMが必ずしも一つの役割しか持たないというわけではない。

PdMの3つのロール

ここからは、前出の図に則って、PdMの3つのロールについて詳述する。

機能プランナー | Feature Planner

このロールは新規機能の追加、既存機能の改善、など機能を企画する役割だ。

新規アプリの立ち上げもこのロールに含まれる。 PdMといって、真っ先に思い浮かぶのはこの役割だろう。

具体的には、ユーザーの課題やニーズを捉え、その課題やニーズに対して、適切な解法として機能を考えて、ユーザーに届けるところを担う。

アプリ内マーケター | In-App Marketer

このロールはサービス内でのキャンペーンやコミュニケーション設計を企画・実行する役割だ。

具体的には、ポイント配布キャンペーンやセール等のインセンティブキャンペーンや、Push通知やお知らせ配信などのノンインセンティブコミュニケーションを中心として、ユーザーセグメントに応じた適切なコミュニケーションを図ることを担う。

コンテンツマネジャー | Contents Manager

このロールはサービス内のコンテンツを更新、拡充させていくことを担う役割だ。

具体的には、オウンドメディアの運営や、メディアであれば記事の編集、動画系サービスであれば番組企画などを担う。 ECサイトでのトレンドランキングやメルマガ運営や、CGM系のサービスであれば、コンテンツを投稿してもらうためのトピック運営などもここに該当する。

3つのロールと企画工程によるタスクマップ

ここまで、ロールマップの説明を展開してきたが、これらの理解をベースにもう一歩、構造化を進める。

PdMの業務は3つのロール x 企画工程でマッピングすることができる。(※図内の①〜⑨はイメージを掴むための一例である)

f:id:kyosu-ke:20181216213441j:plain
PdMのタスクは3つのロール x 企画工程によるマッピングで定義できる

企画工程はシンプル化するために3つにまとめているが、任意の切り方で捉えて構わない。

そして、このマッピングを利用して、下記の3点を考えることができる。

  • [過去]これまでの業務経験は、マップのどこを埋めるものだったのか?
  • [現在]いま取り組んでいる業務は、マップのどこに当てはまるのか?
  • [未来]これからどんな業務を選択し、マップのどこを埋めたいのか?

今後どういった方向を目指すのかを考えた上で、このタスクマップを使うことで、これまでの経験を棚卸しし、いまの業務に意味を与え、今後の業務選択の指針を作ることができる。

こういった整理により、曖昧で見通しの立ちにくいキャリアイメージを構造的に捉えることができるのではないかと思う。

キャリアパスのあり方

最後にほんの一例に過ぎないが、キャリアパスについてまとめる。 上述のPdMの3つのロールでの経験を積んでいくと、掛け合わせで新たなキャリアパスが見えてくる。

1/ グロースハッカー | Growth Hacker

上記の分類に従えば、アプリ内マーケターとしての経験および、機能プランナー、コンテンツマネジャーとしての企画設計の経験が必要なキャリアであろう。 加えて、ユーザー獲得マーケティングの経験もあると立体的に業務が遂行できるだろう。

2/ UXデザイナー | UX Designer

機能プランナーを経て、定性調査への適正や興味が強くある場合、ユーザーニーズを紐解き、それを実現する設計に注力するためにUX Designerになるという道がある。 ユーザー体験を作るために、インターフェース設計が必要になる場面が多いので、ユーザーインターフェース(UI)への深い理解と経験も必要になる。

3/ プロダクトオーナー | Product Owner

プロダクトのすべてを司る "Mini-CEO"としての役割である。 プロダクトによって必要度合いの濃淡はあれど、このキャリアのためには、前述のPdMの3ロール全領域に精通する必要があるだろう。 またそれだけではなく、オペレーション構築・最適化、事業計画・会計、組織開発・採用等も重要なため、それらの知識と経験も同時に必要になる。

まとめ

エンジニア、デザイナー、会計、マーケティング、リーガルなど他職種は学問として存在するが、PdMには学問が存在せず、俯瞰して体系的に全体像を学ぶ機会は少ない。

私自身が暗闇の中を進む中で、手探りで描いてきた地図であるが、だれかの役に立つと幸いである。

プロジェクトマネジャーからプロダクトマネジャーへの転向に必要な3つの変化

これはなにか

本記事はプロジェクトマネジャーがプロダクトマネジャーに転向する際におさえるべき重要な点をまとめたものだ。

私自身、プロジェクトマネジャーからプロダクトマネジャーへと転向しているが、その際にいくつか重要なポイントが存在した。 この記事が、同じようにプロジェクトマネジャーからプロダクトマネジャーへ変わったばかりの方や、これから転向しようと思っている方の助けになれば幸いだ。

以降、プロジェクトマネジャーをPjM、プロダクトマネジャーをPdMと略称表記する。

PdM は PjMの延長線上にはない

f:id:kyosu-ke:20180916000545j:plain

字面が似ているせいか、「PdMはPjMの延長線上にある」と考えている方も一定数いると思う。(私自身そう思っていた)

しかし、そうではない

共通する部分はあるが、PjMとPdMでは、それぞれの役割に求められるものが異なるため、転向する場合、3つのポイントについて大きく認識を改める必要がある。

  • 実行の担保 → 結果の担保
  • 管理・調整 → 方針・意思決定
  • 開発現場視点 → ユーザー視点

まずは、議論の土台となる、PjMとPdMそれぞれの役割について記述し、のちに各ポイントについて詳述する。

PjMの役割と主な業務

役割

PjMは割り当てられたリソースで期日までにアウトプットを出すことにコミットする役割である。 よって、プロジェクトの進行上の課題に対してのアクションがメインになる。

たとえば、新規プロダクトと運用プロダクトでは下記のようなミッションを持つことになる。

  • 新規: プロダクトを期日までにリリースすることに責任を持つ
  • 運用: プロダクト改善施策を期日までにリリースすることに責任を持つ

主な業務

PjMの主な業務としては下記が挙げられる。進行の管理および調整ごとの占める割合が多い。

  • 開発進行管理
  • 仕様の調整
  • 工数アサインメントの調整

PdMの役割と主な業務

役割

一方、PdMの役割は、プロダクトが生み出す成果にフォーカスしている。 プロダクトをリリースした先にある「成功」を担保する役割である。

当然、一口に「成功」と言っても、定義がなければ判断がつかないため、「なにが成功であるか」を定義することも重要な役割の一つである。

例えば、新規プロダクトと運用プロダクトでは下記のようなミッションを持つ。

  • 新規: プロダクトがPMFに到達することに責任をもつ
  • 運用: プロダクト改善施策により目標KPIを達成することに責任を持つ

主な業務

よって主となる業務としては、方針決定・意思決定が中心になる。 また、意思決定を行うにあたり、必要な情報を集めるための分析も広義として当てはまる。

  • 戦略方針の決定
  • 仕様の策定
  • 分析・振り返り

3つのポイント

前置きが長くなったが、ここからPjM → PdMに転身する際の3つのポイントについて詳述する。

f:id:kyosu-ke:20180915235438j:plain

実行の担保 → 結果の担保

5W1Hでたとえるなら、When, HowからWhat, Whyへの視点の変更である。

PjMは担当しているプロジェクトを期限内(When)に限られたリソースで(How)させることに責任がある。 一方PdMは担当プロダクトの成長に責任があるため、実行だけでは役割を果たせない。

実行レベルから業務領域をストレッチして、実行の前段階に存在する、なにをやるのか(What)、そしてそれはなぜか(Why)を明確にしなければならない。 また、最後にその結果がどうであったのかを分析により確認し、次のWhat, Whyにつなげていく。

管理・調整 → 方針・意思決定

上記の責任領域の変更に伴い、帳尻を合わせや整理からロードマップ作成、製品仕様の意思決定にウェイトをよせる必要がある。

PjMであれば、進行に問題が合った場合に、仕様のスコープ削減を提案したり、リソースを要求するなど、整合性が取れない部分の最終意思決定をエスカレーションできる。

一方でPdMになると、そのエスカレーションを受けて、意思決定を行う側になり、理想と現実のギャップに対して、最終的な結果責任を引き受ける役割を担う。

開発現場視点 → ユーザー視点

PdMはより視点をユーザーにフォーカスさせる必要がある

PjMの視点では、いかに期待された機能を、期待された期日に出すかという視点になるため、最終的には期待値を調整することで整合性を保つことができる。( ex. 仕様のスコープを削ってもらう、リソースを追加してもらう、期限を延ばしてもらう)

よって、要求仕様とリソースがマッチしない場合に、収めることを優先して考えるインセンティブが働きやすい。

一方、PdMの視点では、ユーザーに届ける価値が全てとなるので、開発している機能の中心的な価値がなにかを見極め、仕様削減や必要に応じたリリース延期等の意思決定を行う必要がある。 「収めること」ではなく「どんな価値を届けるか」にフォーカスする必要がある。

PjM から PdMになるには

ではPjMからPdMになるには、具体的にはどうしたらよいのか?

主に3つのパターンがある。

  • 1) 急拡大中の組織に入る
  • 2) 新規立ち上げの組織に入る
  • 3) 既存のチーム内で転向させてもらう

1) 急拡大中の組織に入る

急拡大中の組織では、関わる人が増えていく中で、ステークホルダーをまとめ上げながら、実行を推進する力が重宝されるタイミングがある。

また、業績がよく、急拡大している組織であれば、やることが山程ある状態が想定されるので、ポジションへのニーズが強い可能性がある。

2) 新規立ち上げの組織に入る

設立間もないスタートアップ等の組織の場合、人材ニーズによっては近接領域であるPjMからPdMへ転向するチャンスが開ける可能性がある。

採用力のある組織の場合は、PdM経験のある人が採用できてしまうため望みは薄いが、一般的なスタートアップであれば道はあるはずだ。

3) 既存のチーム内で転向させてもらう

自社内や既存チームであれば、PjM業務で組織内の信頼・評価を重ねることで、チャンスを掴める。

所属する組織のカルチャーにもよるが、可能であればこの選択肢が一番無難とも言える。 なぜなら組織内評価を引き継ぐことができ、これまでのステークホルダーとの関係値をもとに成果を上げやすい状態で始めることができるからである。

まとめ

PjMとPdMは似ているようで、実は全く異なる役割を担っており、転向する際には大きな視点の変更が強いられる。

また、PdMはPjMの延長線上にはないため、転向を目指す場合は戦略的に行動を起こす必要があるといえる。