1→10のプロダクトマネジメント 個からチームの力で成長する仕組みづくり

エピックベースのファウンダーで、スマート書記というプロダクトのプロダクトマネジメントに携わっています。@marioです。

エピックベース社の運営しているスマート書記は、プロダクトのフェーズとして、0→1から1→10の転換期。チームとしても今年拡大を予定しております。
「チーム」としてどうバリューを実現するか、メンバーが増える中で「プロダクトとビジネスと接続性」をもっていくか？が私にとってのお題であり、それに対してどう取り組んでいくかというのをお話してきます。
まだ定義をしたばかりなので、運用してみてどうだったかもふりかえりnoteを書く予定です！

プロダクト開発サイクルの再定義

とにかくPMFに向けての検証を続け、目の前の課題を解決をするべく動いていましたが、プロダクトとチーム拡大でいくつかの課題が発生していました。

• 属人化・視点の偏りの懸念

• 目の前の課題に精一杯になってしまい、未来について考える余裕がなくなる

• 顧客フィードバックがどうなったか追いづらい / フィードバックが意味があるかわからなくなってしまう

そこでプロダクト開発サイクルの再定義を行いました。

ビジネスとの接続性を意識した目標設定

今まではとにかく「ソリューションフィット」を徹底してきたので、（それが価値提供につながるため）あえてビジネスとの接続性を意識した内容にはしてきていませんでした。
ただ、特にセールスメンバーも増えていく中で、「今開発している内容は、どう影響があるんだろう？」というのがイメージしにくい状態になってしまっていました。

弊社ではJIRAで運用しており、「エピック」「ストーリー」での運用を行っていましたが、新たに「イニシアチブ」という一つ上の概念を導入しました。

KPIツリーを使い事業全体のつながりの認識合わせ

イニシアチブ策定に向けて、事業全体をみんなが考えられるようにするために、KPIツリーを明示しました。
この中で「今注力すべき指標は？」と問いをした時に、それぞれ重要だと思う指標が違うと納得感が生まれなくなってしまうためです。

ユーザーリサーチを通し、指標と価値提供の結びづけ

指標を追う、だけだとどうしても偏った視点になってしまう可能性があるため、改めてプロダクトの現在地を理解するためにユーザーリサーチを行いました。
現在では「どれだけ工数削減ができたか」「どれだけ心理的負担が軽減できたか」が重要なポイント。現時点を把握し、これから行う改善でどう変化していくか？をウォッチしていきます。

イニシアチブの定義

最終的に2つのイニシアチブを設定し、「ビジネス観点でどう影響があるか」「どういう状態になったら達成できたのか（計測可能）」を定義、それを元にビジネスサイドのメンバーにも共有を行いました。
これからチーム拡大していくにあたって、どうしてもビジネスサイドとプロダクトサイドというそれぞれのチームの動きが見えづらかったり、コラボレーションが起きにくくなってしまったりするので、そういうのをなくせるようにコミュニケーションを実施していきたいなと思っています。

問題への向き合い方の定義

とにかくスピード重視だったので、「最小限」で「最大化」をする思考が強かったのですが、もう少し長い目をみてもう少し長期的な「成果」にフォーカスをしたかったので、改めてチームで問題への向き合い方の定義を行いました。いままで試行錯誤してきた中でチームで自然と醸成された価値観だなあと思ったりします。

プロダクトリニューアル後、寄り添ってソリューションをつくったり、少し背伸びしてこうあってほしい、といった形でソリューションをつくってきたりしました。なかなかこうあってほしい、で現状の根本的な課題を解決することはなかなか難しく大変なこと、というのは見えてきました。
ただ、難しいとしても、非生産的なもの作成・非効率な作業の工数削減だけをしたいわけではありません。本来的にベストな作業フローを提供し、意味にあるものをつくるお手伝いをしたい。そして、それを活用される状態をつくりたい。 なので、一時的に遠回りで寄り添ってお手伝いをしたとしても、本当の理想はなにか？と、それが無理ならばその先に一歩を踏み出せる方法はなにか？ それでも無理なら寄り添ってアプローチしよう、と考えています。 使ってくれる人たちの背中を押せるプロダクトでありたい、そう考えています。ただの御用聞きではなく、スマート書記を通してよりベストな方法やスタンダードを体験できる、そんなプロダクトにしていきたいです。

実行する体制の構築と運用開始

開発サイクル・目標・問題への向き合い方についての定義を行ったので、次は実行についての定義です。
アジャイル開発とデザインプロセスの組み込みに悩んでいたのと、思想がかなり似ている部分があったので、Lean UXを実践したプロダクト開発を取り入れました。
大事にしたい価値観は3つ、定義しました。

結果（アウトプット）ではなく、成果（アウトカム）にこだわる
「機能を作る」ことがゴールではなく、実際に行動変容できたか？のような「成果」に徹底的にこだわりましょう！

失敗を許容しよう
仮説検証は失敗に終わることが多いです。10個だして1個あたればすごい、そう思ってやっていきましょう！それでも、1つ1つのチャレンジは丁寧にやれるといいなと思います

チームでチャレンジを！
1人の力では大きな物事は成し遂げられません。1人のスポットライトをあたるメンバーがいると、他のメンバーのアイデアが出にくくなったり、コラボレーションがうまくいかないことも発生してしまう懸念も。チームで最大限の力を出していく、ということを意識して行きたいなと思います。

ここの内容については今まさに実践中なので、しばらく回してからふりかえりをしたいなと思っています。

やってみての学び

今回これらの定義を行うのは試行錯誤で、かなり議論を重ねました。普段、目の前の課題に向き合ってばかりだったので、いろんな視点で議論できて、それぞれのメンバーの視野が広がった気がします。（自分が特に）

個人としてはどうしても個で抱えがちだったのですが、こうして仕組み化することでみんなの協力が得やすくなったし、いろんな意見ももらいやすくなったな、と思ってます。大変だったけど、やってよかった！

定義しても自分で率先して発信していかないと、結構形骸化しちゃいそうだなと危機感があるので、新しい考え方や大事にしたい価値観やドキュメントなどはしつこいくらいメンバーに対して発信していきます。

以上です！この取組はおそらく手探りで、まだ試行錯誤は続きますが、この試行錯誤ができるチームが醸成できたら、少なくともよりよいチームになっていくのではないかなと思います。きちんとプロダクトの成果にもつながっていくと信じています。

もし、エピックベースのプロダクト開発や取り組みにご興味を持ってくださった方はお気軽にお話できればと思っているので、以下からどうぞ！

エピックベースのプロダクト開発・チームについて | YOUTRUST 募集