プロダクトマネージャー
竹村 淳
MVPにおいて、「スコープは絞っても質は犠牲にしない」ということです。
市場投入を急ぐあまり、MVPとして出したプロダクトで「当たり前品質」が満たせていなかったことがあります。
そのプロダクトでは、市場投入後、品質がネックになり本来やりたかった検証ができなかったり、その部分の改善にほとんどの手を取られてしまったということがありました。
そうしたことにならないよう、投入する市場でどのようなレベルが「当たり前品質」として求められるのかを定義し、その品質を満たすように作ることはきちんとした検証をするためにも必須であることを学びました。
関係者との認識合わせの重要性です。
一度、顧客導入案件の中で、動作イメージのコアな部分で大きな食い違いがあり、強いクレームに発展したことがあります。
営業中、導入支援活動中など各段階での掛け違いの結果が大きなクレームを生んだと思っています。
これらを踏まえて、以下の点を丁寧に行うようにしています。
・過去経緯のまとめと共有（特に目的、意思決定理由など）
・それを踏まえた狙いと、段取りの共有
※ プロダクト企画の場合は、これに加えて、「単機能の狙い」、「先々の布石としての価値」を語るようにしています。
株式会社マネーフォワード
プロダクトマネージャー
植竹 広佑
「ユーザーが欲しいと言ったものをそのまま作る」は好ましいものではないというのがよく言われますが、「ユーザーが求めているものを先回りしすぎても使われない」という失敗体験がありました。（乗換案内サービス担当時、電車の遅延を予測するための機能として「天気の警報/注意報情報」をお知らせする機能を提供しましたが、この機能が遅延の予測に役立つと気が付かれず使われなかった…）そこから「ユーザーの0.5歩先を狙う」ということを意識するようになりました。
プロジェクトの一番の失敗は「使われないものを作ること」だと思うので、提供者目線にならないようあくまでユーザーが見る景色・想像する景色をイメージして進めるようにしています。
STORES株式会社
シニアプロダクトマネージャー
浅田 純史
自分自身が熱狂できる（例：このプロダクトはヒットする、世の中に役に立つ）もの、その理由をチームメンバーに伝えて納得できるものであるかどうか。
自分が熱狂できないもの、身近であるチームメンバーに説明しても納得してもらえないものは、第3者に公開しても、指示をえることはできないというのを何度かトップダウンでプロジェクトを行って失敗したことから学びました。
トップダウンのものであっても、なぜそれをやるべきなのかを自分の言葉で他者に説明して納得してもらえるまでは、本当にやるべきかどうかを考える方が良いと思います。PMというのは作ることだけでなく、やめることも決断する役割です。
ビジネスオーガナイザー
渡邉 侑
質問にあるプロジェクトという単位に限らないのですが、「過度な透明性」です。
少し古いかもしれませんが、当時のスタートアップでは求職者をアトラクとする独自カルチャーの一環として「情報の透明性」を謳う会社が流行っていた記憶があります。経営ボードmtgの議事録から始まり、投資家とのmtg、会社のランウェイ、個人の給与、中にはメンバーレベルの会議の録画を全て公開する会社も見てきました。
一見素晴らしい試みに見えますが、この透明性がワークするには条件がある気がしています。それは所属する「メンバー全員の情報リテラシーが圧倒的に高いこと」です。情報を建設的に処理する能力がない組織に、溢れんばかりの情報を公開すると逆効果になることもあります。目的ありきで、ガバナンスがセットでの透明性を設計できるといいなと思います。
株式会社Granty
取締役COO
金井 祐樹
以前の職場で新規サービスの立ち上げをしていた時、あれこれ構想はするものの、あれがダメだこれがダメだと周りから言われ続け、結局何も開始できずに終わってしまった経験があります。
無計画に進める事は良くありませんが、極端に失敗を恐れすぎて行動できないことは更に良くないことだと考えています。
特に新たに始めるサービスでは、どう失敗したらいかもわからないといった状況もあるため、選択肢を消していく意味でも計画的に失敗していく事も必要だと学びました。
現役のプロダクトマネージャー（PM）に回答してほしい質問がある方は、「質問を投稿する」ボタンから投稿ください。（匿名で質問可能）
回答者になっていただける方は、「回答者に申し込む」ボタンからお申し込みください。