プロダクトマネージャーが「つくらない」判断をするとき
こんにちは、プロダクトマネージャーのたけまさです。
プロダクトマネージャー Advent Calendar 2022の18日目の記事です!
プロダクトは中長期で大きな価値をユーザーに届けることを目指します。
開発の現場では「つくる」判断以上に、無数の「つくらない」判断と向き合うことになります。今回は日常的に発生する「つくらない」判断を通して、なぜプロダクトをつくるのか?を考えます。
1.つくる以前の状態のとき
PM「いまプロダクトをつくるのはダメです。なぜなら…」|
そもそも事業の段階がプロダクトをつくる以前の状態です。ユースケース、事業戦略、競合との違いなどの不在が論点です。
プロダクトをつくる = 事業が伸びるではない
商売の仕組みを説明できない場合、プロダクトを作るには早い状態です。プロダクトさえあれば事業が立ち上がる、というワンチャンはありません。
この段階で大事なのはプロダクトがあることではなく、スケールするための顧客、課題、解決法を見つけることです。
すでに作ってしまっている場合の対策
中途入社した1人目PMあるあるです。「作りたい」「作らないとわからない」と考える経営者やメンバーと目線を揃える必要があります。フラットに現状、あるべき、カネの話ができる関係性が必要です。
作る前に出来ることはたくさんある
何よりも成長を実現するユースケース、グロースドライバーを特定が先決です。PMFに向けて実行可能なことは、完全動作するプロダクトを作らなくても紙芝居やモック、オモテだけ整えたプロダクト風人力オペレーションなどたくさんあります。
プロダクトとは事業の上手なやり方を型化して、スケールさせるためのものです。プロダクトあれば事業が立ち上がるは順番が逆です。
2.つくる意味がブレるとき
PM「ウチが本当にやるべきことですか?なぜなら…」|
コンセプトとアクションの一貫性の話です。顧客にこれまで積み重ねてきた体験、事業の構造上の強み、それらのギャップが論点です。
唐突ですが先日いただいたお土産のドーナツがおいしかったので、ドーナツで例えてみたいと思います(笑)。
要望はどれも間違っていません。お客様はそのお店が好きだから、もっと楽しみ方が広がると嬉しいな。という要望です。
コンセプトと施策の整合性
コンセプトのブレには顧客体験の一貫性だけでなく、生産性にも大きく負をもたらすケースがあります。上記の要望を叶えたときに起こる負を考えてみたいと思います。
誰の課題を解決するためのプロダクトか。その要望を自分たちがやる意味と合理性は何か。コンセプトのブレは顧客体験の文脈だけでなく、カネの流れにも影響がないか注意が必要です。
3.つくる価値が低いとき
PM「やる価値がないです。なぜなら…」
これは投資対効果の話です。プロダクトの開発と運用にかかるコスト、リターンとして得られる利益や効果が論点です。
「利益」と一言でいっても、何で最適を考えるかという話もあります。継続的に利用いただくためのバグ修正や、開発効率を高めるためのリファクタリング、金銭的な利益には繋がらないけど共感を生むような仕組みなど、利益は目先だけでなく全体最適で考えることも必要です。
営利活動では利益をもたらさない課題や要望に対して、貴重な資金やメンバーの時間を使う理由がありません。
このあたりの条件を満たすものは、典型的なつくる価値の低いものです。
「つくらない」判断をか、価値を高める再プランニングが必要です。
つくる価値を高める2つの方法
投資対効果を高める方法はシンプルにこの2つです。
大事なのは1つの解決手段に固執しないことです。達成したいゴールには基本的に「程度のグラデーション」があります。松竹梅プランを用意して、複数のROIを検討するのがおすすめです。その機能が寄与する時間軸のなかで適切なプランを選びましょう。以下は例です。
開発プロセス効率化でコストを抑える方法は、過去の記事をご覧ください。
4.つくる順番があるとき
PM「つくるけど今ではないです。なぜなら…」
これはシンプルに順番の話です。優先度と開発順序の2つが論点です。
優先度の話
事業計画やプロダクト開発計画に基づいて、「何からつくるべきか?」を複合的に考え、優先度の判断が必要があります。
優先度については、12/5のアドベントカレンダーでTakuya Asakoさんの記事で詳しく事例が公開されています。
開発順序の話
ある機能の実現には、それを支える複数の仕組み、依存関係の強弱、効率のよい順序があります。開発は「空を自由にとびたいな、はいタケコプター!」とはいきません。
開発順序の見える化
これらを見える化した図などを作ると便利です。私のいた環境では、Civilizationというゲームの文明開発の技術ツリー、Final Fantasyで魔法を覚えるためのスフィア版、カレーの作り方などに例えてマップを作成しました。
これはPMやエンジニアが開発するときの状況整理にも使えるのですが、社内のステークホルダーにも「なぜ今ではないのか?開発に順番があるのか?」を丁寧に説明することができます。
まとめ
誰かに対して「NO」を表明することは、それなりにストレスがかかります。その役割を担うPMてちょっと損な役回りですよね(笑)。
プロダクトマネージャーの過不足ない判断が、最速でお客様の課題を解決する。事業の成長に貢献し、結果ステークホルダーみんなの幸福につながる。そんな矜持をもって「つくらない」判断と向き合っていきましょう!
今年のAdvent Calendarも素敵な記事がたくさんあります。
ぜひご覧ください!
この記事が気に入ったらサポートをしてみませんか?