読者です 読者をやめる 読者になる 読者になる

Yamotty Blog

プロダクトマネージャーの雑記

プロダクトマネージャーを陥れる「経験から判断するという罠」

f:id:yamo3:20150211170037j:plain (PMは海の近くに住みたくなるもの。)

まえがき

先日出したこの記事が思った以上に界隈で読まれたみたいでびっくりした。 noize.hatenablog.com

ありがとうございます。

僕自身Product Managerとしてのキャリアは長くない。さらに、目まぐるしく毎日違う仕事をしているような状態なので人に役立つ内容が書けるかは不安だったが、文章を公開することの意味をすこし考えなおすきっかけにった。

今回もPM考です。

運用期のプロダクトにある問いに対応する

多くのプロダクトにとって、ライフタイムのほとんどは運用期で占められる。プロダクトを産み出すまでの過程も長いものがあるが、成長することを前提とすると、1st verをリリースしてからがプロダクトの始まりだと思う。 今回焦点を当てるのは

  • 運用期にあるプロダクトのなかで如何に問を解決していくか。
  • そしてその中で気をつけるべき(僕自身が気をつけている)こと

如何に問を立てるか?がより重要な視点だと考えているが、本稿に含めると長くなるため避ける。

問に対し何をもって判断するか

運用期のプロダクト、とくにMinimum Viable Productからグロースフェーズへのジャンプ(文字通りそれはジャンプである)を目指すプロダクトには、大きい小さい合わせてそれこそ毎日数十の課題(issue)が生じることと思う。自社のプロダクトもまさにこのフェーズを走っており、GithubのissueListは長くなる一方。

PMはこのissueに対し、重みをつけ、マイルストーンをおき、仕様へおこし、開発チームとのcooperationを行っていくことが求められる。 同時に、こういった目下のissueのみならず、中長期的にプロダクトの方向性を打ち出していくことも求められるのがPM。それこそが最大の難所に思う。

例えば、

  • 3年後、プロダクトはどんな状態であるべきか
  • 新サービスや新プロダクトはどのタイミングで作り始めるか?
  • キャッシュポイントをどこにおくか
  • 将来的なマーケティングプランと如何に連動を測るか

など、issueまで落ちていない漠然とした大問に対して、答えを創りプランへ落とし込んでいく責務がPMにある。

経験から判断するという罠

これらのサービス/プロダクトの将来を左右する問いに対し、何をベースに答えを創り出すか。

たとえば、

  • 知識:事例や先人の知恵を用いる
  • 経験:自身の失敗/成功から得た学びを用いる

といった引き出しを使うと、自分自身を納得させられる解には最速でたどり着くことが出来る。しかしこれこそがPMが陥りやすい(と、個人的に考えている)だ。

PMに限らず、問いへ向かう人は多くの場合、この2つのいずれかから最も確度の高そうな引き出しを使うことが多い。

一方、前回の記事にも記載したとおり、PMは超個人的な意志を未来のプロダクトに反映する必要と権利と義務を併せ持つ。 このとき、自らの意志を測るリトマス紙として僕は次の問を使っている。

わたしの創ろうとしているものは...

  • ユーザーが使うことで幸せになるか
  • わたしのチームが創る必然があるか

知識や経験といったツールは、1つ目のリトマス紙をクリアするときにたしかに役に立つ。 例えば近い業種の先行事例をパクることで、ユーザーがどの程度幸福になるか(≒便利になるか)はあらかじめ計算した実装ができる。

しかしながら、過去から得た知識や経験にすがっていてはでは後者のリトマス紙をクリアすることは不可能に近い。 そして後者の試験にひっかかってしまうということは、PM自身が意志を形成できていない。 おそらくこの状態でプロダクトの仕様を作りこむと、関わるチームのメンタルや市場での優位性という2点においてプロダクトに負債を残すことになり、それは僕がPMとして最も避けたいことでもある。

チームに目を向ける

では、中長期的な目線でプロダクトを前へ進めるための意志をいかに形成するか?方法論は毎回登場する以下の本に譲るとして、

アイデアのつくり方

アイデアのつくり方

僕自身の答えとしてはチームに目を向けることだと考えている。 ユーザーのためのプロダクトを創っておきながらユーザーに目を向けないのは言語道断なので考慮しないとして、それができている場合、プロダクトの方向性は

  • チームの強みをのばす
  • チームができないことを補う

いずれかに(もしくは両方に)特化させていくことで、自社チームがそのプロダクトを創りだす必然性が産まれ、徹底的に磨かれた必然性が他社の追随をゆるさない強みになるだろうと考えている(AWSとかその好例)。

インターネットサービスはECだろうとメディアだろうとSaaSだろうと価値のマッチングが生業になるので

  • 供給サイドを集める
  • 需要サイドを集める
  • マッチングさせる

という3つの機能はあらゆるプロダクトが備えているはずだ。チームがこのなかのどこに強みを持っているのか、弱みがあるのかを洞察し、将来的なチーム設計と一緒にプロダクトの未来を考えぬくのが良いと思う。

補足:若いプロダクトのユーザーとの向き合い方

なお、

ユーザーに目を向けないのは言語道断

と書いたが、逆にユーザーとの向き合い方はどうするの?と悩む場合も多い。 これは完全にプロダクトのフェーズ論ではあるが、

Minimum Viable Productからグロースフェーズ

においては、

  • プロダクトを最もstickyに使っているユーザーがとっている特異な行動を最大化することにフォーカスするには何をしたらよいか?という補助線を引き、
  • 元にプロダクトに付いているユーザーの行動ログを眺める

ことかなと考えている。 ちなみに完全に私見であり、うまくいくかどうかはまだ実証できていない。

まとめ

  • PMが陥りやすい「経験から判断する罠」
  • リトマス紙的な2つの問いを使うことで、罠を避けられそうな気がする
  • 尖ったプロダクトはやはりチームから産まれる。チームを見て中長期的な目線を考えぬく。