ono プロダクトの価値を最大化するには？
新井：
プロダクトの価値をどう定義するか。その価値とはお金のこと、ユーザーの数、もしくはプロダクトの機能を充実させることかもしれません。迷ったときは実際にプロトタイプを作り、インタビューしながら、この価値は本物なんだということを確かめつつ定義していく活動がおすすめです。
中村：
プロダクトの価値はいつも”誰かの何かを解決する”ことからスタートします。それを間違えて定義すると作ったもののインパクトも小さくなってしまいます。
仮に偉い人が「こういうのが売れるかも」と思いついたとして、そのアイディアにはどんな裏付けがあって、誰がうれしくて、何を解決してくれるのか。必要とする人はどれくらいいて、届けたい人たちの世界はどうなっているのか、といったことを探してみるといいと思います。
新井：
現場を見に行くことはとても大事なことですよね。
中村：
また、これは変化球ですが、思いついたアイディアをサーチエンジンで検索してみるというのもありかもしれません。すでにたくさんあるものはよくないし、どこにもないものならブルーオーシャンかもしれない。ではなぜ今までなかったのか？というところから考えていくのもいいと思います。
新井：
そうですね。ビジネスモデルキャンバス、仮説キャンバスですね。それを書いてみると因果関係や既存の代替手段、片づけたい用事が明確になるかもしれません。
※ビジネスモデル・キャンバス：ビジネスモデルの構造を分かりやすく可視化するためのフレームワーク。既存ビジネスの改善や新規事業を創出する際に活用される。
※仮説キャンバス：仮説検証（仮説を立てて、その内容の確からしさを検証する活動）を進めるために、必要な情報を整理するためのフレーム。
Message from coaches
- プロトタイプを作ったり、インタビューを行うことで、何が本物の価値なのかを確かめながら定義していこう。
- アイディアをサーチエンジンで検索してみるというのもあり。
- 「そのプロダクトは誰の何を解決できるのか」に注目して、ビジネスモデルキャンバス、仮説キャンバスなどのフレームワークも用いながら、片づけたい用事を明確化してみよう。
価値のあるプロダクトバックログを作るためには？
中村：
カスタマージャーニーマップやユーザーストーリーマップを作って、ユーザーを知る活動をして、価値のあるプロダクトバックログを作る。まずは小さく作ってくり返していくことがいいと思います。
新井：
そうですね。そしてコアのMVP(Minimum Viable Product/顧客の課題を解決できる最低限のプロダクト)は何かを決めながら、かな。
中村：
プロダクトオーナーは確証が持てない中でいろいろな決断を積み重ねていきます。その中でそのプロダクトがよいかどうかも見えてくると思います。
新井：
なんでも放り込めばよいわけではなく、捨てたり削ぎ落したりして洗練させていくことは上級編かもしれませんね。
Message from coaches
- カスタマージャーニーマップやユーザーストーリーマップを作ってユーザーを知る活動をくり返すことで、プロダクトバックログが価値あるものになっていく。
- MVP(Minimum Viable Product/顧客の課題を解決できる最低限のプロダクト)を見極め、加えるだけでなくときには削ぎ落すことで、価値を洗練させていこう。
プロダクトオーナーは開発のことをどれくらいわかっているとよい？
中村：
プロダクトオーナーが開発のことも分かることで、話が早い場合もあれば、首を突っ込みすぎて、大事なユーザーを見ることがおろそかになってしまうこともありますよね。
新井：
分かっているに越したことはないけれど、HOWの部分は開発者に任せて、意思決定に専念してほしいこともあると思います。バランス感覚にこれが正解というものはないのかもしれないな。
中村：
随分前に支援したチームのプロダクトオーナーに、プロダクト自体を作った方がいました。今後は書くことは若手に任せようとプロダクトオーナーになったのはよいのですが、何をどう修正すればよいかまで分かってしまうので、伝えすぎてしまうこともあって。仕事は早かったのですが、プロダクトオーナー任せになってしまうんですよね。
新井：
そこは権限委譲していかないと開発者も育たないし、ずっとプロダクトオーナーの顔色や決定任せになってしまいます。チームとしてはインクリメントが出るかもしれないですが、長期的にみると脆弱なチームになってしまうかもしれません。
そういった場合は、とにかく早くプロダクトを出すフェーズと、チームの成長を見守るフェーズに分けて、関わり方を変えるときちんと表明するといいかもしれませんね。
中村：
そうですね。今はどこに力をかけるべきか、分けて活動できることが理想ですね。
というところで残念ながらお時間となってしまいました。本日はありがとうございました。
新井：
ありがとうございました。
Message from coaches
- プロダクトオーナーが開発のことも分かると、話が早い場合もあれば、首を突っ込みすぎてユーザーを見ることがおろそかになってしまうこともあるので注意が必要。
- 権限を委譲して開発者を育てていくことで、本当の意味で強いチームを作ろう。
- とにかく早く結果を出すフェーズと、チームの成長を見守るフェーズに分けて、関わり方を変えることもおすすめ。
redjourney.jp