【読書ログ】プロダクトマネージャーのしごと

こしけ
·

プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイドを読んだので気になった箇所をピックアップ。

気になる箇所多すぎ問題😇

頑張り屋さんはたくさんのものを届けられるやり手として、経営陣からは尊敬されていますが、それがビジネスやユーザーの目的を実際に達成したかどうかはまったく定かではありません。

  • アウトプットよりアウトカムが大事。働いた時間ではなくてどれだけ価値を提供出来たかを測る

やっていることとその理由をチームが明確に理解をしているか確かめるために、必要な質問や会話のファシリテーションをしているか?ユーザーやビジネスにとってより大きなアウトカムを得られそうだと思ったとき、他のチームやプロダクトマネージャーに積極的に働きかけにいくか?連絡してきたステークホルダーにすばやく、思慮深く反応しているか?

  • チームが何のためにこのタスクをやっているのかを明確に伝えられてないなあ、、、この辺が自分には不足しているなと感じる。

自分のチームは少なくとも週 1回はユーザーや顧客から直接学んでいるか?すべてのプロダクトに対する意思決定は、ビジネスゴールとユーザーニーズにもとづいているか?自分のチームは、ユーザーニーズや行動に対する理解を深めるために、定期的に自分たちのプロダクトと、それと競合・関連するプロダクトを使っているか?ユーザーニーズと利用目的は実際の自分たちのユーザーのニーズと利用目的を反映してはっきりとまとめられているか?それとも、ビジネスが想像するニーズや目的だけか?

  • ユーザや顧客から学ぶっていうところが全然やれていない、、、。

    そろそろちゃんとユーザーインタビューに向き合わないと。

  • プロダクトに関する意思決定に関しては、ビジネスのゴールには基づいていると思うけど、それがユーザの求めているものなのかは正直自信がない。

日々の仕事に追われてユーザーの現実世界から引き剥がされないようにしてください。会社とユーザーが気にしていることは違いますが、執拗なまでにユーザーの擁護者であることを忘れないでください

  • 執拗なまでにユーザの擁護者であるっていう文言いいなあ。

    プロダクトマネージャーは売り上げとかはもちろんだけど、ユーザが求めているものを提供するのが大事だもんね。

同僚が何か質問や考えがあってあなたに声をかけてきたなら、どんなにその質問や考えが取るに足らないものでも、その行動を奨励しましょう。同じように、同僚のやっていることに興味があるなら、他人の時間をもらうことをためらわないでください。

  • 他の人がやっていることに興味があったとしても、中々時間を作ってもらって聞くっていうのが出来てなかった。こういうコミュニケーションで横の繋がりも出来るし、積極的に関わるようにしていきたい。

    逆もまた然りで、声をかけられたらありがとうという気持ちを忘れない様に接していく!

その顧客は、その機能を本当に必要としているのでしょうか?開発しなかったら、本当に顧客を失うのでしょうか?開発者は顧客のニーズを完全に理解しているのでしょうか?

  • 開発しなかったら顧客を失うのか、ここまで徹底して考えていくの大事だなあ。そこまででもないのに、残業とかまでして対応とかになったらモチベ的にもしんどいもんね。

こういった制約をより理解することで、ビジネスやユーザーにとって価値のあるものを届けつつ、制約のなかで働けるようになることを意味します。

  • 制約を取り払うのに注力するのではなく、制約の中で最大限出来ることを考える。そこから成功体験重ねていき、制約を少しづつ広げていく。

ユーザーはあなたが作ろうと計画している解決策をそのまま説明してくることがありますが、必要とする理由はまったく違うかもしれません。

  • 必要とする理由を誤解したまま作ったとしても、ユーザのニーズを満たしたことにならないので注意。

最高のプロダクトマネージャーは、ベストプラクティスを実施する前に、あるいは提案する前でも、組織特有の状況について学ぶのに常に時間を取ります。ベストプラクティスを実施する場合も、小さく始め、だんだん広げていくというやり方をします。

  • 小さく始めてフィードバックを得ながらだんだん広げていくっていう考え方大事。いきなり大きく始めると始めるの自体も大変になるし、、、。

プロセスを内省し洗練する時間を作らなければ、ビジネスやユーザーにまったく価値をもたらさないでっち上げのセレモニーや儀式のせいで、結果的にチームの士気を低下させることになりかねません。

  • やりっぱなしでは無く、プロセスの振り返りをして改善をしていかないとただやってるだけになってしまう。プロセスの振り返りだと厳しい意見が出てきそうで避けてきちゃってる自分がいたからそこはちゃんと向き合う様にしないと。

世界最高の印象的で網羅的なメニューを作ることより、素晴らしい食事を作ることに集中しましょう。

  • 仕様書やロードマップを作っただけでは何も価値を提供出来ていない。

    そこから価値を提供していくのが大事なことを忘れちゃダメ

すぐに使えるプロダクト戦略は、「ユーザーは誰?」、「解決しようとしている課題は何?」、「私たちがその課題を解決するにふさわしい会社である理由は?」といった、単純な質問に集中的に答えられるものになっている傾向があります。

  • リーンキャンバスとかは割とこれに回答するのに使えそう

本当のデータドリブンの実験では、直感に従い、そのあとで直感が適切かをテストするためのフィードバックループを作るのです。

  • 何をするにも全てデータを取得してやるっていうのではなく、仮説を立ててそれが適切かを検証していく。

    データを全部集めてからってなるとどうしてもスピード感落ちちゃう。

テストが「統計的に有意」な結果をもたらしても、それがビジネスやユーザーにとって重要というわけではありません。

何人のユーザーがこれを実際に使っているのか?そしてそれにはどれくらい意味があるのか?それが大したことがないなら、「データドリブン」な実験は本当に無意味なエクササイズになるかもしれません。

  • ABテストでこの視点はちゃんと持たないとダメだな。

    統計的に優位な結果をもたらしたとしても、そもそも使っている人がほとんどいなければそれは重要ではない。そこに時間をかけるのはもったいないよね。

一般的には、「全員」の妥協点を見つけようとするより、特定のユーザーの特定のニーズを考えたほうがよいとされています。

  • 確かに少数のユーザに気を使いすぎるあまり全員の妥協点を見つけてそれを実装するよりも、多数のユーザのニーズを考えた方がいいよなあ

チームのメンバーからメッセージを受け取ったら、どれくらい早く返信がくることを期待しますか?」という質問をするところから始めてみましょう。チーム全員からすぐに同じ答えが返ってこないなら(普通のことです)、明示的にコミュニケーションアグリーメントを決めることの重要性を示す良い例になります。

  • この辺結構人によって認識が違うから、共通認識作っておくとストレスなくコミュニケーション出来そうで良さそう

シニアリーダーから質問があったときは、努めて好意的に解釈した上で、暗黙の要求としてではなく、本当の質問として扱うことにしています。また、自分自身からの質問も同じく暗黙の要求として受け取られるかもしれないことに気をつけています。

  • ステークホルダーから質問があった場合は、それをやらないといけないのではなく、どうしてそれが必要なのか?それがないと何がダメなのかなどを聞く様にする。

コミュニケーションこそが、ほとんどすべての問題の解決策の扉を開くカギだと信じています。何かが起こっているだとか、誰かが何かを考えているだとか言う人がよくいますが、「当事者と話しましたか?」と聞くと、答えは「してません」です。私からの返答は「今私に言ったことをそのままの言葉で相手に伝えてきてください」です。

  • 確かに勝手に思い込みで話してることとかもあるから、当事者と話して相手にちゃんと伝えるのって大事。コミュニケーションから逃げても何もいい事ないよね。

チームが自動操縦のように感じたら、挑戦的なアイデアや別の説明を探すことが今まで以上に重要になります。たとえ数は多くなくてもプロダクトを使うのをやめたユーザーがいれば、その人たちと会話して、何が間違っていたのかを理解しましょう。競合のプロダクトを探して、基本的なユーザーニーズにどう対応しているのかを文書化しましょう。

プロダクトマネジメントがいちばんうまくいっているときというのは、新しい課題を積極的に探し、素直な気持ちで、好奇心を持ち、先入観なく取り組んでいるときです。

  • 安定してきた時こそこの様なことを意識していくのが大事

    新しい課題を積極的に探すためにユーザへのインタビューを行ったり競合調査を行ったりする。

    安定するとこの辺全然やらなくなっちゃうし、段々無関心になっちゃうから気をつけないと

あなたがどんなに頭が良くても、プロダクトマネジメントをするには失敗することを学ばなければいけません。あなたがどんなにカリスマでも、プロダクトマネジメントをするには、言動を裏付ける行動が必要なことを学ばなければいけません。あなたの志がどんなに高くても、プロダクトマネジメントをするには、同僚をうやまい尊ぶことを学ばなければいけません。

  • 最初からプロダクトマネジメントに正解なんてないから、泥臭く失敗しながら色々なことを学んでいく必要がある。失敗する為には挑戦し続けないといけないので、これからもチャレンジをし続ける!!

まとめ

  • 今回この本を読んでみて、改めてプロダクトマネージャーがどういうことを考えていかないといけないかを少しづつだが理解することが出来た。

  • どうしても自分の性格上正解を求めてしまうのだが、プロダクトマネジメントにはそういうのは無く組織やプロダクトによっても違うものなので、色々な経験をして失敗を重ねていきながら段々成長していきたい、、、!

@koshike
好きなことをゆるーく書いていきます。