プロダクトマネジメントが失敗する原因と対策

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る
         

「開発人員は確保しているけど、プロダクト開発がうまくいかない。。」
「プロダクト管理ができるメンバーがいなくて、中々リリースできない。。」

プロダクトマネジメントがうまく機能せず、プロダクト開発がうまくいかないケースをよく耳にします。

では実際なぜプロダクトマネジメントが失敗してしまうのか?

専任のプロダクトマネージャー(PdM)が不在だと何が問題なのか?

今回は、プロダクトマネジメントがうまく機能しなかった時に何が起こるのか、現場でよくある失敗例をもとに原因と対策について紹介します。

少しでも参考になったら幸いです。

こんな方におすすめ

どのようにデザイナーに依頼すれば良いか知りたいエンジニア
プロダクトマネージャーを目指していて、デザイナーとの仕事の進め方に不安がある人
デザイナーを含めたチームビルディングに悩んでいるマネージャー

プロダクトマネジメントが機能しないことで起こる弊害

プロダクトマネジメントがうまくいかないと、以下のような弊害が起こる可能性があります。

  • リリースが大幅に遅延する
  • リリースした機能が使われない
  • プロダクトもしくは機能がリリースされない
  • 一部もしくは全体のユーザ体験の質の低下
  • 技術的負債により、スケールもしくは改善ができない(しづらくなってしまう)

上に挙げた例は、主にプロダクトや事業への影響になりますが、それが起因して開発メンバーのモチベーション低下につながったり、ビジネスサイドと開発サイドの間に亀裂が入ったりして関係性が悪化する場合もあるため、なるべくなら避けたいところです。

そういった負のサイクルに陥らないように、ビジネスサイドと開発サイドの間に入ってプロダクトの価値を高めることがプロダクトマネージャーのミッションです。

それではこれらの弊害が起こる原因について一つずつ紹介します。

プロダクトマネジメントが失敗する原因と対策

技術的に実現できない

実は技術的な実現可能性(フィージビリティ)が検証されずに企画だけが先走ってしまうケースが多々あります。

特にバズワードとなっている「AI」や「ブロックチェーン」といった先端技術は、大抵の場合過剰に評価されすぎています。

また、WebならWebの、モバイルアプリならモバイルアプリの技術的制約は必ず存在します。

おそらく出来るだろうという甘い見込みでプロジェクトが進んでいくと、いざ開発段階で実現不可能だったり、全く要件を満たせないことが判明するなど起こり得ます。

こういった弊害を避けるために、企画の段階でエンジニアや技術的知見を持ったアドバイザーに相談しましょう。場合によっては、簡単な技術検証を事前に開発スケジュールに組み込むことも必要です。

最初から仕様を盛りすぎている

開発リソース(人員)が潤沢にあり、スケジュールも大分余裕があるなら話は別ですが(そんな現場は存在しませんが)、多くの現場では限られたリソースで、最短でのリリースが求められるはずです。

そのためにまず考えるべきは、「絶対開発しなければならない機能以外は開発しない」ということです。

どんなに開発効率を上げたり、優秀な人材を採用しても、開発が必要な対象を絞り込むこと以上にインパクトのある解決方法はありません。

プロダクトは一度リリースしたものがそのまま使われ続けるものではなく、ユーザや市場の反応を見ながら細かく修正を重ねて育てていくものです。

最初のリリースに全ての機能をリリースする必要はありません。

メインターゲットであるユーザが絶対に達成したいユースケースは何かをよく議論して、そのシナリオを達成できる最低限の機能に絞り込みましょう。

工数またはコストとのバランスが取れていない

意外と見落とされがちなポイントです。

ある特定のユーザの課題を解決するための機能を検討しているとき、その機能を実装するのにどれくらい工数がかかるのか。

また、その機能を実現するためにどれだけのコストがかかるのかをよく考慮する必要があります。

ここで注意が必要なのは、「実装・実現コスト」=「ユーザの課題の大きさ」=「ビジネス価値」ではないことです。

100かけて作るものが、ユーザにとっては10程度の価値しかないのであれば、やらないという決断が妥当な場合もあります。

プロダクトは「アート」ではなく「ビジネス」です。

開発における費用対効果(ROI)については、ビジネスサイド・開発サイドとも普段からよく議論しておいた方が良いでしょう。

仕様が複雑すぎる

これから実装しようとしている機能があまりにも複雑すぎると感じたら、何かが間違っていると考えた方がいいでしょう。

複雑な機能はユーザ体験を損なうだけではなく、プロダクトとしても負債になる可能性が高いです。

「仕様上の負債」はある意味「技術的負債」よりも厄介なものになります。

多くの要件を満たす必要がある場合でも、出来る限りシンプルな形に落とし込むことがプロダクトマネージャーには求められます。

ユーザ体験もしくは業務フローが設計できていない

コンセプトは目新しいが、いざ使ってみようとすると「あれ、誰がいつ使うんだっけ?」「業務プロセスに合わないな。。」といった事態に陥ってしまうことがあります。

ユーザ体験もしくは業務フローが適切に設計できていないと、いざ利用するときにユーザの課題が解決できなかったり、すごく使いづらいものになってしまう危険性があります。

カスタマージャーニーマップや、UXマップなど、ユーザ体験を設計するためのツールがあるので、何をどう設計すれば良いのかわからない方は、一度参考にしてみても良いかもしれません。

ただし一番重要なのは、「顧客の理解を深めること」です。

BtoC向けプロダクトならターゲットのライフスタイルや嗜好などを深掘りますし、BtoB向けプロダクトなら業界の慣習や業務知識への解像度をどれだけ上げられるかです。

必要に応じてユーザインタビューやアンケートなどを用いて、顧客の理解度を深めていきましょう。

BtoCサービス:一般ユーザ向け。エンタメ・ライフスタイルなどの一般消費者向けのサービス。
BtoBサービス:法人向け。中小企業や大企業など法人が利用するサービス。

まとめ

いかがでしたでしょうか。

私たちは普段、日の目を見た(成功した)プロダクトしか見ることはありません。

しかし、実はプロダクトマネジメントの失敗によって日の目を見なかったプロダクトは数多く存在します。

今回はプロダクトマネジメントが失敗したときに起こる弊害と、その原因そして対策について紹介しました。

今回の内容が、プロダクト開発に少しでもお役に立てたら幸いです。

スポンサーリンク

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

SNSでもご購読できます。