はじめに
はじめまして。ゆずたそ（@yuzutas0）と申します。私はソフトウェア開発者からプロダクトマネージャーへ役割を変更した後、多くの失敗を経て「マインドセットを切り替えること」の重要性を痛感しました。
この連載では、私が学んだ「プロダクトマネージャーのマインドセット」を解説します。
想定する読者・提供価値については、2つのパターンを想定しています。1つ目は「同じように失敗した経験のある人」です。自分の経験を振り返りながら「こうすればよかったのか！」と考える機会になるはずです。2つ目は「これから失敗を経験するであろう人」です。これから起きる課題について「こうすればいいのか！」と考える機会になるはずです。
注意・免責
①本連載の内容は、筆者の個人的な見解にもとづきます。適宜ご自身の立場に置き換えて、読み進めていただければと思います。万が一、誤りや不快な点がありましたら、どうぞ筆者個人宛にコメントいただけると幸いです。
②本連載で紹介するエピソードは、特定の企業・案件を正確に表現したものではありません。あくまでダミーです。その点はご承知おきください。
③この連載ではプロダクトマネージャーをPdM、プロジェクトマネージャーをPjMと略します。言葉の普及度としてはプロジェクトマネージャー職のほうが一般的なので、PMと呼称すると読者に混乱を招くのではないか、と考えました。エントリー層の読者に配慮した結果なので、プロダクトマネジメント関係のコミュニティの皆様には、どうぞご容赦いただけると幸いです。
「早くリリースしよう」の落とし穴
私たちは呪文のように「早くリリースして、早く改善しよう」と唱えていました。画面には新機能の説明が書いてあります。この説明文を読めば、ユーザーは新機能の意図や使い方を理解できるはずです。万が一、多くの問い合わせが寄せられるようだったら、リリースした後でUIを改善すればよいだろう、と話していました。私たちは迷わずに新機能をリリースしました。
結果はダメでした。「このボタンは何か？」という問い合わせが大量に寄せられました。問い合わせ対応とUI改善に時間を取られて、次の機能追加のスケジュールは大幅に遅延しました。日々のトラブル対応で、開発スタッフは疲弊しました。計画の遅延を報告するたびに、ステークホルダーはあきれ顔を示しました。リリースするたびにプロダクトには「分かりにくさ」が増えていき、ユーザーのアクティブ率は低下しました。
同じような失敗を繰り返して「妥協は破滅を招く」と思い知りました。もちろん悪意があって妥協したわけではありません。それどころか妥協したという自覚さえなかったのです。数名の開発スタッフと協力して、創意工夫して新機能を作りました。自分たちにとって、これまでにないチャレンジでした。当時はそう思っていました。
しかし、私たちは無意識のうちに妥協していたのです。ユーザーやデザイナーを10人ほど集めて、新機能の画面を見てもらったら「分かりにくい」と言われたはずです。知り合いに声をかけて画面を見てもらうだけなら、時間やお金に余裕がなくても、ちょっとの工夫で実現できます。そういった「できるはずの努力」をしていませんでした。「できるはずの努力」があることに気づけていませんでした。
