ku-sukeのブログ

Just another hatena blog

プロダクトマネージャーと呼ばれる何かになるまで(メモ)

まとめる時間はないのでメモ。自分で見返すようなので読みにくいです。

 

今日は、こちらのイベントをやってきました。

pmjp.connpass.com

第2回ということで、第1回もあったのですが。

 

Slackのpmjpという集まりがあって、そこの皆さんに「育成とか評価とかどうしてますかー?ちょっとオフ会前に壁打ちやってくれませんかー」と呼びかけたところ大勢集まってしまったという会です。

 

第1回、第2回を通して、人はどうやってPMになっていくのかの入り口が見えてきた気がしました。

第1回での学びは、事前にもっていったスキルがあって、だいたいプロダクトマネジメントトライアングルと同じなんですが、これができる人ですかね?という問いかけでした。

ninjinkun.hatenablog.com

結論としては、そんなの全部できるやついねーよ!とか、プレイヤーとしては各スキルが一流でなくとも、焼き肉力とかで成功するPMもいるよね。ミニCEOなんだから、事業を成功させる力だよねPMって。みたいな学びがありました。

しかしながら、組織としてPMをどう育てていくかみたいな部分で、初めの第一歩をどう踏み出すのがいいかまだ納得いく言語化ができておらず、第2回でエンジニアスペシャルをやり、エンジニアからなぜPMになったのかみたいな話を深堀しました。

 

そこで無理やり出したまとめとしては、エンジニアが顧客に興味を持ちだしたらそれはPMの第一歩ではないかというふうになってきました。「正しいものを正しく作る」という言葉がありますが、まずは後半の正しく作る部分のエンジニアリング力を上げていき、そこから顧客が本当に必要だったものを知ろうとするスキルを付けていくのではないか(僕の解釈です)

そのために組織としては、エンジニアが顧客と触れ合って、プロダクトが必要になる場面を観察させる場を設けるのは大事だと。全エンジニアに強制しなくてもよく、興味ある何人かが参加できるようになっていればよいのではないか。

 

逆にグロースハックに進むのはどう?という問いかけにはなんか違う気がする・・な反応でした。まぁA/Bテスト一つとってもエンジニアだけではやりにくいですし、顧客に興味がない状態でKPI至上主義になるのも健全じゃないですね。

 

そして、顧客がほしがるものをある程度作れるようになったらミニPMで、そこからは苦難を乗り越えながら&社内の専門家と協働して成長していく感じでしょうか。

  • 顧客が喜んだのにたくさんの人には届かない
  • 顧客が喜んだのにチームが険悪で退職者が
  • 顧客が喜んだのに売り上げ規模が足りない。あるいは大赤字
  • 顧客が喜んだプロダクトに営業部門がごり押しで変な機能を増やす
  • 顧客が喜んだのに主力プロダクトに人をとられて(ry

みたいな。正しいプロダクトを作れたとしても、それがビジネスとして成功するかはもっと乗り越える壁があると思います。

そうやって、マーケを学んだり、全社の事業戦略、事業ポートフォリオを学んだり、営業部門が普段どんなことで悩んでいるのかを知ったり、契約ごとに詳しくなったり、ある程度社内政治にも耐えうる振る舞いを知ったりして「ミニCEO」になっていくのかなーと思いました。

 

 

 

あと余談メモ

 

・東京においては、人材を確保する力っていうのも、ベテランPMに求められそうです。金と案件くそほどあるのに適材適所にばちっとはまる人がいなくて動かないプロダクトが結構ある気がします。まぁスモールチームが多いから、わりとフルスタックXXを求めちゃうせいかもしれない。チケット単位とか明確な業務なら比較的リモートとかで仕事ふれる時代にはなりましたしね。

 

・エンジニアとのコミュニケーションは現場ごとの文化がありますが、エンジニアが納得感があるってのが大事だと。なんでこの機能をこの時期に作らなきゃいけないの??とか。あと職場でヘッドフォンしている場合話しかけてよいかとかw

 

以上メモなので読みにくいですが寝ると忘れる性格なので書き残し。