権限がほしいなら、意思決定のフロー図を書き出す
3行でまとめる
権限をくれ〜と叫ぶより「私はこのフローで意思決定をしようとおもってます」というと、デキるやつっぽくて任せてもらえるよ
創業者から権限をもらえない問題
いろいろな企業のプロダクトマネジメントを拝見させていただいて、モノづくりには2つのパターンがあることに気づきました。
1. ロジック後付けセンス型
「こういうプロダクトが良いのではないか」というWhatの思いつきをそのまま形にする勢いのある作り方です。最初からぼんやりとターゲットに対する仮説はありますが売れてからのほうが、どうして売れたのかのロジックを強く意識します。
2. ロジックありき戦略型
「この課題を解決したい」というWhyがあったうえで、その課題を解決するための最善の手段を探索する作り方です。最初からロジックありきで作り、売れた後にはそのロジックをより強化します。
創業者が 1. ロジック後付けセンス型 で、 任せたい相手に 2. ロジックありき戦略型 を期待することで権限をもらえない問題が発生しているのでは?という仮説を私は持っています。
権限を渡したいが、自分のように振る舞ってほしいわけではない
つよいビジョンをもった創業者の頭の中にあるプロダクトをチームが実現している状態は、1. ロジック後付けセンス型 です。この状態でプロダクトマネージャーの役割を委譲しようとしたとき、問題がおきます。
責任を取れる人だけの 1. ロジック後付けセンス型
任される側はその会社のカルチャーや、これまでどのように意思決定がされてきたのかを学んでいます。そのため、創業者と同じ方法(= 自分のセンス)で意思決定をしようとしますが、創業者はその意思決定が可視化されていないので不安になります。
また、任される側はこれまで創業者のビジョンを形作る仕事をしてきたのでHowは得意ですが、自分でWhatを探索することには伸びしろがあります。また、Whatを探索することができても、創業者と新任者が同じセンスを持ち合わせていることは稀なので、意見が割れがちです。
誰も、2. ロジックありき戦略型をしらない
「任せる」というのは、全部好きにしていいという意味ではなく、「創業者がしたいことの実現を任せる」という意味です。
しかし、会社のカルチャーとして 2. ロジックありき戦略型 がないので、どのように振る舞えばよいかのモデルがありません。名ばかりプロダクトマネージャーの誕生です。
仮説の連鎖を可視化する
プロダクトの仮説の連鎖を表したのが下図、仮説のミルフィーユです。Howの意思決定はWhatによってされ、Whatの意思決定はWhyによってされ、WhyはCoreによってされるという関係を表しています。
創業者と新任者でWhatの階層だけをすり合わせることをしていると、創業者の考えるWhatをつくることになり、任されることができません。初手は創業者の頭の中がCore〜Howまでどのようになっているのかを吐き出してもらい、理解をすることからはじめましょう。
創業者とユーザーをつなぐ
創業者の頭の中を仮説のミルフィーユで理解できたら、次に仮説検証をしましょう。創業者の頭の中身を仮説として、本当にそんなユーザーがいるのか、ユーザーが求めているのはそのWhatなのかを検証して創業者にフィードバックしましょう。
How → What → Why の順番で権限をもらう
仮説検証を繰り返していると、創業者の頭の中にあった当初のアイデアより良いアイデアを得ることになります。その段階でやっと思考が創業者より進んでいる状態となり良さの軸が創業者の頭の中から取り出されることになって、仕事を奪うことができるようになります。
ハッピーエンド🎉
まとめ: 任されたら、まずは意思決定のフロー図を書き出そう
「これから私はこういう軸で意思決定をしようと思いますけれど、あってますか〜?」ときいてみましょう。
それを書き出すことも難しければ、相手がどういうふうに意思決定をしているかを聞いてみて、そのどの部分を担ってほしいと記載されているのかきいてみましょう。プロダクトに関する意思決定であれば、仮説のミルフィーユが役に立つかもしれません🥰
そして、その軸が正しいかを創業者とユーザーに聞き続けることで徐々に任されるにちがいないです。
※ このnoteには、1. ロジック後付けセンス型 を揶揄する意図はありません。私が尊敬する方も大勢います。1. と2. はバランスだと思っていてどちらかに偏ると成長が鈍化する気がしています
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか?