最も大きな学びを得たプロジェクトでの失敗経験は何ですか？

回答者（6名）

株式会社エンペイ

プロダクトマネージャー
竹村淳

MVPにおいて、「スコープは絞っても質は犠牲にしない」ということです。

市場投入を急ぐあまり、MVPとして出したプロダクトで「当たり前品質」が満たせていなかったことがあります。

そのプロダクトでは、市場投入後、品質がネックになり本来やりたかった検証ができなかったり、その部分の改善にほとんどの手を取られてしまったということがありました。

そうしたことにならないよう、投入する市場でどのようなレベルが「当たり前品質」として求められるのかを定義し、その品質を満たすように作ることはきちんとした検証をするためにも必須であることを学びました。

株式会社ROBOT PAYMENT

プロダクトマネージャー

立石

関係者との認識合わせの重要性です。

一度、顧客導入案件の中で、動作イメージのコアな部分で大きな食い違いがあり、強いクレームに発展したことがあります。

営業中、導入支援活動中など各段階での掛け違いの結果が大きなクレームを生んだと思っています。

これらを踏まえて、以下の点を丁寧に行うようにしています。

・過去経緯のまとめと共有（特に目的、意思決定理由など）

・それを踏まえた狙いと、段取りの共有

　※　プロダクト企画の場合は、これに加えて、「単機能の狙い」、「先々の布石としての価値」を語るようにしています。

株式会社マネーフォワード
プロダクトマネージャー

植竹広佑

「ユーザーが欲しいと言ったものをそのまま作る」は好ましいものではないというのがよく言われますが、「ユーザーが求めているものを先回りしすぎても使われない」という失敗体験がありました。（乗換案内サービス担当時、電車の遅延を予測するための機能として「天気の警報/注意報情報」をお知らせする機能を提供しましたが、この機能が遅延の予測に役立つと気が付かれず使われなかった…）そこから「ユーザーの0.5歩先を狙う」ということを意識するようになりました。

プロジェクトの一番の失敗は「使われないものを作ること」だと思うので、提供者目線にならないようあくまでユーザーが見る景色・想像する景色をイメージして進めるようにしています。

STORES株式会社
シニアプロダクトマネージャー

浅田純史

自分自身が熱狂できる（例：このプロダクトはヒットする、世の中に役に立つ）もの、その理由をチームメンバーに伝えて納得できるものであるかどうか。

自分が熱狂できないもの、身近であるチームメンバーに説明しても納得してもらえないものは、第3者に公開しても、指示をえることはできないというのを何度かトップダウンでプロジェクトを行って失敗したことから学びました。

トップダウンのものであっても、なぜそれをやるべきなのかを自分の言葉で他者に説明して納得してもらえるまでは、本当にやるべきかどうかを考える方が良いと思います。PMというのは作ることだけでなく、やめることも決断する役割です。

ビジネスオーガナイザー

渡邉侑

質問にあるプロジェクトという単位に限らないのですが、「過度な透明性」です。
少し古いかもしれませんが、当時のスタートアップでは求職者をアトラクとする独自カルチャーの一環として「情報の透明性」を謳う会社が流行っていた記憶があります。経営ボードmtgの議事録から始まり、投資家とのmtg、会社のランウェイ、個人の給与、中にはメンバーレベルの会議の録画を全て公開する会社も見てきました。
一見素晴らしい試みに見えますが、この透明性がワークするには条件がある気がしています。それは所属する「メンバー全員の情報リテラシーが圧倒的に高いこと」です。情報を建設的に処理する能力がない組織に、溢れんばかりの情報を公開すると逆効果になることもあります。目的ありきで、ガバナンスがセットでの透明性を設計できるといいなと思います。