こんにちは、プロダクトマネージャー（以下、PM）の一柳です。 groovesでは Crowd Agent（クラウドエージェント） というtoB向けSaaSサービスを担当しています。
私は今年でPMキャリア3年目の駆け出し（？）PMなのですが、これまでの2年間を振り返って感じた「プロダクトマネジメントの基本」を3つのポイントに絞ってお伝えします。
ポイント1: PMはドキュメンテーションがとても大事
アジャイル開発を採用している開発現場におけるドキュメンテーションへの誤解として「アジャイル開発だから、ドキュメント不要なのでは？」というものがあります。（最近は流石に減ってきた気もしますが・・・）
またドキュメント不要論としては「どうせ仕様変更に対して追従できなくなるのだからドキュメント作っても無駄」というものもありますね。
ソフトウェアエンジニアとして開発に従事しているとどうしても「ドキュメントを書くよりコードを書いたほうが早い！コードこそが生きたドキュメントだ！」と感じることが多いですし、実装フェーズにおいてはその見解が正であることが多いと思います。
ただPMが関わる要件定義フェーズにおいては、ドキュメントに十分な情報が残されていないと、とても困ることになります。 通常、要件定義フェーズにおいてPMはPRD（Product Requirements Document）と呼ばれる文書を作ることが一つのマイルストーンとなります。
PRDをざっくり説明すると、プロダクト（または機能）を作る理由や、評価方法を記載したドキュメントです。
PRDがいい加減な内容の場合「開発チームが実装した成果物（Output）が事業成果（Outcome）につながらない」ということが発生します。
せっかく貴重な開発工数をかけて開発していくわけなので、どのような狙いがある機能で、その狙いが達成できたか否かをどう評価するのかぐらいは分かっている状態で開発していきたいですよね。
また、PM視点からすると他にもPRDをしっかりと記載したほうがいい理由が2点あります。
1点目は合意形成コストが削減できること。
プロダクト施策の実施には、プロダクトチームだけでなくセールスチームやカスタマーサクセスチームなど多くのステークホルダーとの合意形成が必要です。 各ステークホルダーが論理的に納得できている状態を作るために各種調整を行うのがPMのしごとの1つですが、口頭で確認、納得したとしても人はいずれ忘れてしまいます。
というわけでなんども同じ説明、説得をしてもしょうがないので、合意事項とそのロジックは全てPRDに記載して読めばわかる状態を作るのが合理的です。
2点目は施策評価についての保険をかけることが出来ること。
PRDが立派であれば施策が成功するわけではないですが、PRDがしょぼいとだいたい失敗します。
ですので、実施施策のマイルストーンとしてPRDをレビューすると手酷い失敗を防ぐ効果があると考えています。
またPMの人事評価という面でも、PRDをOutput評価の1つとして見てもらえると自身でコントロール可能な評価項目が増えるので安心して働けますね。 （究極PMへの評価はプロダクトの成功指標と連動すると思いますが、プロダクトのフェーズや特性によってはそれだけで評価する/されるのは難しい場合もあるため。）
ポイント2: 施策の基盤は「KPIとユーザーニーズ」
ドキュメンテーションの話の延長となりますが、PRDを作成する時点でKPIとユーザーニーズが両方が明らかになっていない状態で施策を実施するのは非常に危険だな感じています。
この2つが押さえられていない場合、施策の振り返りが困難です。何がどう成功 / 失敗したのか要因分析ができなず、学びが得られない。その結果として学習サイクルが回らずにプロダクトの成長が止まってしまいます。
恥ずかしい話、昨年の私はKPIとユーザーニーズそれぞれ片方だけでも分かっていればいいのでは？と勘違いしていたのですがどちらか片方だけでは説明ができないことが多すぎて大変苦労しました…。
KPIは設定されているがユーザーニーズを理解していないパターン
このパターンの場合
- ユーザーニーズが分からないので、定量データの変化の解釈を間違えやすい。
- ユーザーニーズを無視したKPI向上施策はevilになりやすい。
という罠にハマります。
evilな施策例としては下記のようなケースが想定できます。
記事ページのPVをKPIとして、これを向上させたいというシーン。
→ 一覧表示画面で重要情報を隠し、記事へのアクセスを誘導する施策を実施する。
→ ユーザー視点では記事ページにいかないと情報確認ができず利便性が下がっているがPVは向上する。
ユーザーニーズを理解しているがKPIが設定されていないパターン
KPIがなくて困るケースは単純で、施策評価ができないことです。 せっかくユーザーが喜ぶ機能をリリースしても、定量的に評価できなければ意味がないですよね。
また単に定量データが分かるというだけではなく、事業上のゴールと紐づくKPI として設定されている指標が存在することが大事です。 事業ゴールとの因果関係を説明できない指標が向上したとしても、事業の方向性とマッチしているのか確認できなので単にプロダクトの独りよがりになってしまいます。
既存のKPIがイケてないので、良いKPIを探索、再設定するという行為は有りえますが新しいKPIを設定し、指標の確からしさを検証するのはなかなかに大変なので施策実施前に済ませておきたいです。
ポイント3: プロダクトマネジメントは「チーム」で実現する
もともと弊社ではPMが1名でプロダクトマネジメントの全てのタスクを実施する体制だったのですが、どうにもこうにも1人でタスクを回せる分量じゃない！辛い！ということで、2020年4月よりプロダクトマネジメントチームを組成し、チームでタスクをこなす体制となりました。
スタートアップの初期段階ではPM ＋ デザイナー ＋ エンジニア数名といったミニマムチームで回すことも多いかと思いますが、ある程度プロダクト規模が大きくなり関連する組織の規模も増えるとPM1名だけで全てのタスクをこなすのは難しくなってきます。（残業時間がエグいことに…）
PMは、開発チーム、マーケチーム、営業チームetc...といった事業を構成する各組織をつなぎ合わせていく動きが求められますので、組織規模が大きくなるほど調整・交渉範囲がひろくなり、一人ではカバーできない領域がでてしまいます。
いかに効率的にプロダクトマネジメントを行うか、ということを考えた際に取れる選択肢は以下の3つと考えます。
- 問題を抽象化して捉え直す
- 調査コストを支払い学習する
- 必要なスキルを備えた人をチームに迎える
問題を抽象化して捉え直す
日々PMが対処する様々な問題を全てイチから調査・検証・判断していくのはとてもコストが高いです。
対応していく問題を一段抽象化することで、対処しなければ行けない問題や、解放の選択肢がシンプル化して対応コストが下げることができます。
調査コストを支払い学習する
例えばマーケや開発に関する用語やセオリーが分からない、社内の誰もドメイン知識を持っていないといった場合、問題に着手するまえに調査段階を踏んで学習するフェーズを設けましょう。 前提となる知識がない状態で問題に取り掛かっても無駄にコストがかかったり、失敗/手戻りのリスクが高くなります。
必要なスキルを備えた人をチームに迎える
ドメインエキスパート、UXリサーチャー、テクニカルディレクター、マーケター…とにかく自分が持っていない専門知識を持っている人間をPMチームに迎えて一緒に問題解決していきます。 同じチームで働くことでPM自身も足りない知識が補われていくので、前段の学習効果も期待できます。
もしいま1人でプロダクトマネジメントすることにつらみを抱えている方がいましたら、自身のスキルと、事業・プロダクトフェーズによって求められているスキルの差分を確認し、足りないスキルを補うようにチームビルディングしていくことをオススメします。
おわりに
この記事ではPM3年目の筆者が自身の業務を振り返った際に気づいた「プロダクトマネジメントの基本」を記載しました。 まだまだPMの深淵に触れたばかりで力不足を感じる場面も多いですが、ドキュメンテーション、KPIとユーザーニーズ、チームによる協業の3本柱を外さずにプロダクトマネジメントに邁進していきます。
もし私達と一緒に働くことに興味がございましたら、お気軽にカジュアル面談へご応募ください。
