こんにちは、プロダクトマネージャー(以下PM)の adachi です。(ToDo: ここになにか面白い文章を入れる)
先日、プロダクトの目的・目標・指標をまとめた図をTwitterに投稿したところ、わりと反響があったのでこちらで解説したいと思います。
開発メンバーから「会社の戦略とプロダクトの目標がどう紐付いてるかわからない」という声をもらって作った図。
— Takashi Adachi (@asanebo_) 2022年6月1日
改めて整理する中で自分のなかでも気付きがあり、もっと早くやっておけばよかったなと思いました。 pic.twitter.com/tuedZhaZG2
この記事でお伝えしたいこと
- 会社のミッションや戦略とプロダクトの目的・目標・指標は、構造的に整合していることが重要である
- PMにとって自明に思えることでも、アウトプットしなければチームで共有できない
- 目的・目標・指標の全体構造を可視化してチームで共有すれば、「Why」の部分からチームで考えられる(はず)
- SmartHRに応募してほしい!
前提
プロダクト開発の現場というのは各社かなり多様だと思いますので、まずはどのような状況において前掲の図が出てきたのか、というコンテキストの部分を簡単にご説明します。
SmartHRは顧客向けにはひとつのプロダクトに見えますが、内部では複数のプロダクトに分かれており、いわゆるマルチプロダクトの体制になっています。開発チームやコードを分割することで機動的に開発を進められる一方、どうしても「全社の戦略に個別のプロダクトがどう紐付いているか」という点が現場からは見えにくい状況でした。
また私が担当するプロダクトでは、プロダクトビジョン、ロードマップ、OKRといったパーツは存在していたものの、それらがどう関連しているかという全体構造については、POである私の頭の中にしかない状態でした。
経緯および反省
ことの発端は、開発メンバーからの提案で開催された『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』の読書会でした。プロダクトの戦略についての章を読んでいくなかで、参加者から「われわれのプロダクトの戦略ってなんだっけ?」「会社の戦略とどう関係しているの?」といった疑問の声が挙がりました。
その場で私から「こういうことだよ」という説明をしてみたものの、そもそも今さらこの説明をしている自分やばくないか?という思いが湧いてきました。このような基本的なことをチームにきちんと共有しないまま「チームでものを作る」とか言ってて本当にすみません。いたく反省しました。
プロダクトの目的・目標・指標
反省の気持ちを図にしたためたのがこちらです。
実際には白枠のなかにぞれぞれテキストが入っているのですが、やや社外に出せない要素も含んでいるため消しています。なにか世の中にこういうフレームワークがあるわけではなく、要素を並べていったらこうなったという感じです。(似たようなものは探せばありそうですが)
また、この図はあくまで私たちのプロダクトでの使い勝手しか考慮しておらず、あえて入れていない要素などもあります。もしご自分で作られる際は、ぜひそれぞれのプロダクトに合った形を模索してみてください。
以下、参考までにそれぞれの要素について解説します。
目的
会社のミッションや戦略と、プロダクトのビジョンやミッション、優先順位がどう接続されるかという部分です。ここはあまり頻繁に更新するものではなく、1年〜数年単位で見直していくことを想定しています。
なお、私たちのプロダクトでは「直近1年くらいで達成したいこと」と「それ以降に達成したいこと」が明確に異なるので、それぞれ「中期ミッション」と「次の中期ミッション」という形で表現しています。この図だけでは時間軸を表現しきれないので、別途ロードマップで補完するイメージです。
目標
私たちのチームでは半年ごとにOKRを設定しているので、それがそのまま目標にあたります。ここから更にメンバーの個人目標へ分解していくのですが、図が大きくなりすぎるので別のところで管理しています。
指標
定量的な指標はわかりやすいので目標と混同してしまいがちなのですが、あくまで目的に近付いているかどうかを測る手段でしかありません。もちろん「指標XをYまでにZにする」といった形で、目標と指標が紐付くことはあると思いますが、そういった場合も両者の関係を明確に認識しておくことで、むやみに数字ばかり追ってしまう事態は避けられると思います。
作ってみてどうだったか
まず図を作ってみてわかったのが、自分でも意外と整理できていない部分があったということです。特に目的と指標がどう結びついているかという点については、これまでわりと感覚的にしか把握しておらず、今回ようやくロジカルに説明できるようになりました。
開発チームからの反応も良く、さっそく来期のOKRはこれをベースにチームで考えていけそうです。今までは「POに何か考えがあるのだろう」みたいな形でブラックボックス化していた部分が可視化されたことで、よりプロダクトの方向性に対してツッコミが入れやすくなったのではないかと思います。(ここはまだ仮説なので要検証)
また前述の通り、今までこのようなアウトプットを出してこなかったことを反省したわけなのですが、問題をもう少し抽象化すると、プロダクトマネジメントというものがPM個人に閉じすぎているということも改めて認識できました。今回はたまたまチームからの発案でプロダクトマネジメントについての勉強会を行ったことがきっかけとなりましたが、このような活動は今後も継続していきたいなと思った次第です。
補足
社内の数名から「こういうのってどういうプロセスで作るんですか?」という質問を受けたのですが、まずは私がたたきを作って、次に開発チームに共有して意見を求めました。
上記の「プロダクトマネジメントをチームに開いていきたい」という主張に反するように思われるかもしれませんが、個人的にはこういった抽象的なアウトプットをゼロから合議で作ることは難しいし、作れたとしてあまり筋の良いものにはならないと感じています。まずは個人の考えや思いから出発し、次にチーム内外に開示して複数の視点を取り入れていくという手順を取るべきというのが、現時点での私の考えです。
ちなみに今回の図を初めてチームに共有したときは、なにもリアクションがなくてZoomが壊れたのかと思いました。もう少し粗い状態で見せるべきだったかもしれません。
最後に
プロダクトに対する顧客要望がたくさん来るようになると、どうしても「売上インパクトが多い順に対応していこう」のような受け身のロードマップを作ってしまいがちです。短期的には効果的に見えても、長期的にはプロダクトの価値を損ない、競争優位性も失われていってしまいます。
このような事態を避けるためには、POだけでなく開発チーム全体がプロダクトに対してオーナーシップを持ち、将来どうなっていたいのか、なぜ今これを作るのかという「Why」の部分から考えていくことが必要です。
今回の記事をお読みいただければわかる通り、こういった理想に対して私たちはまだまだ道半ばにありますし、志を同じくする仲間を必要としています。
SmartHRでのプロダクト開発に興味を持っていただけた方は、ぜひお話しましょう!