- 前回の記事はこちら：「第3回 ステークホルダーと目的・ゴールを共有していますか？共通言語づくりの重要性と仕方」
プロダクト開発で起きがちな失敗とは？
BizMake（ビズメイク）のプロダクトマネージャー（PM）としてプロダクト推進してきたなかで、もっと上手なやり方があったと感じることは数えるときりがないですが、いま振り返ると以下の3つが特に学びが大きいと感じています。赤裸々にご紹介したいと思います。
顧客セグメントを広げ過ぎる
BizMakeは「ビジネスフレームワークを活用したワークショップには参加するものの、型として定着していない事業担当者（当時はリアルイベントが多く模造紙でまとめることが多かった）」を初期ユーザー像として、その課題解決をするために思いついたサービスでした。ビジネスモデルキャンバスをブラウザ上で作成できる、という非常にシンプルなサービスだったのですが、そもそもお客さまに使ってもらえるかどうかをSNS広告で検証したところ、たった数日で100名以上の方々に利用いただいたことからそのニーズを確信し、その後まもなくベータ版をリリースしました。
いざリリースしてみると、新しい発見がありました。狙い通り新規事業を推進する方々に使っていただいていたのですが、その属性を見ると、デザイナーや経営企画、コンサルタントなど、さまざまな方が使っていました。
BizMakeは思考整理に悩むすべての方の課題解決に寄り添っていきたいという考えを大切にしてきました。そのため業種や役職、事業の規模感などで顧客セグメントを絞るようなことをせずに、文字通り「すべてのビジネスパーソン」を対象にしています。
ただし部署や職種によって必要な機能やフレームワークは大きく異なっていました。ユーザーの声に耳を傾け過ぎた結果、一部の方がよく使う機能やフレームワークができてしまいました。あらゆる立場の方にご利用いただけるのは非常に喜ばしいことですが、狭く深く設計したサービスを途中から広く深くプロダクト開発を進めるような形に切り替わってしまい、結果として成長スピードを緩めてしまったのではと考えています。
ロードマップと短期施策の乖離
スタート時に立てたロードマップ通りに事が進む、ということはまずあり得ません。フェーズによって目まぐるしく状況が変わるなかで、日々の活動、短期的な施策、長期的なロードマップに沿った施策のバランスを取り、決してトラブルシューティング屋さんにならないよう常に広い視野を持つ必要があります。
また併せて注意したいのは、課題は顕在化している（≒言語化できている）ものだけではない、ということです。ごくごくシンプルな、すぐに解決できる課題であったとしても、それは本当に解決すべきことなのか、理想的な顧客像から整合を取る必要もあります。
上述した、あえて顧客セグメントを広く持っていたことにも起因するのですが、ローンチ間もない頃から使ってくださっているユーザーの声、というのはどうしても目立ってしまいます。大切にしたいと思うがゆえに、意見に耳を傾けすぎてしまった結果、短期施策の改善にフォーカスしてしまい、気づけば策定していたロードマップとズレが生じ始めていました。
またステークホルダーも増えてきた結果、ユーザーからさらに一歩進んでBizMakeの可能性を感じてくださるサポーターも増えてきました。例をあげると、BizMakeを使ってクライアントへのコンサルティングを行いたいと申し出ていただいたことがありました。エバンジェリストのような形で活動いただくことは非常に喜ばしい一方で、そのような活動をしていただける方に対してBizMakeとして何ができるだろうかと頭を悩ませていたこともありました。事業推進のための型提供としてスタートしたサービスであり、そこからはやや乖離してしまう話でもあったためです。
このように特性を見極められないまま、いただいた意見を真に受けてしまったり、その方々にとっての価値提供・メリットをきちんと考えきれないまま中途半端に関わっていただいたりしてしまった結果、関係性が悪くなってしまうこともありました。
自身が出したい世界観とプロダクトの収益計画について、冷静に俯瞰・判断しなければならないのは他でもないPMです。PMが主体性を持ってプロダクトの価値を訴求していかなければ、自身が推進する意義がなくなってしまい、結果として誰にも刺さらないものになってしまいます。近視眼的にならない習慣をつけることは必須と考えます。
前提条件のすり合わせ
立場や状況の異なる各ステークホルダーの認識を合わせることは、たやすいことではありません。
例えば事業開発のシステム設計において、PMはシステム開発の大枠を理解することは必要ですが、プログラムなどの詳細知識を備えておく必要はありません（もちろんスキルがあるに越したことはありません）。このような場合、日付を決めて新しい機能開発を進めるなかで、PMはバッファを持たせて進めていると思っていたとしても、システム開発側では、PMに余計な心配をさせまいと本来報告すべき事柄をひた隠しにしていることもあります。
自身ではオンスケジュールだと思っていても、相手からすれば非常に切迫した状態で、互いに認識合わせをすることなく進んでしまった結果、予定していた期日からは大幅にスケジュールが遅れ、信頼関係も毀損し、非常にストレスを抱えてしまった、ということは往々にしてあります。
互いの期待値のズレが合っているかどうか、定例などで顔を合わせるなかで少しでも疑問に思うことができたら確認をすべきです。また相手の立場にたった目線を持ち、安心感をもってなんでも話してもらう雰囲気作りを心がけることも重要です。小さなリスクをそのままにしておくと、気づかないうちに大きなリスクとなりやってきます。
