プロダクトマネージャーが注意すべき「5つのBadList」
2016/07/02
もっと、もっっっっと x 1,000 … 良いプロダクトを世の中に送り届けたい！
っと、お考えのプロダクトマネージャー、企画者、プロダクトオーナーのみなさま、こんにちわ。
- WEBサービスの新規立上げにおいて、生粋のプログラマーである同僚が、初めて体験する「プロダクトマネージャー／オーナー」をサポートする過程で、色々と感じる事があった
- 昔、僕が、企画のお師匠様に、口を酸っぱくして教えて頂いたことを改めて思い出した
ので「開発することが得意だったり、もともと、開発のプロ／専門家だったり」した、新任のプロダクトオーナーの方、企画者の方、プロダクトオーナーの方が、特に注意した方が良いと思う事を5つに纏めてみようと思います。
まだまだ、僕も修行中の身ではありますが…
少しでもみなさまのヒントや、何かしらを改善する “きっかけ” となれば、嬉しいなぁーっと思います。
でわでわ、能書きはこれくらいにして、早速、いってみましょう〜！
スポンサーリンク
what や how からはじめてしまう
先ず最初に、僕思うに、プロダクトマネージャーとして一番大切なことだと思う、このテーマからです。
- 創るもののイメージを、ザックリと考えるとき
- 運営中のWEBサービスが、KPI を達成出来ず、改善策を考えるとき
- もっともっと、良いプロダクトにする為の施策を考えるとき
たとえば、上記のような、ケースにおいて…
- 「何を」創ろうかなぁ…
- 「どうやって」改善しようかなぁ…
と、「what」や「how」から、考え始めちゃう。
こんなこと、ありませんか？
何をするのか、どうやってするのか？
これらを考えるより先に、「WHY」から考えることが、プロダクトマネージャー、企画者やプロダクトオーナーにとって一番大切な心得だと思います。
「何故(why)、創るのか？」
「何故(why)、現状を改善する必要があるのか？」
と、物事をする “理由、目的、理念、ビジョン” を真っ先に考える癖を付けることが大切だと思うのです。
例えば、自分が壁を創る職人さんだとして、教会を創るプロジェクトに参画しているとします。
教会を創るプロジェクトの責任者（プロダクトマネージャー、企画者やプロダクトオーナー）から…
- 教会の周りを囲む壁を創って欲しいんだ！美しいデザインで、周りの雑音を良い感じに遮断出来るようにして欲しいんだ！
- 教会にお祈りしに来てくれた人をハチャメチャに幸せな気分にしたいんだ！そのために、美しくデザインし、周りの雑音を良い感じに遮断する。そんな壁を作って欲しいんだ！
と言われたケースを想像してみてください。
「1. と 2.」 どちらの言葉の方が、職人魂が鼓舞されるでしょうか？
また、どちらの方が、良い壁 が出来るでしょうか？
ちなみに…僕が「壁を創る職人さん」だったなら、「2.」の言葉を言われた方が…
「このプロダクトマネージャーは、壁の大切さを良くわかってるな！壁を軽視する輩もいるなか、感心出来るな」
「よ〜〜し、俺の壁で皆を、もっと幸せにしてやるぞ！」
「そうだ！ 長年考えていた、新しい作り方が良いかもしれない、プロダクトマネージャーに相談してみるか！」
ってな感じで、プロダクトマネージャーへの信頼も増すし、心を鼓舞されるし、良いアイデアがあったら試してみよう／相談してみようと思えるし…
と、断然「2.」の言葉の方が良いですし、結果、良い物が出来上がると思います。
こんな感じで、what や how からはじめるのではなく…
why -> how -> what の順ではじめるのが、プロダクトマネージャー、企画者、プロダクトオーナーには、特に大切だと思います。
この辺のことについて、もっとちゃんと学びたいぞ！
っという方には、下記の書籍がお勧めです。
僕はこの本に出会えて、長年「もやもや」っとしながら、考えていたことがとっても「クリア」に整理できましたよ。
buid からはじめてしまう
はい、続いて2つ目の僕思う Bad List はこれ「buildからはじめてしまう」です。
最小のコストで、最大の価値を提供する為の、起業や新規事業の立上げの為の手法である Lean Startup では…
- 必要最小限のプロダクトを作って、
- 「Build > Measure > Learn」 の仮説検証サイクルを回すのだ
的なことが言われているのですが…
つい先日、このような事がありました。
「ユーザから、貴社のサービスはとても素晴らしいのですが、日々の業務に追われて、ついつい、使い忘れてしまう」 と言われたのです！
「なので、サービスの利用を促すリマインドメールを送信する機能を追加開発しようと思います！！」
っと、新任プロダクトオーナーの方が言うのです。
・・・
う〜ん… 果たしてコレは最善の選択なのでしょうか？
一見すると、ユーザーさんが抱えている “課題、問題” に対応する為に、解決策である「リマインドメール送信機能の追加」をすると。
んー、良いような気もします。
ですが…
- 開発するとなると「開発者の方の時間を使ってしまいます」他の機能追加よりも、本当にこの機能の優先順位が高いのでしょうか？
- リマインドメールを迷惑がるユーザーさんは居ないのでしょうか？
- 使うのを忘れてしまうユーザーさんがいる一方で、ちゃんと毎日使ってくれるユーザーさんも居ます
- 本当にこのユーザーさんの抱えている問題の本質が “使うのを忘れてしまう” なのでしょうか？
こんな感じのことも気になります、、、よね？
なので、直ぐに build からはじめるのではなく、仮説（この場合、ユーザーの使用率を向上する為にはリマインドメールが適切である）を検証する為の、実験をデザインすることからはじめるのが良いかと思います。
つまり、Lean Startup のループを逆からはじめるのです。
「Learn（何を学ぶべきか？）」を最初に定義し、
次に、それを評価する基準である「Measure」を定義し、
最後に「build」する。
こんな感じで考えていくのが良いと思います。
あと、「本当に開発しなければ、検証出来ないのか？」は、慎重に判断した方が良いですね。
このケースであれば、開発しなくても、検証出来る方法は、いくつかありますよね？
この辺りについて、もう少し詳細を学びたいぞ！
っという方は、僕が LeanStartup のワークショップで学んだ事を整理した記事があるので、コチラ も参考になるかと思いますー。
判断を急ぎすぎてしまう
さてさて、いよいよ中盤となってきました、僕思う BadList の3つ目です。
プロダクトマネージャー、企画者やプロダクトオーナーは、周りのステークホルダーからのプレッシャーや、開発チームからの仕様に関する質問など…
日々、なんかしらの判断に迫られていることが多いかと思います。
でもね。
今求められている判断、それ、本当に「今」する事が適切なのでしょうか？
もちろん、必要な情報が全て出揃った、万全を期した状態で “判断” 出来ることなんて、無いでしょう。
もし、必要な情報が 100% 揃ってからする判断では、スピード感が不足し過ぎちゃってお話にならないでしょう。
でも、、、あまりにも情報が不足し過ぎている中で、勘だけで判断していくのは、リスキー過ぎますし、博打のようになってしまいます。
頃合いとしては「70%」、必要な情報を揃えて、判断するのが良いらしいです（参照：補足）。
- サービスのリリース日を決める
- 大掛かりな機能追加をするかしないか決める
- 今までの製品の考え方をガラッと変えてピボットするかしないか決める
特に、このような重要な判断をする時には、プロダクトマネージャー自身が「70% の確立で、絶対イケる！」と思えない場合には、未だ準備が不足し過ぎている、つまり、早すぎる判断なんじゃないかなーっと思います。
何故、それを今、決める必要があるのか？
特に、重要な判断を迫られた時には、今一度「今、判断する理由」を、相手と一緒に考えてみる事をお勧めします。
（補足）
「孫の二乗の法則」という本の中で孫正義さんが「６０％では少な過ぎる、100%では遅すぎる。70%が丁度良い」的な言われてます。
この本には、この事以外にも、プロダクトマネージャー、企画者やプロダクトオーナーとして、とっても参考になる珠玉のフレームワークが掲載されていと僕は感じているので、ぜひぜひ、一読をお勧めいたします。
なんとなくのKPIを測定してしまう
さてさて、4つ目の僕思う BadListです。
これは、、、悲しいかな、結構見かけるケースなんですよね。
プロダクトマネージャー 「今週から、ユーザーのActive率を集計するようにしてみました〜！」
サポート役 「ほぅ、それは素晴らしいですね！ それを集計して、どのような施策に繋げようとしているのですか？」
プロダクトマネージャー 「・・・えっ？」
サポート役 「えーっと、、◯◯さんが、Active率を集計しようと思ったのは、何故でしょう？」
プロダクトマネージャー 「えー… それは、どれくらいの人が Active なのか、知りたかったからですよー」
確かに、プロダクトの健康状態を、客観的に把握するためにも、幾つかの KPI を設定し、それらのトレンドを見ていくことは、とっても重要です。
でもね、KPI のトレンドを見ることの “目的” を明確化しておかないと、効果が半減してしまったり、「アチラを立たせば、コチラが立たぬ」的な状況になってしまったりする事が多いです。
KPI 集計の目的を聞かれたら…
「ユーザさんからのフィードバックで、XXX 機能が使いづらいという意見がありまして、僕としては、それの本質的な問題は A だと思っています。なので、それを検証する為にXとYとZというKPIを集計します」
的に回答出来る感じで、ちゃんと “KPIを測定する目的” を自分自身に問うことが大切です。
目的と、測定するKPIを、ちゃんとリンクさせていく為の手法として、GQM というものがありますので、気になる方は、Google で検索するなどしてみてください。
GQM (じーきゅーえむ; Goal, Question, Metric)は、メリーランド大学のビクター・バシリ教授によって開発された、ソフトウェア工学における計測の枠組みおよびモデル化手法である。
ソフトウェア工学におけるあらゆる計測は、無目的にメトリクスやデータを集めるのではなく、何のために測定するのか、前提となるモデルは何か、結果をどう解釈するかなどを明確にした上で実施されるべきである。
あ、、あと、プロダクトのKPIでは無いですが、過去記事で「もっと上手に開発する為のKPI（メトリクス）」を、GQM の考え方を参考にしながら整理したものがあるので、よろしければ コチラ もどうぞ。
GQM の雰囲気は掴めるかとおもいます。
聞き耳を立てすぎてしまう
さてさて、いよいよ最後のテーマです。
ココまでで、なんと4,800文字を超えてます…汗。想定以上に長文になってしまった…
でも、まぁ、最後のテーマはとても、シンプルです。
かのスティーブ・ジョブズも、下記のようなニュアンスのことを言ってます。
「ユーザの言う言葉をそのまんま聞いていてはいけない」
「なぜならば、ユーザは、自分が本当に欲しいものを知らない事が多いから」
なので、ユーザから、プロダクトに関するフィードバックや機能追加の要望を聞いた時には「なぜなぜ5回分析」をやるのが、本質的なニーズに辿り着くコツだと思います。
これも有名な話ですが…
「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。」
と、ヘンリーフォードも言っています。
ポイントとしては…
- 自動車を知らないユーザは、自動車という概念を想像できないので、「自動車を作ってくれ」とは言えない
- 馬という表面的なソリューションにとらわれず、人々の本質的なニーズ、つまり「速く移動したい」という欲求を見抜いた
ことでしょう。
でわでわ、なが〜〜くなってしまいましたが、少しでも読んでくださった方にとって有用な情報になっていれば幸いです。
ではでは〜、良い、プロダクトマネージャー、企画者、プロダクトオーナーライフを〜♪
そいじゃーーねーーーっっ！！