もくもくプロダクトマネジメント( @Nunerm )

プロダクトマネジメント・エンジニアリングマネジメントなどについて黙々と

不確実性の高い変数が2つ以上あったら、数字のことを考えるのをやめる

プロダクトマネージャーたるもの、プロダクトロードマップやOKR、KPIツリーなど「目指すべき数字」を定義する(または修正する)時間はそれなりに多いと思います。

  

会社によってはゴリゴリに数字を定義して一心不乱にその数字の達成を追い求めるところもあるでしょうし、ある程度定性的な目標を定めるところもあるでしょう。それはプロダクトのフェーズや市場によって変わってきます。

 

私事ですが、先日CAMPFIREに転職して半年間手がけてプロダクトがついにリリースされました。

 

つまり今新規事業のプロダクトマネージャーをやっておるのです。

この新規事業における「目指すべき数字」の定義が非常に難しい…!

なぜなら数字の根拠となるデータが少ないので。

 

もちろん他サービスやユーザーインタビューなどからデータを得ることはできます。が、それが自分のプロダクトに適用した際に同じ結果になるとは限りません。

つまりそこに不確実性が存在しています。

その高い不確実性をどう評価するか、楽観的に考えるか悲観的に考えるかで数字は大きく変わってしまいます。その不確実な要素を不確実なまま立てた数字目標は、現実的な目標ではなくただの「願望」であり、そんな状態で数字目標の妥当性を検討している時間は無駄だと思うのです。

 

 

つまり言いたいのは、

「数字目標を構成する要素に不確実性の高いものが2つ以上あったら、一旦考えるのをやめようぜ」

ということです。

 

特に2つという数字に大きな理由はないです。1つだったらその変数の楽観パターンと悲観パターンの2パターンを想定しておけばよいが、2つになったら2×2で4パターンを想定する必要あり、どんどん考えることが増えていくので、早めに考えるのをやめたいのです。

 

 

ではどうするのか?

検証をするのです。

 

 

先日参加したDevLOVEのイベントにて、書籍「カイゼンジャーニー」や「正しいものを正しくつくる」の著者の市谷さんの登壇を聞いて、非常に参考になりました。

www.slideshare.net

 

f:id:swnws322:20190915161312p:plain


 ここでは主にプロダクトの立ち上がり期に起こりがちな失敗パターンをまとめてくれています。

 

いくつか抜粋。

 

想像だけで始めてしまう

  • プロダクトを作るという意思決定が終わっているが根拠がない
  • ユーザーのことを知っているという思い込みで作り始めてしまう

 

体験の検証をやっていない

  • モックアップとかで検証をしたけどまだ実際に深く使われていない
  • 想定ユーザーの利用体験を成り立たせることができるのか、検証しないまま進めてしまう

 

チャネル検証をやっていない

  • 開発が終わってからチャネルの検討を始めがち(結局広告頼み)
  • 後になって「届けるコスト」が現実的ではないことに気づく


検証結果を都合よく解釈してしまう

  • 自分の見方にバイアスがあることに気づいていない
  • 解釈は正しいがデータが誤っている場合もある


事業を始めてしまう

  • わかりやすい動くものができると関係者の期待が高まり「どうやって売るか、どうやって売れるか」の議論と活動が始まってしまう(検証が終わってないのに)
  • モデルの検証のはずなのにビジネス自体が始まってしまう

 

世の中の理論を鵜呑みにする

  • 世の中の理論を自分の事業に適用してしまう
  • 世の中の理論が根拠としている事例や状況が当てはまるとは限らない

 

 

つまり検証を行わずに、あるいは検証結果を正しく評価せずに具体的な数字ばかり追い求めてると、高い不確実性を伴ったまま成長に挑むことになります。それはかなりのリスクです。

要は「なぜうまくいってるのか正しく理解していない」ので、いずれ「なぜかわからないがうまくいかなくなった」という事態に陥っても不思議ではありません。

 

今何の不確実性が高いのかを正しく把握し、それに向けての検証を的確に行うことで不確実性を下げるが求められるのです(不確実性をゼロにすることは不可能です)。

それまでは具体的な数字目標は一旦忘れてよいと思います。検証後に改めて考えればより良い現実的な目標が立てられるので。

 

 

というわけで、私のプロダクトもリリースしたところなので、これからバシバシ検証していきます。

【スポンサーリンク】