見出し画像

エンジニアに伝えたい!プロダクトマネージャーの頭の中 - プロダクトをもう一段階成長させる仮説の立て方

Tablyの小城久美子(@ozyozyo)です。
デブサミでは多くの方にチャットやTwitterで盛り上げて頂けたので大変お話しやすかったですし、何よりとても楽しかったです。ありがとうございます!
資料のダウンロードはアンケートに回答された方への特典とのことなので、登壇内容の一部を抜粋してまとめます。ご参考頂けますと幸いです😊

どんなセッションでしたか?

エンジニアからプロダクトマネージャーに転身した私が、エンジニアだった頃に知っておきたかった「プロダクトづくり」についてお話するセッションです。

「プロダクトをつくる」フローとは?

スクリーンショット 2021-02-21 1.55.46

プロダクトをつくるとは、大きく2つに分かれます。上図の上側にあるプロダクトを育てていくものと、それを下支えするプロダクト志向な組織を維持することです。
上側にある、プロダクトを育てるステップとして、まずは明確なゴールを設定すること、そしてそれをもとに豊かな仮説を立案し、素早く仮説検証することが重要です。

プロダクトの成功

スクリーンショット 2021-02-21 1.58.58

エンジニアだった頃は、「バグがなくて、多くのユーザーに喜んでもらえること」がプロダクトの成功だと思っていました。しかし、今は継続的にユーザーに価値を届けるために、事業として収益を上げることも重要だと考えています。バックログを作るときにも、ユーザー価値と事業収益のバランスを意識しています。

もう一つ大事にしているのが「ビジョンの実現」です。プロダクトをつくるプロとして、私達はユーザーがほしいと思ってもいなかったプロダクトを提供しなければなりません。ユーザーの言いなりになるのではなく、どのようにビジョンを実現するのかという目線も持っています。

ビジョンに向かう仮説構築

プロダクトの未来を思い描くとき、多くの仮説を作らなければなりません。それらすべての仮説はビジョンに紐付いていて、一気通貫していることが重要です。仮説をつくり、管理するときにはこの4つの階層で捉えることがお勧めです。

スクリーンショット 2021-02-21 2.02.46

上にあるプロダクトのCoreを元に、プロダクトのWhyの層を発想します。このように仮説を階層構造で捉えていることで、チームで議論が噛み合わないときにひとつ上の層へと登っていくことができます。

スクリーンショット 2021-02-21 2.09.16

プロダクトをつくるとき、いつの間にかWhatの層だけで議論しがちです。その結果、プロダクトを良くするために努力をしていたはずなのに、気がつくとプロダクトが発散して上図の魚のようになってしまいます。(この魚は蛇足のだそくんという名前です🐟)

スクリーンショット 2021-02-21 2.13.58

これが起きる原因を図解したものがこちらです。課題と解決策はセットですが1:1ではありません。同じ解決策で別の課題が解決できることもあります。このとき、目に見える解決策の認識があっているからといって、課題の認識を取っていなければ、いつの間にか色々な方向にプロダクトが改変されていってしまいます。

だそくんを生み出さないためにも、そのプロダクトが目指す姿やターゲットユーザー、なぜ自社が取り組むのかといったCoreとWhyの層の認識もチームであわせていきましょう!

豊かな仮説構築

プロダクトが一気通貫していることも重要ですが、一気通貫性を保ちながらもユーザーが思いつかないような豊かで大胆な仮説を構築することも重要です。そのためには、短期的にプロダクトを改善する目線だけではなく、中期的な「誰をどんな状態にしたいか」からプロダクトを発想する目線を持ち続けましょう。

中期的な目線でビジョンを満たすために、「誰をどんな状態にしたいか」を100本ノックすること、そしてその100本から最も良いものを選択する、つまり発散と収束を繰り返します。

スクリーンショット 2021-02-21 2.13.42

自分が思いついたアイデアは可愛いですが、アイデアに執着をせず一度そのアイデアでどんな課題を解決できるかを分析し、他にもっとよい解決策が無いかを豊かに発想していきましょう。

伝えたいこと

以上を踏まえて、プロダクトマネージャーとしてエンジニアさんに伝えたいことが2つあります。

スクリーンショット 2021-02-21 2.28.46

私はエンジニアだったころ、自分が書いたコードが捨てられるのがとても嫌でした。しかし、未来を占うことはできず、開発前に可能な限り不確実性を小さくしたとしてもユーザーにぶつけなければわからないことのほうが多いのです。そのため、論理的に大胆な発想をして、小さく仮説検証をすることがとても重要です。書いたコードが使わなくなるとしても「その方向が間違っていると分かること」は非常に重要な発見です。無駄ではありません。

もう1つは「プロダクトのHowだけではなく、CoreとWhyも議論させてください」ということです。もちろん、プロダクトマネージャーはプロダクトのCoreやWhyに責任を持つのが仕事です。しかし、プロダクトに関わる全員が、「プロダクトをもっと良くするためにどうすればよいか?」の視点を持っているチームは強いです。プロダクトのHowに責任を持つエンジニアだから見えているCoreやWhyの要素があります。ぜひ、プロダクトのCoreとWhyについても一緒に議論をさせてください。

宣伝

プロダクトマネジメントのお話をしましたが、特に日本ではまだまだプロダクトマネジメントが浸透していません。チームにプロダクトマネージャーがいない組織のほうが多いのではないでしょうか。

スクリーンショット 2021-02-21 2.15.05

そんな思いから、プロダクトマネジメントの教科書を目指して弊社代表の及川と曽根原春樹さんと一緒に本を書きました。3/3発売です。よろしければ、ご参考ください!