プロダクトマネージャー1年目にやったこと。(前編)
こんにちは、Cake.jpプロダクトマネージャーのまつながです。2023年の2月に専任プロダクトマネージャー1人目となり、ちょうど1年が経ちました。
社内に「プロダクトマネージャーとはかくあるべし」というモデルケースも体系化されたオンボーディングも無い中、手探り・体当たりでプロダクトマネージャーとしてこの1年間にやってきたことを棚卸したいと思います。
プロダクトマネージャーになった1年目ってぶっちゃけどんな感じ?ということが気になる方に読んでもらえたら嬉しいです。
上期・下期でアプローチが変わったこともあり、noteもそれぞれに分けて書こうと思います。
今回は前編(上期編)です。
▼後編はこちら
🙏免責事項
アクションの棚卸しがメインなので、「プロダクトマネージャーとは?」のような話はしないつもりです。
個別具体的な機能やプロジェクトについては触れません。
やったことがうまくいったものもあればそうでないものもあります。
本noteは随時更新される可能性があります。
🍙自己紹介
まずは私がどんな人なのか、簡単にご紹介。
横浜育ち、青森暮らしの新米パパです。お笑いが人並みに好き。最近になって望遠鏡を手にし、天体観察にハマる予定です(買ってからずっと曇り)。
キャリアとしては総合広告代理店の営業→広告プランナー→株式会社ロコガイドでトクバイというチラシアプリのマーケティング・プロモーション→2年ほど前に株式会社Cake.jpにジョインし、マーケティング担当としてキャンペーン企画・商品企画・アライアンス構築などを経験したのち、2023年2月に社内ジョブチェンジしプロダクトマネージャーとなりました。
基本フルリモートです。
💪上期にやったこと
プロダクトマネージャー1年目の前半戦は、「プロダクト作りの“現場”を身体で覚える」期間でした。
当時専任PdMがおらず会社としてのロールモデルが無い中、PdMを兼任していたCTOが上司となり、PdMとしてのチャレンジとアクションを一緒に考えて貰いました。
チャレンジは大きく分けると以下の3点です。
プロダクト及びプロダクトチームメンバーを理解する
プロダクト作りの流れを理解し、アウトカムにつながるプロダクト施策をやり切れるようにする
プロダクトのWhy,Whatの仮説構築力を高める
上記のチャレンジをしながら、新機能開発や既存機能改善、新規サービス立ち上げなど、大小20個ほどのプロジェクトに関わりました。
以降の章で、いくつかのアクションを簡単に説明しつつ、そのアクションによって得られたアウトカムについても記載しています。
🤝プロダクト及びプロダクトチームメンバーを理解する
簡単に言うと、プロダクトとプロダクトチーム、とそれに強い影響を与える人を、ソフト(性格や人柄)・ハード(スキル・得意不得意)を理解するためにコミュニケーションを取るようにしました。
#1 開発メンバーとの横1on1
プロダクトマネージャーとしてプロダクトチームにジョインしてから、デザイナー・エンジニアと定期的な1on1を行いました。
「最近面白かったプロジェクト」「苦手な仕事」などテーマを設けながら話をすることで、徐々にメンバーのソフト・ハードの特性について理解を深めて行きました。
#2 CTO,CMOとの1on1
私にとってはマーケ時代の上司とプロダクトマネージャーとしての上司になりますが、定期的に時間をもらいながら、自分やプロダクトへの期待をすり合わせたりするためのヒアリングと対話を行いました。
#3 CEOとの定例
開発見通しの話や方針の話を膝を突き合わせて会話を重ね、同じ方向を向いてプロダクトを成長させるためのコミュニケーションを取りました。
プロダクトや機能に関しての考えを伝え擦り合わせる貴重な時間でありつつ、CEOからのリクエストにNOを伝えることもあり、その中で「共通言語」が生まれる点がとても有意義でした。
#4 プロダクトをとにかく触る
Cake.jpは個人ユーザーとしてだけでなく法人利用もできるECプラットフォームです。Cake.jpで販売する店舗様用管理ツールや社内スタッフが利用する社内管理ツールもあり、基本的なUXは理解できるように触りました。
あまり既存のボトルネックなどが分かっていない中でプロダクトを触った時の経験はバイアスが少ない分ユーザー視点に近いため貴重でした。
#5 システム連携図などシステムオーバービューと仕様ドキュメントを読む
私はいわゆる非エンジニア出身のPdMです。そのため、エンジニアとの会話をできるだけエンジニア視点で話せるように、フロント・バックエンドのシステム連携図や技術仕様や購買フロー図など、ありがたいことに社内にまとまっているものがあったのでそれを読み込みました。
(あとは、耳馴染みのない開発単語が出た時はメモしておいて、後でChatGPTでストーリー形式で解説してもらうと理解しやすかったです。)
🏃♂️プロダクト作りの流れを理解し、アウトカムにつながるプロダクト施策をやり切れるようにする
これまでのキャリアでは開発チームには「リクエストする」立場で関わることが多かったため、どのような流れで開発を進めているのかについての理解が乏しく、「企画意図」を「ソリューション」に落としこむ部分で色々と試行錯誤し学ぶことができました。
#6 開発の流れに関するドキュメントを読む
社内のアジャイル開発体制やリリースフローに関しては身体で覚えるのが一番ではありつつ、こちらも親切なオンボーディングドキュメントがあったため、それを事前に読みました。
#7 アサインされた機能に関する仕様を策定し、レビューをしてもらう
最初はデザイン要素があまり絡まない、比較的ライトに進められるプロダクト施策を主に任せてもらい、徐々に難易度が高いプロジェクトに取り組むようになりました。
アサイン時点で既にざっくりとした目的と価値仮説が定義されており、それを元に他社プロダクトのUI/UXをリファレンスしつつ仕様・振る舞いを策定します。
この時は、開発チケット自体に直接仕様ドラフトを書き込み、CTO,エンジニアにレビューをもらいつつ仕様を詰めてました。
#8 フェーズ分けから相談する
シンプルな機能であれば仕様も複雑にならないのですが、開発タスクが大きくなる機能についてはフェーズ分けかは相談しました。
タスクの粒度・難易度・工数・影響範囲などの見立てが弱いため、仕様をドラフト的にまとめたた段階でデザイナーやエンジニアに積極的に「どのように実装するか」「どれくらいかけるか」「違うHowアプローチはないか」などの壁打ちをし、フェーズ分けについては実装者目線の意見を聞きながら一緒に決めていくようにしました。
#9 バックログアイテムを作成する
レビューを経て開発タスク・フェーズ分けまで完了したら、それを詳述した形でバックログに追加するようにしました。
このアクション以降を経て「完了条件」について意識を向けるように。
#10 アジャイル開発フローを経験する
基本的にはアジャイル開発のスタイルではありつつ、実施するスプリントイベントや実施タイミングに教科書的なものとは異なるものがあり、スプリントプランニング〜レトロスペクティブまでを身体で覚えました。
#11 PRDを使い始める
ひと通りの開発フローを何周か経験する中で、特に単一機能・画面を跨ぐUXを変更する場合や開発範囲が広くなる時、それまでのように開発チケットに機能仕様を描くスタイルではうまくいかないと感じるようになりました。
メモ程度の記載も残ってしまう一方で内容の網羅率が低かったり、更新性・可読性に欠け、デザイナーやエンジニアとのリレーションが難しくなってきたためです。
それを機に、色々なリサーチを経て、Googleドキュメントで要点を整理したPRDを作成するスタイルを導入しました。
#12 Design doc にトライ
こちらはトライし、個人的には有用性を感じてはいたものの、なかなか耳馴染みがないステークホルダーも多かったために浸透させることが出来ず…。当初利用していたPRDフォーマットをDesign Docの要素を参考にしたアップデートを加える形をとりました。
Design Docの有用性はこちらのnoteを参照しました。
#13 MVPラインを決めるためにメンタルモデルダイアグラムとカスタマージャーニーマップを活用
figmaを利用して叩きを作成しつつ、それをプロダクトチームに共有しながら移動させたり不足している体験を足したりして、MVPラインを決めるやり方を試しました。
有名な『プロダクトマネジメントのすべて』を参考にしてます。
コミュニケーションを取る人の中にはやはり視覚化されないと上手く伝わらない場合もあり(新機能や大型リニューアルあるなどでより顕著なイメージ)、テキストだけでの説明よりも個人的には良かったです。
#14 KPI計測しアウトカムを図る
機能をリリースしたのち、実際に求めるアウトカムが生まれてインパクトに繋がったのかを、GAやSQL使って定量的に計測。そこから得た学びと新たな仮説をもとにNextActionを整理してチームへの共有をしました。
🧐プロダクトのWhy,Whatの仮説構築力を高める
CTOとの目標設定の中で『ダブルダイヤモンドの左側(「正しい問題を見つけるダイヤモンド」)に強くなろう』『右側はみんなで強くしたいこう』という話しをしており、そこに対応するチャレンジです。
#15 他のプロダクトをたくさん触り、Why,Whatのトレースをする
トレースするというのは施策をまるパクリするという意味ではなく。いくつかのプロダクトを選び、「いまのUXをアウトプットするに至るには、どんな課題背景がありどんな解決策を立てたのか」を推定するワークをしました。
良い施策の場合、そのまま真似したくなる気持ちになりますが、グッと我慢です。
#16 ユーザーインタビューをする
デザイナーと一緒にインタビューを企画し、主にデプスインタビューを通じてヒアリングしたり、実際にプロダクトを触る様子を見せてもらったりしました。
まずは慣れているデザイナーがインタビューを実施し、自分は書記に徹するところから始め、徐々に独立してインタビューシート作成し、インタビューをするようになりました。
ご協力頂いた方々には感謝の限りです。
#17 マッピングから仮説をつくり、定量的に確認する
実際にインタビューした内容をもとにfigmaを利用して行動フローを書き出しつつ、その中で生じるボトルネックや期待をマッピング。
ユーザーがタスクを完了する(=価値を体験する)までの最短距離を取るための仮説を出すのに有効でした。
#18 ファネル分析をして定量的なボトルネックを探す
ユーザーの行動フローをもとに主にはGAを利用したファネルを様々なセグメントで確認し、ファネルの離脱率からボトルネックを推定するワークも頻繁に行いました。
ただ、闇雲に興味の赴くままに見ていると時間が無限に溶けます。前述のユーザーインタビューなど、事前に他の情報から得られた仮説をもとに定量的なところを確認するようにしました。
#19 シーケンス分析をして想定外のユーザーの動きを探す
ユーザーがコンバージョンするまでのイベントログをN1で追って、直線的ではない動きがないか、想定外の動線を辿っていないかなどを見たりもしました。
これについては、どんなユーザーデータが取れているかによって精度が異なるのと、上手くBigQueryを使って素早く抽出できないとなかなか時間を取る作業になってしまいます。
この点、私はまだまだ。。。
#20 プロダクトの「カタ」のワーク
『プロダクトマネジメント〜ビルドトラップを避け顧客に価値を届ける〜』にて紹介された、プロダクトのカタ。このカタに沿って、問題探索からソリューションの探索をするワークを試みました。
こちらも参照してます。
👀振り返り
以上、3つのチャレンジと20個のアクションに棚卸しをしてみました。
細かいアクションは省略しているところもあるので、そちらは機会があればまた。
半年前までのことではありますが、今の目線で実棚卸してみると、2-6月の実質5ヶ月でトライ&エラーを繰り返し、まさに身体で覚えた期間といえますね。
戦略的なアプローチというより、またまだ手当たり次第、という感じです。
下期で改善なるか…!後編をお楽しみに。
🍰仲間を募集しています!!
Cake.jpでは仲間を募集しています。
面白いフェーズなので、興味を持ってもらえたら門を叩いてみてくださいね。