Slide 1

Slide 1 text

「強い」エンジニアと働く中で、 新卒1年目・未経験プロダクトマネージャー が何に悩み、どこに自分の価値を見出した か 2024.4.13 かしもと

Slide 2

Slide 2 text

自己紹介 ● かしもと(@kassy_1127) ● 新卒3年目 ● 株式会社リンケージ所属 ○ BtoBtoEでヘルステックサービスを提供 ○ CTOそーだいさん筆頭に強いエンジニア ● 現在のお仕事 ○ 事業開発・カスタマーサクセス ● 今までのお仕事 ○ 新規事業のカスタマーサクセス(2年) ○ 新規事業のプロダクトマネジメント(1年) ● 好きなこと ○ 自然。軽めにキャンプ、山登りします この時のお話をします

Slide 3

Slide 3 text

今日お話したいこと ● 技術・PHPの話はしません(できません) ● 組織として事業・プロダクト価値を最大化させるうえで、 ○ 「強い」エンジニアって何が強くて、 ○ PdM(というかBiz職全般)はどういうコミュニケーションを取って、 どういう役割を果たせるとチーム・事業が前進するの? ● というお話を、私の新卒1年目の経験をもとに話します

Slide 4

Slide 4 text

アジェンダ 1. 新卒1年目のある日のこと 2. 「強い」エンジニアとは 3. 自分なりに見出した価値・学び 4. まとめ

Slide 5

Slide 5 text

新卒1年目のある日のこと CSを兼務しているので、様々な要望をもらってきます ● 特定の部署だけxxのボタンを非表示にしたいです(by 大きな企業) ● ○○の画面を印刷したいです ● ○○のデータを画面上で見たいです etc. 私「大きな企業さんに言われてるし、チャーンしたくないし、断りづらいな、、やるしかない よな!」

Slide 6

Slide 6 text

新卒1年目のある日のこと 私「どういう機能・UIにするか決めないとな」 to エンジニア ● 特定の部署だけxxのボタンを非表示にしたいです ● 部署ごとにボタン表示を切り替えられる機能を作りたいです ● 部署ごとの表示切り替えは、この場所でこんなイメージにしたいです ● どれくらい工数かかりますか?○○までに間に合わせられますか?

Slide 7

Slide 7 text

新卒1年目のある日のこと 「強い」エンジニアの方々の(優しい)フィードバック ● 誰が何のためにボタンの表示を切り替えたいんですか? ● その課題解決は、事業上の数字にどうインパクトするんですか?他のバックログア イテムと比べてどの程度優先順位が高いんですか? ○ お客さんはその課題解決にどれくらいお金払いますか? ○ どのくらいの頻度で要望が発生してますか? ● あと、How(解決方法)を決めて依頼はしないでください

Slide 8

Slide 8 text

・・・わからん

Slide 9

Slide 9 text

新卒1年目のある日のこと 私の悩み ● エンジニアの方にはWhyを伝えられないし、お客さんに明確なHowを伝えられない し、自分がいる意味あるのだろうか。 ● つらい、PC捨てて山行きたい。 ● とりあえず、お客さんやドメインエキスパートに全部聞くか・・・ といった感じで顧客⇔エンジニアのやり取りを続けてました。 (正直に言うと、スクラムイベントで何言われるのか毎回怖かった)

Slide 10

Slide 10 text

新卒1年目のある日のこと 顧客⇔エンジニアの間で話すことを繰り返すと、2つのことに行きついた 1. 機能開発はせずに課題を解決できた ○ ボタンの表示を切り替えたい理由(Why)を深ぼる ○ エンドユーザーの課題解決のためだと勝手に思っていたが、組織内で慣習と なっているワークフローが理由であることがわかった ○ 顧客のワークフローを変える提案が最適な解決手段であると行き着く 2. やるやら・優先順位を決める明確な基準が事業にないことに気付いた ○ 仮に機能開発をするとして、やるやら・優先順位を決められなかった ○ それは、「事業がどのターゲットのどの課題を解決するのか」「何を付加価値・ 優位性にしたいのか」の解像度が低いから

Slide 11

Slide 11 text

「強い」エンジニアとは 僕から見た(リンケージの)エンジニアの「強さ」 1. Whyを追求することで、解くべき課題を見誤らない 2. 課題を解決するインパクトを追求することで、優先順位を見誤らない ○ 時に事業の戦略・方針の曖昧さを浮き彫りにする 3. 会社や事業のフェーズを踏まえたHowの提案をしている ○ 例)検証フェーズの事業では手動オペレーションをする、ミニマムで作れるもの を早く出す ● (+何も知らない人間が理解できる言葉で、必要なことが伝えられる)

Slide 12

Slide 12 text

自分なりに見出した価値・学び そして、自分が当時見出した価値・学びは、2つの側面でのWhyの深掘り 1. 顧客のWhyを深ぼる ○ Howは自分で決めなくていいし、何なら考えなくてもいい ○ なぜ何がやりたいのかを深ぼり、顧客について誰よりも詳しくなる ○ 顧客と話して解くべき課題を特定できるようになる ○ ユーザーストーリーの解像度が高まり、「顧客に聞かないとわからん」が減り、 エンジニアとのコミュニケーションもスムーズに 2. 事業のWhyを深ぼる ○ 事業として、「誰の何の課題を解決したいのか」「何が付加価値・優位性になっ て、どうすりゃ売れんのか」の解像度を上げる ○ やるやら・優先順位の基準を少しでも明確にして事業の方針を見出す

Slide 13

Slide 13 text

まとめ ● 「強い」エンジニアは、ユーザー・事業のWhyを追求することで、プロダクト・事業の 価値の最大化に貢献できる ● PdM(Biz職全般)は、Howを決めなくていい ● 顧客のWhyを徹底的に深ぼって、誰よりも詳しくなることに時間を注ぐ ● ※必要あらばエンジニアからそれを伝えることが組織を良くしていくかも?

Slide 14

Slide 14 text

チームで #それはhowなんよ からの卒業

Slide 15

Slide 15 text

Thank you