Quest PM

米系スタートアップで働くプロダクトマネージャー(PM)の姿をサンフランシスコから

料理は至高のPMエンタメ! 身近でできる疑似プロダクトマネジメント体験

f:id:questpm:20190113233826j:plain


1/1にPM入門講座をリリースして以来、いろいろと相談をいただくようになった。多いのが、「どうしたらPMになれますか?」、「自分はXXというバックグラウンドがあるんですが、PMに合っていますか?」というもの。まずは「僕の講座で思いっきりカバーしていますんで、ぜひ受けてみてください」とはご案内するものの、ふともっと身近にPMを体験できることがあるじゃないかと気がついた。今日はそれをまとめてみます。


料理はPMだ

先日何気なくツイートしたことがプチバズした。

 
多くの共感があったこのツイート。自分がこういう結論に至ったのには、実際に各々の役割を兼任したりして、試行錯誤の繰り返しがあった。この一連のプロセス、実行は上記のプロフェッショナル達に任せるものの、プランニングの段階ではPMもかなり絡む。そして、実は面白いことに「料理」でこの流れを追体験できる。各々のステージでPMが考えていること、そのステージを誰かに任せるということはどういうことかが、体験として透けて見えてくる。

具体的には、

 

Why: なぜ料理をつくるのか?

腹減った(けど食べに行くのが面倒)。持ち寄りパーティーに参加する。彼の胃袋掴みたい。彼女に料理男子ぶりをアピールしたい。

なぜ料理を作るのか、料理を通して何を達成したいのか?まずPMとしてWhyに対して明確な答えを用意する必要があります。


次にWhat

料理を作る目的を決めたのなら、次は「何を」作るのか。
和食、中華、イタリアン、大皿料理、小鉢、一汁三菜などいろいろあります。

ここで「誰に食べてもらうのか」という観点が必要になってきます。そう、PMの世界でいう「ユーザー」です。作った料理(プロダクト)は食べてもらう人(ユーザー)に満足してもらってナンボです。そうなって初めてプロダクトとしての価値を理解してもらえることになる。


When

その料理をいつまでに作るのか。それは今日の夕飯?週末のイベントとして?
タイムラインを決めないと、いつまでたっても料理たるプロダクトは出来上がらない。


How much

冷蔵庫の中のものですますのか、買い出しに行く必要があるのか、予算はいくらまで出すのか、オーブン料理(USのほとんどはガスオーブン)だとガス代かかるし、煮込むなら圧力鍋を使ったほうが1時間も煮続けるより経済的。

Who

自分で作るのか、誰かと作るのか、外注するのか。シリコンバレーではよく"Build or Buy"と言ったりします。


How

どのレシピを参考にして作るか、レシピ通りにつくるのか、アレンジするか、それとも独自にレシピを考案するか。盛り付けはどうするか?作り手のスキルレベルや、食べ手の期待値、要求の高さ、予算やタイムラインの関係でこのあたりが決まってきます。


いざ調理開始!

これで料理(プロダクト)のScope of work (SOW)が決まりました。いよいよ作っていきます。決められた時間内で作るのはスプリントと一緒。

スプリントが走り出すといろいろな障害にぶつかります。それはバグであったり見積もり違いであったり、ビジネス要件の変更であったり。料理で例えるなら、調味料の分量を間違えたり、レシピ通りにつくったのになぜか薄味、といった感じです。

期待してた食材がイメージと違ってた時なんかは、3rdパーティーAPIが期待どおりに動かなかった時のがっかり感とそっくりだ。

また、時間が決まっているため複数のことを同時並行で進めなければいけない。パスタを作る時、お湯を沸かし麺を茹でている間にソースを作るというように。かといって、茹ですぎてしまってはおいしくなくなる。

プロダクトマネージャーとしてはこうした困難に直面しても逃げられない。何をして、何をしないか決断をする必要がある。プロダクト開発と料理の関係でいうと、

バグを直す -> 作り直す
Workaroundを当てる -> 調味料や別の食材を追加して味を調整する
Backlogにして後回しにする -> 今回はあきらめ、次回再チャレンジ
運用で回避 -> 完成後、食べる直前に何かを一味加える、つけダレやソースでなんとかする。

当然それぞれのオプションにはPro/Conがあり、PMならばどの選択肢が失敗のリスクを最小化しベネフィットを最大化するかについて頭をめぐらさないといけない。


そして実食

こうして様々なプランと実行の積み重ねでできあがった料理を食べてもらうことになります。食べた人から「おいしい(これは便利)」と言ってもらえればPMとしてはひとまず及第点。「また食べたい(また使いたい、誰かに薦めたい)」と言わせて初めてナンボです。これはUser retentionやNet Promoter Scoreの考え方と同じ。

料理にはプロダクトマネジメントのエッセンスがつまっている。もちろん料理ができるからといってPMにすぐなれるわけではないが、少なくともPMがどんなことを気にしながらプロダクトを作っているのかを疑似体験できる、至高のエンタメだ。


実際には

冒頭で紹介したツイートのように、本当のプロダクト開発となると一人ではなく多くの人と連携しながらおこなうことになる。PMとしてWhy/Whatをどう決めるかは会社の命運すら左右する決断。Why/Whatが決まるためには、ユーザーだけでなく、会社の上層部やマーケ、営業、サポート、BizDevといった部署とも話しビジネス要件を決めなければいけない。一度決まればPJMやエンジニアリングマネージャーと議論してどう作っていくかを決める。一人で料理を作る時にはなかった、他のプロフェッショナル達との高度なコミュンケーション能力やビジネスセンス、取捨選択の決断力が要求されることになる。

(また、子育て家庭や共稼ぎで忙しい家庭では、正直言っていちいちこんなことは考えていられない。あくまでPMという観点で料理を噛み砕くと、という記事なのであしからず。)

 

料理教室イベントはチームビルディングに最適!

シリコンバレーのスタートアップ界隈でも実はCooking Classがチームビルディングのイベントとしてよく行われたりしています。 複数名でやると、PMの観点だけでなくチームプレイの観点も入ってきてなかなか頭使うんですよね。Googleだとビルによっては社員食堂にCooking Classの施設があって、社員なら自由にスケジュールして使えたり。

これまでPMってどんなことを考える人なのかわからなかった、という人にこの記事を通して伝われば幸いです!

新年だからこそ、もう一度意識したい”Bar"の高さ

f:id:questpm:20190107122024p:plain


自分を高める言葉の力

「言葉の力」はなかなかあなどれない。気分が落ち込んだ時、落ち着かない時、良い言葉を知っていると、自分の中で反芻することでどのような状況でも自分をコントロールすることができるようになってくる。なので、自分は本や会話の中でよい言葉や表現に会うと、決まった場所に残すという習慣を続けている。わりとそういうことが10代のころからあったりして、USに移り住んでからは自分を高める英語の表現を集めている

当然場所柄、「おお、英語でこんな表現があったのか」という瞬間に立ち会うとちょっとうれしい。そうした言葉は、日本の英語教育システムの中で10年も英語を勉強していたのに、なんと一度も出会うことのなかった言葉なのだ。そういう「教わらない」英語が日本の外では普通に日常で使われていて、時として強烈に自分を刺激した。

Raise the Bar High

「いつかは本場でPMへ」と志を胸に2006年にシリコンバレーに渡米した時、最初の仕事はカスタマーサポートエンジニアだった。当時外資の社内転籍で日本からUSへ来る人間など珍しく、日本人など同じチームにもビルにすら一人もいない。完全に現地採用だ。4年ほどそのチームで奮闘し、やがてテックリードになってちょっと自信をつけた自分は、PMへの社内転職を試みる。日本人でPMを名乗る人など当時はほとんど誰もいなく、全てが手探り。

当然うまくいかなかった。ビザの関係上社外への転職はできなかったため、社内転職でPMを狙うしかない。でもなかなか手がとどかない。キャリアの方向性で行き詰まり、胃の痛い日々が続いたある日、VP of PMをランチに誘い出して思い切って相談した。その時相手に言われた言葉、それが"Raise the bar high"

通常は「他のだれも打ち出すことののなかった、新しいスタンダードを作る」といった意味で使われる。ただ、このVPと話していて、実はそんな単純な意味で使っていたのではないことに気づく。ちなみにこの"bar”は棒高跳び走り高跳びの"bar"を意味している。棒高跳びというのはルールとして、1試技成功することに、5cm高さが変わっていく。(走り高跳びの場合は2cm)

実はこの上げ幅にミソがある。今自分がギリギリ飛べている高さの30cm上でもなければ1cmでもない。5cmなのだ。もし30cmなら、おそらく今やっていることを一旦ストップして(もしかしたらリセットして)、全く別のアプローチをしないといけないだろう。1cmならば、運がよければちょっとだけがんばればできてしまう可能性が高い。(そして自分の実力と勘違いしてしまうかもしれない。)

「5cm上」となると、30cmと1cmのちょうどハイブリッド的なアプローチが必要になる。今の自分の努力のしかたをそのまま足し算にしていく線形的なアプローチと、ちょっとやり方を変えてみる、今までノーマークだった部分も視野に入れてみて、そこから考えると何に自分が足りないのか、とかそういう非線形なアプローチの両方が必要なのだ。

当時の自分はとにかくPMになりたいがゆえ、誰に頼まれるでもなくPRD(今考えればひどいクオリティー・・)を書いてはPMに送りつけてみたり、プロダクトのダメ出しをふっかけてみたりと、かなり無茶苦茶していたと思う。このVPは自分にRaise the bar highの精神でアプローチのしかたを変えて、自分の新しいスタンダードを作ることを教えてくれたのだ。

その後自分は直接PMを狙うのではなく、一旦テクニカルマーケティングチームへの社内転職に挑む。なんとかチャンスを掴み、PMの右腕としてマーケ観点で日々サポートする立ち位置で働けることになった。その後PMにたどり着く。

これまで4年もカスタマーサポートチームでPMになろうともがいていたが、アプローチを変えたらPMへの道を開くのにかかった時間は1年半だった。

うまくいかないのなら、Barの上げ方に問題があるかも

もし今目標に向かって努力してるはずなのに・・なんかうまくいかない、近づいているように感じないことがあったら、この"Barの高さ”に意識してみると何か別の視点が開けてくる。

今の自分に高すぎると感じたら、一旦少し下げて確実にそこを乗り越えられるようになってからあらためてBarを上げればいい。あと少しなのに・・と感じるなら、きっとそれはあと5cmの部分だ。線形と非線形の努力という視点で自分の力の入れ方を見直せばクリアできる可能性はあがる。新年だからこそ自分の目標の高さをもう一度確認することをおすすめします。

 

 

Netflixだって失敗から学ぶ。世界のPM達が注目した10個の教訓

Image result for netflix logo

シリコンバレーのプロダクトマネージャー(PM)界隈で、大御所の一人として有名なGibbson Biddleさん。元はNetflixのVP of productで現在のNetflixの成長の原動力を作った人です。彼のブログは勉強になることが多く、世界のPM達からも一目おかれています。

昨年暮れに投稿された記事は今では2000以上のLikeがつき、日本のPMの皆さんにもぜひ読んでもらいたいと思いました。ツイッター上でGibbsonさんに翻訳していいかと聞いたらあっさり「いいよ」と答えてくれたので、今日はそれについて書きます。

読了目安:6分  5000字につき長文注意

Image result for netflix gibson biddle
Gibbson Biddleさん

 

私はNetflixを例に多くのプロダクト開発戦略について、これまでいろいろなところで書いてきました。他の会社にNetflixの成功と失敗を学んでほしいからです。よく私がお伝えするのは、Netflixで行われる試みの半分は成功していますが、実は残り半分は失敗しているということです。

こうした失敗事例は多くのプロダクトマネージャーにとって、プロダクトローンチやスタートアップを成功させることがいかに難しいかを教えてくれる教訓です。加えてアートとサイエンスをうまく組み合わせて、作るべきプロダクトを見つけ出すのがいかに難しいかを我々に強調しています。

 

なぜ、Netflixはそんなにも失敗が多いのでしょうか?理由は2つあります。

1. 多くの人間が介入することで生まれるバイアスの多さ

2. うまくいかないプランにこだわってしまう(本当はそんなプランはすぐに諦めて、別の勝ちプランを見つけてそちらに集中すべき。良し悪しを見極める判断力がキモ。)

Netflixの友達機能について

Netflixは2004年に友達機能(Netflix FriendsもしくはCommunityと呼ばれた)を始めました。この時Facebookがユーザーを100万人から600万人に増やした頃です。この華々しい成長の結果、シリコンバレーのVC達は「あなたの会社のSocial Startegyは何か?」とよく聞くようになりました。

 
Netflix’s Friends, 2004–2010.
Screenshot: Wesley Fryer/Flickr/CC BY-SA 2.0


この友達機能で、Netflixは競合が真似できず、利益率の高い状態でユーザーを喜ばせることができると信じていました。Netflixの加入者は映画の良し悪しを友達から得られることを喜び、ユーザー同志で強固なネットワークができあがり、映画のレコメンドが友達経由で次々になされることで、レコメンド自体の効率があがると考えたのです。

Netflixがユーザー定着率(Retention)の改善を望んていた一方で、計測できるメトリックとして、「少なくとも一人の友だちとつながるメンバーの割合」を採用していました。

友達機能がリリースされたとき、この機能を使ったユーザーの割合は全体の2%、4年後に8%。そして2010年(すでに私はCheggという会社に移っていましたが)、Netflixはこの友達機能をやめてしまいました。この機能を継続するためには20%のユーザーに使ってもらう必要があったのです。この閾値を超えない限りはユーザー継続率の改善はみこめません。6年にもわたる努力をもってしても、ゴールには全く届かなかったわけです。

なぜNetflixはそんなに長くこだわったのか?

 

ここで賢明なみなさんなら思うでしょう。「なぜそんなに長くこだわったのか?」それには理由があります。

CEOによるサポート

CEOのReed Hastingはこの機能に大変自信を持っていました。こうなってはCEOが諦めない限りなかなかやめることはできません。

 

戦略として、ソーシャルな機能は意味があった

「机上の戦略」としてはソーシャル機能になんの不備もありませんでした。ユーザーを喜ばせ、競合による模倣が難しく、利益率の高い機能だからです。全てのチェックボックスを「机上では」満たしています。

 

"Small wins"が判断を曇らせた

友達機能をリリース後、メトリック自体は順調に伸びていました。問題は、Netflixがその成長率が目標には届かないと早い段階で認識できなかったことにあります。

 

プロダクトマネージャー達が楽観的すぎ

PMは避けることの出来ない挑戦に打ち勝たないといけません。このような状況下ではPMは往々にして楽観的になりがちで、ネガティブな要素を無視してしまうことがあります。ただ、こうした性質は成功するPMの資質として自然なもので、むしろ必要なバイアスとも言えます。

 

イデアに問題があったのではなく、実行に問題があったと考えた

この友達機能はFacebookがそのソーシャルネットワークを外部に公開する前にリリースされました。そしてNetflixは業界特有の問題に多く直面することになりました。その結果実行部分でかなりの苦労がともなったのです。例えば、U.S. Video Privacy Protection Actは、DVDのレンタル履歴を他者にシェアする場合、ユーザーから*オプトイン許可が必要になります。これは友達機能のUXとしては大変問題です。
(*ユーザーが自主的に情報開示を認めることを、約款を表示の上明示的に許可をもらうこと)

こうした問題の対応に注力してしまうと、Netflixとしてそもそもソーシャル戦略をどうするのかという評価から焦点がずれてしまいます。

逆説的だが、過去の「小さな成功」がシャットダウンを難しくしてしまった

Netflixの仕事はユーザーを喜ばすこと。友達機能をやめてしまうことはその原則の逆をいってしまうことになると考えるようになっていました。この背景には、2009年、Netflixはユーザーの*プロファイル画面の機能をやめたときの経験があります。この決断はユーザーから大きな反発を受けました。全ユーザーのたった2%しかつかっていないにもかかわらずです。
(*複数のNetflixユーザーが同一の画面で使う場合、アカウントをスイッチできる)

明らかになったのは、その2%のユーザーは本当にこの機能を大切だと思っていました。もしプロファイル機能でアカウントがわけられないと、1つのアカウントを複数のユーザーで使うことになります。これが発端で離婚にいたってしまうユーザーもいたのです!Netflixは後にこの機能を復活させました。(そういえば、Netflixのボードメンバーのほぼ全員がプロファイル機能をつかっていたこと、話しましたっけ?)

失敗から得られた教訓

 

それでは今回のようなNetflixの失敗事例から重要な学びを抽出してみます。

1. アイデアの出どころではなく、アイデア自体に注視する

友達機能は社内でも時間と投資がかなり割かれました。CEOがバックについていたからです。ですがCEOが間違っていました。こういうことは起こりえます。この場合NetflixのPMはアイデア自体とそのメリットについて冷静に評価すべきでした。

 

2. 社会・社内通念にとらわれていないか注意する

シリコンバレーのThought Leader(思想的な指導者)達は、ソーシャル戦略の価値を強調していました。この"ソーシャル"というのは音楽の分野には親和性が高いものでした。(映画とあまり大差ないように見えますが。)しかしNetflixは次第にユーザーは自分が見た映画の情報を公開するなんてだれも望んでいないと学んでいったのです。さらに大事なのは、映画の趣味趣向は驚くほど個々人で別れています。こうした多様性が強い状況下では下手をすると「あなたの友達は自分には全く興味のない映画を気に入っている」という、どうでもいいことをユーザーは知ることになります。そこに価値はないですよね。

3. プロダクトに対する行き過ぎたプライドを和らげる

PMは作り手として、当然作ることが大好きです。誰もプロジェクトをやめることを望んでいません。ただ高ぶる情熱と期待は判断能力を曇らせます。

4. クリアな目標を定める

Netflixはユーザーの行動を見るための指標を設定しています。しかし、友達機能の時はゴールに到達する際のタイムラインを設けていませんでした。(2年以内に10%のユーザーエンゲージメントを増やすといったもの)

こうしたクリアなゴールを設定することは、「次の四半期にはどうにかなる」といったゆるい期待をしてしまうことに対するガードになります。これは私が好きな、Noon time turnaround ルールと同じです。(エベレスト登山をする登山家が、頂上まであと100メートルであったとしても時間が正午になったら引き返す。なぜなら午後になると酸素量の変化や、天候、日照の条件も急激に変わり登山家の判断を狂わすから。)

5. ブラインダーを開ける(データに対して目を見開け)

PMはゴールにフォーカスするあまり、進めべき方向変えるような新しいデータに対して盲目的になってしまうことがある。ユーザーが良いアイデアと思ってくれるのなら、多少機能に不足があっても熱狂的に受け入れられたりする。こうして成功するプロダクト開発はモメンタムをすばやく形成できるもの。しかし友達機能の時、トンネルにいるような視界だったNetflixには失敗を受け入れられなかった。

 

6. サンクコストは無視せよ

「私達は多くの時間と労力を投入した。今さらギブアップはできない」こんな言葉が何度もあった。過去の資金やリソースの投入量だけで未来の投資判断をしてはいけない。自分自身に冷静に問いかけてほしい。「今日自分達が知っていることをもとに、どこまでリソースを投入し続けるべきか?」

7. より良いアイデアに対してはオープンに

Netflixは最終的に友達機能を開発したチームを他のチームに移しました。そのためには、偏見をもたないエグゼクティブが彼らの目を覚まさせ異動を後押ししていました。新しいアイデアやプロジェクトにオープンになってもらったのです。

8. 辛い判断でもあなたの役割上貫徹すべき

リーダー・マネジメント職やエグゼクティブの立場の人にとって、一番の仕事はバイアスのかかっていない判断を提供すること。その判断はプロダクトへのプライドや情からは離れたものであるべきです。5年にわたる努力をやめさせることを言い伝えるなんて、誰もやりたくありません。しかし、立場上やらざるを得ません。言わなくてはならないものは全うしましょう。

9. やめるべきプロダクトを適切にシャットダウンさせる

プロダクトをシャットダウンさせることは非常に難しいです。規律に沿った形で実行されるのはなかなかまれでしょう。Netflixは友達機能を「安楽死」させるアプローチをとりました。ユーザーにはかなり前からこの機能をやめることを通達し、なぜやめるかを説明し、どのようにユーザーがこの機能から離れられるかパスを提示し、同様のコンテクストで何度も説明しました。その結果、ユーザーからは大きな反発はありませんでした。

10. 失敗の遺産を既存のプロダクトに残さない

Netflixが友達機能をやめた時、サイトから当該機能を抹消しました。こうした徹底的な排除に失敗してしまった会社は、コーナーケースに遭遇するたびに本来のプロダクト開発の動きを遅くしてしまいます。シンプルで使いやすいUXを作り続けるために、実はこうした機能の排除(Sunsetting)が適切にできることが求められます。

 
The year 2010 brought about the end of Netflix Friends.
What barnacles should you scrape?
Screenshot: Tech-media-tainment


あなたのプロダクト開発は大丈夫ですか?

巧みなプロダクトマネジメントは、人・ビジネス・プロダクトについて、いかにベストな判断ができるかに依存しています。そのためには、Consumer science(データや定性的なリサーチやインタビュー、A/Bテストなどで仮説を構築検証するプロセス)を使えるだけでなく、使いこなすためにある程度の直感も必要です。市場で成功できる、消費者向けテックプロダクトを作るというのは本当に難しいものなのです。


プロダクト開発に携わった時、あなたの人間性は時として判断を曇らせてしまうことがあります。上層部の強い押し、社会・社内通念から距離を置きましょう。達成すべきゴールを設定し、あくまでそれに向かうことに集中。あなたの中で高まるプロダクトへのプライドを落ち着けて、自分に問うてください。

過去の自分達の時間・資金・労力の投入量にかかわらず、今日自分たちは何に力を向けるべきか?

 

もし自分がこのままでは失敗してしまうプロダクト開発のただ中にいるのなら、あえて声をあげましょう。そして失敗の産物を全て削ぎ落としましょう。こうした失敗によって研ぎ澄まされていったあなたのプロダクトセンスは、プロダクトマネージャーとしての成功確率を劇的に高めることになります。

 

編集後記

いかがでしたでしょうか?Gibbson氏があげた教訓はどのようなプロダクト開発に関わるPMであっても意味のあるもの。今プロダクト開発に関わる方は自分たちのPMを見て、また現在PMの人は今自分が行っていることをこうした教訓と照らし合わせてみて、どこを修正するとよさそうかぜひ冷静に見直してみてください。自分のPMレベルを一段ひきあげる良いきっかけになるはずです!

 

<お知らせ>
NetflixFacebookGoogleやその他シリコンバレーのスタートアップでどんなプロダクトマネジメントがされているか興味ありませんか?今年公開したシリコンバレー流プロダクトマネジメント入門講座は、多くの注目を集めており現在5段階評価で星4.5をいただいています!ぜひ2019年のスキルアップにご活用ください。

f:id:questpm:20190108124517p:plain



 

シリコンバレー流プロダクトマネジメント入門講座をリリースしました

f:id:questpm:20190103133321p:plain

 

本格的なPM入門講座をUdemyで。

明けましておめでとうございます!年明け初日に昨年度から作ってきたプロダクトマネジメント入門講座をUdemyでリリースしました。ツイッター上で以下のようにアナウンスしたところ、

 

 

プチバズしました。

f:id:questpm:20190103133601p:plain

 

多くの方がプロダクトマネージャーという仕事について興味を持っていただいていることをあらためて感じています。

 

講座を作ろうと思った理由

プロダクトマネージャーという仕事が日本で注目されている割には、経験者が体系的に説明している講座がないな〜 と思ったのがきっかけです。PM本として日本語訳の本がいくつか出ていますが、僕から言わせると一長一短で、「それを読めばOK」にはとてもならないですね。例えばよく日本のPMの話題がでるとよく参照されるInspired 第1版は10年以上前に書かれたもので、もはや参照するには古すぎる感があります。(日本語版は2015年に出版。今は原書で第2版がでています。)

questpm.hatenablog.com

 

ということで、シリコンバレーで日々PMとして戦う中で体得してきた「今のPMの姿」をよりタイムリーにお見せして、「PMってこういうことするんだ」という気づきをたくさんの人にお伝えしたいというのがモチベーションです。

 

興味を持ったら

1/6まで$30オフにてご提供していますので、年初のお休みのうちにぜひチェックしてみてください。ひとセッションが3分程度の動画で細切れにしてありますので、隙間時間や移動中に気軽に見ていただけます。リンクは↓

https://www.udemy.com/introduction-to-pm/?couponCode=OEIDFW

以下がイントロダクション動画です。


シリコンバレー流 プロダクトマネジメント入門講座 イントロ

 

「エンジニアのためのマネジメントキャリアパス」をPMの観点で読み解く

f:id:questpm:20181015134014p:plain


及川さん(@takoratta)さんに先日お会いした時におすすめしていただいたこの本。「エンジニアのための」とあるものの、PMの観点で読んでも読み応えがありました。学びのあった部分を一部紹介します。(ちなみに翻訳前のバージョンで読んでいるので洋書ベースの書評になります。)

Strategies for Saying NO (NOというための戦略)

PMは多岐にわたるステークホルダーと仕事をする以上、なんでもYesと言ってしまう八方美人では何も決まらず物事が進まない。Noと言わなければいけない場面も往々にしてある。そんな時どのようにうまくNoというかは非常に需要なコミュンケーションスキルの一つ。本書ではいかのオプションを提示しています。

 

 "Yes, and.."

まずは相手の意向を「Yes」で受け取る。その後に逆説的な表現でYesであるための意味を伝える。例えば、

"Yes, we can do this, and all I need to do is to delay the start of this other project which is currently on the roadmap."

というような表現。訳すと「それならできますよ。自分がしないとけないのはロードマップにある他のプロジェクトのスタートを全て遅らせることです。(-> それはかなり難しいですよね?ちゃんと他のステークホルダーにも相談しました?という裏の意味を含んでいる)」

 

Create policies

Noと言わなければいけない場面が多いのは、その裏返しとしてチームや会社としての「決まりごと」がないとも言える。例えば営業チームが「顧客AがXという新機能を必要としている」からといって、基本的なWhy/Whatや見込める収益も定義せずに提案していては当然PMからNoと言われて致し方ない。

リクエストがあるのなら、それが有効だと理解してもらえる情報群をしっかり集める。どんな情報群が最低限必要なのか、PMによる定義(もしくは会社による定義)がポリシーとなる。一旦これができれば、基本的にリクエストする側もまずはポリシーで決められた情報を集めなければいけない。PMが「XとYとZという情報が集まってから議論しましょう」とリクエストのたびに言う必要がなくなる。

 

"Help me say yes"

これは上のポリシーに近いかもしれない。自分としてはNoと言いたくないけど、Yesと言うためにはあまりにロジックや裏付けが弱いよ、というシグナルを伝えるための表現。そんな時にこの言い方が使える。ただ、その場合PMはYesというための基準がなんなのかを説明する必要があります。

 

Appeal to bugdet

PMがかかわるプロダクトチームの稼働状況について時間的・人的リソースの状況がいかにタイトかを伝えることで、"Not right now"(今はムリ)というシグナルを送るという方法。

逆に、PMから「今はムリ」と言われた側は「いつなら可能なのか」、「リソースをどこからか用意できれば可能なのか」をフォローアップすべし。PMのプライオリティーに関する意思決定を助けてあげれば、Yesと言わせることも可能。

 

Let's work as a team

自分一人でNoと言うより、チームとしての意思決定プロセスを経て決めようというリクエストのリダイレクト。

 

Don't *prevaricate(*言葉を濁す)

Noと言わなければならないのなら、後回しにしない。とはいえ、あまりに先走ってNoと言ってしまったらそれはあとで謝らないといけないケースもあります。ただ、時間価値を考えれば全ての決断マターに時間をかけていくわけにも行かない。であれば、その場を濁して、相手がどうしていいかわからない状況にしてしまうのだけはやめましょう。

 

”Say No"を使いこなすのはPMとしての一つのスキル

同じNoと言うにしても、一方的にはねつけるのではなく相手がアクションしやすいようにNoと言うほうがお互いのためになる。上記以外にも表現のしかたはあると思うが、大事なのは、"Responding positively but articulrating the boundary." 「ポジティブに反応しつつも、どこがYesの境界線なのかしっかり伝える」ということ。PMは「良い人」であるよりも「芯の強さと頭の柔らかさがある人」でいたほうが信頼されるし、結果的に関わる人の生産性があがるのだ。

 

(Strech goal) ぜひ洋書版にもチャレンジを

今回Management Pathを洋書で読んだが、読みやすい英語で書かれていてページ数も200ページくらいと薄い本。なのでそこそこ英語の読解力がある人なら、ちょっと自分にストレッチをかけるだけで読めるはずです。洋書と聞いて「そんなの無理」と避けてしまう前に、部分的に触るだけでもいい。筆者の生の声が読める原書は和訳とは違った学びがあります。つねに広い視野を要求されるPMとして、洋書を読めるようになると自分の知性の世界観が広がりますよ。

 

 日本語版   

 

洋書版

プロダクトマネージャーがすべきプライオリティーづけについて

f:id:questpm:20181006152355j:plain

 

 PMが開発要件に関して「全て大事」と言ってきた。

本当に迷惑ですよね。そのプロダクトを作る際に何が一番大事かを知りたいのに、「全部大事」と言ってくるプロダクトマネージャー。困るんですよ、開発する側から言わせると。当然コストも時間もかかるし、クオリティーを担保するのも一大事。ゴールがとてつもなく遠く見えてしまう。プロダクトチームとしてビジョンに一向に近づかない、枝葉にとらわれて森を見ず、何も進まないという状況に陥ります。PMが「全て」という言葉を使いだしたら、それはそのPMが思考停止していると言ってもいい。こういうことはシリコンバレー企業ではまず起こりえません。それはなぜか?

 

PMがすべき大事な仕事、それはプライオリティーづけ

プロダクトマネージャーはプロダクトの運命を決める人であり、ユーザーエクスペリエンスとそこからあがる収益に責任を持つ人です。それは最初のプランニングから、リリースしてユーザーが定着して収益がついてきて、最終的には次期バーションにユーザーを載せ替えるところまでも場合によっては考えます。

そのEnd to Endのサイクルは短いと数週間、長いと年単位の期間になるもの。当然開発する側からするとサイクルが短かろうが長かろうがScope of Workが適切でなければ作れるものも適切に作れなくなる。GAFAクラスの企業でもなければ潤沢なリソースがないので、必ずどこにフォーカスするのかを決めなければ、プロダクトチームのメンバーも会社自体も「一体PMはどこに向かっているのか?」という疑問を持つことになります。こういう空気が出てきてしまうのはPMとしては負けです。シリコンバレー企業ではPMのこのプライオリティーづけがスタートアップから大企業まで徹底しています。ここをうまくできないPMは評価されない。

だからこそPMは「全て大事」などと軽々しく言うのは間違い。プロダクトチームおよび、会社に対して、その期間はプロダクト開発のどこにフォーカスして何にプラオイリティーを置くかをクリアに伝えなければいけない。

 

プライオリティーづけでPMが意識すること

では「全て大事」と言ってしまうPMの何が問題か?それは「判断の軸」がないこと。優先度を決めるということは個別のアイテムを比べてどちらが上か下かを決めることであり、そのためには判断の軸がなければ無理。自分がこの地でPMを経験してきてひしひしと感じるのは、軸とは「インパクト」につきる。これを分解すると、

1. 短期・長期的に会社として達成したいことへのインパク
2. ユーザーへのインパクト(UI/UX的に。Customer Wow Factorと呼んだりもする。)
3. KPIに対するインパクト(ユーザー継続率や収益性など、どのくらいKPI向上に効果ありそうか)
4. フロントエンド・バックエンドへのインパクト(開発負荷・運用負荷という点で)

が代表的な軸。

PMはこうした軸を使ってプラスのインパクトとマイナスのインパクトのそれぞれの大きさを評価していく。当然マイナスのインパクトが大きければ、対策をするというよりも、一歩引いてそもそもなぜそんなにマイナスのインパクトがあるのかを考える。その結果として開発スコープを変更したり、狭めたりするなどしてインパクトのコントロールを行う。

 

PMがするプライオリティーづけはアートとサイエンスの掛け算である。

上の1,3,4に関して、もし社内でデータ化ができていないのならまずは会社としてこうした部分を数値化することを始めてください。この地のスタートアップも大企業もどの会社もPMがプロダクトに関するデータを自由に取得できる状態です。なのでSQLを叩いてデータ取得して、Pythonで加工してビジュアライズとかも自分も普通にやります。語るならデータなしには語ってはならないというのが徹底しています。

上で言うCustomer Wow Factorは計算で求められるものではないものの、PMがデザイナーと議論して1(low) - 10 (high)の間で感覚でスコアを決める。ここは完全にアートの世界。PMとしてのユーザーに対する理念やセンスが問われるところ。

従いプライオリティーづけは1,3,4のサイエンスの部分と、2のアートの部分の 「掛け算」。どちらかがゼロだとそのプライオリティーづけは裏付けがなくなってしまい、後々なぜそのプライオリティーづけで良かったのか(悪かったのか)きちんとトラックできなくなってしまう。4つの軸がなければどう決めてよいかわからず「全て大事」となるわけだ。

PMの仕事の面白さは0->1を作るだけではない。作ったプロダクトを不確実性の中で進化させ、チームや会社のサポートを正しい方向に導く指揮者となる部分にもある。このプライオリティーづけは多様な知識と経験、アートとサイエンスな洞察力をミックスして行うもの。今までなんとなくプライオリティーを決めていたのであれば、ぜひ上の軸を意識してやってみてください。ステークホルダーの納得感が変わり、何をすべきかがより明確になります。

Silicon Valley Workersさんにインタビューしていただきました

 

 

Silicon Valley Workersというウェブメディアがあるんですが、そこでインタビューされた記事が公開されました。日本からやってきてどのようにシリコンバレー外資の中でPMになり、現地のスタートアップでどんなことを考えてプロダクトマネジメントをしているのかが垣間見れます。グローバルにキャリアを展開してきた一つの事例として読んでみてください。