PMの仕事と気持ち入門
プロダクトマネージャーAdvent Calendar 2022 の14日目の記事です。
締め切りギリギリになった深夜のテンションで、謎の語りかけ口調の記事を書いてしまいました。
やあ、はじめまして。プロダクトマネージャーのkamyuだ。
君が新しくプロダクトチームに入る子だね。
君はエンジニア？デザイナー？プロダクトマネージャーの卵？
…まぁ、どれでもいいか。
今日は、プロダクトマネージャー(PM)がどんなことをしているのか、どういうところに興味があって、どういうところに興味がないのか、知ってほしいなと思っている。
「PM間でより良い手法について議論して高め合う」よりも、「PMではない人がPMの仕事と気持ちを知る」ほうが効果的な気がしているんだ。
仕事1: 価値をきちんと把握する
いいかい？PMってのは、「プロダクト価値を高める(ためになにをすればいいのか考える)」って職種なんだ。
…
―――ああ、すまない。これだけ言われても、よくわかんないよな。
具体的にはどういうことを考えているのか、説明させてくれ。
プロダクトの価値を高める方法は、基本的には「機能の追加開発」をしていくことになる。開発には工数がかかるから、価値を高めるには、工数(コスト)をかける必要があるということだな。
ただ、コストをかけても価値がほとんど上がらなかったり、全く上がらなかったりすることは本当に多い。場合によっては、価値が下がってしまうこともある。
でも、作る前から「あんまり価値がないけど、やろうか！」って思ってるわけじゃないよな。「この機能が必要！」って信じて作ってるよな。
え？ 「価値なんてないと思っていたけど、社長の鶴の一声で作ったものもある」だって？そっか、大変だったな。今度飲みに行こうか。最近はTwitter社もそんな感じらしいぞ。
思ったより価値が上がらないのは、顧客のことを考えられていなくて、課題のインパクトを見誤っているからなんだ。「課題と価値を正しく把握すること」が、プロダクトマネージャーの最初の仕事。
これには、やっぱり、顧客の声を聞きまくるのがイチバンだな。ペルソナやカスタマージャーニーマップなどを通して顧客になりきるのも有効だが、やはり自分というバイアスはなかなか除去できない。
ん？「我々は長年やってきているので十分把握している」だって？
バカヤロー！そんなこと言ってるからゴミを作ることになるんだよ！！！
仕事2:優先順位をつける
さて、インタビューを繰り返した結果、たくさんの課題とそれぞれの解決価値がわかってきた。次、どうする？
価値が変わらないものや下がるものはやらず、価値が上がるものは全部やりたいよな。それも、理想を言えば「念じるだけで明日の朝には全部出来てる」くらいだったら最高だよな。
まぁでも、そんなことはないからさ。優先順位をつけることになるわけだ。
優先順位をつけるには、価値の他に、コスト感も必要になってくる。
コストを想像するには、価値の解決方針がある程度わかっていないといけない。
というわけで、上の図のように、課題、方針、コスト感が表になっているようなイメージだな。この表を頭の中に作ることが、プロダクトマネージャーの第二の仕事。と言っても、こんな単純化できるわけじゃないんだけどな。雰囲気だよ雰囲気。
なお、方針やらコスト感やらについては、正確なところはエンジニアやらと相談しなければならない。が…経験上、この段階だと、プロダクトマネージャーがある程度予想できた方がいい。内容も時期感も不確実な状態で他チームに見積もり依頼する、というのはお互いなかなか辛いからな。
コスト感を予想しやすいという意味で、エンジニア出身のプロダクトマネージャーは有利だと思う。また、後述するが「プロダクトチームへの引き継ぎ」の観点からもそう感じるよ。
さて、ここの優先順位づけの具体的なやり方については…
ちょっと話が長くなるから、またの機会にとっておこうか。
まとめるとだな。
課題とインパクトを正しく把握する
インパクトとコスト感から、優先順位を決める
ってのが「プロダクト価値を高めるために何をすればいいか考える」の正体、PMの仕事ということだな。
+α: プロダクトチームに引き継ぐ
以上がPMの仕事の本懐というわけだが、もう一つやることがある。
自分ですべてをやるわけではないから、決めた開発案件をどこかのタイミングで「プロダクトチーム」に引き継ぐことだ。
ただ、ここの引き継ぎは俺も結構苦労していてな。ずっと試行錯誤している気がするよ。
もう少し、時間はあるかい？ちょっと愚痴みたいになるかもしれないが、よかったら聞いてほしい。
「Whyだけ深くする」と出てくる問題
引き継ぎでは、PRD … Product Requirement Document を作ることになる。会社によっては別の名称になっているかもしれないが、まぁ要は「なぜこれをやるのか」「できなければならないこと(要求)はなにか」などが書かれている資料だな。
これをどこまで「深く」「広く」書くか、というのがなかなか難しい。
深さ広さというのは俺がたった今思いついた言葉だ
・深さ → その結論に至った経緯をどこまで詳細に書くか
・広さ → Whyだけ書くのか、What的なことまで踏み入れるか
「深く狭く」つまりWhy側を厚く書いて、後は任せた！…とできるのが理想ではあるのだが、やはり通信不確実性は消せないので、どこか 伝えきれていない部分や違う解釈をされる部分がでてくるんだ。
一度「任せた！」をしたはずなのに、「あああごめん、そこはこっちで」だとか「そこまでは要らない」だとか後から言うのは、よくないよな。
特に「そこまでは要らない」というケースに困ることが多い。
「あああごめん、そこはこっちで」のほうは、きちんと説明できるしきちんと謝れるのだが…「期待価値のレベル感」は事前にはなかなか伝えづらいし、後出しだと「良かれと思って考えたものを否定する」ことにもなる (それでも言わざるを得ないが…)
また、モチベーションの問題もある。
特にエンジニアでは「自分で考えたものをつくりたい！」ではなく「で、何をつくればいいの？」という職人気質なモチベーションの人も多い。長ったらしくWhyだけ書いてある資料なんて、きっと読む気にもならないし、「それを読んで考えさせる」というのは、その人の強みを潰しているとも思う。
「Whatまで広く書く」と出てくる問題
こういった問題は、PRDをWhatまで染み出させることで解決できる。
つまり「要件定義書」に近くしていくということ。
ところが、要件定義書に近くしていくと、それはそれで問題が出てくる。
WhatがPMの脳内に閉じてしまうとか、いろいろあるが…
一番の問題は、「PMがその機能にかかりきりになる」ということだと思う。「何を作るべきか」という部分に時間をさけないほどに。
最近は経験値も増えてきたので、自分のなかでは「誤解を極力避けられて役割分担をきちんとできるPRDテンプレート」が固まりつつある…
んだが、もう3000字か。よかったら、また今度紹介するよ。
おわりに
でも、一番大事なのはツールとかではなくて、「PMはプロダクトチームに寄り添う、プロダクトチームはPMに寄り添う」ということかなと思う。この記事を読んでくれたあなたが、PMのことを少し考えられるようになってくれていたら嬉しいな。
この記事が気に入ったらサポートをしてみませんか？