プロダクトオーナーの1年を振り返ってみた

こんにちは、クラウドワークスでプロダクトオーナー兼UXデザイナーをしている西部です。

クラウドリンクスという副業・フリーランスのマッチングサービスのプロダクトオーナーになってから、1年が経ちました。ちなみに前回のジョブチェンジした際の記事はこちらです。

今月のクラウドワークスデザイナーブログは、「新学期、自分を見つめ直す」というテーマでお送りしています。
今回は、1年間プロダクトオーナーとして活動してきて学んだことを、大きく「プロダクトオーナーとしての業務」「役割」「振る舞い」に分けて振り返ります。

クラウドリンクスにおけるプロダクトオーナーの役割

社内の新規事業として立ち上がったクラウドリンクスは、開発メンバーが4人、事業サイドのメンバーと合わせて7人で運営しており、プロダクトオーナーは新機能企画や施策運用など、プロダクト開発のマネジメントを行っています。他社だとPMやPdMと呼ばれることもあると思います。

1 プロダクトオーナーとしての業務

1-1 ロードマップを一度カタチにしてみないと解像度が上がらない

この1年を通して、「ロードマップをカタチにしてみて、はじめてサービスの解像度が上がった」ことが、この1年での1番の学びかもしれません。いわゆる叩き台を作るということです。
プロダクトの全体像を把握しにいくのは大事ですが、やはりそれだと初速が出ないので、叩き台としてロードマップを作成しました。ロードマップ上の施策がそもそもニーズがあるのか、どれくらいの人の行動に影響があるのかという問いが生まれ、データを見に行ったり、ユーザーへヒアリングしたりして、解像度を上げる行動につながります。
1度ロードマップにしてKPIなどと照らし合わせてみたことで、当初考えていた施策数の半分のボリュームになったり、デザインの変更部分が倍になったりなど、課題とソリューションがどんどん具体的になっていくのがわかりました。また、現状の課題を振り返ることもできますし、次に解決したい課題がどんどん出てきます。

1-2 「あとは泥臭く」の罠

プロダクトオーナーになったタイミングで他社の事例や書籍からプロダクトオーナーとしてどのように動けば良いのかを読み取ろうとしました。この1年を通して感じたのは書籍やnoteには「あとは泥臭くプロダクトに向き合う」という言葉があっさりと書かれている反面、実は業務の大半を占める言葉だということです。
自戒も込めて、いろいろな人に1週間弟子入りした方が良かったのかもしれません。

1-3 データの肌感があるだけで、話が前に進む

チームメンバーとの会話の中でフラッシュアイデアとして出てきたものを施策として具体化する際に、サービスのデータの肌感があることが大事だと思います。（まだまだ修行中ですが）
データの肌感があるだけで、その施策のインパクトが出そうかある程度検討できたり、別のアイデアにピボットができたりします。フラッシュアイデアの話が前に進みます。

2 役割

2-1 地図を描き、進む方向を示す人

ロードマップを作って施策リストをビジネスメンバーに見せた際に全くMTGがうまく進まなかったことがありました。完全に私のコミュニケーションミスなのですが、サービスの中で他の課題はどういうものがあるのか、なぜその課題にフォーカスしたのかの説明が抜けていました。
この経験から、プロダクトオーナーは施策リストを共有するだけではなく、どういう地図（市場）の中でどのように進もうとしているのか（戦略）を示す人なのだと実感しました。

2-2 フラッシュアイデアを具現化して検証する

ミーティングの中で出たとても素晴らしいアイデアを何の疑いもせずにロードマップに載せていた時期がありました（プロダクトオーナーに成り立ての頃）。実際に調査をしてみるとニーズがなかったり、根本の解決策になっておらず、今振り返ると、本当に「フラッシュアイデア」だったんだなと思います。
プロダクトオーナーとして、机上の空論からユーザーの課題を解決する施策になっているかを検証した上でロードマップを作るべきだと反省しました。

2-3 プロダクトオーナーはチームの通訳

クラウドリンクスでは、主要な数値データを毎日Slackのチャンネルにレポートとして通知されるようになっています。チームメンバーはこのデータを見てはいるものの、施策の成果や各数値の傾向などを通訳する必要があると思っています。
数値の上がり幅は順調なのか、なぜこの数値が上がったり下がったりするのか、そういったことも踏まえてプロダクトオーナーはチームの通訳の役割に近いなと思います。

3 振る舞い

3-1 フルリモートでもコミュニケーションはなんとかなる

転職してすぐにフルリモートに移行しました。実はフルリモートが初めてで、プロダクトオーナーも初めてのことだったので、うまく開発を進められるか不安でした。
定例の進め方など通常のコミュニケーションの取り方（Slackや1on1）や仕様の伝達など、相手の温度感やキャラクターがわかっていて、仕組み作りがうまくできれば特に問題は起こらないことがわかりました。
（相手のキャラがわからないのは除いて）リモートワークでコミュニケーションの課題が発生するのは、元々のコミュニケーションの取り方に課題があるのだと体感することができました。

3-2 巻き込む、話してもらえる環境を整える

施策の仕様を詰める際に、実装のプロであるエンジニアを巻き込むようにしています。どの実装が工数と成果のバランスが良いか、中長期的にケアがしやすいかの意見を出してもらうことで、プロダクトオーナーは誰のどういう課題を解決するのかに集中できます。
デザイナーに対しても、大まかな仕様を伝えて、実際に画面に落としてもらったあとに仕様を再度詰めることで全体の時短に繋がっています。
この1年で学んだことは、「その分野のプロにお任せすることが1番効率が良い」ということです。

3-3 コミュニケーションを透明にする

これは最近特に意識して取り組んでいることです。データから読み取ったことやリリースした新機能の効果測定など、Slackでつぶやくことにしています。そうすることで、チームメンバーに思考の流れが見え、たまに思考中のことに関する情報を得られることもありました
また、各施策の仕様を誰でもアクセスできるようにしておき、思考の流れもまとめてそのドキュメントに載せるようにしました。そうすることで、目的に対して他にどういう仕様を検討し、1つに決めたのかを理解することができます。

まとめ

この1年プロダクトオーナーとしての活動を、プロダクトオーナーとしての業務、役割、振る舞いに分けて振り返りました。私の中では「先陣を切って、プロダクトの世界の地図と進み方を描く冒険者」という言葉が一番しっくりきます。時にはわからない中で判断する機会もあり、一番ケガをしやすいのもプロダクトオーナーな気がします。
次の1年はさらに成果を安定して出せる再現性を意識して活動していきます。