よくありがちなメンバーからも施策をあげよう
チームでプロダクトを開発しているとよくメンバーみんなが納得する施策をとか、メンバーみんなで施策をあげようと出ます。一見きれいなことに見えますがこれは個人的には危険な状態だと思います。メンバーの方に施策が向いているからです。開発チームが施策を行うのはユーザーのためであり、チームメンバーのためではありません。そういう意味ではメンバーの納得は必要ないです。
またプロダクト開発は不確実なことの実証実験でもあるので全員納得したのがいい施策とは限りません。むしろ誰か一人の突飛押しもない施策が意外な成果を出したりもします。
僕は昔、こういうみんなで施策をあげようとかの意見が出るとどうも民主主義的な、かつ自分たちがユーザー自身と勘違いしているんじゃないかとちょっと抵抗感がありました。ただ最近は
- 各人が集中的に施策を出す範囲を分類する
- 施策出しと優先順位決定を分ける
をし、メンバー全員で施策を出しながら全体ロードマップを逸脱しないで圧倒的な個人が施策を考えるより良い施策立案ができるんじゃないかと思うようになりました。ちょっと今考え、最近うまく言ってるなと思う運用をまとめてみました。
いい施策はgoodな施策でもbetterな施策でもなくbestな施策
まず前提としていい施策とはなにかについてここでの個人的な見解をまとめてみます。単体で見たときたしかにあったほうがいいよねという機能、施策はめちゃくちゃあります。ただプロダクト開発のリソースは限られています。プロダクト開発における施策立案は施策を出すこと自体よりもこの限られたリソースでどの順番で開発していくかのほうが実は選択肢がたくさんあります。
プロダクト開発は便利機能をつけることではない
またプロダクト開発ではユーザーの声などを吸い上げて便利機能をつけていくのが理想ではありません。ユーザーは眼の前のニーズしか気付かないし、プロダクトは何年にも渡って運用されます。プロダクトの開発は事業として捉えて将来的にどういうプロダクトになったらよりユーザーに価値を提供できるかから逆算していくように心がけています。より便利にしていくことと長期的どういうプロダクトにするかから逆算していくのは重なるところもありますが＝ではありません。逆に直近の声に偏りすぎると時代の動きに乗れずに時代遅れのプロダクトになる可能性もあります。例えばPCからスマホにwebサービスがシフトしていく中でPCの既存ユーザーの声を聞きすぎて新スマホ発サービスに市場を取られたサービスはこれに当たるかもしれません。
PMとメンバーの見ている情報の差
となったときにPMはより広く、そして長く視野を持たないといけません。そして各実装者、メンバーのやっていることを把握しているPMのほうが各メンバーよりもこの視野は広くなりがちです。逆に視野の深さは各メンバーのほうが良くなります。ここにギャップが生じがちです。例えばプレミアム会員を伸ばすKPIをもったメンバーからはもちろんプレミアム会員を伸ばす開発施策が上がると思いますが新規ユーザーを伸ばすのが全体の優先順位的に高い場合、後者を優先したほうがいいでしょう。しかしプレミアム会員を見ているメンバーがその全体戦略を把握していないときに自分の施策が不当に却下されたように思います。これはどちらが悪いということではなく、全体の中でなにを任しているのかをコミュニケーションできていないからです。
全体像を伝える
なのでPMとメンバーが施策立案で互いに不満を感じるパターンの一つに戦略と戦術で視点が違うというのがあると思います。施策は優先順位が重要で単体で良くてもより良いもの、今やらないといけないことをやります。そしてそれは全体像の見やすいPMの意見と専門分野で深く見やすいメンバーで視点や情報が違うため齟齬が生じます。ここを埋めるためにはPMはメンバーに全体像がなにで今なにを優先順位上位に持ってきているか、他の施策の進捗がどうかを伝える必要があります。
施策の分類とそれぞれどこの人間が一番出しやすいか
どちらが優れているという話ではなくそれぞれが見やすい分野の施策をあげ共有することが大切です。このへんのほうれんそうの大切さは脱出ゲームをするとよりわかりますｗまとめると
- 施策立案は優先順位ぎめが大切
- その優先順位は全体像が見えている人間がスピーディーにやるべき
- しかしその全体像、優先順位をメンバーに共有するのも必要
- PMが戦略、優先順位を各深い施策立案をメンバーにと分ける
- メンバーに対してどの分野の施策立案をしてほしいか明確に伝える
- その施策が全体の中でどういう位置づけと考えているか明確に伝える
が大切なのかなと思っています。もうちょい具体的に言うと僕はゴールとなるKPIとその構成要素を書き出し、どの数字、分野の施策を立案してほしいか提示しています。そして各人があげたものを優先順位付けし、開発のロードマップに起こしています。圧倒的な個人がいてもSEOで細かい施策やデザイン面でのUX改善など一人で全部をカバーするのは現実的ではありません。この施策立案はメンバー各人に任せたほうがより詳細に詰めれますし、PMのスキルセットに依存しないので常に専門的なロードマップをしけます。よくみんなで施策立案するとなるとこのプロダクトの施策何がいい？となげがちですがちゃんと全体像と意図を伝え、どこを集中的にお願いしたいかを明確化することによりそういうことじゃないんだよなーを防げます。
以上最近思っていて僕も気をつけなきゃなーという半分自戒でした。
