PM(プロダクトマネージャー)チームを立ち上げて。わかったことと課題5つ。(ShanonAdventCalendar2016・4日目)

このエントリーをはてなブックマークに追加
こんにちは

PM(プロダクトマネージャー)チームのOmiです。
日曜の深夜にこそっとブログ更新します。ギリギリ4日目ということでお許し下さい。

私のテーマはPM(プロダクトマネージャー)チームを立ち上げて。わかったことと課題

PMとはWikiによると
  • プロダクトマネージャーとは経営学用語の一つ。
  • 企業においてマーケティング活動全般の権限と責任を持つ管理者を担当する職種。
  • 製品の開発から、その製品の宣伝、販売、流通などの広範囲にわたっている。
といったことが記載されています。

マーケティング製品を開発しているシャノンにおいては、もちろんマーケティング部がしっかりと活動してくれていますので、「製品の宣伝、販売」といった領域は専門部署に任せ、企画、開発、流通(顧客への導入フロー)といったところを担当しています。

シャノンでは試行錯誤期を含めるとPMチームが発足して約2年が経過しました。
チームの発足から少し軌道に乗るまでの2年間を通してわかったこと、見えてきた課題5つをまとめてみました。

自分の課題をまとめたつもりです。他社様でのPMの苦労話ももっと聞いてみたいです。

===
【わかったこと①】
基幹製品であるSHANON MARKETING PLATFORMという製品を開発・運用を継続して7~8年位経過している。
  • 最低限の必須機能自体はすでに開発は完了している。
    • 問答無用で開発するものは少なくなってきた。
    • 開発するにしても逆に「次に何を開発すべきか」について選択肢が多い状態かつ議論が別れる状態。
→ PMに判断を動かすことを委ねられることが多い
→ 情報流通が体制として見えるようになったので、情報の流れができやすくなった。

【見えてきた課題①】
PMに判断の精度を上げることがより多く求められるようになってきた。
  • 今までお客様の前に立つことが少なかったシャノンのPMにもお客様を最も理解しなくてはいけなくなった。
    • 直接、間接を問わずお客様のニーズが頭に入るようにしなくてはいけない。
    • 特に自分がユーザーになりにくいB2B製品では特に重要。
===
【わかったこと②】
一つの製品について機能毎にアジャイルチームで開発している。
  • 各チームがそれぞれの判断で機能仕様を決めていては、UIなどについて製品としての一貫性が持ちにくい。
→ PMが複数の機能を担当することで一貫性を持ちやすくなる。

【見えてきた課題②】
複数の機能を持つために、PMの稼働がかかりすぎるようになってしまった。
PMが複数立ったためにPM間の意思疎通を図らねばならなくなった。
  • PMが得意領域を作り、少しでも稼働を落とせるようにする。
  • PMが役割分担をしつつも、各PM間で情報交換して判断がズレないようにする。
===
【わかったこと③】
(わかったこと①で触れたことにも近いですが)せっかく製品を作ってもお客様に想定通り利用していただいているかどうかわからない。
  • 機能が利用されない理由が多岐に渡るが主要因が見えにくい。
    • 必要のない機能を作ってしまった。
    • 機能が気付いてもらえなかった。
    • 機能が不足していた。
    • 機能説明や価格等マーケティング要因。
→ 機能毎にKPIを設けてみる。

【見えてきた課題③】
結果としてKPIが多すぎて管理しきれなかった。
数値が分かっても、製品に反映できないKPIを設定してしまった。
機能ごとに連携しないKPIを決めても、製品の価値を向上させることは難しい。
  • 機能毎にKPIを作るのではなく、製品全体のKPIを設ける。
    • 製品KPIから機能KPIを噛み砕いて設定する。
  • 開発チーム外に情報が流通するように、チーム外との連携を増やす。
    • 基本的には開発者はシャイなので、交流のハブになれるようにする。
===
【わかったこと④】
PM呼称問題はある。
  • PMと呼称するだけでは、名は体を表しきれず
    • プロダクトマネージャー / プロジェクトマネージャー / プロダクトマーケター
【見えてきた課題④】
社内へのPMへの期待値が各部署で曖昧になりがちになる。
どのように呼んでもらうかはともかく、宣伝を継続することが必要。
===
【わかったこと⑤】
いろんなPM先人達のみなさんがおっしゃっているが、やはり開発チームや社内他部署と信頼感を持つことは非常に重要だった。
  • そういう意味では、PMの定義に縛られず、まずは手っ取り早い、目の前の問題を解決して、信頼感を構築することは後々役に立つ。
    • 特に開発者はシャイなので他部署との連携はメインで行うようになった。
    • 信頼の反面、PMに求められる守備範囲が広範に渡るようになった。
→ 関係性を持たなくてはいけない部署が多くなった。

【見えてきた課題⑤】
開発チームだけではなく、他部署との関係・フローを強化し、スムーズな業務連携ができるようにする。

次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...