10→100フェーズにおける組織におけるプロダクトマネージャーの役割とは
はじめに
10→100フェーズのプロダクトに関わる中で
- プロダクトマネージャーの役割とは？
- プロダクトマネージャーとして資質を伸ばす、成長するには？
というのを最近考えていて、そのまとめです。
プロダクトマネージャーの役割とは？
プロダクトマネージャーの役割とは何なのか？ネットで調べたり、色々な人がよく言うのは
- ミニCEO
- 売れるプロダクトを見つけ出す（考える）人
- プロダクトの全てに責任を持つ人
とかが多いかなと思います。 いずれも プロダクトの企画〜運用、全てに責任を持つ というコンテキストが見え隠れするのですが、現場で働く中であんまりしっくりきていなくて、理由を考えてみました
その１ プロダクトの全てに責任を持てない
プロダクトの全責任を持てるというのは、結構限定された状況じゃないかなーという気がしています。その状況とは
という場合だと思います。
まず成長ドライバーがテクノロジーではなく、コンテンツ（動画、記事など）や営業パワーだったりすると、はたしてプロダクトマネジャーがそこまで権限を持てるのかという疑問があります。
当たり前ですけど、成長ドライバーとなる要素をハンドリングする人が最も権限を持つべきで、そこがテクノロジーでない場合、全責任を持つべきではありません。
もちろん、「じゃあ、どこまでがプロダクトなのか？」という疑問ももちろんあり、例えば、下記のような要素とかはグレーゾーンですね
- コミュニティ
- サポート
- セールス
- マーケティング
- 説明文やドキュメント
- 調達
- リソース
- 広告
- コンテンツ
組織、事業の状況と何よりプロダクトマネージャーの資質、志向性によって範囲は変わりますよね
ちなみに上記とかは全部ひっくるめてプロダクトだろ！いう論理もあると思うのですが、そういう時はプロダクトマネージャーでなくプロデューサー、事業責任者というロールの方がスッキリします。
※なおプロダクトマネージャーがアジャイルでいうプロダクトオーナーに近い（要はバックグランドがエンジニア）という前提でバックログとして開発案件の管理が主業務という前提で書いています。
その２ 売れるプロダクトを見つけ出すケースはそんなにない
本当に昨今のスタートアップ企業が発信力を上げているというのもあり、基本的に全て０→１前提（０からプロダクトを開発してリリースする）で語られることが多いのですが、現実世界で圧倒的に多いのは既存の事業なりプロダクトがあって、その中の１つのモジュールを新規にリリースする場合だったりするんですよね
いわばPMFには到達していて、そこからエンハンスするケース（といっても完全に延長線なわけではなく、ターゲットは違ったりしますが）
PMFに向けてひたすら全力で仮説検証を回すというよりかは、どちらかというと持続的な成長のための仕組みづくりとかの方が優先度高かったりします。
組織もプロダクトと考える https://techblog.timers-inc.com/entry/org_as_product
プロダクトマネージャーとして、どこに責務を持つか？
基本の形は下記だと思います
個人的にプロダクトマネジメントのバイブルだと思っているInspiredに書かれたことを参考にしており
- プロダクトマーケティング:製品の発信が責務
- プロダクトマネジメント:製品のプロフィール決めるのが責務
になるのかなと
自分なりの解釈ですがプロダクトのAARRRモデルにおいて
- Acquisition(ユーザー獲得)
- Referral(紹介)
においてプロダクトにとっての成功を定義して、実行するのがプロダクトマーケティング
- Activation(利用開始)
- Retention(継続)
- Revenue(収益の発生)
においてプロダクトにとっての成功を定義して、実行するのがプロダクトマネジメント
と考えるとイメージしやすいかと思います。
事業として実現したいことがあって、その手段がプロダクト、上記２つだけだとそこに責務を持つ人がいないので、 上位にプロデューサーがいるという構図になります。
この基本形がありつつ
- プロダクトの性質
- 本人の資質
- 組織的な成熟度
によって兼務したりが発生するんだと思います。 （スタートアップとかだとほぼ例外なくプロデューサーとプロダクトマネジメントが兼務）
なので、最低限
- プロデューサーとコミュニケーションした上で、事業を理解してプロダクトのWhy,Whatを決めることができる
- プロダクトのWhy,Whatを伝えて、エンジニアが納得感を持って開発を進められる状態にする
がプロダクトマネージャーの役割となります。
そこから資質と志向性によって、マーケティングにも手を出したり、事業戦略にも手を出したりしていくわけですね。
そして、このWhy,Whatを決める部分で いかに引き出しをたくさん持って、インパクトの強いプロダクトのWhatを定義できるか というのが プロダクトマネージャーの腕の見せどころかと思っています。
この記事のアートとサイエンスの掛け算という表現がとても気に入っています https://questpm.hatenablog.com/entry/2018/10/08/assign_priority?utm_source=feed
プロダクトマネージャーとして資質を伸ばす、成長するには？
シンプルに 打席に立つ回数を増やす 以外にないと思います。多彩な状況に置かれて判断を下していくことで 引き出しが多くなり、判断軸も出来上がっていくのだと思っています。
ということもあり、とにかく副業でもサイドプロジェクトでも、１つでも多くのプロダクトに関わってWhatを定義するということを最近意識してやっています。
ただ、実行している中でどういう打席に立つか というのは結構重要で プロダクトとしての
- 仮説
- 検証
- 検証による学び
を１周しないと打席としてはノーカウントかなと思います。
要は
- リリース前にバックログの整理や推進だけやって、リリース後は別のプロジェクトに行く
- リリースしてないけど、ユーザーインタビューとかして仮説検証している
とかだとノーカウントということですね。
必ずしもプロダクトの一番最初の企画から関わる必要はないと思いますが、とにかくリリースして、リリース後の反応を元に試行錯誤を繰り返さないと何の意味もないと思います。 より高次元の大きな仮説に関われるので、企画の初期段階からいるに越したことはないかと思いますが
リリースすることの重要性 http://yuzutas0.hatenablog.com/entry/2018/12/25/170000
さいごに
自分もまだまだですが、プロダクトマネージャーって組織だったり、事業だったりに応じて求められるスキル、役割が変わるので、明確な定義はないと思っています。 とはいえ皆悩んでいるのは、Google先生の結果からもある程度わかっているので、 こういう場合は〜なタイプのプロダクトマネージャーが必要 というのがある程度パターンとして定義できるといいのかなと思っていたりします。
プロダクトマネージャー目線でAdobe Max2018参加してきた
先日ロサンゼルスで開催された2018年度のAdobe MAXに参加してきたので、その感想 自分はXDやイラレをバリバリ使ってデザイン起こすというよりは、ツールを使ってエンジニアも含めて、チーム内でどういったコラボレーションをしていくかに興味があり、 またプロダクトマネージャーとしてAdobeのプロダクト、ビジネスがどういう思想で行われているかも興味があったので、そこら辺をまとめました。
Adobe MAXとは
年に一度開催されるAdobeの新製品の発表を中心にしたカンファレンスです。
カンファレンスの特徴として基調講演以外にも
- 映画監督、アニメーターといった著名なクリエイターの講演がある
- ワークショップなどが豊富で、Adobeの社員と共にプロトタイプ作成、各種ツールの効果的な使い方を学べる といったコンテンツが用意されています。
キーノート
会場の様子。今年の来場者数は１万４０００人らしいです。
キーノート冒頭で
Adobeのこれからの方針として
クリエイティビティが人にも場所にも、手段にも縛られないような世界にしていきたい。
一部の専門的なクリエイティブだけが使えても意味がないし、デスクの前だけ使えるのでも不十分
インターフェイスもキーボードやマウスだけではなく、音声など多様なものを用意したい。
全人類のクリエイティビティを引き出すような製品を作っていきたい
というメッセージがありました。
それを受けて、Adobeの今後のサービスは
- ACCELERATE
- LIBERATE
- DRIVE の３つをコンセプトとして強く打ち出していきたいという発表がありました
以下それぞれの詳細です。
ACCELERATE
Adobeの製品を使った場合の作業スピードの高速化
具体的にはAdobe Senseiを使ったサジェスト、作業のアシストなどです。
ここ数年で強化されている点で、単純作業をツールが代行し、クリエイターが本来やるべきクリエイティブな作業に集中できるようにするというのを
今後もさらに継続していくというメッセージがありました。
LIBERATE
クリエイティブを場所、手段の制約から開放する
マルチデバイス対応により、いつでもどこでもAdobeの製品を使えるようにすることはもちろん、複数のツールを使う作業においては
単純にツールを切り替えてやるのではなく、異なるツール同士の機能をシームレスに使うことができるというものです。（PhotoShopとillustratorなど）
DRIVE
AR、音声インターフェイスといった新技術への対応
スマートスピーカーを始めとして次々と新技術が生まれていく中で、
Adobeの製品を使って作れるコンテンツも、進化していく技術に対応したものにしないといけないという方針です。
キーノートでもXDで作成したプロトタイプをスマートスピーカーをインターフェイスとして操作するデモや、ARコンテンツを使ったデモが行われていました。
個人的に、今回のカンファレンスで一番強く推されていたのはLIBERATEだと思っており
２０１９年に向けてAero,Rush,Geminiといった新製品が発表されたのですが、それらは全てデフォルトで
iPhone,iPad,PCのマルチデバイスに最適化されてリリースされます。
それぞれのプロダクトのデモがあったのですが、どれも「アイデアが思いついたら移動中など、どこでも制作できる。制作したものはリアルタイムでCreative Cloudにアップロードされるので、続きはデスクで」という価値をアピールしていました。
さらに新規のプロダクトだけマルチデバイスかなと思っていた所に、PhotoShop CC for iPadが発表されました。
どういうことかというとこれまで、３０年間積み上げてきたPhotoShopを機能はそのまま、iPadに最適化した全く新しいものとしてリリースするということです。
おそらく秘伝のタレ状態になっているレガシーなソースコードを置き換えていくのはエンジニア目線からしてもとてつもなく大変なプロジェクトではと思います。Adobeのマルチデバイスに対する本気さを感じました。。。
このプロジェクトについてはAppleとしっかり協力して進めているらしく、Appleのバイスプレジデントの方がゲストとして登壇し、両者のパートナーシップを強調していました。
PhotoShopの移行する機能の洗い出しの様子。わからないが大変そう、、、
AdobeとAppleが同じ壇上に立つ様子に、会場も大盛り上がりでした
ずっとFlash時代からAdobeとAppleの間にはある種の溝があったと思っていたので、感慨深い光景だなと思いながら見ていました。
セッションやワークショップなど、もうちょっとディープな情報はこちらにまとめました
プロダクトマネジメントにおける事業理解について、NETFLIXの事例を考えてみた
最近０→１以降のフェーズでプロダクトマネジメントする上で最も重要なのは事業、ドメイン理解だと思っています。
PMというただでさえよくわからない業務の本質は、
事業の価値や戦略を理解した上で、全体最適を維持する。 その上で、何かしらの専門性（エンジニアリング、グロースハックなど）を発揮して事業のHOWであるプロダクトを作って事業を加速させること
だと思っています。 それをするには、結局「この事業の価値は何だっけ？」、「今ビジネス的に何が最重要なんだっけ？」という問いに常に答えれないといけない訳です。
NETFLIXの最強人事戦略～自由と責任の文化を築く～
を読んで、そこら辺が書かれていて面白かったのでまとめます。
Googleとの企業文化の違い
イメージ的にNETFLIXと近い企業としてGoogleがあるなと思っていたのですが 読んでみると両者は根底の部分が違っていて
- Googleの事業はとても多様。そして採用ではメンバーの創造性を何より重視する。アイデアを出してもらい、それを事業にできるから
- NETFLIXは基本プロダクトが１つ。事業上必要なことが厳格に決まっていて、メンバーに高度な事業の理解と貢献を求める
どちらが優れているという話ではないのですが、NETFLIXは事業に対して必要な業務、人材の定義が徹底していると感じました
実際のエピソードとして、事業として検索に力を入れたいが、Facebook広告に固執する超優秀なエンジニアに対して、退職を推奨するという、、、 Googleとかであれば、配置転換などでやらせてもらえそうだなと
他にも象徴的なエピソードが
- 人事考課は時間のムダ。なぜなら事業KPIのどれにも紐付かないから
- 人事にも事業理解を求める。人事が事業理解をし、チームに必要な人材を採用する。事業が成功した時は「私があのチームを作った」と感動して号泣する
などが興味深かったです。
自由と責任と事業理解
本のタイトルにもなっている「自由と責任の文化」というのは、
- 組織として透明性が担保された状況（全従業員が事業の現状と今後の戦略について理解している）
- 事業理解をもとに自分のミッションの明確化（＝責任）
- ミッションを果たすために邪魔な制約は会社として全て取り払う（＝自由）
ということなのかなと解釈しました。
自分の好きな技術を何でもやっていいということでは決してなく、やるべきことは事業戦略として厳格に決まっている。 そこがスタートラインにあった上で、徹底的に情報アクセスのハードルを下げて、自由と責任を持って事業戦略に基づいたミッションにコミットできるということなのかなと
ここらへんは自分のPMとしてのバックグラウンドのバイアスが思いっきりかかっているので、あくまで１つの解釈として読んでもらえれば
従業員のモチベーションは不要なのか
後半で従業員エンゲージメントに対しても真っ向否定していて、「まるで従業員のやる気不足が原因のような言い方だ。やる気のない従業員を解雇して好業績になるなら、とっくに他のところも成功している」これは「なるほど」と思うところがある一方、かなりのパワーワードだなと 笑
この背景としては、すでに上述していますがNETFLIXはプロダクトは１つ、さらに事業としてのビジョン、やることを明確にしている さらにアメリカのジョブディスクリプション文化（総合職とかではなく、明確に職務が規定されている）とも重なって、 完璧に事業戦略〜１人１人のミッションがつながっているからで、組織マネジメントの１つの完成形だと思いました。
つまりは採用のタイミングで完全にミッションが事業戦略からの逆算で決まる＆人事、現場がそれを理解しているので求職者にブレなく伝えられている。 という前提になるので、モチベーションは関係ないと
日本だとそもそもジョブディスクリプションを厳格にできない、風土の問題も大きいし、そもそも厳格にしてしまうとポジションがクローズした時に解雇が発生するが それができないという事情があります。 事業理解など参考になる部分は多かった一方で、前提が違うので日本でそのままやるのは難しいなと感じました。
https://www.amazon.co.jp/dp/B07GWJCBVP/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
中小企業のM&A、留職事情について調べてみた
最近新規事業として大企業から中小企業に留職（留学の社会人版）する事業を検討していて、周辺事情について調べてみた
背景
日本に380万社あるといわれている中小企業は後継者不足がとにかく深刻。ざっと試算ではこの中で１００万社ほどが 社長が６０歳以上＆後継者不在だと言われている。当然この中には黒字企業も含まれている
中小企業のM&Aについて
上記のような問題があるので、ここ数年で中小企業と個人のM&Aが盛んになってきた。M&Aというと企業がやるもので 数百億のディールとかイメージしてしまうが、中小の場合は数百万レベルでM&Aできるものも多く存在する。 ただ当然だけど、購入しようと思っても個人が中小企業を探すの大変だから最近多くのプラットフォームができてきている。
あとはこの辺りのテーマについてドンピシャな本がある
要約すると
- 老後不安だろうし、頑張って資本家になろう
- とはいえ０→１企業は難しいしリスク高い
- 飲食店経営もレッドオーシャンでおすすめしない
- 後継者不足の中小企業を経営するのがおすすめ
- 中小は普段大企業で当たり前にやっているような業務効率改善（Excel使うとかのレベル）ができていないから、普通に大企業で働いて自然に身についたスキルで十分貢献できる
https://www.amazon.co.jp/dp/B07C21NBMM/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
事業検討について
事業検討していく中で、それなりのキャリアの人が中小企業で働くにしても、会計、人事とかの専門知識ないと厳しいかなーと思っていたのですが、中小の業務の実情が結構レトロそうなのでいわゆる真ん中くらいの普通の層でも大企業でしっかり業務プロセスの仕組みを学んでいれば中小企業で業務改善などで活躍できるかもというのは新鮮だった
本だと上のTRANBIとかM&A仲介サイト使って探すの進めてるものの、相当ハードル＆リスク高いと思うので、実際やる前に一度体験するという留職は中小側にもニーズありそう （実際、本でもリスク把握のためのデューデリジェンスと社員との信頼関係を作るためにまず２年位は役員で働くこと勧めている）
留職だと現状は大企業とベンチャーを結ぶこういうのがある。
留職考える上で難しいのは、派遣元企業、派遣先企業、社員のどこにピン留めするか。 それぞれのニーズ想定すると
派遣元企業
- 中間層派遣して、メッチャ優秀になって帰って来てほしい
- 最悪優秀にならなくてもいいから、さっさと退職させて代謝良くしたい
派遣先企業
- 大企業のノウハウ知りたい。業務改革したい
- 後継者欲しい
- お金はあんまりかけたくない
社員
- 経営者やってみたい（ここは老後ゆっくりしたい層と、暇だし肩書欲しいし働きたい層で結構違う）
- とはいえ年で老後もあるし、金銭的なリスクは最小限に押さえたい
上のローンディールとかは派遣元の「中間層派遣して、メッチャ優秀になって帰って来てほしい」にフォーカスしてる気がする（しかもメインターゲットは３０代）。 中小企業の後継者不足＆黒字倒産にピン留めするならどういう座組みがいいか要検討。
エンジニア組織における組織開発について
先日会社でこんな感じのイベントをやってきました
https://tech.recruit-mp.co.jp/event/post-16667/
ぶっちゃけ転職して今の会社に入るまでは組織活性、組織開発という言葉も知らずにひたすら
- 雑談大事
- 1on1大事
- メンター大事
みたいな戦略なき根性論みたいなことしかやってこず（それでも一定の効果は出ていたと思う）、しっかり組織開発について自分でも学んでみました。
イベントの趣旨として、実現したいのは開発組織におけるあらゆる知見がなめらかに循環する世界で、 中でもこのイベントの中でも参加者の１人が言っていて印象に残っているのがエンジニア組織は組織開発のsandboxということ エンジニア組織は規模もそれほど大きくないことがほとんどだし、エンジニア自身が勉強熱心で流行りに敏感だし、変化の許容量が大きいので最適だと、確かにその通り
ただ現状の問題として大体会社ごとに１つしかsandboxを持ってなく、そこへのcommitログが公開されておらず他社から見れないこと それにより、ある場所で起きているrevertとか、他の場所でも全く同じこと繰り返したりしてる ここらへんを循環できるようにしていきたいなと
最終的には別に他の会社のsandboxにcommitしてもいいと思うし、お互いのログを見せ合うことでかつてないほどお互いのコアな部分を知り合うことができると思っているので その関係値を利用した、施策とかが行えれば面白いなと思っています。
アジャイルについて最初に知るべきことだけをまとめてみた
今の副業してるところが本格的にフルコミットのエンジニアと学生インターン数名で開発組織を作ろうとしていたものの アジャイル開発について開発フローも何もかも全然わからんという状態だったので、 とりあえずアジャイルサムライとかScrum Boot Campとかエンジニア組織論への招待とかは読んでもらうとして
最初に知るべきことだけをまとめてみた。
- 歴史
- アジャイルに対する誤解
- 目指すべきところ、そのために明日からやること
という構成に
特にこだわったのはアジャイルに対する誤解のところ
これだけ色々なところでスタートアップやっているアントレプレナーやエンジニアがいる中で アプリの開発について色々聞いたことや、ちょっとググって色々な資料が出てきたりする。
大体開発やったことない事業サイドの人だと、それらの情報から間違った開発フローのイメージ持って 突き進んでしまうなと経験的に感じているので、歴史的経緯と誤解を解消して事業サイド、開発サイド もゼロベースでスタート地点を合わせてこれから皆でインプットして健全に議論しながら 進めていこうというところを目指してみた
https://speakerdeck.com/hikoharu06/aziyairudeiketerutimuru-men
GTmetrix使ってサイトのパフォーマンス改善した
これは何
ブラウザアプリをGTmetrixというサイトのパフォーマンス計測するサービス使って、速度面でのボトルネックを特定して解決した話
そもそもなぜやろうと思ったか
最近、SEOやらコンテンツマーケティングやらに興味が出てきて、グロースハック的なmeetupに行っている。 その中である人が、「グロースハックには色々施策あるけど、一番コスパのいい施策は速度改善」と言っていたのが印象的だった。 実際に自分がプロダクトオーナーやっているサービスで試してみた
実際やってみた
これが最初に計測した時
屈辱のF評価。。。。 どの項目が悪いか調べると
Serve scaled images: 必要以上に大きい画像を用意して、cssでサイズ調整している
Leverage browser caching: ブラウザキャッシュが有効になっていない
が問題なのがわかる。
なので、それぞれ
Serve scaled images: 画像のサイズ調整
Enable gzip compression: nginxでcss,javascriptをgzipするようにnginx.conf設定変更
Leverage browser caching: nginxで静的ファイルを30日間ブラウザキャッシュするようにnginx.conf変更（ブラウザキャッシュはブラウザ側の設定だけだと思っていたので、nginxにも設定あるの初めて知った）
結果が
喜びのA評価！！
まとめ
まだサービスが動くようになってから、数ヶ月ということもあり２〜３時間程度で対応できた。nginx周りで少し詰まったので、知識ある人なら１時間以内とかでできると思う ただこれが１年運用したとかになると、膨大な修正を入れなければならず、永遠塩漬けになる未来が見える。。。
持論だけど速度改善（にとどまらず改善系全般）は担当者がちょっと手が空いた２時間くらいで「やってみるか」という状態にいかに保つことが重要だと思う。
- マメにリファインメントして、課題の粒度を細かくしておく
- 計測方法、修正方法の確立
- チームの文化（空いたらその分機能開発ではなく、改善に力を注ぐ）
のを常に実行しようというのが改めて身にしみた
