Studying as a junior PM @kichijojipm#15 by htk291

@htk291 Hideaki TAKAHASHI 吉祥寺pm#0 からの最古参 今年からエンジニアリーダー的な役割＠東五反田 (SIer -> Front-end Engineer -> ???)

新規プロダクトでジュニアPMとしてやって きた気付き、学びについてお話していきま す

TABLE OF CONTENTS ◦ 論理よりも信頼と共感 ◦ ぼくのかんがえたさいきょうのあぷり仕様 ◦ 課題の発見と解決アプローチの選択

論理よりも信頼と共感 「人」に関する学び 1

“ ロゴスだけじゃなくて、エトスとパトスも大事な要 素だよ by アリストテレス

論理よりも信頼と共感 論理的に正しいからといってチームが 納得して開発を進められるとは限らない ◦ メンバーそれぞれで思い描くゴールが 異 なっている場合がある → 「ここまでOK？何か気になるところはない？」を 確認し、モヤモヤを解消しながら進める → 同じゴールに向かおうとしているかを確認する

ぼくのかんがえたさいきょうのあぷり仕様 「製品」に関する学び 2

“ 製品開発というのは、自分が思いついた最 新のアイデアや最高のアイデアを試す場で はないことを忘れてはならない 『INSPIRED:顧客の心を捉える製品の創り方』

ぼくのかんがえたさいきょうのあぷり仕様 ◦ 自分がユーザの気持ちを一番理解している！ 自分が定義した仕様なら必ず売れる！と考え てしまうのは陥りがちな罠 ◦ 目的達成のためには最低限必要な機能を定 義することが大事 ◦ 定義したことが正しいかどうかは現場ではわ からないので、早めにターゲットに確認してFB を得ることが大事

課題の発見と解決アプローチの選択 「プロセス」に関する学び 3

“ それってなんの課題を解決する機能なの？ by 弊社シニアPM

課題の発見と解決アプローチの選択 ◦ 正解はひとつ！じゃない！！ ◦ 発見した課題に対し、その解決へのアプロー チは一つとは限らない。これはどういう課題を 解決するための機能か、立ち止まって一歩下 がって考える ◦ 正しいアプローチができているかは、 ひた すらユーザテストを繰り返し検証する必要があ る

まとめ 製品開発におけるハマりがちな罠について、自分の 経験元に紹介しました 1. チームが同じゴールに向けるようにする 2. ユーザありきの製品仕様を考える 3. 解決策を先に思いついたとして、それがなんの課 題を解決するものだったのかに立ち返り、正しい アプローチを取れているかを見直す必要がある