プロダクト開発をHowだけで進めない方がみんな幸せになれるよ、という話

はじめに

こんにちは、エンプラSaaSのプロダクトマネージャーをがんばっている@diceK66です。

どこの会社でも起きがちではあるけれど、放置してしまうと、組織全体を悪いサイクルに巻き込んでしまう可能性がある、「プロダクト開発をHowだけで進めてしまう問題」について、書きたいと思います。

この記事は、「Howだけでプロダクト開発をはじめてしまうと、こういう問題が起きやすいですよ」という課題提起のための記事です。この問題にどう向き合えばよいか、解決策は何かについては、この記事では深くは言及しません（時間ができたら、それもいずれ詳しく書きたい・・・）

また、私は、BtoB、とくにエンタープライズ向けのプロダクトマネジメントを頑張っている人間であるため、それ以外の領域の方からすると違和感を感じられる可能性がありますが、ご了承ください。

「プロダクト開発をHowだけで進めてしまう問題」とは

BtoBのプロダクトでありがちな、下図のようなコミュニケーションを指します。多少デフォルメしたストーリーにしていますが、みなさんも、おそらく似たようなコミュニケーションをどこかでご覧になったことがあると思います。

ちょっと読みづらくて申し訳ないのですが、ぜひ拡大してストーリーを追っていただければと思います。

簡単にまとめると、すべてのステークホルダーが「機能がどうなってほしい」だけでコミュニケーションしてプロダクト開発を進めてしまうことで、結果として顧客のニーズに何も答えられない機能を開発して、それが各ステークホルダーのストレス要因になる、そして、それが繰り返されてより悪化するという悪循環を起こしてしまうことです。

何が問題なのか

クライアント・ユーザー

実際にリリースされた機能が使いにくいというストレスを感じます。
特にエンプラSaaSの場合、事前に機能の内容についてコミュニケーションが取られるケースが多く、「自分の要望した機能が実装されるぞ」という期待値が上がった状態で、「出たけど使いにくい！」という、落差が強調される事態となり、ストレスをより強く感じてしまいがちです。

カスタマーサクセス・カスタマーサポート

お客様のストレスが上がった状態となるため、カスタマーサクセス・カスタマーサポートのメンバーにとっても、ストレスフルな環境になってしまいます。
また、製品に対する期待値が必要以上に下がってしまうことで、Churnリスクを含む、本来ならば向き合う必要がないリスクと向き合う手間が余計にかかります。

エンジニア

使われない機能を作ることにストレスを感じます。
仮に使われたとしてもネガティブなフィードバックを受けることになりやすく、エンジニアのモチベーションが上がりやすい環境とは呼びにくい状態になるはずです。

プロダクトマネージャー

使われない機能を作らされることなった、せっかく要望を伝えたのにお客様に満足していただけるものを出してもらえなかったなど、ステークホルダーたちの信頼を失います。
この状態が続くと、「このプロダクトって本当に作る意味があるのだろうか・・・」という謎の猜疑心が湧いてしまい、メンタルケアが必要になります。

この問題にどう向き合うべきなのか

今回の記事では、手短に記述しますが、少なくとも、図の中のクライアント以外のメンバーは、以下のポイントにフォーカスしたコミュニケーションを心がけるべきです。

1. 機能の目的、要望の背景
2. その機能が実現されたら、誰にどんなメリットがあるのか
3. そのメリットは、どの程度の定量効果があるのか

例えば、カスタマーサクセスはクライアントに対して、プロダクトマネージャーがカスタマーサクセスに対して、このようなコミュニケーションを取るイメージです。

「なぜその機能がほしいのですか？」
「どんなシーンで、誰が必要とするのですか？」
「それが実現されたら、どんなメリットが、誰にありますか？」
「そのメリットは、定量的に言うと、どれくらいのメリットなんですか？」
「仮にその機能がない場合は、どのような代替案をするのですか？」
「その代替案と比較して、どれくらいのメリットが、あるのですか？」

（注意）これは、対1顧客に向けた話ですが、SaaSなので、これに展開性があるのか、ビジネス機会になるのか、競合との比較などの論点を検討し、最終的な決断を下すべきだと思います

エンジニアのリアクションをよく見てほしい

エンジニアは、基本的に、根が真面目で、人の役に立つものを開発したいと考えて開発をしている人がとても多いです。

もしも「最近エンジニアから、これってなんで作るんですか？」みたいな意見が多いなと感じている方は、潜在的に「プロダクト開発をHowだけで進めてしまう問題」が起きている可能性がありますので、ご注意ください。

プロダクトマネージャーは、製品の仕様を考えて決めるのが役割ということ以上に、機能の本質をステークホルダーに伝え、「だったらそれ、絶対作ったほうがいいよね！」というチームの納得感を醸成することが重要と思います。

逆に、そこまで本質的なコミュニケーションがとれていれば、機能の仕様の詳細は勝手に回りのメンバーが理想的なものを考えてくれるはずで、それこそがプロダクトマネージャーが本来目指す姿なんじゃないかなと思ったりもします。

おわりに

今回は、問題の提起と簡単な深堀りまでの記事でしたが、おそらくこれに似たような問題というのは、特にBtoBのSaaSを作っている会社では、一度は見かけたことがある課題ではないでしょうか。

この問題がもしも身近で発生していた場合、それを繰り返して発生してしまいやすく、チームメンバー全員が全力で頑張っているのに、ステークホルダーがお互いに対して不信感をつのらせてしまうという、最悪の問題に発展するケースもあります。

この問題にどう立ち向かうべきかについては、皆さんに興味を持っていただけそうでしたら、改めて詳細を書いてみたいと思いますので、気になる方がいらっしゃったら、ぜひ「スキ」やSNSでのシェアをお願いします、記事を書くモチベーションに繋がりますので！ｗ