見出し画像

BtoB SaaSの新卒PdMの「プロダクト企画」ってどんなことしてるの？

Chikako🦖

こんにちは、株式会社スタメンでアソシエイトプロダクトマネージャーをしていますChikakoです🌸
’21年新卒デザイナーとして入社後、PdMに異動し、現在は社内1人PdMとしてプロダクト改善運用や新機能企画・開発までの管理をしています。

このnote記事は、スタメンnoteリレーの11日目です！スタメンのnoteリレーにはついてはこちら👇 https://note.com/stmn_hr/n/n7dca2dd870e7

今回は、BtoB SaaSのPdMが新機能企画においてどんなことをしているのかについて書きます。まだまだ手探り状態ですが、これまで企画をしてきた中で見えてきた経験談を踏まえて、弊社の企画フローと各フェーズで重要だと思うことを書いていきます。


前提として話しておきたいこと

弊社の事業フェーズ・開発組織体制におけるプロダクトマネージャーの「企画」についての内容になります。
一般的なプロダクトマネジメントの書籍やwebサイト記事の業務定義とは異なる部分もありますがご了承ください。

はじめに

一般的に、開発フェーズを分けると以下の図で表されます。

プロダクト開発の流れ

図を踏まえて、弊社のPdMの企画は以下2点を主に担当しています。

  • 課題選定やゴール設定

  • ソリューションの検討

この2点に該当するフェーズでの取り組み内容を、1〜5のステップに分けて話していきます。

1. 情報収集・ヒアリング

弊社では、事業会議やプロダクトロードマップ会議にて開発方針が決まります。
方針が決まっただけでは、プロダクトに落とし込む材料としては少ないのでここから情報収集を進めていきます。
主に、

  • なぜやりたいのか？

  • どこが・誰がターゲットなのか？

  • 何が課題なのか？

  • なぜ今やるのか？

などの事業戦略的な観点を中心に、部長・経営陣へヒアリングをしています。

情報収集・ヒアリング

💡point
・最終的には事業戦略とプロダクトを一致させることが重要であるため、ここでは「どんな事業戦略でいくのか」の理解が必要
・この段階で、目的・背景がブレるとその後のソリューション検討まで進んだ際に全てがひっくり返るので、疑問点がある際はすぐに関係者とすり合わせる（スピード大事）

2. PRD作成

1で情報収集した後は、情報整理と言語化のためにPRD(product requirements document)に記載していきます。
弊社で利用しているPRDは大きく「Why」・「Who」・「What」・「How」を分けて記入します。

具体のPRD項目はこちら▼
※弊社では、開発に関する全てをPRDには載せていません。

・開発スタートまでの全体スケジュール
【Why】
・なぜ必要なのか？
・なぜ今必要なのか？
・マネタイズ（どうビジネスに寄与するか？）
・期日
・ステークホルダー
・指標（プロダクト指標・KPI）
【Who】
・ユースケース（誰がいつ使うのか？使う理由はなにか？）
・ユーザーストーリー（5w1h＋登場人物）
【What】
・競合調査（競合はどこか？最低限必要な要件はなにか？）
・機能要件（必要な仕様はなにか）
・コンセプト
【How】
・受け入れ要件
・本機能ではやらないこと

PRDを作成していく上で、ヒアリング内容ではカバーできなかったものについては、営業資料やTUNAG(弊社サービス)の投稿、MRR表を見たり、既存顧客の運用状況を確認したりしてPRDを肉付けしています。

PRDを埋めていく
構想や頭の中を図解化する

💡point
・PRDに落とし込むまでの過程として、カスタマージャー二ーマップを作成したり、ペルソナを作ったり、ワイヤーラフを作ったりなどと、頭の中の構想を図解すると良い
・図解化することで、自分の理解も深まるだけでなく、ステークホルダーに対して説明する材料としても活用できるので、認識齟齬なく進めることがメリット

3. 調査・ステークホルダーとの確認

弊社では、だいたい最低3社程度を対象に調査し、
「Why」・「Who」まで記入した後は、競合他社調査を進めます。

  • 製品として最低限必要な機能

  • どんなユーザーをターゲットにしているのか？

  • どんな導線で利用するのか

を理解していきます。

競合他社調査

その後、機能要件を洗い出しPRDを一通り作成したらステークホルダーへ壁打ちしに行きます。

  • Why・Whoの解釈が合っているか？向かっている方向性に齟齬はないか？

  • 課題から、理想ユーザーストーリーの共有

  • 機能要件

を重点にすり合わせをします。

ステークホルダーとPRDの確認

💡point
・オリジナルで機能要件を考えるのではなく、競合他社調査はすること（調査してからオリジナル要素を追加すること）
・1人でPRDを埋めている中でわからない箇所もでてくるので、早めにステークホルダーに壁打ちすること（または、知ってそうな部署メンバーなどに聞く）
※PRDは作成して終わりではないので、必要に応じてアップデートしていきます。

4. ワイヤー作成

PRDを元にプロダクト方向性が合意できたら、機能要件を元にワイヤーを作成していきます。
最初は理想形を固めていき、そこから要件と照らし合わせて削ぎ落としてもよさそうな箇所を削っていきます。
沢山発散してワイヤーを引くことで、自分もユーザー視点にたつことができます。
この段階で、細かい仕様検討や開発優先の検討時に検討材料になりそうな箇所をあらかじめ見つけられるだけ見つけておきます。

ワイヤー作成

💡point
・競合他社調査や、似たようなサービスから画面遷移や情報設計を参考にしてワイヤーを組んでいく
・とにかく発散すること（手を動かしていると、この導線ではこんなことしたくなりそう、ここでは条件選択させたほうが良さそう　などと自分もユーザー視点にたって考えることができるので良い。）

5. 仕様策定

一通りワイヤーを作成できたら、ステークホルダーに共有し仕様を詰めていきます。
ワイヤーレベルで理想形と削ぎ落とした形も見せて、どこまでをまず1stリリースの要件とするかを話していきます。
具体的な仕様は、仕様書にまとめ開発メンバーとも共有します。

仕様書作成

💡point
・最低要件でのリリースになる場合、「理想・できたらここまでいきたい・ミニマム」に分けて要件とワイヤーを準備する
・仕様書は、一つ一つの行動に対して「どの画面で起きることか」・「何をしたいか」・「受け入れ要件」・「機能要件」を記載し、本当に要件として残すべきか？落としてもよいかのジャッジをするために細分化しておく

まとめ

以上、弊社の企画フローと各フェーズのポイントでした。
いかがだったでしょうか？弊社のプロダクトマネージャーがどんなことに取り組んでいるのかを知っていただけたら嬉しいです⭐️
これからは、PdM1人だけではプロダクトづくりはできないからこそ、チームや部署を超えてのコミュニケーションを増やし、開発組織だけでのプロダクト開発に閉じずに、組織全体を巻き込んだプロダクト開発をしていきたいと思っています。

🤝共創大事🤝

最後に

弊社では、エンジニア・プロダクトマネージャー・プロダクトデザイナーの採用を積極採用中です⭐️
本記事では具体的なプロダクトの話は控えておりますが、よりリアルなお話もできるかと思いますので、もし興味を持っていただけた方は下記の募集ページからお気軽にご連絡ください👇🏻


この記事が気に入ったらサポートをしてみませんか？