開発経験なしでプロダクトマネージャーになって、やった事③

投稿の目的

これまでの経験で得た事や教訓を
アウトプットする目的で書いてます。
拙い文章ですが、温かい目で見守ってください。

今回は過去に投稿したものの続きになります。
過去の投稿は下記を確認ください。

実際にやったこと（続き）

ヒアリングした内容（チーム状況）の再確認

入社した際にヒアリングした項目の中には
プロダクトに関するものと会社の
体制に関するヒアリングも実施していた。

1. 所属チーム

2. チームの課題

3. チーム内でのナレッジ共有

4. チームで不足していると思われるポジション

5. どんな人(性格面)なら活躍できるか

6. チームの採用状況

7. 会社全体で改善したい事

8. お客様から会社の評価は？

体制面に関するヒアリングは
まずは身近なチームの状況から始めて
場が温まり話しやすい状態になってから
会社全体の話をするようにした。

ヒアリングした結果から見えてきた課題は

• マネジメント層の不足

• 採用が思うように進まない

• 会社として一体感がない

• 利用者からの信頼低下

マネジメント層の不足

ヒアリングの中でチーム内の状況を
確認すると、基本的には個人商店の集まりで
営業やCS内で対応した内容が共有されることは
無いという状況で、顧客から同じ質問されても
対応者によって回答や対応内容が異なっていた。

そういう状況に課題と感じて対応する
リーダーがそもそもいないという状況が
続いていたので
サービスの品質として誰が対応しても
的確に顧客サポートができる大切さ
をプロダクト品質として全社会議で伝えるようにした。

またマネジメント層の不足が顕著に出ていたのが
担当者が顧客から要望された内容を発信できない
発信しても何が課題なのかを説明できないというのがあった。

プロダクトを成長させるのに
要望に応えるのではなく課題を解決する
ことが重要だが何が課題なのかまで踏み込まないため
プロダクトが成長する機会が損なわれるだけでなく
満足度が下がっていく要因にもなっていた。

この件は、仮に要望に答えたとしても課題としては
解決していないために他の顧客で同様の問題として
再燃したり、対応した事で他社は対応したのに
なぜうちのは対応してくれないだとクレームに
繋がったりもして悪循環を生むものになっていた。

個人ではなくチームとしてどうすべきか？を考える
チームマネジメントの人材を採用あるいは教育が必要となった。

採用が思うように進まない

前述した内容を踏まえ全員が不足と感じるポジションが多々あった。
人事、経営企画、マーケティングなど。

人事不在は大きな問題で、システム側でも採用をしたいが
その他の部署でも採用する手立てが、会社HPしかない状態だった。

また人事は会社の顔にもなる人材でもあるので
不在は問題となるため、採用しにくいシステム関係の人材と
人事担当者の採用を最優先することとした。

人事が不在となり、採用しても1名体制のチームとなることから
他社で人事チームのリーダ経験、中途採用の経験者に絞って活動した。

ただ人事ポジションは直接プロダクトに影響しないこともあり
売上を上げたい経営陣と方針について衝突も多々あった。

特にエンジニア採用に対してはお金さえ出せば集まるという
二昔ぐらいの感覚だったので、人材紹介会社の担当にも
協力してもらい、現在の転職概況を伝えながら進めた。

その人材紹介会社もダイレクトリクルートを含めて
7社ぐらいと契約して面談、書類選考、面接を
人事とエンジニア採用で自ら実施した。

会社として連帯感がない

個人商店の集まりであったため、
チーム内で相談する事がない。

それがチーム間になるとさらに希薄という状況。
始めて参加した会議では進行役以外は
誰も発言しない。

会議中に昔流行った
「無駄な会議ザウルス？」というのを
思い出した。

そんな事も知らないのとか
言っている意味がわからないなどの
発言が飛び交っていたのが
要因になっていそうだった。

いきなり会議で発言しましょうとか
自由に発言してもいいよと言っても難しいので
新たに会議体を設置する事にした。

会議の目的は顧客からの問い合わせ内容で
技術的な意味の確認と対応方法検討の会議とした。

そこではDNSとかSMTPとか問い合わせ本文に
記載されている用語の解説をシステム側から補足するのと
本当の課題の確認と解決策の確認を話合い
このような対応であれば顧客が困っている事が
クリアできそうかなどを話し合う事で
会議で発言をする練習の場とした。

利用者からの信頼低下

前述した部分とだいぶ内容は被るが

• 課題を相談しても何も対応されない

• 問い合わせしても回答まで時間がかかる

• 製品説明がわかりにくい

というのが要因で、システムに関する知識が
不足しているので用語が伝わらない
課題の本質を捉えていないから
対応しているつもりでも課題は解決していない。

さらに悪い事に機能や対応内容を説明する際に
口頭や文字で説明する事が多く見られたので
いくつか顧客との会議を同席して
機能を説明する際には実際の画面でデモを見せながら
説明するという方法に慣れてもらうようにした。

基本的な事ではあるが、提案資料も同様で
文字だけでなく図や表を使って説明するという
いくつかのパターンを作成・共有する事で
提案時のテンプレートを充実化する事に勤めた。

まとめ

プロダクト以外の部分も大量に課題はあり
一見、それぐらいは当たり前にやってそうな事も
他社を知らないから、これが当たり前だと思っていた
というのが実際の感覚だった。

プロダクトマネージャーになると
プロダクトを拡大するために現状把握なども必要になる
そうすると必然的にシステムとは異なる部分まで
改善が必要になるのでPMやシステム的なスキルの他にも
幅広い知識が必要になると感じた。

そういう意味では会社で課題が出た時に
他社ではどうしているかを気軽に聞ける関係作りも
プロダクトマネジャーには必要だと感じた。

私自身もだいぶ他社の方にお世話になりながら
色々な課題に取り組む事ができました。