転生したら営業色がつよいプロダクトの開発PMだった ~ プロダクトの土壌作り編 ~

地味PM Advent Calender 2022 の12日目の記事です。

はじめに

はじめまして、タケハラ（＠sauna_engineer）と申します。
サーバーサイドエンジニアとして3年ほど開発に勤しみ、新規事業責任者（1年弱）を経て、2022年4月からAI-OCR系の新規事業の開発側のPM（BizDev側のPMと協働）を担当しています。
営業色のつよい組織からの新プロダクトということで、当然周りは営業畑の方が多く、プロダクトの暗黙の文脈も通じず…な日々、そんな組織の中でよりプロダクトとしての価値を追求していくために大切にしている「プロダクト組織として土壌づくり」について記事にしています。
巷のプロダクト本のノウハウを組織に導入したいが….職能の違いでなかなか上手く行かないという方の参考になれば幸いです。
※ 営業色が強いことが悪い訳ではないので、悪しからず。

プロダクトマネジメント土壌は地味に重要

よく、作物作りにおいて、土づくりの重要性が語られていると思いますが、プロダクト作りも同様で、チームの動きがプロダクトの価値に直結するような好循環を生む環境・組織作り = 土壌づくりが重要だと考えます。
「EMPOWERED 普通のチームが並外れた製品を生む出すプロダクトリーダーシップ」でも言及されていますが、プロダクト開発において重要なことは関係者が同じ向かうことです。
自らが人事権を持ち自由にチームを組織できるなら別ですが、多くの場合は会社の方針によって招集された、それぞれバックボーンも考えも違う方々が集まったチームだと思います。もちろんプロダクト作りへの理解も薄いかと思います。
そのような状態では、なおさら声の大きさや権限に引っ張られてしまい良いプロダクトは生まれません。まずはチームを耕し、プロダクトを作る上での認識を揃えていく必要があります。

地味によかったアクション３選

どれも地味でなんならこんな取り組みを目的を持ってやっていることにすら気が付かれていないとは思いますが、それでいいんです。そんな地味なアクションをご紹介します。

KPIの優先度に対しての認識をチームで揃える

当然組織には、KPIが設定されており、それぞれに対し優先度※が設定されているかと思いますが、これを正しく理解しているメンバーはどれだけいるでしょうか？ この認識が揃っていないと、チームのメンバーは各々の業務に近いものを優先するようになってしまいます。もちろん担当領域で結果を出すことは重要なことではありますが、時として優先度の低いものが声の大きさにより優先されてしまうなどということが発生してしまいます。
この問題に対しては以下のようなことをセットで対応しました。

• マイルストーンの整備による、全体感の認識合わせ

• 着手判断時に「なぜこの順番で着手するのか？」について説明する

• 開発リソースの何割をどのKPIに割くなどの緩い約束をして、KPIとその領域に近い人を置いてけぼりにしない

「この機能あれば契約できる…」プロダクト価値貢献度の低い目先の契約につながる機能についての対話

「この機能があれば契約するって見込み顧客が言ってくれてるんだけど…作ってくれない？」このフレーズ、どこかで聞いたことありませんか？
市場が広く他にも見込み顧客が多い場合は無視できるかもしれませんが、ニッチな市場でやっと契約直前まで来たのに…という状態だとなかなか無視できませんよね。
結局は着手したとしても、この状況を良しとしない認識を持つことが重要です。私のチームでも着手することにより、システムの複雑化・技術負債などの副作用について時間をかけて会話し、今後は「プロダクトの価値」を追求しそれに貢献する開発を行うということで認識は揃えつつも、商談時の顧客の声を開発側に届けるためのデータベースや商談中に対応スケジュールの確認ができるマイルストーン整備など、営業メンバーに製品の可能性という武器を持たせることを心がけています。

とはいえ、状況に応じてはまた同じことをやるんだろうなという感が拭えず、この辺のノウハウなどありましたら教えていただきたいです。

非開発メンバーのシステムへの理解促進

私の属している組織は外部に開発をアウトソースしていたこともあり、エンジニア以外のメンバーにはプロダクト作りのノウハウがない状態でした。そのため、HTTPSのような基礎的なことだったりから、開発者の考えなどの理解を促す非公認アンバサダー活動を行ないました。
主には以下のようなことを丁寧に会話する時間を設け、自らも相談しやすいような雰囲気を醸し出すことで会話の絶対数を増やすことで浸透は図りました。

• 提供しているサービスのシステム側面への理解

• バグと仕様の違い

• なんでもできる機能は結局何もできない（機能開発のスコープ）

• 技術負債への理解

この中でも「提供しているサービスのシステム側面への理解」はとても効果がありました。営業メンバーが正しく製品の説明をすることができるようになったため、導入に伴う差し込み開発の回数が減り、そして営業側からの製品フィードバックもより具体的なものになってきました。
またシステムへの理解が前述したプロダクトのマイルストーンの納得感にもつながったため、直近ではKPIに貢献しないけど必要な開発にもチーム内で納得感を持って取り組みことができるようになりました。
これまでのプロセスを通して、少しずつプロダクト価値にフォーカスした組織になってきたという実感があります。これまで機能の開発依頼が来ていた場面でも、まず「欲しい機能ではなく、顧客の課題」が共有されるようになり、全体感を考えながら意思決定ができる状態になってきています。

まとめ

リーンキャンパスだったり、NSMだったりプロダクトマネジメントへのHowは最近増えてきたように感じます。ただ実際にそれを導入するにしても、職能やバックボーンの違いでなかなか浸透しないことが多いかと思います。
そこで重要なのが、なぜ浸透しないのかを理解し対話をしていくことです。そうすることで少しずつ土壌が整っていくのでは思っています。

そんなわけで、やっとこさプロダクトマネジメントの土壌が整いつつあるので、2023年はNSMの導入など、よりプロダクトの価値向上に向け一気にアクセルを踏む１年にしていこうかと思います。
まとめてしまうと、ありきたりな記事になってしまいましたが、職種の壁で悩まれている方の参考になれば幸いです。