プロダクトを考えるのはPMだけではない
前回の記事では、北口より“複数のPMでも「健康的な意思決定」をするためのチームビルディング” について紹介しました。今回は私、宮下よりChatworkにおけるプロダクトマネージャー以外がプロダクトについて提案するための方法についてお伝えさせていただきます。
プロダクトマネージャーの仕事は、ユーザーの課題を発見し、その解決方法を提供すると同時に、会社の利益にもなるよう、双方よしの状況にプロダクトを通して導いていくことです。「どんなユーザーの、どのような課題を解決することで、どのような結果を得たいのか？」を考えたうえで、プロダクトマネージャーの内で閉じるのではなく、社内に発信していく必要があります。
社内にプロダクトマネージャーの意思を伝えることはとても重要です。なぜなら「自分たちが作っている・売っているものは一体何なのか？ どうして必要なのか？」が分からないままでは、プロダクトへの不安が社内にたまってしまうからです。一方で、社内のメンバーにも「プロダクトをもっとこうしたい」という思いがあります。プロダクトマネージャーが意思を伝えたとしても、社内のメンバーのプロダクトに対する思いをどのように受け止めるか？を考えておかないと、一方通行のコミュニケーションとなってしまいます。
そこで、Chatworkでは「Quick PRD」という仕組みを用意しました。プロダクトマネージャーが書くPRD（Product Requirements Document）が持つ、「どんなユーザーの、どのような課題を解決することで、どのような結果を得たいのか？」はそのままに、より簡単に提案できる共通フォーマットのことです。
このQuick PRDの仕組みの始まりから、取り組みを発展させた専用部署である「GE（Growth Engineering）部」の立ち上げについてご紹介します。
Quick PRDの誕生
Chatworkにプロダクトマネージャーの仕組みが登場してから、プロダクトに関するあらゆる要望がプロダクトマネージャーに集中してしまうといった課題が生まれました。これは、組織規模に対してプロダクトマネージャーの数が少なかったり、プロダクトマネジメントへの認知が広がってきたりしたときに起こりうる課題だと考えています。
弊社の場合はCEOからプロダクトの決裁権がプロダクトマネージャーにしっかりと権限委譲されたため、社内的にもプロダクトの要望はプロダクトマネージャーにあげれば良いという意識が向いたことも起因していました。
社内からの要望は、要望のあげやすさを重視して、Googleフォームを使って収集していました。その結果、要望はたくさんあがってくるものの、比較的短い文章で書かれていることも多くありました。その要望の中身も、プロダクトの方向性に関わるようなものから、コードの修正方針に関するもの、ビジネス要件に関するものまで、実に多様でした。
こうしたとき、短い文章で書かれた要望の後ろにある思いやストーリーを読み取ることは難しく、要望をあげてくれたスタッフに確認する必要がありました。プロダクトに対しての思いを持ったスタッフが多いのは幸運なことですが、プロダクトマネージャーが要望を理解するのに何度もスタッフに確認をする状況が発生すると、コミュニケーションコストが高くなってしまいますし、すべての要望を拾いきれずに、提案者に「どうして理解してくれないんだろう」とモヤモヤがたまってしまいます。
そこで、要望のあげ方をプロダクトマネージャーが確認しやすい方法に工夫することで、コミュニケーションコストを下げ、要望の起案からリリースまでのサイクルをスピードアップできるのではないかと考えました。
プロダクトマネージャーはPRDを使ってエンジニア含む社内メンバーとコミュニケーションを取っています。そして、中身には「何を、なぜやるのか（WhyとWhat）」が書かれていて、誰が見ても動機と目的とゴール像が分かるように書かれています。これを使えば、プロダクトマネージャーでなくてもプロダクトに提案ができるのではないか？と思ったわけです。
しかし、PRDは非常に分厚いドキュメントになりがちです。ChatworkのPRDはエレベーターピッチから始まり、ターゲット、課題分析、KPI、トレードオフスライダーなど多岐にわたる項目を埋める必要があります。プロダクトの提案をあげたい人に毎回PRDを書いてくれというのは現実的ではありません。
そこで考えたのが「Quick PRD」です。PRDの「誰の、どんな課題がなぜ存在し、何を解決して、どんな結果を得たいのか」のみにフォーカスし、プロダクトに対する提案をユーザー課題の解決という目線で行えるように整えたフォーマットです。 2018年の10月末の時点で、まだ筆者はスマートフォンアプリケーション担当のエンジニアとして活動していたため、プロダクトマネージャーと一緒にQuick PRDの仕組みを作り、まずはクライアントアプリケーションエンジニアとデザイナーから使ってもらえるように働きかけました。
どのようなルールで運用し、どのような成果が得られ、どのような課題があったのか。メンバー全員がプロダクトについて提案できる仕組みを整えていくにあたり、得た知見を紹介します。
