「プロダクトマネジメントの“罠”を回避しよう」のセミナー備忘録
翔泳社主催の「プロダクトマネジメントの“罠”を回避しよう」のセミナーを聞きました。
テーマは、ビルドトラップと呼ばれる罠について。
講師は「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」を翻訳した吉羽 龍太郎 さん。
noteは基本的にここで話されたアウトカムとインパクト思考のいい組織だと思うけど、今の私はまさにビルドトラップにはまっている状態だろうと感じた。すぐに実践できるセンスがないので、意識して試行錯誤をしようと思う。できるだけチームにストレスかけないようになりたいし、ユーザーが便利になるものを作りたいんだ。
最後のQAタイムがめちゃくちゃ盛り上がった。相談レベルはそれぞれ違うけど、いろんなレイヤーの相談があったので、悩みはつきないのだと思った。
↓↓↓ここから下は備忘録で、まとまりはありません↓↓↓
アウトプットって重要？
アウトプット：出力
アウトカム：顧客が抱える問題の解決、行動変容
インパクト：そこから組織に与えたビジネス的な影響
→「アウトプット」が最重要なわけではない。質、成果、効果が大事。
リリースはゴールではない。スタート地点。
アウトプットとアウトカムは混ぜて話されることが多い
勝ち交換システムとは？
顧客：問題要望ニーズ ⇄ ビジネス：プロダクトやサービス
この価値交換を継続し続ける を意識する
ビルドトラップとは？
・アウトカムではなくアウトプットで成功を図ろうとして行き詰まっている状況
・実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況
使わない機能はユーザー体験を阻害する。
機能が増えすぎるとユーザー満足度は下がる。
「ハッピーユーザーピーク」
スタートアップの失敗理由の第一位は、ニーズのないものを作っていること。人が欲しがるものを作ろう
「プロジェクト」は、プロダクト開発の一部、要素。
プロダクト価値の最適化を実現するためにプロジェクトがある。
プロジェクトは、アウトカムで考えよう。
ビルドトラップにはどう対処する？
・適切なプロダクトマネージャーを据える。プロジェクトのマネージャーではない。
→「なぜ」に責任をもつ。ユーザーをよく知っている。実験から学習できる。
・適切なチーム構成にする
→問題発見〜目標設定〜アイデア創出〜デリバリーまでの一連の流れができるのがいいチーム。
・戦略を組織に行き渡らせる
→やろうとしていることは、組織のミッションビジョンから戦略に落とせているのか？
・ソリューションの前に問題を理解する
→機能がないのは本当に問題なのか？
→ソリューションの話の方がしやすいからそうなりがちだけど、ユーザーは機能がほしいわけではなく、課題やニーズを解決したい。解決すべき問題は何かを考えるようにする。
・ソリューションを探索する
→学習のための実験をする。仮説が正しいかどうか証明するためになるべく素早く実験する。捨てる覚悟を持って。
・適切な指標をきめて活用する
→プロダクトやビジネスの健全性を示す指標をウォッチする。
PVやUUではない。
どういう数字を見た方がいいか、チームとステークフォルダーと一緒にきめる。誰かがこれだと決めるものではない。
・組織をプロダクト主導にする