はじめに
GENIEE SFA/CRM部署でプロダクト企画をしている増田といいます。
私は、入社してから5年間エンジニアとして働き、去年2023年の7月からプロダクトマネージャー（PdM）にロールを変更しました。現在は、GENIEE SFA/CRMのAIチームとして、AIを活用した商品企画、プロトタイピング、そしてAIで解決できる顧客課題の発掘と提案を主に行なっています。
SFA/CRMというのは営業活動や顧客関係性の管理を支援するためのツールで、会社や商談情報、顧客との活動の履歴などをSFAに貯めて一元管理や可視化をすることで、日々の営業活動の効率化等に役立てることができます。
この記事では、PdMに異動してから半年間で得た気づきや学びとともに、プロダクト開発チームがどのような目標を持って開発を進めるべきか、エンジニアからPdMへの転職でどのような視点の変化があったか、そしてどのような思考を持つ人がPdMに向いていると思うのかについて、私の経験を通してお伝えしたいと思います。
なお、この記事で述べられているほとんどの内容は、以下に紹介する書籍で既に触れられています。この記事にご興味をお持ちいただけた場合は、ぜひその書籍もお読みいただくことをお勧めします。
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
https://amzn.asia/d/7HX4UMl
エンジニアにも知ってほしいたったひとつのこと
何のためのプロダクト開発チームか = 顧客課題の解決に全力で取り組める
プロダクト開発チームの存在意義とはなんでしょうか。ここでいうプロダクト開発チームとはエンジニア、PdM、デザイナーを含めたチームのことです。もちろんそれぞれのロールごとに責任を負うべき範囲や重要視する考え方は異なりますが、プロダクト開発チームとしての本質は顧客課題の解決にあると思います （下図のWhyの部分）。
ここの課題設定やチームへの伝わり方が間違っていると、せっかく苦労して機能リリースをしたのに顧客が全く使ってくれないとか、顧客が最も課題を感じている箇所が改善されていない、といったことになります。もちろんここの課題設定に責務を負うのはPdMの役割ですが、チームとしての本質は課題解決にあるということをチーム全員が意識することが重要だと思います。
以降では半年間でのPdM業務で得た気づきを述べますが、どれも本質的には顧客課題の解決が重要という話に帰着すると思っています。
プロダクトの4階層
引用：https://note.com/ozyozyo/n/nc4a35eed9f37
気づき1 解法ではなく問題に恋せよ
自分がPdMになるきっかけとなったのは2023年のGAIブームでした。その年の3月頃、SFAに元々存在していた「プロセスビルダー」というSFAのレコードの更新などをトリガーにしてレコードを作成したり、項目の値を更新するような自動化機能にGPTを組み込み、それをリリースしたことがきっかけで、SFAのAI機能のプロトタイピングや企画を担当するようになりました。
上期に上のプロセスビルダー機能に加えて、今ではFunction callingでお馴染みの、GPTからAPIを呼び出す技術を応用し、チャット形式でSFAのレコード一覧取得やレコード作成・編集が行える機能を開発しました。それを開発した際はすごいものを作ってしまったと優越感に浸っていましたが、結果としてそれらの機能は全く売れませんでした。
自分では最新技術を取り入れた革新的な機能だと思っていましたが、お客さんからするとその機能があることで解決できる課題やベネフィットがほとんどありませんでした。 このようにいくら最新技術を取り入れて作った機能だとしても、それが顧客の課題に刺さっていなければ意味がないのです。
顧客のペイン・ゲインに対して価値を提供することが重要
引用：https://blog.nijibox.jp/article/value_proposition_canvas/
気づき2 顧客の一次情報としての声を聞きにいく
上期の反省を踏まえて下期では課題ベースでの商品企画や設計を行いました。3Qで主に行なったことは下記です。
- 社内の営業やCSチームからAIで解決できる課題がないかのユースケースの募集
- 競合SFAのAI機能の分析
- 営業資料にAI機能の紹介ページを作成
- 営業やCSチームにAI機能やその機能で解決できる課題のインプット
しかしながらこれらを行なっても、AI機能の受注はおろか、商談も全く獲得することができませんでした。
SFAのAIチームは自分と事業開発部の二人構成なのですが、どちらもほとんど営業の経験がなく、実際のお客さんに紹介しに行く機会を作っていませんでした。その結果、社内や机上の仮説だけで商品設計を行い、具体的にAI機能がどういう顧客課題を解決できるかの解像度が上がらない状態が続いてしまいました。また、営業資料やチームへのインプットによってデリバリーをしていた気になっていましたが、実際に営業やCSメンバーでAIの紹介をしていたのはごく一部のメンバーに限られていました。
これらの失敗を踏まえて、4Qからは新規・既存のお客さんに対してAIチーム自ら紹介の機会を作ってフィードバックをいただくようにしました（自分は喋るのがめっぽう苦手なので、もう一人のメンバーにほぼ喋ってもらってますが、、）。実際のお客さんのフィードバックを一次情報としていただくことで、導入にあたってどこがネックなのかや実際どんな課題を抱えているかの解像度が格段に上がりました。
同時に録画した商談の動画を見てAI機能の提案余地を発掘し、営業チームに提案余地を伝えることで、具体的にどういう課題に対してAI機能を提案できるかを営業チームにも理解してもらうことができました。
気づき3 結局動くものがないと売れない
気付き2での改善の結果、4QではAI機能単体での紹介機会や、そこからの商談化の割合もかなり改善されました。特にニーズの多い機能として、ZoomなどのWeb会議を録画した音声データから発話をAIが文字起こしし、それをSFAに連携、AIで指定のフォーマットに沿って議事録を要約、自動作成するといった機能があります。
この機能自体の企画は去年の夏くらいにあってチーム内でも共有をしていたのですが、実際に注力して企画や提案を進めたのは4Qからになります。
4Qから注力し始めたのは、Japan AIというGENIEEの子会社の方で文字起こしのプロトタイプを開発しており、それを使って実際のSFAの商談の動画からGPT4で要約をさせたところ、思っていたよりも精度が高くこれは使えるぞ、となったのが理由です。
新機能の企画をPdMが説明するシーンにおいて、その時は反応が悪かったのにいざ画面イメージやプロトタイプを触ってもらうとめっちゃいいじゃん、と反応が一転することはAI機能に限らず弊社でもよくあります。また、企画段階のものをお客さんに提案した時に多いのは、トライアルでとりあえず使って試したいという声だったりもします。やはり実際に動くものや画面がないと、業務での利用や販売のイメージが湧かないのです。
弊社内で新規プロジェクトがうまく行く場合のほとんどにおいて、ビジネス側とラフにコミュニケーションが取れて爆速開発できるエンジニアが必ず一人いました。 新規のプロダクト開発は下図で示すように、課題の定義、MVP（Minimum Viable Product）の構築、顧客への提案・紹介、フィードバックの分析、の仮説検証のPDCAをいかに高速で回せるかにかかっているため、爆速開発エンジニアがいればそこのサイクルが爆速で回せて仮説検証の回数を増やすことが可能です。
新規プロダクト開発のPDCAサイクル
気づき4 PdMとBDは唯一の職能横断ロールである
プロダクトマネジメントに必要な要素を表す図としてよく見られるのが下のプロダクトマネジメントトライアングルです。各専門領域ごとにその領域を担当するチームや部署が存在しており、それらが健全に機能し、連携できるように全体最適を図るのがPdMやBDの役割です。
プロダクトマネジメントトライアングル
気付き2の内容と重複しますが、3QのAIチームの動きは営業やCSチームにAI機能のデリバリーを全面的に委ねてしまっていた状況でした。具体的な商品設計、ターゲット市場、提案事例が欠けている状態で、「紹介してほしい」と依頼されていたため、依頼を受けた側も、どのような顧客にどのように製品を販売すればよいのかがわからない状態だったと思います。
4QではAIチーム自ら商談動画から提案余地を掘り起こしたり、メール施策を打って既存顧客への提案機会創出と実際の提案を行ったりと、自分たちの本来の職能を飛び越えて動くことで、一定デリバリーの部分を改善することができました。
エンジニアとして開発をしていた際にはある程度自分の役割の範囲で実務をこなしていればうまく仕事が進むことが多かったのですが、PdMとして全体最適を担うことになった今では、自分の職種や能力に関係なく、ボトルネック箇所があればそれの解消に全力を注ぐことが重要 なのだと気付きました。
エンジニア出身のPdMの強み
上のような考え方や視点の違いで、エンジニアからPdMに異動して半年で苦労することが多かったのですが、逆にエンジニアだったからこそうまくいったことについても話そうと思います。
やはりエンジニア出身ということで、Howの部分を考えるのが得意だったため、ビジネス側や顧客の要望に対するソリューションがその場である程度返せるのは強みだと感じました。また普通のPdMであれば開発に見積もり依頼をしてソリューションや工数を見積もってもらう必要が出てくるのですがそこがある程度自分で完結できるのも大きな強みです。
また、気付き3で述べたように、企画段階の新機能をすぐにプロトタイピングしてそれを元にデモなどで社内外に提案ができるのは何よりも強みだと思います。実際、今あるAI機能の多くは私の方で検証やプロトタイプ実装をしたものをベースにしています。
PdMに向いていると思う人物像
個人的な意見にはなりますが、最後にこういう考え方の傾向や好みがある人がPdMに向いているのではないか、という特徴を自分の性格的な部分も合わせて記載します。
- 全体観や視野を広く持つのが好き
- スペシャリストよりもジェネラリスト
- 様々な部署や顧客と話しながら企画をするのが好き
- ビジネス課題の発見からソリューションの構築までに一貫して関わりたい
気づき4の通り、PdMというロールは全体最適のためのロールなので、知識の面でもコミュニケーションの部分でも幅広く関わっていくのが好きなタイプの方は合っているように思います。
Discussion