Good product managers crisply define the target, the “what” (as opposed to the “how”) and manage the delivery of the “what”. Bad product managers feel best about themselves when they figure out “how”.
・イケてるPMはインフォーマルに指示は出さないが、逆に情報収集はインフォーマルに行う
Good product managers don't give direction informally. Good product managers gather information informally.
・イケてるPMはレバレッジをかけられる作業をし、ダメなPMは一日中問い合わせ対応に追われる
Good product managers create collateral, FAQs, presentations, and white papers that can be leveraged. Bad product managers complain that they spend all day answering questions for the sales force and are swamped.
・イケてるPMは収益と顧客に、ダメなPMは競合が何をやっているかにチームをフォーカスさせる
Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building.
・イケてるPMは問題を分解するが、ダメなPMは問題を一つにまとめる
Good product managers decompose problems. Bad product managers combine all problems into one.
■蛇足ですが
ちなみに、ということで、マッキンゼーのブレストについての論文にも参考になる点が多いのでリンク貼っておきます。一つ一つの論点は上記の内容とは直接関係しませんが、こちらも単に「クリエイティブな議論を!」「悪いアイデアなんてない!」といった安易な掛け声に警笛をならしています。特にそのような記載はないので憶測ですが、「Obligation to dissent(反論する義務)」を求めるマッキンゼーでも「No, BECAUSE」は求められるのではないかと思ったり。ご参考まで。
以前の講演で濱口さんがおっしゃっていたことに、自転車に乗れるようになる時のメタファーがあります。子供のころ、自転車に乗るために何か教科書を読んで頭で理解して自転車にまたがったら乗れた、という経験をした人はまずいないのではないかと思います。行きたい方向見る、スピードを出して漕ぎ出す、何回かこける。これで乗れるようになるわけです。Just do itだと。
3. Capture findings @3min needs: things they are trying to do* *use verbs
ここからは、問題の咀嚼。1.2でインタビューした内容を捉えなおす。まずは「ニーズ」。パートナーがなぜ語られたようなギフト経験をしたのか、その背景にあるパートナーのニーズを書き出す。ポイントは、「Aさんがギフトを送ったのは、XXXXしようとして」といったように動詞で書いてみること。これにより具体的になる。
insights: new learnings about your partner’s feelings/ worldview to leverage in your design* *make inferences from what you heard
1.2でインタビューで見えた「インサイト」を書き出す。ソリューションを後ほど創出する際にレバレッジできそうな発見を見出す。
4. Define problem statement @3min ______________(partner name/description) needs a way to ______________(user's need) Surprisingly//because//but ______________(insight)
上記の”__________”の部分を埋めてみることで、パートナーのギフト経験における問題(背景にあるニーズや特筆すべきこと)を構造化してみる。
Ideate: generate alternatives to test.>>アイデア出し:代替案をテストする
5. Sketch at least 5 radical ways to meet your user’s needs. @4min
ここからはアイデア出し。パートナーのニーズを満たすための新しくて過激なギフト経験のアイデアを最低5つ書き出してみる。ここはまだアイデア評価の段階ではないので、ラフでもなんでもいいので取りあえず数を出してみる。
6. Share your solutions & capture feedback. @8min (2 sessions x 4 minutes each)
5で考えたアイデアをパートナーに共有してみて、フィードバックをもらう。ここで気をつけるのは1にあった「共感」。フィードバックを通じてパートナーの持つ感情や動機を改めて探る。
Iterate based on feedback.>>フィードバックに基づき改善する
7. Reflect & generate a new solution. @3min Sketch your big idea, note details if necessary!
これまでのステップで積み重ねたパートナーへの理解・共感と自身のアイデアを踏まえ、改めてギフト経験のソリューションを組み立て直す。
Build and test.>>プロトタイプを作り、テストする
8. Build your solution. @10min Make something your partner can interact with!
ここからは紙の上ではなく、実際に色々なマテリアルを使ってプロトタイプを作ってみる。ギフトがモノであればそのモノを、目に見えない経験のようなものであればそれをイメージできるような造形を作ってみる。
9. Share your solution and get feedback. @8min (2 sessions x 4 minutes each) What worked.../What could be improved.../Questions.../Ideas...
8で作ったプロトタイプをパートナーに共有し、フィードバックを得る。触ったり使ってみたりしてもらい、どうそれを使うのか(またどう間違って使うか)、どんな感想を持つのか、何かよくわかってないようならそれは何か、プロタイプに対するフィードバックを探る。
”It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change.” 「この世に生き残るものは、最も力の強いものでも、最も頭のいいものでもなく、変化に対応できる生き物だ」