「プロダクトマネジメントと事業開発に関する私的な振り返り」という記事を読みました。
膨大な試行錯誤が細やかに生々しく書かれており、現役PdMやPdM志望者のコンパスと言える記事です。著者の卓越した言語化能力を感じます。
私もPdM兼機械学習エンジニアとしてプロダクト開発に日々勤しんでいますが、読んだ中で、特に大事だなと感じたことを３つ取り上げてみました。
プロダクト開発でやりがちな失敗は、機能比較表を作って、競合より豊富な機能を作ってしまうことです。これをやってしまうとコスト増になってしまい、「悪くないけど価格が高い」となって顧客に選ばれなくなります。
要件を増やすことは誰でもできますが、減らすことはPdMしかできません。
また労働環境から言っても要求の最小化は重要です。PdMはミニCEOとか言われていますが、取締役でもないただの１使用人なので「最小工数で成果を上げていく」という姿勢は持ち続けたいものです。
この方と一緒に働けるエンジニアは幸せだろうなと思います。著者はエンジニア出身のため、エンジニアのことを細部までよくわかっています。エンジニアのために環境を整えてあげたいけど自分はリーダーとして前を向かないといけない、というジレンマを抱えているのだと思いました。
また、エンジニアに丸投げしないというのは、エンジニア特有の発想だと思います。
開発経験がなければ、エンジニアとかみ合ったコミュニケーションができません。最先端技術を興味本位で使ってみたいエンジニアに、枯れた技術でやるようにお願いするためには、技術知識のキャッチアップが必要です。
特にAIや機械学習が関わるプロダクトの場合、技術的な難易度が3段階くらい跳ね上がるため、開発経験がないとPdMのロールを担うのは難しいです。
一方開発経験があれば、開発者がどのように作りこんでいくかイメージできます。「時間さえあれば自分でプロダクトを作れる」という思いがあると迫力が出ます。
もちろんエンジニアと比べ、コードを書く機会はかなり少ないのですが、伝家の宝刀として持っておくイメージです。（伝家の宝刀は、あまり使わないから宝刀なのです）
参考記事：デジタル化(DX)の要求定義できる人材いますか
先を見通すということは、周囲より一歩先にプロダクトイメージを持っているということです。PdMが脳内で作りこんだプロダクトイメージを、ユーザー起点でブラッシュアップしながら、必要な機能に絞り込み、エンジニアが開発していく流れになります。
おそらく大企業が求めるDX推進マネージャーなども、PdMと似たようなスキルセットになるのではないでしょうか。
例えばですが、ホワイトボードで図解的に説明するのが得意なエンジニアは、PdMの適性が高いと思います。
関連記事：【事業開発担当必見】おすすめのビジネス書をランキング形式で紹介する
膨大な試行錯誤が細やかに生々しく書かれており、現役PdMやPdM志望者のコンパスと言える記事です。著者の卓越した言語化能力を感じます。
私もPdM兼機械学習エンジニアとしてプロダクト開発に日々勤しんでいますが、読んだ中で、特に大事だなと感じたことを３つ取り上げてみました。
①ワオ体験を描く
1つのユースケースに絞って「便利じゃん！」「これは感動だ！」「ワオ！」と思わせる。特定のユースケースで120点のUXを見せつける。たとえ他の機能が不完全でも、1つが魅力的だから、次のアップデートが楽しみになる。 全てを平均点で作るよりもROIが高い。
プロダクト開発でやりがちな失敗は、機能比較表を作って、競合より豊富な機能を作ってしまうことです。これをやってしまうとコスト増になってしまい、「悪くないけど価格が高い」となって顧客に選ばれなくなります。
一方、120点のユースケースを作りこむと、良いことが3つあります。
①顧客に訴求できる
②社内に訴求できる
③プロダクトのコンセプトが洗練化する
優れたユースケースは、顧客や社内の関係者に訴求できますし、何よりプロダクトのコンセプトが洗練化する効果があります。特に初期開発では「一点豪華主義」が有効です。
①顧客に訴求できる
②社内に訴求できる
③プロダクトのコンセプトが洗練化する
優れたユースケースは、顧客や社内の関係者に訴求できますし、何よりプロダクトのコンセプトが洗練化する効果があります。特に初期開発では「一点豪華主義」が有効です。
②要件をカットする
・仕様書の整備と合わせて、対象スコープを大胆にカットした。
・本当はやりたい。全部を作って、提示したい。
・だけど、目標期間でリリースして、利用してもらって、成果を出さないといけない。
・さらに、コアのUX（ワオ体験）に関する機能・UIは、中途半端な開発をして、妥協するわけにはいかない。この決断こそが企画屋の真価だと信じている。
要件を増やすことは誰でもできますが、減らすことはPdMしかできません。
「この課題だけ対処すればOK」「この機能いらなくね」みたいに、ユーザー体験と時間軸を踏まえ、要求を最小化していくことが腕の見せどころです。
また労働環境から言っても要求の最小化は重要です。PdMはミニCEOとか言われていますが、取締役でもないただの１使用人なので「最小工数で成果を上げていく」という姿勢は持ち続けたいものです。
③Developerに丸投げしない
・もともと色々なことをDeveloperが自主的に担おうぜ派だった。自分自身がDeveloperだったときは、そのように心掛けて動いていた。だから周りに集まるDeveloperたちも似た価値観だった。しかし、それはDevOps幻想と呼ぶべきものだった。
・現実としては、Developerはコーディングで一杯一杯になりがちだ。意欲や能力がないからではない。 予算とスケジュールに余裕がないからだ。
・必要な開発要件は山積みだ。 しかも、Developerは1文字のtypoでエラーになる世界で戦っている。「これはユーザーにとって使いやすいのだろうか」「この挙動でOKだろうか」と考えるには、切り替えが必要になる。予算とスケジュールに余裕がないと、単価の高いDeveloperには、コーディングに専念してもらわざるを得なくなる。
この方と一緒に働けるエンジニアは幸せだろうなと思います。著者はエンジニア出身のため、エンジニアのことを細部までよくわかっています。エンジニアのために環境を整えてあげたいけど自分はリーダーとして前を向かないといけない、というジレンマを抱えているのだと思いました。
また、エンジニアに丸投げしないというのは、エンジニア特有の発想だと思います。
開発経験がなければ、エンジニアとかみ合ったコミュニケーションができません。最先端技術を興味本位で使ってみたいエンジニアに、枯れた技術でやるようにお願いするためには、技術知識のキャッチアップが必要です。
特にAIや機械学習が関わるプロダクトの場合、技術的な難易度が3段階くらい跳ね上がるため、開発経験がないとPdMのロールを担うのは難しいです。
一方開発経験があれば、開発者がどのように作りこんでいくかイメージできます。「時間さえあれば自分でプロダクトを作れる」という思いがあると迫力が出ます。
もちろんエンジニアと比べ、コードを書く機会はかなり少ないのですが、伝家の宝刀として持っておくイメージです。（伝家の宝刀は、あまり使わないから宝刀なのです）
参考記事：デジタル化(DX)の要求定義できる人材いますか
図解的に説明できるエンジニアはPdMに向いている
ＡＩ・機械学習案件は「PoC倒れ」が非常に多いです。PdMは、プロダクト納品後のユーザー体験まで見通して、PoCやプロダクト開発を進めていくことが求められます。先を見通すということは、周囲より一歩先にプロダクトイメージを持っているということです。PdMが脳内で作りこんだプロダクトイメージを、ユーザー起点でブラッシュアップしながら、必要な機能に絞り込み、エンジニアが開発していく流れになります。
おそらく大企業が求めるDX推進マネージャーなども、PdMと似たようなスキルセットになるのではないでしょうか。
例えばですが、ホワイトボードで図解的に説明するのが得意なエンジニアは、PdMの適性が高いと思います。
関連記事：【事業開発担当必見】おすすめのビジネス書をランキング形式で紹介する
