プロダクトマネージャー1年目の教科書
こんにちは！
dely, Inc.でVPoP (Vice President of Product) として、新規事業開発をしている奥原 (@okutaku0507) といいます。役割としては、プロダクトマネージャー (PdM) 兼エンジニアと言った方がわかりやすいかも知れません。VPoPとはどのような役割なのか、後ほど書かせていただければと思います。
この記事はdely Advent Calendar 2019の7日目の投稿です。
6日目は伊ヶ崎さん (@_ikki02) が「データサイエンティストと機械学習エンジニアをやって思ったこと」という記事を書いてくれました。
データサイエンティストと機械学習エンジニアをされてきた中での経験してきたことが書かれていて、それぞれの違いもわかる良記事でした。
はじめに
僕はdely, Inc.に入社した2016年から元々はずっとサーバーサイド (Ruby on Rails) のエンジニアをしていました。そして、2018年の5月ごろからプロダクトマネージャーになり、レシピ動画サービスであるクラシルのプロダクトマネージメントを担当していました。現在も新規事業のPdM兼エンジニアをしています。
昨年 (2018年) のdely Advent Calendarで以下のような記事を書かせていただきました。
駆け出しのPdMとして、右も左もわからない中、PdMとはそもそもどんな役割なのかからどのようなことをしてきたかを書いてあります。この記事から1年が経ち、駆け出しのあの時、こんな記事があったら良かったのにと思えるような「教科書」を書きたいと思います。できる限り、抽象と具体を書き、オススメの記事や書籍を加えながら書いていきます。
まだまだPdMとして矮小な僕が「教科書」と書くのはおこがましいですが、キャリアハックさんの以下の連載にフィーチャーされています。教科書という大それたタイトルですが、時間の都合もあり、読みやすさは十分に配慮したいのですが、書籍のように読みやすいように再編したりせず、思いつく限りをバーっと書いていきます。各節の独立性はある程度は担保されていると思うので、目次から気になるところを読んでいただければと思います。
僕も「答え」を持っているわけではありませんし、それは常に変化し続けていると思います。これからPdMにチャレンジする方、今まさに駆け出しのPdMをされている方、すでにかなりの経験をされている方にも、この記事が少しでもお役に立てれば幸いです。
最後にこの1年で読んだオススメの書籍や記事を感想と一緒にご紹介させていただきます。
2021年12月に追記。このnoteを書いてから久しく、PdMとしてキャリアをスタートさせて3年の月日が経ちました。自分が3年目に欲しかった学びを詰め込みましたので、もしキャリアが進んできて悩んでいる方がいましたら、参考になれば幸いです。
PdMに一番大切なことはマインドセット
まず最初に心に刻んでおきたいのは、プロダクトマネージャーに必要な最も大切なことの一つはマインドセットです。ここでいうマインドセットとは何か。まずは、是非この本を読んでいただきたいのですが、この本の中で成長とは何かを説明する理論で、アイスバーグ理論が説明されています。
アイスバーグ理論とは、下の図のような説明されます。
成長とは、このアイスバーグ (氷山) の面積を大きくし、より成果が出せる人材になることだとします。このアイスバーグでは、表層化している成果を出すために、その下にある3つの要素との関連が必要不可欠だとしています。つまり、能力・スキルといった頻繁に身につけた方が良いとされ議論されやすいものの下には、ふるまい・習慣・行動があり、最下層には意識・想い・人生哲学が横たわっています。僕は、この最下層に存在する層こそがマインドセットが重要だと思っている理由で、この層が厚いほど、結果的に成果が出せる人材になると思っています。
PdMとしてどのようなマインドセットを持つべきどうかは人によりけりで答えは自分の中にあると思っていますが、いくつか記事を引用します。
日本のPdMと言えば、MicrosoftやGoogleでプロダクトマネージャーとして活躍されてきた及川さん (@takoratta) です。及川さんが登場する記事が続きますが、大切なことを教えてくれます。
まず、PdMとはどのような存在なのか。一言で表すならば、「プロダクトの成長に責任を持つ人」です。上の記事では「愛」だとか「執念」だとか抽象的な概念が語られていたりしますが、それが一番重要だと思っています。PdMは結構泥臭い役割です。プロダクトを成長させるためには、何でもしますというスタンスが求められていると思っていて、自己犠牲的である時もあると思います。思うように上手くいかない時もあるでしょう。最初は自分の無能さに毎日絶望に浸る時期もあると思います。その中で諦めず、プロダクトを成長させるために自分を今何をすべきかを考えて実行していくためには、愛するということ、執念深いことが必要不可欠だと考えています。
では、そのようなPdMとしてのマインドセットは天性として生まれた瞬間から決められているものなのでしょうか。僕は違うと考えていて、それらは後天的に身につけられるものだと思っています。エンジニア、デザイナー、ディレクター、セールス、マーケターなどプロダクト開発に全ての人に素質はあると思っています。「成長マインドセット」にも書かれていることで、自分事化し、課題を適切に分離させることで、自分がどこまでやり切ればいいのか、それ以降は自分がコントロールすることができない問題として扱うことが大事だと思っていて、これは訓練によって身につけられる技術だと思っています。
PdMの役割はフェーズごとに変化する
PdMという役割は組織やプロダクトのフェーズによって、本当に多種多様です。PdMの目的は「プロダクトの成長をさせること」だとすると、それ以外は手段だと考えています。そのため、型にはめ込まない方が良いと思います。以下の「プロダクトマネジメントトライアングル」は頻出するので、一度は見たことがあると思います。
もちろん、この全てができた方がいいのですが、それだと時間がいくつあっても足りません。そして、これらを全てのスキルがあったとしてもプロダクトを成長させられるとも思っていません。PdMの役割は組織とプロダクトのフェーズによりけりだよね、という結論ではこの記事を書く意味がないので僕が思う考え方を書いておきます。
それは「今のプロダクトにおいて一番ボトルネックになっていることは何か？」を常に考えることです。これがフェーズやプロダクトの種別ごとに異なるため、新規事業の立ち上げ期はこうした方がいいよなどの一般解が存在しないのです。もしも、新しくPdMになったのであれば、まずは情報を集めるところから始めましょう。もしも組織が大きくなって、セールスやマーケなどの専門部署があるのであれば、週次の会議に出てあるいはランチに誘って現状をヒアリングして、プロダクトの現状を鑑みて何が今ボトルネックになっているのか、どこがスタックしていて何を改善したら施策が進むのか把握することで物事が進むようになります。
今すべきことがわかったは良いが、そのスキルセットを自分が持っていなかった場合は、すぐに頼むことをせずにまずは自分で調べて周辺の知識を埋めること、スキルを付ければ自分でできるとわかった場合は最速でそのスキルをつけましょう。自分の得意領域でなくても、チャレンジすることが越境の一歩だと思います。その後、やるべきことが明確になってきた時に専門の人と一緒に組んで課題解決をしていけばいいと思います。
PdMと組織マネージメント
プロダクトマネージメントとプロダクト開発を担っている組織は切っても切り離せない関係です。組織のマネージメント、評価や人事に関することは切り分けて考えて、できればPdMの範疇にしない方がいいと考えています。もちろん、小さいスタートアップでは色々兼務してしまってるケースは良くあり、弊社でもPdMが様々な業務を兼務してしまっていました。もちろん、全てができる超人であれば、それに越したことはないのですが、全ての人が超人ではないです。
現在では、プロダクト開発チームの評価や人事マネージメントはVPoEという役職を置くことで、役割を分けています。しかしながら、最初からこのような体制ができる敷けることは難しいので、チームの現状をみて上手く仕組み通して切り出しして、PdMはプロダクトを伸ばすことにフォーカスできる体制を作ることが重要だと思っています。権限によっては、組織編成の権限が自分にないこともあると思うので、その権限を持っている人に話をするのがいいと思います。この時には、PdMの役割と組織マネージメントの役割がしっかりと明文化できていることが必要なので、自分が説明できる状態にあるようにしましょう。
成果にフォーカスする
PdMになると様々部署から大小関係なく、話が雪崩れ込み一気にすべきことが爆発します。物理的な時間は限られているので、その時間の中で成果を出さないといけないわけです。
「みんなフェイクな仕事に忙殺されている。そういう仕事はたくさんミーティングがあって、多くを成し遂げている気分になりますが、週の終わりに振り返ると、大したことは成し遂げていない」
— NewsPicks (@NewsPicks) November 10, 2019
Airbnb共同創業者インタビューより、抜粋を画像でお届け📮
全文を読む 👉 https://t.co/cHKmCj5QRM pic.twitter.com/xlWdspKWp0
Airbnb共同創業者インタビューに関するツイートを引用します。物事が進んでいそうにみえて、大切なことが進んでいない、そのような仕事をフェイク仕事と表現しています。
PdMをしていると、気がつくとこういう状態になります。mtgばかりで日々の仕事が埋まり、帰り道で今日は頑張ったなという気分になり、家で何を成し遂げたかを考えると、実は何も成し遂げていない。そのような症状になったら一度立ち止まってみてください。本当にそのmtgは必要か、本当にそこに自分のリソースを投下することが今ある選択肢の中で一番重要なのか。何かを選択するということは、同時に何かをしないという意思決定をしたということです。フェイクな仕事に逃げずに、本当に重要なことに時間を使いましょう。
このインタビューでは同時に最も時間を費やすべき大事な2つを教えてくれています。
・人々に愛されるプロダウトを作ること
・素晴らしい人材を採用すること
これらは本当に大切です。そのためには、まずは自分が何に時間を使っているのかを棚卸して、権限移譲することで分担できることはないか、いつも話をしてるだけで何も進んでいないmtgはないかを検討するといいと思います。何度も言いますが、プロダクトが上手くいってないと今まで血汗を積みかせてきた全てが無に帰してしまう可能性があります。プロダクトを成功させることにフォーカスしてください。
この節の最後にもう一つ記事を引用します。
「夏の大会後にチームに言い続けてきたのが、『何かを捨てる勇気を持とう』ということでした。同じ時間を使うならば、それをいかに効率的に使うのか。『何かをする』ということは、イコール『何かをしない』ということと同意だと生徒には言っているんです。ある時間で『野球をする』ということは、その時は『野球以外のことはしない』ということですよね。いま『何をすべきか』ということはよく言われるんですけど、『何をすべきでないか』の方が大事なんだと思うんです。いま『何をすべきでないか』という発想を持っていれば、野球の試合の中でもそういう思考でいられるんじゃないかと。するべきこととするべきでないことを明確にするということ、それがすべてなんじゃないかと思います」
PdMのスキルセット
PdMの役割は一つで「プロダクトを成功させること」ですが、スキルは組織やプロダクトのフェーズによってカメレオン的に変化します。もちろん、全てのスキルをマスター級に持っていることは理想です。
とはいっても、全てのスキルを習得して熟練度をあげていくためには、人間に用意された時間は少なすぎます。そして、僕個人的な考えでは、各スキルは進化と変化を急激な速さで起こっていると考えています。
どういうことかというと、昔は複数の学問で大きな功績を残している人が多く、学問の隔たりがなかったが、近年は学問が細分化されて、専門性が高くなって、一つの学問に秀でて情報を追うだけでも時間がかかるというようになりました。これがプロダクト開発に必要なスキルにも生じていると思っていて、情報のアップデートが早すぎて、1年前の情報がもう使えないという世界観の中にいるので、それを追っていくだけでもかなりの時間が必要になります。
しかしながら、一方でスキルの民主化も進んできていて、今では独自ドメインでサイトを立ち上げる、モノ売るためには自前のECを立てないといけないなどの作業のほとんどが、ググってちょっと勉強すれば、すぐに実行できる世の中になっています。この世界で何を勉強すれば、通用するPdMになれるのか、自分の時間をどこに投下すればいいのか。僕なりの考えを書いておきます。
全てのスキルの結論は、その道のスペシャリストと対話して、プロダクトを成長させるために、長期的な視点と短期的な視点、鷹の目とアリの目を持ち、提示された選択肢のメリットデメリットを理解して、会社としての最適解を意思決定できる状態です。しかしながら、全ての結論がそこに帰着してしまってはこの記事を書いてる意味がないので、僕が考えている、このスキルを持ってるとこういうことができるなどを含めて書きたいと思います。
PdM x エンジニアリング
エンジニアリングといえば、プログラミングのスキルがあることに越したことはないです。一度、プログラミングスクールに通って簡単なアプリケーションを作れるようになることも良いとは思いますが、PdMがエンジニアリングを知っていて良いところは、以下だと思います。
・ステークホルダーと話をしている時に、施策の実装難易度をある程度は把握しながら、話を進められる
・実施したい施策をエンジニアと話をする際に、やりたいことを伝えたり、方法を一緒に考えることができるので、話がスムーズになる
・簡単な仕様なら自分でさくっと作ってしまうことができるので、用件定義と実装が一体となって実装スピードが爆上がりする
一方で、陥りやすい罠は実装できることベースで思考が固まってしまうので、その枠組みを超えるのがたまにできない時があることです。一つの機能を実装するのにとても工数を使うと思うと、工数を削減しようと周り道な解決策を思いつくけれども、結局何も解決せず終わってしまうなどはありました。
PdM x デザインスキル
PdMとデザインの利点は、抽象と具体を行き来する際に、ステークホルダーに具体的なデザインを提示することで、みんなの抽象的な認識を一気に具体化して進められる点にあると思います。具体的なデザインをみせることで、それを叩き台に議論を展開することができるので、具体的なことを詰めたり、そこから抽象化してコアバリューを定義することに役立ちます。弊社PdMの小林 (@kazkobay) のツイートを引用します。小林はデザイナーでもあります。
UIデザイン×PdMの1番のメリットは、もっとより良くするための設計や表現を自分自身が作る事によって、プロダクトの印象と体験面を自分のボールとして扱える事だと思う。形にしてみるとやっぱり違うって事もあるし、何度も違うアプローチで試せるのは自分が作る大きい利点。
— 小林 和央 / dely (@kazkobay) December 5, 2019
デザインスキルがない場合には、まずはFigmaというツールを使えるようになるだけでも価値があるので、是非試してみてください。
PdM x マーケティング
マーケティングは広い概念なので、捉え方が難しいですが、僕の中のマーケティングは「ユーザーにとって価値が自分たちのユニークバリューを適切なタイミング、方法でユーザーに届けること」だと思っています。その中で思考の助けになる記事と書籍をおすすめします。
ユーザーの体験をファネルで分解して、今どこがボトルネックになっているのか。ユーザーのメンタルモデルは何かを捉えて、それを考える方法は何かを考えることが大切だと思っています。結局、ユーザー体験全ての改善をしようとしても注力ポイントがどこなのかわかっていないと手の施しようがないです。その時は、改善したい指標のカウンターメトリクスを意識すると良いと思います。
元SmartNewsのマーケター西口さんの著書「たった一人の分析から事業は成長する 実践 顧客起点マーケティング」はとても参考になります。
詳しくは本を読んでいただければと思いますが、自分達の独自の価値を「プロダクトアイデア」と、それを伝えるための「コミュニケーションアイデア」を考えて着実に検証していくという考え方で、これでSmartNewsは爆発的に伸びていると思っています (要因はたくさんあると思いますが) 。
PdM x ビジネス
僕が一番難しいと思っているところですが、基本的な考え方としては、クライアントさんの課題解決をした報酬として売上があがると思っています。そのため、クライアントさんの課題を何かを今までの歴史という文脈を考える必要があります。業務改善サービスを提供するならば、自分がその業務を体験してみて、非効率でテクノロジーで代替可能なところはどこかなどを探るのがいいと思います。
プロダクトについて、一番詳しいであろうPdMは、クライアントさんの課題を把握した上で、実現可能なあるいは今後解決することができる課題の解決策をビジネスサイドと話つつ進めていくことが重要です。
よくあるパターンとして、プロダクトサイドとビジネスサイドのコミュニケーション不足によって、溝ができてしまい、今のプロダクトでなにが解決できるのかだったり、今後どのような変更が加わっていくのかがわからなくなってしまい、ビジネスサイドからしても動きにくくなってしまうなどはあります。その時には、単純にコミュニケーションパスとしてPdMが機能するのがいいと思います。手始めに週に1回でも話す機会を設けるだけでもだいぶ動きがよくなると思います。
PdM x グロースハック
グロースハックについて勉強するときには、MEZONの梶谷さん (@kajikent) の記事を読むのが一番良いと思います。本も書かれているので、是非読んでください。
その中でも良い記事を引用します。
グロースハックに「ハック」とついてしまっているので、何か銀の弾丸のようなものを発明するのかと思われてしまうかもしれませんが、グロースハックの本質は「普通のことを普通にやるだけ」だと思っています。その普通がめちゃくちゃ難易度が高いのですが、梶谷さんは体系的にそれを教えてくれるので、是非とも記事を読んでください。
PdM x データ分析
今後、データを軽視するプロダクトはすぐに淘汰されてしまうと思っていて、自分のプロダクトの現状を知る方法として、データ分析は非常に重要です。PdMとしては、定性的な考え方と定量的な考え方の両方を行き来することができるようになった方が良いと思っています。
データ分析と一口にいってしまっては、かなり広義な捉え方をしてしまいますが、PdMが最も抑えておきたいところでは、施策の評価方法と探索分析による改善施策を生み出すことでしょうか。もちろん、SQLを自分で書けるようになることは重要で、簡単なものはどの職種においても必須スキルだとは思いますが、高度のものになるとそれ相応の学ぶ時間が必要なので、この記事では取り扱いません。
PdMが施策を打つ時には、その施策をリリースしたあとにどのような指標をもって良かったのか悪かったのかを明らかにする必要があります。ユーザーからの定性的なレビューも大事ですが、ユーザーは忖度するけれども行動データは正直です。どのような指標を評価するのか、それを取得するためのログを設計するなどを事前に話をしておく必要があります。
まずは、グノシーやメルカリの記事を調べて読むと良いと思います。
ファシリテーションと合意形成
PdMはプロダクトの成功に対して責任を持っていると同時に、プロダクトの変更に対しての意思決定を持っています。責任と権限がセットではない場合もあるので、その場合は思い切って権限をもらえるように言いましょう。バッターボックスに立ち続けることがPdMとしての成長する唯一の道です。
自分がCEOとして全ての権限をもっている場合以外は、プロダクトに対して変更を加える場合は、変更する内容に応じてステークホルダーが存在すると思います。PdMとして、必要なアクションとしては、まずは情報を集めます。PdMはステークホルダー間で情報の集約地点でないと、統一的な意思決定はできないと思います。また、組織として正しい意思決定をするためには、各ステークホルダー間にある情報の非対称性を解消して、何かを優先したら、何かを犠牲にするということを示さなければなりません。
当たり前ですが、自分のリソースも限られているということは、開発チームとしてのリソースにも限りがあります。何かをするということは、何かをしないという意思決定をするということになります。全ての変更を加えることはできません。そのため、何をすべきかの意思決定をすることも大事なことですが、何をしないかということを決めることも大切です。どうしてかというと、組織の全ての人がプロダクトを良くしたいと思い、日々時間を使っているわけで、死にものぐるいで施策を考えています。全てを試してみたいと思うかもしれませんが、全てを実行することはできません。それを説明し、もしも実施するならば、いつできるのかを示して、ロードマップを引き、説明する責任を持っています。みんなが使っている時間と労力を最大限成果にするために、日々戦う総合格闘技なので、それ相応の覚悟が必要だと思っています。ちょっと文脈は違うかもしれませんが、深津さんのツイートを引用します。
みんなでお手手繋いで仲良く多様性は、割とファンタジーなのでは説。実際の多様性は、頻発する小競り合いと喧嘩の中、より大きな理念のために、喉まででかかった不満をぐっとガマンして、諦めずに調整を重ねる世界だと思う。一方的に自分の理想が叶う、居心地の良い多様性社会は、多分ない。
— 深津 貴之 / THE GUILD (@fladdict) October 15, 2019
合意形成に伴い、ファシリテーション能力も必要になります。先ほど、PdMは情報の非対称性を解消させるために情報の集約地点であると書きました。その持った情報を適切なステークホルダーに説明をする必要があります。そのためには、ただでさえ忙しいステークホルダーたちの時間をもらい説明するわけですから、どの部門の人でも理解できるように、情報を整理して、わかりやすくメリット・デメリットを説明する必要があります。これは、ステークホルダー間での情報量を一致させ、適切な意思決定をするためには大切です。ここで、大事な情報が欠けていると、せっかく作った時間が無駄になり、最悪の場合は進んだ開発をストップさせ、大きな手戻りをしてしまう可能性もあります。そのため、一回一回のミーティングは事前準備を入念にして、自分の考えをまとめておく必要があります。また、あらゆる可能性を模索して、どのような応答にもすぐに考えを展開できることが求められます。僕は、頭の回転が早い人は、その都度考えているスピードが早いのではなく、すでに思考済みだからこそ、すぐに答えがでるものと考えています。頭が千切れるまで考えたかがPdMには必要になります。そのため、24時間マインドシェアを捧げられる覚悟があるのかも大事な素養だと思っています。
PMMとは何か
SmartHRのshigeさんの記事で、プロダクト・マーケティング・マネージャー (PMM) という存在を知りました。PdMは全方位型でカバーすべきと思っていた自分にとっては、それが目的になってしまっていたと思わされました。PdMとは何でも屋になるべきではなく、スキルをつけることはあくまで手段だということを再認識しました。
つまり、組織のフェーズやプロダクトのフェーズ、種類によっては、PMMのようにいわゆるビジネス側の責務とプロダクト開発側の責務を分けることで、円滑に開発が進むと思いました。全方位で守備をして、あらゆるボールをもってしまい、結果としてボールをこぼしてしまう時には、一度自分の役割を棚卸して責務を分けて、役職を新設してしっかりと権限とセットで渡すのは大事だと思いました。
PdMのキャリア論
PdMのキャリアは、そもそもPdMという役割が多様にあり、どのスキルをベースとしてPdMになったのかによって異なるため、キャリアも多種多様だと思います。何でもできる人ができてしまう化物みたいな人も多いので、できる人は自分で起業という人も多くいますし、将来起業するためにPdMをしているという人もいると思います。
僕自身のキャリアの考え方ですが、変化が激しい世の中において、特定の〇〇になりたいというようなキャリアを描くことはせずに、自分の中の信条にしたがってキャリアを考えようとしています。キャリアアンカーという概念があるのですが、自分の価値観を以下のように定めています。極論をいうと、この価値観さえ守られていれば僕は何でもいいと思っています。また、逆にはこの価値観を捨ててまで歩みたいキャリアはありません。もし詳細に気になる方がいれば以前書いたnoteをご覧ください。
・より多くの誰かを幸せにしていること
・寝食を忘れるくらい熱中していること
・心の底からワクワクしていること
自分のキャリアを形成するに役立っている二つの記事と書籍を紹介します。
深津さん (@fladdict) のキャリアチェンジのポイントは二つあると書いてあります。
1. 言語を極めるのではなく、抽象的で応用できるスキルセットを得る
2. 「予測できるもの」と「予測が無駄なもの」を切り分ける
詳細は記事を読んでいただければと思いますが、以下が僕の考えに近いと思いました。
得るべきスキルセットを考えるとき、まずは「抽象的かつ応用できるもの」の優先順位を上げること。特定の言語に対する知識は、趣味や興味、常識の範囲内で十分です。個別の技術を極めようとする人もいますが、flashが使われなくなったことからも分かる通り、スキルの置き換えは可能ですから。
- 中略 -
複数の領域を横断し、掛け算できれば希少性は上がります。1万人に1人のエンジニアになるのは難易度が高いけれど、「10人に1人」なら不可能じゃない。その上で、音楽についても10人に1人という存在になれば、100人に1人しかいない「音楽ができるエンジニア」になれます。加えてゲームの実装が10人に1人のレベルでできたなら、「ゲームと音楽をインタラクションにプログラミングできる」という1000人に1人のエンジニアになれますし、さらに10人に1人のディレクション能力を身につけたなら、「1万人に1人」の逸材になれるわけです。
一つの領域を極めようとするのは大変ですが、2〜3つの分野で10人に1人の能力を持つだけで、極めて希少性の高い人材になれる。そう考えれば、人生はもっと楽になると思います。
また、同様にTakramの田川さんの「イノベーション・スキルセット」にも破壊的変化の時代を生き抜くBTC人材とは何か、その重要性、どうやってなるかが書かれていて、良かったのでオススメです。
複数の領域を横断し、掛け算していき、1万分の1の人材の希少性を出すための方法として、まずは一つの領域で強みを出して、100分の1と言わず、その界隈で認められるくらいの存在になってから、越境していくことが精神衛生的にも良いと思っています。越境するタイミングをミスると立ち返る自分のアイデンティティがなくなって、不安になって思うように力が発揮でなくなってしまう可能性があると思っています。H型人材という言葉も出てきているので、何を目指すのかは、予測できるものに投資して行った方がいいなと考えています。
バケツを大きくし、穴を塞ぐ
コカ・コーラのように長く愛されるプロダクトもありますが、ほとんどの場合は「導入→成長→成熟→衰退」というライフサイクルを描きます。
インターネット、特にtoCでプロダクトを展開し、伸びているマーケットならば、圧倒的な覇者だったとしても、参入してくるスタートアップは多く、そこに何かテクノロジーの変革という波が起これば、一気に衰退してしまうということは往々にしてあります。
もしも、自分のプロダクトに限界が見えてきた時にはどうすればいいでしょうか。その一つの答えが「アフターデジタル」という本にあると思いました。
この本は、中国の事例でOMO (Online Merges with Offline) という概念を紹介している本です。ユーザーはオンラインだとかオフラインだとか気にせずに、自分に最も便利な選択肢を取るだけです。つまり、オンラインがオフラインを包み込んだ世界において「高頻度・低価格でタッチポイントを取り、そのデータでプロダクトとUXを高速に改善できるかどうかが鍵」ということを言っています。詳しい事例などは是非本を読んでいただきたいのですが、一つ事例と伴に説明します。
中国に衆安保険という保険会社があり、保険を売っているのですが、同時にお医者さんを検索して予約までできるアプリを提供しています。なぜ、そのようなアプリを提供しているかというと、保険は売ってしまったらほとんどお客さんとの接点がありません。また、保険に入る前のお客さんとの接点は主に営業しかないわけです。そこで、お医者さんがピンキリという中国の事情とも相まって、アプリでお医者さんを探せるようにすることで、今このユーザーは病気について調べていることなどがわかるようになります。健康体なら保険の心配をすることはほとんどないかもしれませんが、自分が病気になるあるいはその疑いがあって、病院に行こうとしている時は、保険のチャンスなわけです。それをアプリを通じてしることができ、営業に活かすことで、衆安保険は爆発的な成長を遂げています。
この具体的な事例を抽象化すると、二つの事象に分けられます。
・UXの磨き込み = バケツの穴を塞ぐ
・UXの伸長 = バケツを大きくする
もちろん、既存プロダクトの改善 (保険なら商品の磨き込み) も進めていくわけで、それはUXの磨き込みとして考えます。もう一つ、UXの伸長というのが非連続的な成長を遂げていくためには大事だと考えています。
ユーザーは文脈で生きています。食の領域では、料理という生活の一部を切り取っても多くの行動があるわけです。
例えば、クラシルの場合、料理の体験の中の調理という部分を「レシピ x 動画」というわかりやすいコンテンツで課題解決していきたわけですが、料理は献立を考えたり、食材を買ってきたりする行動が隠れているわけです。クラシルでは、材料を買うという行動に対して食のECという切り口でUXの伸長を行おうとしています。もちろん、既存のレシピ動画にも多くの課題があるため、UXの磨き込みも同時に進めていますが、非連続的な成長をしていくために、UXの伸長を行っているわけです。その結果、例えばですが、ECで白菜を買ったユーザーに鍋のレシピをレコメンドしようというような一貫した体験を提供できるようになります。PdMは、UXの磨き込みと同時に、既存ユーザーあるいは新規ユーザーのUXを伸ばしていくためには何が必要なのかを、常に視野を広げて考えることが大切だと考えています。
プロダクト開発を楽しむ
プロダクト開発は終わりのない旅のようなものです。Lean UXというリーンなプロダクト開発には欠かせない本のまえがきを一部引用します。
健全なプロダクト開発はマラソンである
健全なソフトウェア開発は、マラソンのようなものです。ソフトウェアをつくったとしてもその開発を常に続けなければ意味がありません。マラソンを走るためにはまずリズムを整えるためにペースを維持する必要があります。ソフトウェア開発においても同じようなことが言えます。
プロダクトを成功に導くためには、銀の弾丸はありません。ネットで散見されるような成功体験の裏には、数え切らない幾度の試行錯誤が横たわっています。何度も打ち続けた施策が美談のように語られるわけです。
長い旅になるので、その過程を楽しむことが重要です。大きな目標、例えばユーザー数を数倍にするような目標を立てたとして、無茶な目標と思ったけれども1年程度で思いの外、達成しまった時に 、達成感がやってきます。もう自分の役目を終えたと言って、他に移ることも一つの手かも知れませんが、さらにさらに高い山を設定して上り続けるのも良いと思います。一つの目標の次には、また次の目標が待っています。これは達成したいビジョンの通過点にすぎません。
何が言いたいかというと、目標を達成する旅に達成感と虚無感で喜怒哀楽を繰り返すのではなく、長い長いプロダクト開発そのものを楽しみ、ビジョンの実現に向けてみんなで高い高い山を登っていく、そうに考えた方が僕は人生が豊になるのではないかと思っています。
PdMには美意識が必要
PdMには「美意識」が必要だと考えるようになりました。「美意識」とは何か。僕が美意識を考えるきっかけになった本を引用します。
物事の判断を、理性だけでは無く「快・不快」といった感性を用い、自分の中での明確な判断基準を持って意思決定を行う事
もっと詳しく知りたいという方は是非本を読んでみてください。プロダクト開発において、プロダクトを触った時に良いと思うか、悪いと思うかを判断する基準のようなものです。本質を見抜く、審美眼のようなものだと思っています。そして、その美意識は明確なロジックでは表すことができないのです。美意識については、本に委ねるとして、なぜそのような判断基準が必要なのか。
Goodpatchさんの記事を引用します。
同じような製品やサービスに溢れ、差別化が難しい現代。ヒット商品やサービスを作るためには、利用者の行動や本質（インサイト）を理解し、コンセプトやストーリーなどを使い、新たな驚きや感動・喜び、体験の心地よさ・使いやすさ・便利さといったエモーショナルなアプローチが必要になってきています。
技術が進み、プロダクトをリリースするハードルが大幅に下がりました。例えば、メディアを立ち上げるならWordPressでプログラミングを使わなくてもリリースできますし、簡単なwebサイトならSTUDIOを使えばイケてるサイトを瞬時に作ることができるようになりました。もちろん、複雑なアプリケーションを作る手法やフレームワークが発達したことで、革新的なプロダクトが出てもすぐに真似されてしまう世の中になりました。その結果、機能的価値はすぐにコモディティ化してしまうようになりました。
ロジカルな考えでプロダクトを作ると、みんな同じ考え方をすれば作れてしまう世の中ではイタチごっこを繰り返すだけです。そこで重要なのが、美意識だと思っています。コモディティ化したプロダクトに情緒的な価値や、他の人がロジカルな発想では思いつかないようなことを良いと判断することができる能力なのかなと考えています。
美意識を磨くためには何をすればいいのか、美術館に行くなども方法ですが、僕なりの考えは良いプロダクトを沢山見ることだと思っています。海外には優れたプロダクトが沢山あるので、それらに多く触れて、なぜそのユーザー体験、デザインに至ったのかを考えることが良いと思っています。MEZONの梶谷さん (@kajikent) の記事を引用します。
まずは自分で体験してみる
自分が担当しているプロダクトあるいはこれから新しく創るプロダクトにおいても、toCあるいはtoB問わず、まずはそのプロダクトが何を解決するのかを考えて、自分がユーザーになってみることが大事だと思っています。
例えば、クラシルはレシピが動画でわかりやすいというプロダクトです。わかりやすい例は自分で料理をしてみることです。まずはテキストと写真だけの料理を作ってみて、次には動画を見ながら作ってみる。そうすることで、動画でわかりやすく思った部分と、実はテキストと写真だけでもわかやすく作れてしまうレシピもあることに気がつくかも知れません。
自分がオフィスで想像していることはあくまで想像に過ぎません。いくらホワイトボードを使ってユーザー体験を書いてあれこれ想像したとしても、自分で実際に体験してみるとでは、得られる情報の質が異なってきます。
例えばですが、人事向けの作業効率ツールを開発するとします。その場合は、1週間でも1ヶ月でも自分の人事業務をやってみることをおすすめします。実は簡単そうに見えて時間がかかっていることや、難しいと思っていたことが簡単に解決してしまうソリューションがすでにあり、開発しなくても良い機能だったかも知れません。それは自分で体験してみないと、本当の意味で腹落ちしていないわけです。
難しいかも知れないですが、自分が欲しいと思う物を作ることは間違っていないと思っています。自分も一人の人間として、プロダクト開発のエコシステムの一員であり、紛れもないユーザーなわけです。自分が心から欲しいと思うものは、自分以外誰も欲しいとは思わないというわけではないのです。たとえ、自分起点だったとしても、その尖ったアイデアがマスに広がり、多くの人に使われるようになった例は世界でも多いと思います。まずは、自分が心のそこから欲しいと思うかどうかを問いかけましょう。
常に改善を心がけ自分自身もアップデートする
プロダクト開発は長い長い戦いです。一つの機能をリリースしたとして、もしもユーザーにヒットしたとしても、もしも競合サービスがいればすぐに真似てくると思います。また、最初は好んで使われていた機能も数年後には時代遅れの機能になってしまうこと可能性があります。常に外部環境を広く観察し、他のアプリの動向を把握して、自分のプロダクトにおいては何が正解なのかを考え続けなければなりません。
そして、自分自身の思考もアップデートして行く必要があると思っています。情報は日々アップデートされています。日々触れる情報量もかなり多いと思います。そのため、プロダクト開発における手法や考え方もアップデートされています。つまり、一つの概念に執われることなく、自分自身の考え方さえもアップデートしなければ、戦っていけない世の中になっていると考えています。極端な話、確かなロジックがあれば昨日言っていたことと、今日言ってることが異なっても良いと思っています。
リリースの門番として100点を諦めるな
PdMはプロダクトの成功に責任を持っています。そのため、その責務を果たすために、意思決定の権限も持っているいると思います。つまり、何を開発するかのリリースについても権限を持っていることと思います。そのPdMが80点の機能ばかりをリリースしていてはプロダクトはその魅力をどんどん落として行ってしまいます。
弊社での取り組みで、CXOの坪田さん (@tsubotax) を引用します。
毎週水・金曜日に開発中のデモを実機で触ってレビューするプロダクトレビュー会を始めました。開発チーム皆でポチポチ触って話す会です。
今は、そこで通過しないとリリースできない仕組みにしましたが、その際にNG理由を言語化する事が品質基準の目線合わせになります。
僕の場合は、NGの時ほどわかりやすく言語化するように意識してます。
チームが肥大化してレビューが属人的になると、伝言ゲーム化したり、レビュー待ちで開発ブロッカーになると、メンバーのテンションが下がるので、クラシルらしさを話しながらチーム文化として品質基準を醸成していく事を意識してます。
個人間で品質の100点の基準は異なります。その人から100点だったとしても、自分からしたら80点だと思うことがあった場合に、妥協してリリースするのではなく、しっかりとなぜ80点なのかを言語化して伝えて、100点の基準をチーム内で合わせておくことが大事です。
リリースの期限もあると思いますし、ずっと品質をあげていてリリースできなかったでは元も子もないことになってしまうので、100点の基準合わせて、いつまでにレビューをしないと100点に達しないのかを逆算して考えて、スケジューリングしていくのもPdMの役割だと思います。
プロダクト開発のエコシステム
2019年7月に催された「PxTX」というアトラエさんが主催していたイベントで、Product x Teamという回を聞きました。その中で、深津さんが「プロダクトをエコシステムとして捉える」という言っていて、とても興味深かったです。
上手く言葉で表現することができないのですが、プロダクト開発において、今まで自分は開発者とユーザーというように壁を設けてしまっていたと感じました。本当は運営している僕たちもプロダクト開発のエコシステムの中では同じであって、運営の声はバイアスがかかっているかも知れないが、真の声の一つなんだと思いました。そして、ユーザーも一緒にプロダクトを伸ばしていく一員であって、巻き込んでいかないといけないと思うようになりました。
バッターボックスに立ち続ける
PdMに限らずですが、個人として成長していくためには、バッターボックスに立ち続ける、つまり試合に出続けることが大切だと思っています。
プロダクト開発において、試合に出るというのはどういうことかというと、自分が全ての責任を持ち、アクションを実行していくことです。当たり前かと思いますが、これを本当にこなしていくにはマインドセットが重要です。何かアクションを起こして、失敗してしまったとき、心の奥底でどこか自分以外のところに要因を見つけようとしていないか、チームの誰かが失敗した時に、自分には全く落ち度がないと切り分けてしまっていないか。バッターボックスに立つとは、圧倒的な自分事化をしていった先に、意識的に自分の中でけじめをつけることだと思っています。
プロダクト開発は失敗の連続です。なぜ、失敗したのか。次に失敗しないためにはどうすべきか。チーム内で同じ失敗をしないように、学び続けるためにはどうすればいいか。これを常に考えて、実行していければ、全て自分の血肉になっていると思います。もしも、今の組織でバッターボックスに立つことができない。つまり、自分事化しアクションを実行することが難しければ、組織を変えてでもバッターボックスに立つことが重要だと思います。
妥協の産物を生み出さないためには
PdMは施策を実施する時に、ステークホルダーの利害関係を調整することがよくあります。もちろん、全ての利になるような解決策が思いつけばいいですが、二律背反になってしまうこともあります。
よくある例だと、広告収益とユーザー体験の両立でしょうか。広告収益を上げるためには、良い出面を確保することが必要だとした時に、それはユーザーの主要なアクションの文脈の中に仕込まれている時があります。代表的な例では、記事を見ようとすると広告が表示されるなどでしょうか。ユーザーからしたら興味がない広告によって、今すぐ読みたい記事が阻害されてしまうことはユーザー体験を損ねていることになります。ですが、持続可能なプロダクトにするためには、利益を出さなければなりません。
これはわかりやすい例かも知れませんが、利害関係が複雑に絡みあったケースも存在します。各ステークホルダーの利害関係の狭間にいる時に、絶対にやってはいけないことは、多数決や各ステークホルダーの妥協点を見つけることです。PdMは常に組織としての最適解を実行していく立場にあります。もしも最適解を選択した時に、何かを優先して、何かを捨てなければならない時は、捨てるものを追っているチームメイトを説得しなければなりません。本当に良いプロダクトにしたければ、これを恐れていてはいけません。戦い続けて、妥協の産物を生み出さないようにしなればならないわけです。
マインドシェアを捧げる
ミニCEOとも言われるPdMは、チーム内の誰よりもプロダクトのことに詳しくなっていなければなりません。というのは、各部門の情報の非対称を取り除く情報の集約地点となっているわけですから、自然とPdMに入ってくる情報はチームでもっとも多くなると思います。物事の点と点をつなげていき、常に組織としてのチームとしての最適解を出していくには、日々更新される組織内の情報をインプットして自分の中に落とし込んでおかなければ正しい判断ができないと思います。
だからこそ、PdMは常にプロダクトの考える、つまりマインドシェアが必然と奪われていきます。変化が激しい世の中において、意思決定のスピードが落ちることと、行き当たりばったりの意思決定をしていれば、プロダクトの終わりが待ち受けています。そうならないためにも、PdMは常に思考して自分なりの答えを持っているあるいは答えることが可能な状態にしておくことが求められます。もしも、PdMが頭の回転が早い人だと思ったなら、ちょっと違うかも知れないと思うのは、それはすでに思考済みということが多くあるからです。
チームの生産性を最大にする
組織に目を向けてチームの生産性を高めていくことは、どのチームにおいても取り組んでいることだと思います。何でもやるスタンスとはいえ、PdMがどこまで関わればいいのか、僕も答えが明確にあるわけではないです。
一つ明確に思うことは、いわゆるヒューマンマネージメントにPdMが時間を割くことはあまりしない方がいいのではと考えています。ヒューマンマネージメントには、メンバーの目標を設定し、評価することで成長を促して、スキルアップによる生産性の向上が期待できます。しかしながら、しっかりとヒューマンマネージメントとプロダクトマネージメントの責務を分けて役割分担をする方が良いと考えています。
小さいスタートアップですと、プロダクトを見ることとそれを開発するチームをマネージメントすることがセットになっているケースもあり、組織が小さくリソースがほとんどないうちはそれが最適解であると思うのですが、組織が大きくなれば、当たり前ですが組織について時間が使うことが増えます。脳のリソースを100%、プロダクトに集中させるためには、PdMはプロダクトのことにフォーカスすべきだと思っています。弊社では、VPoEを設置することで組織のマネージメントは明確に役割分担をしてします。
PdMが生産性をあげるために時間を使うべきは、生産性の障壁となることとを取り除くことと採用だと考えています。プロダクト開発における生産性の障壁は部署間のパスの設計という大きなものから、細かい依頼の整備など色々ありますが、本質的には開発リソースを本当に今行うべきことに集中させることです。棚卸していくと、結構多くの時間が開発以外の時間に費やされていることがあります。そこを整備していくことが生産性をあげることができると思っています。採用に関しては全員でコミットしていった方がいいと思っているので、PdMもさらに魅力なプロダクトにしていくことで、力を入れていきましょう。
何をするかよりも何をしないか
スティーブ・ジョブズの有名な名言とされている言葉があります。
最も重要な決定とは、何をするかではなく、何をしないかを決めることだ
選択と集中と言い換えることもできると思いますが、PdMのもとには日々様々な話が入ってきます。その度に、常に自分のToDoに追加していたら、時間がいくらあっても足りませんし、本当に大事なことを考える時間が削がれていきます。そのため、もっとも大事なもの以外は、しないと決めてすぐに脳のリソースを空けることが重要です。
一番大切なことは、積まれたToDoをこなしていくことではなく、プロダクトを少しでも成功に近づけることです。そのためには、何をしないか、何にフォーカスするかを決めて、先導していくのはPdMしかいないと思っています。
チームが何を目指すかを明確にし言語化しておく
PdMはチーム内の指針です。プロダクトがどのような方向性を向いているのかを常に示し続けていく必要があります。それはなぜかというと、チームが自走できている状態とは、各々が目指す方向の認識が揃っていないと難しいと思っているからです。
方法はそれ一つだけではなくて、階層構造を作り、指示をそれに沿ってとしていく部隊のようにチームを指揮してプロダクト開発を行う方法もあります。しかしながら、変化の激しい世の中において、一人の指導者を起点として指示を落としていくスタイルには限界があると考えています。そこで、一人一人が適切に権限移譲された中で意思決定して自立して動いていくことの必要性が高まってきて、その判断基準として、僕らはなにを目指すべきかを持っていることが必要だと考えています。
ちょっと文脈は違うかも知れませんが、深津さんのこの記事が好きです。
弊社ではプロダクトのロードマップが可視化されていて、短中期的には何をすべきかがわかるようになっています。
長期的には、クラシルの中でモノが買われる世界 (食品EC) を作りたいという目標がありますが、そこまでのロードマップが図表できるレベルで可視化できているわけではないのですが、遠く遠くに立っている旗を目指して、不確実性を一つ一つ落としながら進んでいます。
PdMはインプットし学び続ける存在
変化の激しい世の中に僕らは生きています。情報社会なので、情報の有無が死活問題になることもあります。PdMはプロダクトの命運が託されているので、アンテナを高く張り、情報を常にインプットし続ける必要があると思っています。自分が行っている情報を取得する方法を3つ紹介します。もしももっと良い方法がある場合はこっそり教えてください。
まず、情報感度が高い同種のコミュニティにいることだと思います。delyにいると、自分以外にもアンテナを常に張っているメンバーが多く、様々な情報が入ってきます。しかも、その情報がかなり新鮮なので、生きた情報なんですね。ネットに転がっているような情報は、装飾された良い部分だけを切り出した情報であることが多いです。そのため、情報の鮮度が重要で、それは利害関係が一致したメンバー同士でしか伝達されないこともあると思っています。
もう一つに、社外に飛び出すことです。社内だけでは情報リソースは均質化してしまって、同種の情報しか入ってこないこともあります。そのため、多くの人にあって、話すことを心がけています。当たり前ですが、情報を教えてもらうのだから、僕からも何かしらのgiveができないかは常に考えています。大変嬉しいことに、常に教えてもらってばかりなので、いつかは恩返ししなければいけないと思って生きています。方法はほとんどがTwitterやFacebookのDMです。話を聞いてみたいと思ったら、まずは行動に移すことを心がけています。迷惑をかけてしまうことも多いですが、、、
最後に、当たり前ですが、本や記事を多く読むようにしています。読書は苦手なので、読みやすいような実用書などを読んでいますが、基本的には薦めてもらった本は全てポチッとしています。あとはTwitterを活用して、自分よりも情報集取をしている人のリストを作って、定期的に情報を収集しにいっています。
視座を高く
「視座」の僕の解釈ですが、プロダクト、組織、社会をより俯瞰してみて、それらをシステムとして捉えることだと思っています。自分個人、職務領域のチーム、部署全体、関係部署、会社全体と見る視点を上げていくことで、どこがどのような関係性を持っているかを俯瞰して見ることができます。
視座を上げるシンプルな方法は、もしも上司がいるならば、上司ならどうすると思うかを考えることです。例えば、自分は〇〇が正しいと思っていたけど、上司がいっていることは違うことを言ってるぞという時、見えてる範囲が異なることが多いです。自分の中での最適解と、会社としての最適解が異なる時、自分の持っている情報では会社としての意思決定を導くには不足しているからだと思っています。
PdMは常にプロダクト全体のことを考えていることが求められます。しかしながら、それだけではなく会社全体、もっと言えば会社を取り巻く競合環境や株主の利害関係まで視座を上げれば、さらに最適な答えが見つかるかも知れません。
常に正直で誠実であれ
PdMは多くの部署との調整役を担うことが多いと思いますが、その中で重要なことは、正直であることと誠実であることだと思います。当たり前かと思いますが、柔らかいコミュニケーションができないと、話しかけづらい人と思われてしまいますし、人によってコミュニケーションの仕方を変える人とであれば、そういう人と思われてしまいます。
自分が間違っていた場合は、その間違いを認めて、謝罪が必要ならば正直に謝る。誰に対しても誠実な対応で、統一的な意思決定をしていく。当たり前のことかもしれないですが、結構大事だと思っています。
人それぞれ、主張には文脈があるので、その文脈を汲み取って話をする必要する必要があります。slackのコミュニケーションで文脈を把握することが困難な場合は、対面で話をするように心がけています。
孤独と孤立
PdMをしているとたまに、ステークホルダーが多く難しい問題にぶちあたることがあります。そこに自分の実力が伴っておらず、一人で解決を模索することがあります。そして、プロダクトについて考えれば考えるほど、自分よりも考えている人がいないのではという状況に陥ることがあります。深夜とか休みの日まで色々考えていると、急激に孤独を感じることがあるんですね。
しかしながら、孤独と孤立は違うということを認識していないと、孤立というダークサイドに墜ちることになります。孤独は組織の中で、独りになる感覚のことで、僕は悪いことではないと思っています。孤独とは自分自身との戦いであり、打ち勝つ必要があります。誰しも、通る壁であると思っています。
孤立とは、自分しかいないと人間関係を遮断してしまうことであり、そうなればチームで開発している意味がありません。そして、いずれは誰も助けてくれなくなってしまいます。
自分に能力が足りないなら頼って任せる
PdMは何でもやる姿勢が大事ですが、最初のうちは何もできない自分に苦しむことが多いです。PdMに必要なスキルセットは全網羅的です。その時に必要なスキルを場面に応じて取得していく必要があります。しかし、全てのスキルをつけていくには時間という制約もあります。
PdMに必要なことは、全てを完璧に自分で実行するのではなく、自分ができないことをチームで補いながら一つの目的に向かって進むことです。全てを自分で解決する姿勢も良いとは思いますが、本質的には成果を出してその結果としてプロダクトが成長することです。責任感を持つことは良いことですが、課題解決するためにはどうすればいいのか、自分の範疇を超えて考え、頼れる仲間に背中を預けて任せましょう。
登るべき山によって答えは違う
みんなが皆、同じ山を登らなくても良いと思っています。Ruby on Railsを生み出したDHHの記事を引用します。
次のFacebookを目指さなくても良くて、他の方法でも幸せになる方法はあるということを教えてくれる良い記事です。
1,000年続く森を目指すのか、7日間の命でも輝きを放つセミを目指しても良いのです。時として、特に自分たちが上手くいっていない時は、隣の芝生は青く見えやすいのです。しかし、お隣さんが登ろうとしている山と自分たちが登ろうとしている山が一緒なのかは認識しておかないと、抱かなくていい感情に支配されることになります。そんな時間を過ごすよりも、自分たちが登ろうとしている山を自分たちのスピードで登っていけば良いわけです。
習慣化することで続けられる
PdMと路線が外れますが、例えば社会人になって何かを勉強しようと思った時に、三日坊主になってしまうことはよくあると思います。勉強と誓っても、日々の業務に追われていると、なかなか手が出せないものです。続けられる方法は、習慣化にあります。習慣化させるためには、自分のカレンダーに毎週毎週〇〇をすると登録し、必ず実行する必要があります。明日が大事な機能のリリース日だったとしても、カレンダーに書かれていることは実行しなければなりません。そこだけ守れば、必ず習慣化することができると思います。その習慣を続けることで、気がついた時にはしっかりと何かを成し遂げられる人になっていると思います。
ひたすら内省を繰り返す
僕は何か失敗すると、slackの自分のDMに何がよくなったのかを書くようにしています。そして、それが本当に自分の中で腹落ちするまで、何度も見にいくようにしています。
なぜ、失敗してしまったのか。何が良くなかったのかを文脈を含めて理解し、自分の中で反芻する必要があります。全てを自分事化して、内省しまくることで、同じミスを簡単にはすることがなくなります。そうすれば、今度はちょっとだけ上手くいく確度が高まると思います。そういうことの繰り返しです。
休むことは罪ではない
日々、脳リソース的にハードワークをしていると、何もしていないことに罪悪感を感じることがあります。ほとんどの方は感じないかも知れませんが、僕は休むことに罪悪感というか、成長していない自分に対しての焦燥感があります。今、自分のライバルたちは必死になって頑張っている。それで自分はいいのかと考えることもありました。
結論として、休むこともワークの一部であると考えるようになりました。マインドシェアを捧げ続けることは非効率になる時があります。そういう時は休んだ方が効率が良くなることもあります。休む時は休む、そういうタスクだと思うことが大事です。
自分が一番安らぐ方法を知る
PdMに限らず、スタートアップで走り続けている方々、仕事が終わっても土日でも全てをかけて戦っていると思います。僕もそうでした。土日でもほとんど仕事をするなり、電車の中でもプロダクトのことを考えていたりしました。
しかしながら、それも3年くらい続けるとメンタリティの支障からのフィジカルにも影響を及ぼしてきます。多分、俗にいう自律神経失調症のような症状が生じ始めます。ハードに働くことも大事ですが、サスティナブルな働き方にしなければ、本当に成し遂げたかったことが志半ばで離脱を余儀なくすることもあると思います。
テクニカルな方法ですが、自分はこれをすれば大丈夫というような切り札を持っておくと良いと思います。僕の場合は、ジムに行ったり、1日中マンガを読んだり、温泉や銭湯に行ったりです。これをすれば自分は大丈夫だという選択肢を持ち、不調がでたらすぐにその方法を取ってください。絶対に無理はしてはいけません。大きな目標を達成するためには、ちょっとの休息も必要です。
逆算思考
人間は元々、未来を創造して逆算して考えることが苦手です。そのため、訓練する必要があります。そもそも、逆算思考がなぜ必要かというと、目標とのギャップから現状を認識するために、目標から逆算して、いつまでに何をしなければならないのかを把握するためです。スマートニュースさんの記事を引用します。
また、大きなジャンプを生むために、目標は逆算で設定しています。
「1年後にユーザーあたり収益を3倍にする」といった厳しい目標を立てて、そこから逆算して考えるということを日々行う。これは、非常に重要な状況設定だと思います。
また、リスクを取ることも大事ですね。人間ってリスクを取れない生き物で、確度が高くて小さく成功するものを選びがちです。
数年後に実現したい姿がある場合、そこから逆算して1年目にはどこの状態になくてはならないのか、あと半年でどこまでいってないと黄色信号なのか、そもそもこの戦略で目標を達成することができるのかを知ることができます。もしも、現状の方法では目標を達成することができないとわかれば、考え方を変えて施策を打つ必要があります。
相手が自分にどう動いて欲しいかを考える
チーム開発をしているからこそ、仲間が自分にどう動いて欲しいのか把握し、その穴を埋めるように動くことでチーム内の生産性が高まります。ベンチャー界隈で人気が出てきているサッカー漫画、アオアシは実に多くの教訓を教えてくれる名作です。是非読んでみてください。
サッカーは11人で相手のゴールまでチームでボールを進めるスポーツなので、個人間の連携が勝敗を分けます。相手のディフェンスを戦略で崩して行く時に、その戦略がチーム全体に伝わり、以心伝心しているかのように、次の一手では自分がどこにいればいいのかという立ち回りを考えることは、実にPdMに似ていると思っています。そのようなチームの潤滑油が機能しだすと、結果的にチーム全体の機動力があがり結果としてゴールを生むことになります。
信じてやり抜く力
PdMには、自分のプロダクトの可能性を諦めずに信じてやり抜く力が必要です。まず、プロダクトの責任者が生半可な気持ちでは確実にそのプロダクトは成功しません。そして、プロダクト開発はいつも上手く行くわけではないわけです。苦しい時も必ずきます。PdMは既存価値の改善による連続的な成長と同時に、非連続的な成長を考える必要があります。しかしならが、そう簡単には行かないので、何度何度も考えたことをユーザーに問うて、答え合わせをしていく必要があります。自分のキャリアの通過点だとか、別に失敗しても自分は終わらないと思わずに、このプロダクトが失敗したら、全てが終わるくらいの意気込みで臨む方が上手くいく確度は高くなると思っています (もちろん失敗したからといって路頭に迷うことはないのでご安心を) 。
手段ではなく目的を達成する
本当は目的を達成する手段であったことが、いつの間にかそれが手段になってしまっていることがあります。その手段を実現するにはどうすれば良いのかに目が向いてしまって、本当に解決したかったことがおざなりになってしまうケースは実は多くあります。
そういうケースではだいたいのことが上手く行きません。自分で気づくことも容易ではないのでは、誰かに壁打ちしてもらいましょう。そうすると、一歩引いて客観的な視点が戻ってくるので、本当に達成したかった目的が思い出されます。自分の頭の中で全てを思考せずに、同じような立場の人に壁打ちをしてもらうことは非常に重要です。考えが煮詰まってしまった時は是非試してみてください。
自分の思考範囲を超えろ
自分の手札だけで勝とうとしてしまうことはよくあります。この要因は、何個あって、大きくは視座が低いこととプロダクトの未来を逆算して考えきれていないからです。
視座が低いというのは、自分の枠組み内でしか思考ができていないので、その中での解決策しか思いつきようがありません。視点をあげて、自分の部署以外を巻き込んで解決することはできないか、はたまたどこかの会社と協力して解決する方法はなにかを考えると思っても見なかった解決策が思い浮かぶかも知れません。
逆算して考えるということは、1年後自分のプロダクトがどのような状態になっていないといけないというところから、半年後にはここ、来月にはここというように、目標から逆算していって考えることです。そうすると、そもそも今の戦い方では到底目標が達成できないということがわかるかも知れません。その場合、ぶっ飛んだような施策を考えないといけないわけですが、それが実は最善の解決策になるかも知れなかったりします。
勝ち癖をつける
勝ちに不思議の勝ちあり、負けに不思議の負けなし
という楽天ゴールデンイーグルスの名誉監督、野村克也さんの座右の銘があります。負けた要因は容易に考えることができるけれども、なぜ勝てたのかはわからない時もあるというものと解釈しています。一方で「失敗は成功のもと」という言葉もありますが、これは失敗をし続ければいつか成功するというようなものではなく、失敗の中での学びを通して、同じ失敗をすることなく、成功の確度をあげることだと思います。つまり、失敗 = 学びの機会として"失敗"と捉えていないです。今年ラグビーが話題になりましたね。とても良い記事があったので、引用します。
ジョーンズ氏に以前インタビューした時、「強いチームと弱いチームの大きな違いは？」との問いに対して、「勝ちたい」と思う気持ちに加えて、「“有意義な練習を重ねた”という自信があるかどうかだ」と答えていました。実際の試合の場面を想定していないランパスのような練習は意味がない、というわけです。
前提としてチームに勝ちたいという意思を持たせることも重要ですが、そしてどれだけ有意義な練習を重ねられたか、つまり学びを得られたかということが重要です。プロダクト開発においては、練習はプロダクトが世に出る前の状態として捉えるならば、その中でどれだけの学びを得られるかを模索する必要があると思います。それがプロトタイプを用いたユーザビリティテストなのか、自分たちの中でのプロダクトレビューなのかは手段ですが、どれだけ有意義な学びを得られたのかというのが重要です。
VPoPという役割について
弊社ではVPoP (Vice President of Product) という役職を設置しています。この役割の責務は「事業の短中期的な開発を主導し、事業目標の達成に責任を持つ」としています。PdMという役割が、組織のフェーズやプロダクトのフェーズで異なりますが、事業が多角化したフェーズにおいて、各プロダクトにつくミニCEOという役割だと僕は考えています。しかし、まだ正解をもっていないので、模索している最中ではあります。同じようにVPoPとして立ち振る舞っている方がいたら、是非話をさせてください。
最後に
明日は、弊社デザイナーのカッシーさんが「デザインとエンジニアリングをつなぐために重要な3つのこと」というタイトルで記事を書いてくれます。お楽しみに。
もし、弊社に興味を持っていただけたら是非とも話を聞きにきてください。会社紹介の資料をご紹介します。
CXOとVPoEへのインタビュー記事もあります。
では、良いお年をお過ごしください。
オススメの書籍や記事
蛇足ですが、この記事で紹介していない、最近読んだ本や記事で良かったものを紹介します。前にも紹介したnoteがあるので、合わせてご活用ください。時間の都合上、雑に貼り付けるだけということをご了承ください。
この記事が気に入ったらサポートをしてみませんか？