First Commitの前にやっておきたいプロダクトオーナーのお仕事
- 1. First Commitの前にやっておきたい プロダクトオーナーのお仕事 What’s your tasks before the first commitment？ 2021/6/26 はち@PassionateHachi 1
- 2. 蜂須賀 大貴 @PassionateHachi お仕事： 複業 プロダクトマネージャー 2 月 火 水 木 金 土 日 9:30 18:30 22:30 固定時間の契約 じゃないお仕事 (アプリ開発PdM、半行政案件、スタートアップ PdM、 SaaS マーケティング支援、新規事業立ち上げ支援) チーム開発/コミュニティ/個別案件 個別案件/ 家事 習い事
- 3. 蜂須賀 大貴 @PassionateHachi お仕事?： アジャイルYoutuber 3 はちの遊び場 で検索！
- 4. 4
- 5. 各種SNS / お仕事依頼 はこちら 5 https://instabio.cc/PassionateHachi
- 6. This session’s Outcome 6 ✔ アイディアの創出~Sprint 1がスタートするまでに プロダクトオーナーがやるべきことの概要がわかる ✔ 事業視点でスクラムのその前に準備するべきことが理解できる ✔ 自分の立場に置き換えて実践できるアイディアを得られる
- 9. プロダクトオーナーの仕事とは 「正しいものを正しくつくる」仕事 【ビジネスマネジメント ~Whyを追求~】 ・事業の成長にコミットする ex) KGI/KPI策定、PLの作成、予実管理 ・「顧客が本当に欲しいものは何か」を高速で検証する ex) 仮説検証、PoC、プロトタイプマーケティング ・憶測ではなく定量的なデータで事実を取りに行く ex) ユーザーインタビュー、 Web/SNSマーケティン グ、Web解析
- 10. プロダクトオーナーの仕事とは 「正しいものを正しくつくる」 【開発プロジェクトマネジメント ~What,Howを追求~】 ・試しに触れるものを少しずつ、繰り返し開発する ex) アジャイル開発(スクラム) ・開発チームが働きやすい状態を作る ex) チームビルディング、ファシリテーション ・より良いアイデアを受け入れる / カイゼンを繰り返す ex) ふりかえり、レビュー、
- 11. エンジニアに手を動かしてもらう前にやること ✔ 顧客のどんな課題を解決できるのか仮説を立て、検証する × ) 収益や事業成長という自分たちの視点”のみ”、 × ) 憶測で開発開始 ✔ ターゲット顧客を明確にし、本当に解決できるのかを検証する × ) 「30代会社員男性」 × ) 憶測で開発開始 ✔ 「私たち(自社)がやる意味」を明確にする × ) 市場にニーズがあるけど、生かせる技術、知識、経験がない
- 12. 今日の進め方 12 ✔ 「10個のやるべきこと」を以下の形式で少しずつ紹介 - 概要 - 解決したい課題 / 効果 - 参考フレームワーク / 資料 ✔ ご自身の進め方と比較しながら、考察を巡らす
- 13. 全体像 13 Why / 正しいもの How,What / 正しく作る 顧客 / ユーザー 自社 / 事業
- 14. ① アイディアを創出する 14 新規事業やプロダクトは誰かのアイディアから生まれる。プロダ クトアウト(内発的)/マーケットイン(外発的) に関わらず全てはアイディアから始まるのだ。 状況 / Context しかし、自分には「苦手」「アイディアマンは一部の特別な人」とい うイメージから敬遠されがちだ。 誰かがアイディアを出してくれれるまでお見合い状態が続く 課題 / Problem
- 15. ① アイディアを創出する 15 アイディアは、「既存の要素の新しい組み合わせ」ということを理解しよう。資料を集め、 常に考え続けよることで、シャワーの時間や散歩中に閉然やってくる ジェームス・W・ヤング氏の名著「アイデアの作り方」によると、 アイデアは5つのStepで生まれる。しかし、そこには資料集めと 熟考が必要ではあるが、特定の才能によるものではないと語ら れている。 解決策 / Solution 参考 / Reference
- 16. ② ビジョン / ミッションを導き出す 16 新しいアイディアが生まれるとその興奮からすぐに形にしたくな る。しかし、ふと立ち止まると ”何のために？”という疑問が浮か ぶ。 状況 / Context アイディアを新規事業として考えるとどうしても「いくら儲かるの か？」といった ”自社視点” になってしまう。そして、直近の売り上 げや利益に注視し、長期的な視野で捉えた世界観が曇ってしまう 課題 / Problem
- 17. ② ビジョン / ミッションを導き出す 17 企業と同様に、プロダクトに対してもビジョン / ミッションを考えよう。そのプロダクトがど んな世界を作るのか、そのためにどんな責務を果たすのかを定義することでプロダクトの 立ち位置や顧客が見えやすくなる。 「プロダクトマネジメントのすべて」によると、ビジョンとミッション はサイモンシネック氏の提唱するゴールデンサークル (Why,How,What)のさらに前提となる”Core”と定義している。これを 明確にすることで後皇帝の親和性も増す 解決策 / Solution 参考 / Reference
- 18. ③ ペルソナと課題を明確にする 18 プロダクトの目指す世界観が見えてきた。「こんなことに困って いる人」「こんなことを成し遂げたい人」とふわっと顧客も見えてき た。「いや、待てよその人誰だ？」 状況 / Context 何となくイメージで「20代会社員男性」をターゲットにしようという 話で盛り上がっている。それは確かに間違っていない。ただ、「20 代会社員男性」はみんな同じ環境、価値観なのだろうか？まだま だ広い気がする 課題 / Problem
- 19. ③ ペルソナと課題を明確にする 19 「20代会社員男性」を”基本情報(デモグラフィックデータ)”と”性格や価値観(サイコグラ フィックデータ)”に分解してみよう。具体的に架空の一人のペルソナを作り上げると、その 人の気持ちでどう捉えられるかが見えてくる。 顧客を具体化することで、プロダクトで解決できる課題(ペイン)や プロダクトがあることで新しく挑戦できること(ゲイン)がイメージしや すくなる。これを実践する「バリュープロポジションキャンバス」とい うフレームワークも有効。 解決策 / Solution 参考 / Reference
- 20. ④ 「私たちがやる意味」を明確にする 20 「顧客の課題が解決できそう」という自信が出てきた。ところで、 とはいえ、リリース後に真似をされるかもしれないし、法律にぶつ かるかもしれない。私たちがやる理由は？ 状況 / Context 画期的なアイディアかつ、ターゲットとするユーザーもいる。現 状、競合も不在だ。これはいいアイディアかもしれない。しかし、自 社の強みや技術とはほど遠い。あれ？これは自分たちにできるの だろうか？と暗雲が立ち込めてきた。 課題 / Problem
- 21. 21 自社の強みや弱み、世の中の動きを分析してみよう。PEST分析、SWOT分析、3C分析な ど、一度は聞いたことがある要因分析をやってみて自分たちの解像度を上げよう 「両利きの経営」には、既存事業を維持、拡大しながら新規事業 を柱にしてきた事例がたくさん載っている。特に富士フイルムの化 粧品事業への舵取りは自社の強みを理解して、新しい挑戦を成 功させたわかりやすい事例だろう。 解決策 / Solution 参考 / Reference ④ 「私たちがやる意味」を明確にする
- 22. ⑤ アイディアを検証する 22 多くの時間を使って検討してきた甲斐があり、予算が確保でき そうだ。最後に社長から「本当にうまくいくんだね？」という問いに はっきりとうなづけない自分がいた。 状況 / Context 自分たちの今まで考えてきた「ペルソナは本当にいるんだろう か？」「本当にこんな課題はあるのだろうか？」不安はあるもの の、責任者は自分だ。最後には判断が必要。確かめたい・・・確か めたい・・・確かめたい・・・ 課題 / Problem
- 23. 23 まずは、定義したペルソナに当てはまる人を探して聞いてみよう。仮説検証をすること で、正しかったことも間違っていたこともわかる。それが答えではないが判断の材料にはな るはずだ。 仮説検証はアジャイル開発とセットと言っても過言ではない。いく ら「正しく作る」ができても「正しいもの」を作っているとは限らない。 「正しいものを正しくつくる」がそんな教訓を教えてくれる 解決策 / Solution 参考 / Reference ⑤ アイディアを検証する
- 24. ⑥ 事業収益性を考える 24 企業における新規事業である以上、事業としての貢献は必要 不可欠だ。慈善事業ではない。では、収益性はどうだろう？ビジ ネスモデルは適切か？を考えることは重要だ。 状況 / Context 「事業として貢献できるのか」を考える上で、コストと収益モデル を考え始めた。予算はどうせ削られるから多く積んでおこう。スケ ジュールはどうせ伸びるけど、短めに書いておこう。そうして「あく まで提出用の計画だから」そんな言葉が飛び交う。 課題 / Problem
- 25. 25 「ビジネスモデルキャンバス」を用いて関係性を行き来しながら、整理してみよう。顧客と 事業、コストと収益それぞれを何度も行き来することで適したバランスが見えてくるはず だ。 そもそも、ビジネスモデルを考える上でそのパターンと例をイン プットしておくのも大切だ。そのためには「ビジネスモデル・ジェネ レーション」を手に取ると自身の引き出しも増えてくるだろう。 解決策 / Solution 参考 / Reference ⑥ 事業収益性を考える
- 26. ⑦ 正しさを常に追える指標を定める 26 初期の事業計画はあくまで”計画”である。その通りに行くこと はまずない。その計画のズレをできるだけ早く知ることで軌道修 正をしていくことが大切だ 状況 / Context 計画のズレを早く把握するために「会員ユーザー数」KPIを設定 した。その指標を伸ばすためにあらゆる試作を行なって、ユー ザー数は伸びた。しかし、事業としての成長や収益には影響がほ とんどない。どうやら、追いかける指標を間違えたらしい 課題 / Problem
- 27. 27 「取得できる指標」より、ビジョン / ミッションの達成に影響する指標を探そう。目先の収 益性よりも目指している世界観があるはずだ。 注視する数字を定めるとその数字だけを考えてしまい、視野が 狭まっています。本質的な目指す姿と関連付けたKPIは「人と組織 を効果的に動かす KPIマネジメント」を参考にして設定してみよう 解決策 / Solution 参考 / Reference ⑦ 正しさを常に追える指標を定める
- 28. ⑧ 体験のつくりかたを決める 28 さて、いよいよ”How”を考える段階だ。顧客の課題を解決する ための手段を具体的に考え、いよいよチーム組成の準備を始め よう 状況 / Context 顧客の課題を解決する”機能”を実現するためにはあんな技術 やこんな技術が必要だ。そのためにはこんなチームを組む必要が あるだろう。事前に根回しをして作りたい”機能”を共有しておこう。 どの”機能”もマストだ。ユーザーはこの”機能”が欲しいに違いな い。 課題 / Problem
- 29. 29 顧客が欲しいのは機能(Output)ではなく、そこから得られる成果(Outcome)である。時に は機能を減らすこと、オペレーションで対応すること、デザインで解決することも有効な手 段である。 ”Whyの仮説検証”に続いて、”What,Howの仮説検証”もとても 重要である。これは開発フェーズに入っても終わらない。そのバラ ンスとサイクルを実現する方法は「Lean UX 第二版」も参考になる 解決策 / Solution 参考 / Reference ⑧ 体験のつくりかたを決める
- 30. ⑨ 適した解決手段かを検証する 30 解決手段のイメージができてきた。まずはプロトタイプを用意し て、リアクションを探ってみよう。ユーザーの声こそが、プロダクト の成功確率を上げる手段なのだ。 状況 / Context プロトタイプを作ってマーケティングを始めよう。そのためにはエ ンジニアに手を動かしてもらわないといけない。急がなくてはなら ないので機能をまずは伝えよう。え？エンジニアが忙しくて2ヶ月 後になる？仕方ない、待つことにしよう。 課題 / Problem
- 31. 31 プロトタイプはあなたにも作れる。紙芝居でいいのだ。頭の中にあるイメージを手書きで スケッチすればそれはもう立派なイメージの共有ができる。作って壊して、また作って、 徐々に精度を上げていけばいい。 Jeff Patton氏の「ユーザーストーリーマッピング」には手法とし てのユーザーストーリーマッピングだけなく常に仮説検証を行う ディスカバリーチームやペーパープロトタイプについても触れてい る。読み返してみると新たな発見も。 解決策 / Solution 参考 / Reference ⑨ 適した解決手段かを検証する
- 32. ⑩ チームをつくり、共有する 32 待ちに待った開発フェーズに突入する。必要なスキルセットを定 義して、いよいよチームビルディングを始めよう。 状況 / Context 選りすぐりのメンバーが集まった。まずは今回作るものを説明し よう。あくまでここまでかなり考え、仮説検証もしてきた。今日から 参加するメンバーより自分が何倍もこのプロダクトを考えているん だ。異論反論など、まだ考えが浅いから生まれるだけだ。 課題 / Problem
- 33. 33 多様性と価値観を認めよう。着眼点が違うとあらゆるアイデアが生まれる。ビジョンやミッ ション顧客の課題など機能を超えた多くのコンテキストを共有することで、良いアイディア は生まれ、それは常にお互いを助けてくれる。 インセプションデッキなどの方向性を揃えるプラクティスや実在 企業での事例などは「アジャイル開発とスクラム 第二版」に豊富 に記載されている。個と個の間に生まれる暗黙知の衝突(知的コ ンバット)についても触れることができる 解決策 / Solution 参考 / Reference ⑩ チームをつくり、共有する
- 34. 全体像 34 Why / 正しいもの How,What / 正しく作る 顧客 / ユーザー 自社 / 事業
- 35. エンジニアに手を動かしてもらう前にやること ✔ 顧客のどんな課題を解決できるのか仮説を立て、検証する × ) 収益や事業成長という自分たちの視点”のみ”、 × ) 憶測で開発開始 ✔ ターゲット顧客を明確にし、本当に解決できるのかを検証する × ) 「30代会社員男性」 × ) 憶測で開発開始 ✔ 「私たち(自社)がやる意味」を明確にする × ) 市場にニーズがあるけど、生かせる技術、知識、経験がない
- 36. 告知
- 38. 各種SNS / お仕事依頼 はこちら 38 https://instabio.cc/PassionateHachi