hikoharu's PM blog

プロダクトマネジメントについて考えていること。twitter: @hikoharu06

プロダクトが進捗していないと感じた時の戦い方

f:id:hikoharu06:20191217200546j:plain

この記事は Product Manager Advent Calendar 2019の18日目 です。

はじめに

Yamotty氏の素晴らしい記事に触発され、 ストラテジーと実装の一致を保つのが困難な状態、つまり プロダクトに関わる負債のせいで進捗しづらくなった時に どのように戦っていけばいいのかを掘り下げていきます。

スタートアップの強みはストラテジーと実装の一致

早さが生まれる理由は「ストラテジーと実装が一致しているから」だと考えている。
逆に言うと、これらが一致していない場合、早さは生まれない。
正しい戦略が、組織や技術的負債のために実行されなければバツ。
逆に素晴らしいテクノロジーを扱えるチームがあったとしても、間違った戦略で活用してもバツ。
いわゆるプロダクトマネジメントは
「ストラテジーと実装の一致状態を継続させる」という機能なのだと思う。
狙うマーケットが変わったり、ストラテジーが変わればプロダクトが変わる必要がある。
プロダクトの原動力は人なので、人に納得性を植え付けるか、人を替える必要がある。

多くの場合、プロダクトのエンハンス、組織拡大していく中で段々乖離が大きくなっていき、

  • プロダクトでの実現が事業戦略のスピード感に合わない
  • 実現するために膨大なコミュニケーション、調整が必要
  • そもそも一部では実現を諦めてしまうほど高コスト、高難易度なものになってしまっている

のような問題が顕在化していきます。

プロダクト作りにおける負債の種類

まずプロダクト作りにおいて、相対する負債の種類をカテゴリー分けしてみました。

技術的負債

説明不要。

これが貯まっていると開発速度が思うように出なくなったり、予期しないところに影響が出て保守性が低下していく

組織的負債

プロダクトを生み出すチーム、組織の負債。

機能開発したんだけどオーナー不在の状態になっていたり、特定の人がハブになっているなど あとは職種間で期待値があっていなかったり、二項対立が起きていたりいうことも含みます

関係者的負債

関係者(特に社外)の負債

特にtoBとかだと顕著で、特定顧客しか使わないであろう機能要望に対応せざるを得なくなったりとか、SaaSを導入するのに受託みたいな期待値になってしまうこと。

顧客以外にも、アライアンスを組んだパートナー、ベンダーに仕様をロックされていたり、投資家との関係性的に計画を思っていた通りに進められないということも

思想的負債

プロダクトの機能における負債

プロダクトの機能に哲学、思想が欠如している状態。この機能はこうあるべきというものがない。 ユースケースがないとも言えます。

プロダクトが成長して機能が増えていく中で起きがちで、 本来は分かれているべき機能が汎用的な1つになっていたり、逆のパターンもあったり、 これが貯まっていくと技術的負債と同様、スピードが落ち、保守性が低下していきます

負債の誕生

負債の生まれ方として、まずイメージしやすいパターンとしては

  1. 顧客的負債&組織的負債
  2. 思想的負債
  3. 技術的負債

の順だと思います。

具体的には

1. 顧客的負債&組織的負債

顧客の声が強く&営業と開発の間に距離がある場合に起きがち。特定のユーザーだけの課題かつ、解決方法が本質的ではないようなものを必須で対応せねばならず、最悪だと交渉の余地なしみたいなことも、、

2. 思想的負債

長期的なプロダクトの方針を考慮したものではなく、短期的な目の前の問題だけを解決するような解決策になる

3. 技術的負債

プロダクト要件が長期的なストラテジーとずれているので、当然プロダクトを実現するためのコードにもずれが発生する

というもの

大体の場合はこうして最初の負債が生まれていきます。 リリースした瞬間には負債という認識がないこともありますが、エンハンスしていく中でゆっくり確実に乖離が大きくなっていきます。

影響し合う負債の恐ろしさ

そして、真に恐ろしいのが負債の発生は必ずしも上記の順番でなくとも起こるということです。

というのも作り手からすると、

「コードが悪くなるのは、思想が悪いから、思想が歪められるのは外部ステークホルダーの存在など制約条件が強いため、、、」

みたいな要件→実装と、一方通行に考えがちですが、

実際には要件を決める段階で

  • 「技術的にこのやり方だと難しいと思ったから、、、」
  • 「プロダクト要件を適切に判断できる人がないから、とりあえず早そうなやり方で実現した、、」

みたく、様々な時系列、カテゴリーの負債が相互に影響しあっています。

こうだったらまだやりやすいのに、、、

f:id:hikoharu06:20191217124021p:plain

負債が積み重なった現実

f:id:hikoharu06:20191217124039p:plain

というわけで、それなりに成長したプロダクトの負債は複雑に入り組んでいるため、 最もインパクトのある部分を特定して、効率よく進めるというのが極めて難しいです。

なぜならどの負債も向き合うのには相当の専門性が必要な中、それら全てを俯瞰して判断しなくてはいけないから

上流から下流に流れていくような一方向の依存であれば、最も上流の根本的な問題を特定して解決しにいくところですが、

このように相互に複雑に依存しあっている場合は目の前の問題を探索的に解決していきながら、依存関係を整理していく必要があります (地道に解きほぐして、解像度を上げつつシンプルにしていくイメージ)

ここからは銀の弾丸はないという前提で、進捗させていくためにどういうアプローチをすべきなのかをまとめていきます。

地道に負債を解きほぐしていく

組織の中で各負債と戦っていくポジションを図にするとこんな感じになります(toB SaaS寄り)

f:id:hikoharu06:20191217124106p:plain

引用:Cultural Capital Theory in Software Engineering - Speaker Deck

基本的に自分のロールから離れた問題を扱うのは非常に難しいです。

理由はスキルセットの問題もありますが、コンテキストがわからないのと、日常でその問題に苦しめられるわけではないのでどうしてもオーナーシップが生まれにくいからです。

たまにバリバリ顧客と接する立場なんだけど、エンジニアのリテラシーに通じていて、 視座が高く俯瞰して見れるみたいなスーパーマンもいたりするが、あまり期待してはいけないなと

進め方としてはまず相手の立場、専門性をリスペクトしつつ、対話可能な状態にしていきます。この記事でいうところのリテラシーを身につけるという話がまさにそうです。

まずはリテラシーからはじめよう

この複雑な問題を進捗させるには1方向からのアプローチではダメで、多様な職種が混ざったプロジェクトチームが必要になります。 その上で少しづつ自分たちが抱えている負債と、周辺の負債を俯瞰して見れるようにしていきます。

もし進めていっても、負債は無限に出てくるし、何から手をつければいいか全然わからんという時は 上図のちょうど中間に位置している、比較的どのポジションでも共通のコンテキストで話しやすい思想的負債、組織的負債から着手していくのが有効だと思います。

誰でも語れてしまう故の難しさはもちろんあるんですが、 組織、フローといった問題は変更というアウトプットが誰の目でも認識しやすいという利点があります。(もちろん結果として改悪になることもありますが、、)

こうして確実にアウトプットを出して進捗させていきつつ、そもそも異なる専門性を持ったメンバーが一緒に負債解消をしたという経験そのものが、さらに複雑な問題にアタックする土台になると感じているので、徐々に領域を広げて、他の負債に対しても取り組んでいくのがいいと思っています。

おわりに

0→1で新しいサービス作ったりするのも楽しいと思う一方で

ビジネスも会社も急成長する中、数年後にストラテジー通りに進められず身動きが取れなくならないように問題を予測し、 急成長に対応しつつも同時に未来に手を打つというのも非常に面白いんじゃないかと思う今日この頃です。

プロダクトマネージャーは積み上げる

プロダクトマネジメントピラミッドと勝手に呼んでいるこの図を自分なりに解釈してみたら、 新しい環境でプロダクトマネージャーをやり始める時の道標になったり、内省にも使えると思ったのでまとめていきます。

f:id:hikoharu06:20191111000924p:plain

ちなみに原文の意訳、解釈というわけではなく、この図を見て思った自分なりの勝手な解釈を書いていくので、原文に興味がある方はスライドを直接ご覧ください

https://www.slideshare.net/ShreyasDoshi4/becoming-an-effective-product-management-pm-leaderby-shreyas-doshi

定義されているPdMの3つのスキル

この図ではPdMの3つのスキルが定義されています

それぞれ解釈してみると

PRODUCT

プロダクトに関する施策を企画、提案する力。機能開発だけではなく、UX改善、技術的負債の返済などプロダクトに関すること全てがスコープ

ANALYTICAL

プロダクトの現状を分析する力。ログやデータを定量的に分析することも、ユーザーインタビューなどで定性的な分析も含む

注意すべき点としてユーザーに関することは、基本的に皆やっていると思うのですが、それ以外にも会社、事業の方向性や技術的負債の状況などについても含まれるということ

いわゆるPdMトライアングルで定義されている、プロダクトを取り巻くユーザー、ビジネス、テクノロジーの状況について、解像度が高く理解できているという状態なのかなと思っています。

EXECUTION

施策を進捗させる力。直接手を動かすというよりは、いわゆる部門間の調整だったり、交通整理、間に落ちそうなボールを拾うことなど プロジェクトマネジメント的なニュアンスが強いと思います。

これが図上ではピラミッドのように積み上がっています。

PdMとして一貫してできることが大事

重要だと思うのは、これら全てを一貫してできるのがPdMやっていると言えるということ。

  • ANALYCAL,EXECUTIONのない状態の企画は、ただの思いつき、絵に書いた餅となりプロダクトのOutcomeにつなげることは難しいでしょう。 またいざ進めよう!となっても、チームに納得感を持たせて進めることはなかなか厳しいと思います。

  • EXECUTIONのない状態の分析はまるで実行に責任を持たず、現場感のないコンサルタントの意見のようになってしまうでしょう

  • はたまたEXECUTIONだけをやっているのであれば、ただの調整屋さんでPdMとはいえない状態だと思います。

「一貫してやるのとかどうするの?」と思うので、PdMとして新しいプロダクトを扱う時には、基本的には下から順に積み上げるということを意識してやっていくといいと思います。

よくある流れとしては、

  • 前任のPMだったり、既存のコンテキストがすでにある施策を引き継いで、無茶振りだな、、、と思いつつも、いろいろな人の助けを借りながら進捗させていく。 ステークホルダーの課題をヒアリングして一緒に解決してあげたり、落ちそうなボールを拾ったりもする 徐々にクレジットが貯まっていく

EXECUTIONをマスターした!

  • 施策を進めながら、キャッチアップしていくと、漠然と次は自分でプロダクトをどういうものにしていこうかイメージが出来てくるので、データ見たり、ユーザーと会ったり、事業の全体像の情報を取りにいって、イメージを研ぎ澄ましていく プロダクトを取り巻くユーザー、ビジネス、テクノロジーの知識が付いてくる

ANALYCALをマスターした!!

  • 満を持して、プロダクトの企画をする。今まで貯めてきた知識、クレジットを使って、プロジェクトとしてドライブさせていき、プロダクトのOutcomeにつなげていく

PRODUCTをマスターした!!!晴れて組織内でPdMと呼べるように

これの繰り返しだと思っています。

おわりに

昨今のちょっとしたPdMブームもあり、外部からいいPdM雇ったらすぐにイケてる企画が出てきて、プロダクトが進捗していくと思われる方もいるかもしれませんが、PdMとしてプロダクトを進捗させるというのは、積み上げが大事でもっと地道なものです。

またこれらを一貫してできるようになり、「よし企画してみよう!」と始めても ユーザーやデータ見て気づく想定違いなどはもとより、事業全体の戦略との整合性が取れなかったりなどで、リリースまで持っていける施策はごく一部です。

すでに走っている施策の調整などで忙殺されていく中でやらないといけないので、執念がないとPdMはやってられないとホントに思います。

どれくらいの速さで積み上げて、企画まで持っていけるかは、

  • 組織や課題の複雑度
  • 要求されるスキルセットと自分のギャップ

など大きく依存しますが、早くて1ヶ月、長いと半年くらいじゃないでしょうか。

自分でPdMやっていても、しっかり積み上げられてなかったなー、失敗したなーっと思うことも多いので、内省しながら、いいものを作っていきたいなと思っています。

PMがいなくてもプロダクトが成長していく世界とは

はじめに

プロダクトマネージャーは責任が大きく、やりがいがある一方で「自分がいないとプロダクトの成長が止まる」というプレッシャーに追われがちです。

組織として、PMなしでもプロダクトを継続的に成長させるにはどうすべきかを考えていきます。

多くの組織が抱える課題

多くの組織の課題としてBizサイド、Devサイドのコミュニケーションや期待値、納得感の問題というのがあると思います。

Bizサイド

  • エンジニアリング、開発フローなどがわからず、バックログの管理をするのが難しい。大きな工数がかかる
  • 期待してくれているほど開発者がオーナーシップ持ってくれない
  • エンジニアからの事業、プロダクトに対して前のめりな提案がなくて、何かモヤモヤする
  • 開発速度が妥当かどうか、わからない。何か遅いと感じる

Devサイド

  • 事業、プロダクトとして何が価値で、どうなったら成功なのかがわからない
  • なぜ、いつまでに開発するのかが腹落ちしてなくて、納得感がない

この手の問題は、20人ほどのスタートアップから、100人超えの企業まで本当にどこにいっても起きているな、、、と感じています。

こういう時に大体PMをDevの手前にロードバランサー的に置くことで一時的には解決します。

ですが、組織間のコミュニケーションのマイナスを0にする期待に対して、PMというロールを置いただけで、一時的に問題が解決しても、組織全体のケイパビリティとしては何も変わっていないという問題があります。 (そして大体PMが孤独で誰も苦労をわかってくれないため疲れて退職する、、、)

この問題に対して、組織として対応していくためにはどうすればいいか考えていきます。

PMなしでも回る組織にしていくためには

最初はPMに集約しますが、徐々にBiz,Dev含めた1つのチームとして課題発見〜機能リリースまでを継続的に行えるようになることが大事です。

これをしないと、待っているのはPMを挟まないと何も進まない、PMがボトルネックになる世界です。

前提として、そこそこコミュニケーションが取れている組織だと、PMがいなくても、

  • プロダクト開発の優先度を決める
  • なぜそれをやるのかを説明して納得感を醸成する

ともに50〜60点くらいは取ることができると思います (時々、優先度や期待値調整がずれて炎上したり。納得感のないまま開発が進んでコンディション悪化したりする)

PMが入ると基本的にここを100点に持っていくことができます。

ただ、ずっと100点を取り続けてもボトルネックになってしまうので、PMは自分なしでも、チームとして95点くらいは取れるように持っていく取り組みをすべきだと思っています。

この辺りはチームを育てる、ピープルマネジメントのマネージャーとかとも共通する概念の気がしています。

具体的に何をする?

シンプルなのですが、即効性があり効果的なのはとにかくステークホルダー間の対話を促すということ

雑に飲み会やイベントとかやったところで、求めている対話は生まれないので ゴールをプロダクトのWhy,Whatについて透明度高く議論できると置きます。

チームには

  • マーケ得意な人
  • P/L引くの得意な人
  • 業務フロー詳しい人
  • ユーザーインサイト引き出す人

など、色々な専門性を持った人がいるかと思います。 その中でプロダクトって特にToC向けとかだと、対話する場所としてちょうどいいんですよね。皆興味あるし、理解しやすく、意見も出しやすい。

これを実現するために、最初はPMが間に入って

Devに対しては

といったビジネス、ユーザーの状況を

Bizに対しては

といったエンジニアリングを伝えていきます。

この時にただ事実を話す。データを見せるのではなく、PM主導でそれぞれの立場に合わせて翻訳した上で、解釈を付けて話すのが重要です。

そして互いに理解する取っ掛かりを作って、対話を促していきます。 (これをやるにはビジネス、ユーザー、エンジニアリングを広く理解している必要があり、結局プロダクトマネジメントトライアングルは大事ということですね)

プロダクトマネジメントトライアングルと各社の PM の職責と JD – Taka Umada – Medium

色々な組織の問題を見たり、聞いたりしていると、ユーザー、事業状況に詳しい人が知らない人を情報格差でマウンティングしやすい構造、それに伴って同じチーム内にも関わらず、発注者と受注者のような関係になってしまっていることが多いと感じます。

この状況から、それぞれが専門分野を持ちつつも、プロダクトのWhat,Whyという場所では、共通言語で会話していくようにしていきます

最終的な決定権はPMが持ちますが、PMの意見、決定に対しても立場問わずオープンに議論していけるようになったらゴールは近いです。

コツとしては1回で伝えようとせず、根気強く対話していくこと。 メインの業務の中で関わらない知識なので、内容よりもとにかく頻度が大事です。

上記以外にも

  • Biz,PM,Devの関係の質が高く、期待値が合っている
  • 事業上、どこに集中するかが明確になっている
  • 開発リソースの配分が事業戦略に最適化されている
  • プロダクトの成功が定義され、定性、定量で測定できている

…etc (それぞれが重厚なテーマなので、また個別で書いていきたい)

などの条件を揃えることができれば、PMなしでもプロダクト改善は進んでいくと思います。 プロダクト改善施策に関して、100点は難しいとしても95点くらいの決断は移譲してチームでやれるかなと思っています。

上記を私はプロダクトを改善するエンジンと捉えていて、PMはプロダクトだけでなく、このエンジンを作っていくことこそ重要だなと思います。

※注意

上記は事業が安定してきて、それなりに会社としてリソースに余裕ができてきた時の話です。 事業フェーズが進んでいくにつれて、1つ1つのプロダクト改善施策が事業、会社に与えるリスクは小さくなっていきます。

スタートアップなど、フェイズによってはプロダクトのWhatにおいて、100点取り続けないと死ぬみたいな世界もあるかと思うので、そういうところは別かなと

チームに移譲できたら、PMいらなくない?

そんなことはないです。そもそも事業の注力領域やチーム編成も結構なスピードで変わっていく中で、上記をキープし続けるのが非常に難しい。 部分的、一時的にできるようになってから、完全に根付かせるまでは長い時間がかかるので、継続して取り組む必要があります。

そして何よりPMの役割って、すごく抽象化すると変化の仕掛けを作ることだと思っています。

プロダクトマネージャーはどう評価されるべき?元Google PM対談|河合敬一×及川卓也 | キャリアハック

ビジネス、テクノロジー、ユーザーを俯瞰して見た時にそれなりの規模の組織、プロダクトって成熟してきているように見えても、どこかに局所的な10倍の成長余地がまだきっとあるはずで、それを発見するのにPMのリソース使うべきだなと思います。

もう少し体系立てるとPMの施策には大きく

  • バケツの穴を塞ぐ
  • バケツそのものを大きくする

という2つの種類があると思っています。

(下記に非常によくまとめてくれている)

PMって何してんの? プロダクト開発の4ステップ|つるちゃん|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を決めるというのはエンジンの中の1つの役割にすぎません。エンジンを設計して、どの部分をPM自身が担っていくかはとても重要なテーマです。

スタートアップがCTOを探すときに用意しておくべき、1つの質問とその答え

最近スタートアップをやっている知人から「今、CTO探していてて、、」と聞かれることが多いです。

大体フェーズはseed期で

  • アクセラレーションプログラムでCTO見つけてきたら出資すると言われた
  • 人脈で出資までは取り付けたがプロダクトを内製開発していきたい
  • 受託で生まれたキャッシュで自社プロダクトを内製開発したい

みたいな状況がほとんどです。

スタートアップで技術アドバイザー的なことを副業でしているというのもあり、最初は現在の状況とか、どういったことがやりたいのか細かくヒアリングしていたりしたのですが、大体の場合、結局同じところに収束することに気づきました。 どこに収束するかというと

「そのエンジニアが、メルカリやクックパッドといった大企業ではなく、自分でサービスを作るわけでもなく、
あなたの会社でやる理由は何なのか?」

ということ

紹介を求めている以上は、これに対する解は欲しいな、、、と思います。 今エンジニアは超売り手市場なわけですし

主観が大分入ってますが、いくつか回答パターンとNG,OKをメモしておこうと思います。

NGな例

「エンジニアリング以外は僕が全部やるから、コード書くのに集中できるよ」

全部やったことがあるのかと聞きたい。メッチャ辛いし、そもそもできないと思う。さらに、仮にこれを魅力に感じるエンジニアがいたとして、おそらく趣向性がスタートアップ向きでないと思います。この体制で成功するのはなかなか難しいですね、、、

ビジネスモデルが〜」

本当に面白そう(もしくは画期的)と思ったなら、自分で個人開発なり、会社を作ってやります。あなたとやる理由にはならないかなと

「0から全部自分でプロダクト作れるよ」

個人で開発します。

OKな例

顧客接点がある

特定領域toBとかで決裁者の人脈があり、販路を確保できそうなケース。 大体顧客の深いところのニーズを捉えて、ヒアリングできる環境もできている。 プロダクトさえ作れば、とりあえずはお金を払って使ってくれるユーザーが確保できそうというのはとても大きいです。

人柄

これかよと思うかもしれませんが、結局はここが大事。 エンジニアリングができても、自分一人だと何かをアップデートするような大きなものは作れないだろうということは皆薄々わかっています。また一人だとモチベーションが続かないということも ユーザーの気持ちがわかる原体験があって、情熱持って一緒にやれる人はどんなテーマであれエンジニアからすると魅力的に映ります。

おわりに

スタートアップは何かしらの取っ掛かりがあることと、その可能性を信じて情熱を持って進んでいけるチームがある以外は、アイデアが素晴らしかろうが、マーケットがあろうが、あまり意味はないんじゃないかなと個人的に思っています。

現在、エンジニアはかつてない売り手市場 というわけで、周りに「〜なエンジニアを紹介して、、、」と聞く時には、一行でいいので

「メルカリやクックパッドといった大企業ではなく、自分でサービスを作るわけでもなく、あなたの会社でやる理由は何なのか?」

に対する自分が思う解を添えてみましょう。 メッセージ送る時も1行でもいいので、最後に添えると紹介率がアップするかもと思います。

10→100フェーズにおける組織におけるプロダクトマネージャーの役割とは

はじめに

10→100フェーズのプロダクトに関わる中で

  • プロダクトマネージャーの役割とは?
  • プロダクトマネージャーとして資質を伸ばす、成長するには?

というのを最近考えていて、そのまとめです。

プロダクトマネージャーの役割とは?

プロダクトマネージャーの役割とは何なのか?ネットで調べたり、色々な人がよく言うのは

  • ミニCEO
  • 売れるプロダクトを見つけ出す(考える)人
  • プロダクトの全てに責任を持つ人

とかが多いかなと思います。 いずれも プロダクトの企画〜運用、全てに責任を持つ というコンテキストが見え隠れするのですが、現場で働く中であんまりしっくりきていなくて、理由を考えてみました

その1 プロダクトの全てに責任を持てない

プロダクトの全責任を持てるというのは、結構限定された状況じゃないかなーという気がしています。その状況とは

  • プロダクトとしてテクノロジーが第一の成長ドライバーとなっている
  • 組織が十分に小規模、かつ全員と信頼関係を築けている

という場合だと思います。

まず成長ドライバーがテクノロジーではなく、コンテンツ(動画、記事など)や営業パワーだったりすると、はたしてプロダクトマネジャーがそこまで権限を持てるのかという疑問があります。

当たり前ですけど、成長ドライバーとなる要素をハンドリングする人が最も権限を持つべきで、そこがテクノロジーでない場合、全責任を持つべきではありません。

もちろん、「じゃあ、どこまでがプロダクトなのか?」という疑問ももちろんあり、例えば、下記のような要素とかはグレーゾーンですね

  • コミュニティ
  • サポート
  • セールス
  • マーケティング
  • 説明文やドキュメント
  • 調達
  • リソース
  • 広告
  • コンテンツ

組織、事業の状況と何よりプロダクトマネージャーの資質、志向性によって範囲は変わりますよね

ちなみに上記とかは全部ひっくるめてプロダクトだろ!いう論理もあると思うのですが、そういう時はプロダクトマネージャーでなくプロデューサー、事業責任者というロールの方がスッキリします。

※なおプロダクトマネージャーがアジャイルでいうプロダクトオーナーに近い(要はバックグランドがエンジニア)という前提でバックログとして開発案件の管理が主業務という前提で書いています。

その2 売れるプロダクトを見つけ出すケースはそんなにない

本当に昨今のスタートアップ企業が発信力を上げているというのもあり、基本的に全て0→1前提(0からプロダクトを開発してリリースする)で語られることが多いのですが、現実世界で圧倒的に多いのは既存の事業なりプロダクトがあって、その中の1つのモジュールを新規にリリースする場合だったりするんですよね

いわばPMFには到達していて、そこからエンハンスするケース(といっても完全に延長線なわけではなく、ターゲットは違ったりしますが)

PMFに向けてひたすら全力で仮説検証を回すというよりかは、どちらかというと持続的な成長のための仕組みづくりとかの方が優先度高かったりします。

組織もプロダクトと考える https://techblog.timers-inc.com/entry/org_as_product

プロダクトマネージャーとして、どこに責務を持つか?

基本の形は下記だと思います

f:id:hikoharu06:20190108152913p:plain

個人的にプロダクトマネジメントのバイブルだと思っているInspiredに書かれたことを参考にしており

になるのかなと

自分なりの解釈ですがプロダクトのAARRRモデルにおいて

  • Acquisition(ユーザー獲得)
  • Referral(紹介)

においてプロダクトにとっての成功を定義して、実行するのがプロダクトマーケティング

  • Activation(利用開始)
  • Retention(継続)
  • Revenue(収益の発生)

においてプロダクトにとっての成功を定義して、実行するのがプロダクトマネジメント

と考えるとイメージしやすいかと思います。

事業として実現したいことがあって、その手段がプロダクト、上記2つだけだとそこに責務を持つ人がいないので、 上位にプロデューサーがいるという構図になります。

この基本形がありつつ

  • プロダクトの性質
  • 本人の資質
  • 組織的な成熟度

によって兼務したりが発生するんだと思います。 (スタートアップとかだとほぼ例外なくプロデューサーとプロダクトマネジメントが兼務)

なので、最低限

  • プロデューサーとコミュニケーションした上で、事業を理解してプロダクトのWhy,Whatを決めることができる
  • プロダクトのWhy,Whatを伝えて、エンジニアが納得感を持って開発を進められる状態にする

がプロダクトマネージャーの役割となります。

そこから資質と志向性によって、マーケティングにも手を出したり、事業戦略にも手を出したりしていくわけですね。

そして、このWhy,Whatを決める部分で いかに引き出しをたくさん持って、インパクトの強いプロダクトのWhatを定義できるか というのが プロダクトマネージャーの腕の見せどころかと思っています。

この記事のアートとサイエンスの掛け算という表現がとても気に入っています https://questpm.hatenablog.com/entry/2018/10/08/assign_priority?utm_source=feed

プロダクトマネージャーとして資質を伸ばす、成長するには?

シンプルに 打席に立つ回数を増やす 以外にないと思います。多彩な状況に置かれて判断を下していくことで 引き出しが多くなり、判断軸も出来上がっていくのだと思っています。

ということもあり、とにかく副業でもサイドプロジェクトでも、1つでも多くのプロダクトに関わってWhatを定義するということを最近意識してやっています。

ただ、実行している中でどういう打席に立つか というのは結構重要で プロダクトとしての

  • 仮説
  • 検証
  • 検証による学び

を1周しないと打席としてはノーカウントかなと思います。

要は

  • リリース前にバックログの整理や推進だけやって、リリース後は別のプロジェクトに行く
  • リリースしてないけど、ユーザーインタビューとかして仮説検証している

とかだとノーカウントということですね。

必ずしもプロダクトの一番最初の企画から関わる必要はないと思いますが、とにかくリリースして、リリース後の反応を元に試行錯誤を繰り返さないと何の意味もないと思います。 より高次元の大きな仮説に関われるので、企画の初期段階からいるに越したことはないかと思いますが

リリースすることの重要性 http://yuzutas0.hatenablog.com/entry/2018/12/25/170000

さいごに

自分もまだまだですが、プロダクトマネージャーって組織だったり、事業だったりに応じて求められるスキル、役割が変わるので、明確な定義はないと思っています。 とはいえ皆悩んでいるのは、Google先生の結果からもある程度わかっているので、 こういう場合は〜なタイプのプロダクトマネージャーが必要 というのがある程度パターンとして定義できるといいのかなと思っていたりします。

f:id:hikoharu06:20181230163025p:plain

プロダクトマネージャー目線でAdobe Max2018参加してきた

先日ロサンゼルスで開催された2018年度のAdobe MAXに参加してきたので、その感想 自分はXDやイラレをバリバリ使ってデザイン起こすというよりは、ツールを使ってエンジニアも含めて、チーム内でどういったコラボレーションをしていくかに興味があり、 またプロダクトマネージャーとしてAdobeのプロダクト、ビジネスがどういう思想で行われているかも興味があったので、そこら辺をまとめました。

Adobe MAXとは

年に一度開催されるAdobeの新製品の発表を中心にしたカンファレンスです。

カンファレンスの特徴として基調講演以外にも

  • 映画監督、アニメーターといった著名なクリエイターの講演がある
  • ワークショップなどが豊富で、Adobeの社員と共にプロトタイプ作成、各種ツールの効果的な使い方を学べる といったコンテンツが用意されています。

キーノート 会場の様子。今年の来場者数は1万4000人らしいです。 f:id:hikoharu06:20181209235631j:plain

キーノート冒頭で

Adobeのこれからの方針として

クリエイティビティが人にも場所にも、手段にも縛られないような世界にしていきたい。

一部の専門的なクリエイティブだけが使えても意味がないし、デスクの前だけ使えるのでも不十分

インターフェイスもキーボードやマウスだけではなく、音声など多様なものを用意したい。

全人類のクリエイティビティを引き出すような製品を作っていきたい

というメッセージがありました。

それを受けて、Adobeの今後のサービスは

  • ACCELERATE
  • LIBERATE
  • DRIVE の3つをコンセプトとして強く打ち出していきたいという発表がありました

以下それぞれの詳細です。

ACCELERATE

Adobeの製品を使った場合の作業スピードの高速化

具体的にはAdobe Senseiを使ったサジェスト、作業のアシストなどです。

ここ数年で強化されている点で、単純作業をツールが代行し、クリエイターが本来やるべきクリエイティブな作業に集中できるようにするというのを

今後もさらに継続していくというメッセージがありました。

LIBERATE

クリエイティブを場所、手段の制約から開放する

マルチデバイス対応により、いつでもどこでもAdobeの製品を使えるようにすることはもちろん、複数のツールを使う作業においては

単純にツールを切り替えてやるのではなく、異なるツール同士の機能をシームレスに使うことができるというものです。(PhotoShopillustratorなど)

DRIVE

AR、音声インターフェイスといった新技術への対応

スマートスピーカーを始めとして次々と新技術が生まれていく中で、

Adobeの製品を使って作れるコンテンツも、進化していく技術に対応したものにしないといけないという方針です。

キーノートでもXDで作成したプロトタイプをスマートスピーカーインターフェイスとして操作するデモや、ARコンテンツを使ったデモが行われていました。

個人的に、今回のカンファレンスで一番強く推されていたのはLIBERATEだと思っており

2019年に向けてAero,Rush,Geminiといった新製品が発表されたのですが、それらは全てデフォルトで

iPhone,iPad,PCのマルチデバイスに最適化されてリリースされます。

それぞれのプロダクトのデモがあったのですが、どれも「アイデアが思いついたら移動中など、どこでも制作できる。制作したものはリアルタイムでCreative Cloudにアップロードされるので、続きはデスクで」という価値をアピールしていました。

さらに新規のプロダクトだけマルチデバイスかなと思っていた所に、PhotoShop CC for iPadが発表されました。

どういうことかというとこれまで、30年間積み上げてきたPhotoShopを機能はそのまま、iPadに最適化した全く新しいものとしてリリースするということです。

おそらく秘伝のタレ状態になっているレガシーなソースコードを置き換えていくのはエンジニア目線からしてもとてつもなく大変なプロジェクトではと思います。Adobeのマルチデバイスに対する本気さを感じました。。。

このプロジェクトについてはAppleとしっかり協力して進めているらしく、Appleバイスプレジデントの方がゲストとして登壇し、両者のパートナーシップを強調していました。

PhotoShopの移行する機能の洗い出しの様子。わからないが大変そう、、、

f:id:hikoharu06:20181209235705j:plain

AdobeAppleが同じ壇上に立つ様子に、会場も大盛り上がりでした

f:id:hikoharu06:20181209235801j:plain

ずっとFlash時代からAdobeAppleの間にはある種の溝があったと思っていたので、感慨深い光景だなと思いながら見ていました。

セッションやワークショップなど、もうちょっとディープな情報はこちらにまとめました

https://tech.recruit-mp.co.jp/event/post-17345/

https://tech.recruit-mp.co.jp/event/post-17379/