プロダクトマネージャー1年目にやったこと。（後編）
こんにちは、Cake.jpプロダクトマネージャーのツナマヨです。
社内に「プロダクトマネージャーとはかくあるべし」というモデルケースも体系化されたオンボーディングも無い中、手探り・体当たりでプロダクトマネージャーとしてこの1年間にやってきたことをしたいと書き始めた、1人プロダクトマネージャー1年目を棚卸するnoteの後編です。
▼前編はこちら
🙏免責事項（再掲）
アクションの棚卸しがメインなので、「プロダクトマネージャーとは？」のような話はしないつもりです。
個別具体的な機能やプロジェクトについては触れません。
やったことがうまくいったものもあればそうでないものもあります。
本noteは随時更新される可能性があります。
🍙自己紹介（再掲）
まずは私がどんな人なのか、簡単にご紹介。
横浜育ち、青森暮らしの新米パパです。お笑いが人並みに好き。最近になって望遠鏡を手にし、天体観察にハマる予定です（買ってからずっと曇り）。
キャリアとしては総合広告代理店の営業→広告プランナー→株式会社ロコガイドでトクバイというチラシアプリのマーケティング・プロモーション→2年ほど前に株式会社Cake.jpにジョインし、マーケティング担当としてキャンペーン企画・商品企画・アライアンス構築などを経験したのち、2023年2月に社内ジョブチェンジしプロダクトマネージャーとなりました。
基本フルリモートです。
💪下期にやったこと
プロダクトマネージャー1年目の後半戦は、「戦略的なプロダクト作りに挑戦する」期間でした。
上期一緒に走ってくれたCTOやエンジニアが卒業となったこと、直属の上司＝CEOとなったこと、よりハイなトップラインKPI達成を期待されるようになったことなど、半強制的により高い視座でプロダクトの成長に向き合うことになりました。
そのため下期では、上期のアクションも継続しつつ、「プロダクトビジョンからの連なりでプロダクト施策を実行する」ことにチャレンジしましたので、そこに関連するアクションを棚卸しました。
また、前編に引き続き、アクションによって得られたアウトカムについても記載しています。
#1 プロダクトビジョンを策定する
プロダクト戦略を立てる前に、プロダクトが目指す世界観をプロダクトビジョンとして言語化することにチャレンジしました。
会社のミッションや中期目標をもとにPdMとしてビジョンステートメントを叩き、CEOに提示し、調整を繰り返して作り上げました。
この過程で改めてCEOのプロダクトへの思いや期待についてヒアリングできたことは非常に貴重で、チームメンバーにもその思いの部分を共有するなどもして良かったことかなと思います。
プロダクトビジョンを言語化することは、後のプロダクト戦略を立てる際に、数ある問題からどんな問題を扱うのか（解決するのか）を選択し、検証リソースを集中することに役立ちました。
ただ、反省点はいくつもあり…。
まずは、プロダクトビジョンとしては短期的に立ち戻るものとしては抽象度が高く（悪い意味で思考停止な曖昧表現が含まれており）、結果的にはそれってどんな状態？という思考を重ねることになったことです。
中期的なプロダクトビジョンを定義しつつも、理想のプロダクトビジョンをLv100とした時のLv10,Lv30を考えておくと良かったです。
こちらのnoteにもありますが、ビジョンをレベル別にブレイクダウンし、「一歩進むための少し先のビジョン」までを言語化したかったなと。
もうひとつは、プロダクトビジョンの策定に他のプロダクトメンバーを交えずに進めてしまい、いまいちビジョンを浸透させることが出来なかったことです。
オフサイトキックオフで話し、定例のフォーマットに記載して何度も目にするような工夫はしたものの、立ち返るものとして染み込んでいたとは言えず。
プロダクトメンバーが当たり前にそれを口にできるレベルに浸透しないと、プロダクトビジョンとしては上手く機能していないことになります。
メンバーと一緒に作る・何度も口に出して読み合わせるといったアプローチをすることが効果的だっかと思います。
【アウトカム】プロダクトが目指す世界観を元 達成するためにプロダクト戦略やプロダクト施策を立案・実施・評価できるようになる。
#2 プロダクトイニシアティブを決める
プロダクトビジョンの言語化を終えた後は、ビジネスの成功（定量目標達成）・ユーザー価値の創出・プロダクトビジョンの達成のために、「どんな問題を扱うか？」「その問題を解決するための方向性はどうするか？」を決めました。
プロダクトイニシアティブに関しては、前編でもご紹介した『プロダクトマネジメント〜ビルドトラップを避け顧客に価値を届ける〜』を参照しています。
そもそもどんな問題があるかは、日々の検証結果や定性定量リサーチ結果などから整理し、プロダクトチームのサイズも考慮しつつ、2つ定めました。
これにより大きな戦略の方向性に基づき、どんな解決策でその問題を解決していくかの集中がしやすくなりました。
こちらの反省としては、イニシアティブの定義が広く、スコープを絞りきれたとは言い切れず、オプションの検討範囲がそれなりに大きかったことがあげられます。
結局はイニシアティブで定義した問題のうちのさらに狭いスコープに集中したのですが、そうなのであれば後で立ち返るものなので、イニシアティブを期中でもアップデートすべきだったと思います。
取り扱う問題に対してある程度スコープ・タイムラインを狭め、期中でも達成できたら随時見直し出来るような柔軟な姿勢が取れたらより良かったと思います。
【アウトカム】プロダクトチームとしてどの問題に対して集中するかが明確になり、解決策の仮説検証サイクルを何回転も回せるようになる。
#3 イニシアティブ毎にミニマムチームで挑む
設定した2つのイニシアティブ毎に、PdM・エンジニア・デザイナーのミニマムチームを作り、細かくプロダクト施策を企画・実施・学習する仮説検証を繰り返しました。
PdMは1人でしたが、PdM経験のあるデザイナーが一方のイニシアティブをメインで担当し、私はもう一方のイニシアティブに集中するような体制をとりました。
扱う問題に対して一定期間同じメンバーで向き合うことで課題認識や言語が共有できるようになり、発散と収束のスピードが上がったと実感しています。
一方、チームメンバーと他メンバーの仮説検証報告の場を設けず上手くシナジーが生めなかったことが反省点です。
やった内容と結果についての報告をする場はありましたが、その途中でレビューを挟む機会がありませんでしたので、「こういう仮説があり、こういう検証をする」「検証した結果、こういうことが分かった」という内容をチーム間でディスカッションする機会を定期的に設けるべきでした。
意味のないMTGは減らすべきですが、意味のある同期MTGはむしろ必要で。この辺りの情報連携の仕組み化（ドキュメント管理や会議体設計）についてはかなり改善余地があります。
また、”ミニマムチームを組成”と体良く言いつつも実態は”プロジェクト毎に同じメンバーをアサインするように工夫した”形だったため、デザイナーやエンジニアからすると「我々は同じチームである」という意識が希薄だったことも要因でしょう。
はじめに曖昧にせず期待と役割を明確にしておけば、チーム間の連携をいかに取るべきかの意識が強まり、自然と仕組み化するような動きが取れたかもしれません。
【アウトカム】チームの成熟度が高まり課題と解決策の発散と収束のスピードが上がる
#4 オプション・解決策を出し優先度付けをする
イニシアティブに対して大小様々なオプション・解決策を出し、優先度を決めて着手していきました。
▼オプションと解決策
定義がイメージし辛いですよね🙏
ざっくり以下のような定義で使い分けてます。
オプション:解決策の方向性
（例えば、〇〇のステップを簡略化することで価値を早く体験できるようにするといった粒度のもの）
解決策:オプションに対する具体的な方法
（例えば、XとYのステップをZという方法で省略することで〇〇ステップを簡略にするという具体的な方法）
優先度付けは、「緊急度・重要度・難易度（工数含）の段階付け」「ICE法」など、いくつかの手法を試しながら判断していきましたが、方法として確立させ統一することまでは出来ておらず…。
常に迷い、頭を悩ませながら決めていきました。
ちなみに、ICE法はこちらのnoteを参照しました。
ここでの反省は、オプションと解決策を同時に考えてしまい、オプションの検討に幅を持たせられなかったことです。
イニシアティブに対する解決策の方向性は本来いくつかあり、すぐに解決策の検討に飛び付かず、「まずは方向性を検討するまで」と区切りつつ前ではなく横に広げることをすれば、もっと早く良い解決策が導けたかなと思います。
プロジェクトとしての期限もある中で動きやすい解決策に走りたくなる気持ちを抑え、「もっと良い解決策」を導き出すための粘りと貪欲さを求めるべきでした。
解決策を導き出すまでの検証ステップを可視化し、「今はどのステップにいるのか」を自分たちで立ち戻れるような仕組みをどう作るかが鍵になりそうですね。
【カウトカム】次に検証する解決策が明らかになり検証準備を始められるようになる。
#5 大きく描き小さく試す
オプション・解決策の仮説までが導けた段階では、理想の形をまずは大きく描き切り、検証サイズを小さく積み重ねていきました。
一度開発着手し始めると手戻りは大きくなるため、
このXというUX,機能に本当に価値がありそうなのかを検証するために、まずはより早く試せるYをリリースしてユーザーの反応を確認する
理想としては画面XYZにまたがったUXを作りたいが、まずは最もインパクトが出やすそうな画面Zにだけ手を加えてから、ユーザーの動きを見て他の画面をどうするか含めて判断する
といったような進め方を大切にしました。
大きく描く時にデザインを作り込みすぎると、その分デザイナー稼働も増えますし、ステークホルダーの期待値を高めすぎてしまい1stリリースにどこまでを含むかの調整にコストがかかる場合があるので、このハンドリングが難しいところかなと思います。
【アウトカム】ユーザーに価値があることを最短で確認することで、必要のない機能を作らない判断ができる。
👹出来なかったこと
個人的にやりたかったものの出来なかったこともありましたので、この機に棚卸したいと思います。
#1 ロードマップを作成する
イニシアティブ・オプションが決まった段階で、アウトカム記載レベルでの3カ月～半年くらいのロードマップを作っておきたかったです。
「このような検証をして、いつ頃までに○○な状態になる」「それにより○○程度のインパクトを創出する」という見立て（約束ではなく）を提示し、全社に公開するところまでが理想でしょうか。
ロードマップを作成しなかったことにより、期中に大小さまざまな「差し込み相談」が発生し、全体のPJT優先度がロジカルに決めきれないことも多くあり歯痒い思いを何度もしました。
市場環境が激しく変化しやすいプロダクトになるためあまり長い期間のロードマップを作るのはやりすぎかと思いますが、3カ月～半年程度であれば見立てとして作成し、営業・CS・マーケ・経理などからの持ち込みPJTがあった時にロードマップを見ながらPJT間の優先度を議論できる状態は作りたかったです。
#2 権限移譲・分担のすり合わせ
特に直属の上司がCEOとなり、専任PdMも私だけという中で、「ここから先は任せて欲しい」「ここは一緒に考えさせてほしい」「ここはトップダウンで推進して欲しい」「この領域のPJTは○○にリードして欲しい」といった権限移譲や分担についての擦り合わせを序盤にしておくべきだったと反省しています。
この点に関しては誰かにやって貰うことを期待するのではなく、PdMとして方針決めをリードしていくコミュニケーション責務になると思います。
当時の私は「ケースバイケースのはずだし、都度判断でなんとかなる！」というある種思考停止のような甘い見立てをしていたため、実際には超短期間でドラスティックな判断を必要とする場面も多く、時に場当たり的な結論を出してしまったなと反省しています。
👀振り返り
以上、「プロダクトビジョンからの連なりでプロダクト施策を実行する」チャレンジに関するアクションを棚卸してみました。
より高い視座からプロダクト作りをするチャレンジは大変価値あるもので、自分がプロダクトマネージャーとしてまだまだやるべきことがあるなと、更なる意欲が湧いています。
全体を通しての反省点は、こうした全体の流れを踏んで進めていること・今どのステップについてどんなアクションをとっているのかを、基本的には自分で考えすぎて比較的クローズドに進めてしまったことです。
それこそバックログには残らないタスクも多いため、他のメンバーからすると「ちなみに今何やってるの？」と思われていただろうと思います。
情報を整理して適切に開示しつつ発散と収束にメンバーやステークホルダーをどんどんと巻き込むことで「記憶と思考を拡張する」工夫をしていきたいです。
現在はこうした棚卸しを踏まえ、改めて座学的にプロダクトマネジメントを学び直すことに時間をかけています。
その点noteはとても学びに溢れてます（感謝）し、曽根原さんのUdemy講座は1年前に受講し始めたかったくらい🧑🎓
ぜひ他のプロダクトマネージャーの皆さんとも知見を共有し、学び合いたいです！
🍰仲間を募集してます！！
Cake.jpでは仲間を募集しています。
面白いフェーズなので、興味を持ってもらえたら門を叩いてみてくださいね。
この記事が気に入ったらサポートをしてみませんか？