ロードマップの変更に心が痛む

ロードマップは生き物だ。仮説検証の結果やプロダクトを取り巻く環境変化に応じてどんどん更新していかないといけない。更新されないロードマップは死んでいる。

理解しているし、それは正しい。

ただその変更に、心を痛めざるを得ない状況があるということも、目を背けることのできないまた一つの事実。

例えばそれは、BtoBのバーティカルSaaSにおいて、どうしても後回しにできない特定顧客からの要望を、その他顧客からは大きな要望が無かったとしても、対応すべきと経営判断がなされたとき。
例えばそれは、大企業プロダクトにおいて開発チームの声が届かない上位層から、社内政治的な側面も含めてこれをやれと指示が降りてきたとき。

プロダクトマネージャーをはじめとした開発チームが積み重ねてきた仮説検証の日々を、その一言は簡単に捨て去るパワーをもちます。

もちろんそのロードマップの変更が自分では考えつかなかった大きな価値を生み出す可能性はあります。それに、これまでの仮説検証だって無駄になった訳じゃない。

でも…それでもやっぱり私は辛いと感じてることを認めざるを得ません。

そんなメンタルモデルじゃプロダクトマネージャーに向いてないって言われたって仕方ないかもしれないけど、プロダクトマネージャーみんながみんな、鉄のメンタルをもっている訳じゃない。泣き言だって許して欲しい。

しかし私だって腐ってもプロダクトマネージャー。
ロードマップは常に私の手で紡がれ、私の言葉で語られなければいけません。

心が痛むロードマップの変更を受け入れた瞬間からが、本当の勝負の始まりです。この変更を受け入れてよかった、最高の価値提供ができたと思えるプロジェクトになるように、腐ってばかりじゃいられない。

そういう時にまず私が心掛けているのは、解決したい課題の優先順位の変更は受け入れても、要求・要件には手を出させないようにすること。
これが実は一番難しくて一番大事だと思っていて、特にロードマップの変更要求の出所に近いビジネスサイドのメンバーから、「この課題解決に対する要求事項はXXだから後はヨロシク」みたいな言葉が飛び出すと危険信号。BtoBSaaSはどうしてもビジネスチームがユーザーに近いところにいるので、ユーザーの声を聞かずにこういった態度を取られることがあります。でも本当にそうなんですか？仮説検証はした？それってあなたの想像ですよね？
そしてこういった態度は得てして、組織内でプロダクトマネージャーの役割や存在意義を正しく理解されていないことが根本原因になっている可能性が高いかなと思います。この組織課題がある場合はまずはここを解決しないと、永遠にプロダクトマネージャーを軽視したロードマップの変更とプロダクト価値の毀損がおこなわれ続けてしまいます。なんとかプロダクトをプロダクトマネージャーの手に取り戻すために、精神を病まない程度に戦って、無理ならその組織はプロダクトマネージャーを必要としてないのねと割り切って辞めればいい。

次に、その課題によって苦しんでいるユーザーの体験に寄り添うことに全力を注ぎます。もちろん実在のユーザーを探し出してヒアリングできればベスト。
例えその課題で苦しんでいるユーザーがたった一人だとしても、ここでそのユーザーの課題にしっかりと寄り添い共感できれば、もう勝利のファンファーレが聞こえてきていると言っても過言ではないのではないでしょうか。

最後は、その課題解決をプロダクトビジョンに沿った表現で言語化、物語化します。
ツールとしてはインセプションデッキを使うのが良いかなと思っていて、さらにはインセプションデッキをエンジニアと一緒に書き上げるのもこのケースでは有効な気がしています。ある程度はプロダクトマネージャーの頭の中で物語が出来上がった状態でエンジニアと会話しながらインセプションデッキを書いていくと、全員が一つの物語の作者になることができ、チーム全体の課題解決に向けたモチベーションが高まります。

なんたって私たちは、プロダクトづくりのプロフェッショナル。納得できれば絶対にいい課題解決ができるんです。あとは、その過程をワクワクするものにできるかどうか。

今日も今日とてどこかで起きている悲しきロードマップの変更。
みんな、なんとか心身ともにご自愛ください。
こんなPMですが、私もなんとかやってます。