エンジニアが推進するプロダクトマネジメント | Qiita Conference 2023
Qiita Conference 2023で登壇の機会をいただきましたので、登壇内容を一部noteにもしておきます。登壇資料は最後に貼ってあります。
前提
プロダクトマネジメントはUX、Tech、Businessの交差領域であり、各々の専門性が重なるというのが基本概念のはずです。（左）しかし、プロダクトマネージャーという職種が増えてきた結果、分業したままなんとかプロダクトマネージャーがその糊となって繋げている組織をみることがあります。（右）
プロダクトマネージャーではなく、プロダクトマネジメントは各領域の専門家が集まるチームでやっていきましょう。プロダクトマネージャーはその旗を降る人であって一人でプロダクトマネジメントをするわけではありません。
エンジニアがプロダクトづくりを推進するためには、Tech x UXやTech x Businessの領域に積極的に手をだして重なりをつくっていきましょう。
ゲームのルールを理解する
プロダクトマネジメントをするために、まずはプロダクトマネジメントで大事だとされるルールをいくつか知っておくといいでしょう。私がエンジニアだったころに理解できていなかった４つのポイントを紹介します。
📌 1. ドックフーディングは大事だが、自分はユーザーの代表ではない
ドッグフーディング（プロダクトを自分でつかうこと）はとても大切です。ただ、「自分がユーザーとしてこう思う！」ということだけを根拠に主張しても、なかなかその意見は通りません。
なぜなら、仕様書をつくるためには、ユーザーの声は十分に聞いているからです。そこにユーザーとしての意見を追加してもなかなか意思決定は覆りません。「自分はこう思う！」は1つの仮説として検証しましょう。他のユーザーはどう思っているのでしょうか。
この学びを得たのはプロダクトマネージャーになって、ユーザーのために作ったプロダクトが全く受け入れられない経験を多くしてからです。自分にはバイアスが掛かっていて、自分がユーザーの代表ではないということが心に刻まれています。
📌 2. どれも「良い」から「良さの軸」が必要
魚の絵を可愛くしようとして鼻をつけた人も、魚として良くしようとして鰭をつけた人も、良い移動を提供しようとして足をつけた人も、みんな「よい」んです。しかし、良さの軸がありませんでした。
かわいいが欲しい人はちいかわを買うし、移動したい人はキックボードを買うので、コストをかけたのに誰にも売れません。
こうならないために、Core〜Howが整合しているか改めて確認してみてください。意外と自分のプロダクトを書き出してみると、WhyとWhatが整合していないものです。
📌 3. 「今」追うべき「良さ」である目標を知ろう
「良さ」には、時間軸もあります。今どこの数字に注力することを良いとするのかを表したのがロードマップと指標です。プロダクト全体としては良いことでも、「今」ではないこともあります。
📌 4. ユーザー以外のステークホルダーを知ろう
エンジニアとプロダクトマネージャーの情報格差を広げる要因の一つにステークホルダーとの関係があります。プロダクトの意思決定に関わるのはどんな人がいて、誰がどのように意思決定をしているのか全体の流れを分かっておくと適切なタイミングを見計らって意見が言いやすくなるはずです。
エンジニアが推進するプロダクトマネジメント
📌 1. 批判者ではなく、相手のゴールを知り達成を助ける
議論をすることは大切です。そして、ときにNOを言うことも大切です。
ただ、NOをいうときは同じ良さの定義を共有しているかという前提条件を確認しましょう。そして、プロダクトを成功させるための方法を職種を越えて一緒に考える姿勢を持ちましょう。
📌 2. プロダクトチームとしてアイデアを出しましょう
「いま」プロダクトチームとして何を目指すのかをロードマップや目標から知ることができたら、バックログになっていない機能を提案したり、バックログをより目標達成に近づけるための意見を伝えてみましょう。
📌 3. エンジニアが主導してプロダクトを成功に導きましょう
Techが重なる領域を増やしていきましょう。Techの専門性がない人が思いつかないようなことを、エンジニアは当然のようにしていることがあります。他の専門家に興味を持って、そこにエンジニアリングをかけ合わせることでプロダクトがどう良くなるかを考え、ロードマップに追加していきましょう。
資料
この記事が気に入ったらサポートをしてみませんか？