プロダクトマネジメントを読んで

いいプロダクトを作ってビジネスとして成功させるには？を考えらせられる本 

「プロダクトマネジメント」を読んで思ったことをつらつら書いていきます。

読んだのはこの本↓

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける | Melissa Perri, 吉羽 龍太郎 |本 | 通販 | Amazon

ユーザ企業あるあるっぽいものが詰まってました。

(私はユーザ企業に勤めたことはないですが、仕事で関わっていたユーザ企業さんや、ユーザ企業に勤める友人からよく聞いたような話がいっぱいでした)

エンジニアも、企画も、運用も、総務も、管理職も、とにかく全員読んでおくと会社の価値が上がりそうな気がしました。

特に以下の考え方が浸透することが大事だと感じます。

• プロダクト自体に価値はない。プロダクトは価値を届けるためのツールである。
• 会社は価値や成果の定義を明確にして共有することで、社員は方向性がわかり、働きやすくなる。成果の定義が定量的であれば、評価もしやすくなる。
• ユーザ目線になるというのは、一生懸命会社の中で考えて妄想するのではなく、ユーザ本人の意見を確認したり、自分で実際に体験してみるということ。
• ユーザに確認しても、ユーザ自信が本当に欲しいものを明確にわかっていることは稀なので、最小限のコストで実験し、本当に必要なもの、欲しいものは何か？を知っていく。そうすることで成功の道筋を立てることができる。
• 小さくたくさん失敗し、失敗から学ぶことが大事。安心して失敗できる文化をつくれ。
• 経営層を説得するときは、実験の結果であるファクトを持っていけ。

以下は、読んで自分が思ったことをまとめました。

プロダクト自体に価値はない

プロダクトやサービスに価値はありません。

価値があるのは、顧客やユーザーにとって意味のあること、つまり問題を解決したり要望やニーズを叶えたりすることです。

プロダクトやサービス自体に価値があるわけではなく、それを使って得たユーザ体験に価値がある。

プロダクトとは、価値を運ぶものです。

プロダクトありきではなく、ユーザに提供できる価値ありきで考えないと、自己満足になりがちです。

ユーザが体験に直結しない技術やデザインに凝りすぎてしまったり、他との差別化と言いながら求められていない機能を追加してしまったり。

もちろん技術もデザインも、他との差別化も大事ですが、どうユーザが嬉しいの？を意識してやる、やらないの選択をしないとビルドトラップにハマります。

アウトプットで評価しない。アウトカムで評価する。

アウトプットで評価しない。アウトカムで評価する。

どれだけ生産できたではなく、どれだけ顧客の価値を生み出せたかで評価する。

アウトプットは評価しやすいです。でも、たくさん生産できたからって、たくさんの成果に繋がるわけではありません。

たくさんの人に喜んでもらい、必要としてもらい、それによって得た成果で評価するべきです。

そのためには、何に価値をおくのか、どんな成果を求めているのかを会社として、チームとして定義し、合意し、それに沿ってどれだけ実現できたのかを評価をする必要があります。

成果、価値の定義を明確にして、会社として共有することはとても大事です。

これがないと、みんなが向かっている方向がバラバラになって、力が分散されて発揮できません。最悪の場合、意図しない足の引っ張り合いになります。

これがちゃんと定義されていなくて、暗黙知になっている会社やチームが多いように感じます。

今、自分のいる会社、チームもそうです。

当然わかるでしょ？くらいの空気。分かんないから。

しかもその評価、誰かのお気持ち次第のやつじゃん、みたいなのも見受けられるとモチベーションも下がりますよね。

ちゃんと定義して、口頭だけじゃなくて、いつでも見返せる形で共有しておいて欲しいところです。

プロダクトマネージャーとプロダクトマネージャーは違う

この本には、プロダクトマネージャーとプロジェクトマネージャーの違いについても書いてありました。

プロジェクトマネージャーは「いつ」に責任を持つ。プロダクトマネージャーは「なぜ」に責任を持つ。

プロダクトマネージャーは自分の意見を実現するのではなく、ユーザに価値を届けることが仕事です。

また、チームメンバーになぜそれが価値なのか、なぜ必要なのかなど方向性がわかる情報は伝えるが、何を作るべきかは伝えません。

プロジェクトマネージャーは期限に責任を持ち、期限までに顧客に最大限の価値を届けることが仕事です。 

明確に役割が違いますが、実質兼務している会社も多いように感じます。

役割が違うので、できるだけ人を分けた方が良いと思います。

価値を届けたいプロダクトマネージャーと、期限を守りたいプロジェクトマネージャーでは、守らなければならない優先度が異なるからです。

プロダクトビジョンを作って共有する

 Amazonはプレスリリースでプロダクトビジョンを語って共有するそうです。

確かに、プレスリリースをみると、「ユーザはこんなことができるようになって、こう嬉しいです。」みたいなことがわかりやすく整理させれています。

これはみている人全てに価値を共有しているということになり、考えているタイミングで何をユーザに届けたいのか？が明確になります。

社員にも会社はユーザにいつまでに何をどう届けたいと思っているのか、が共有できます。

とてもいい方法だと思いました。 

まとめ

全体として、「妄想で仕事をするな、必要なのは明確化された価値の定義とファクトである。」「自己満足でプロダクトを作るな。ユーザに価値を届けるためツールであることを忘れるな。」っていうのがわかりやすく纏まっている一冊だったと感じます。ユーザ企業じゃない私が読んでも学ぶところのある良い本でした。

受託であってもプロダクトを作っていくときは、上に書いたようなマインドを持ってやっていきたいです。