プロダクトオーナーが知るべき97のこと

1.2K Views

July 25, 17

スライド概要

postudyのライトニングトークス(5分)で話したこと。

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

プロダクトオーナーが 知るべき97のこと 97 Things Every Product Owner Should Know Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓

2.

Ichitani Toshihiro 市⾕聡啓 ギルドワークス株式会社 代表 株式会社エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス 代表理事 DevLOVE コミュニティ ファウンダ ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 0→1 http://about.me/papanda0806 Toshihiro Ichitani All Rights Reserved.

3.

ギルドワークス 仮説検証型のサービス企画開発、 現場改善、組織改善コーチ 年間80本の企画開発及びコーチ https://guildworks.jp/service/value/ Toshihiro Ichitani All Rights Reserved.

4.

97 Copyright (c) Toshihiro Ichitani

5.

しまった… Copyright (c) Toshihiro Ichitani

6.

全97のうち 今⽇は5とか Copyright (c) Toshihiro Ichitani

7.

プロダクトオーナーが 知るべき9.7のこととか Copyright (c) Toshihiro Ichitani

8.

結論 Copyright (c) Toshihiro Ichitani

9.

108 Copyright (c) Toshihiro Ichitani

10.

仮説検証 開発 1. プロダクトは誰のものか、顧客の仮説を⽴てる。 2. 傾向性を⾒つける 3. ⽚付けたいジョブは何か。 4. 課題仮説を⽴てる。顕在課題と潜在課題 5. 現状の代替⼿段とその満⾜状況を知る 6. PSfitのための検証 7. PMfitのための検証 8. 顧客とであるチャネルは検証できているか 9. 顧客は何に対価を払うのか 10.顧客のpainとgainを考える 11.顧客への提案価値を磨く 12.どうやってプロダクトの状況を判断するのか、評価指標を⽴てる 13.ビジョンを描く 14.⽬的を常に問う 15.ふりかえりとともに向き直る 16.ソリューションの仮説を⽴てる 17.サービスの差別化要因を探せ 18.圧倒的優位性を棚卸しする 19.ユーザーインタビューする 20.顧客のジャーニーマップを描く 21.仮説を更新し続ける 22.プロトタイプを⽤いてインタビューをおこなう 23.MVPを定める 24.予算を⾒⽴てる 25.ファネル分析し、計測する 26.コホート分析 27.アテンションとトラクションを⾒⽴てる 28.検証キャンバスで検証のプランニングをする 29.世の中のソリューションで何ができるか知っておく 30.何を分かるための検証かをあいまいにしない。 31.ドメイン知識に触れておく 32.業界の課題を知る 33.収益計画を⽴てる 34.ユーザーを⾃分に憑依させる 35.アーリーアダプターを理解する 36.パートナーシップの可能性 37.ランディングページで検証する 38.アンバサダー・マーケティング 39.インフルエンサー 40.ゲーミフィケーション 41.NPS 42.なりきりエスノグラフィー 43.お妻テスト 44.リーンブランディング 45.マーケティング技法を知っておく 46.プランB 47.ストーリーマップを描く 48.エレベータピッチが話せる 49.狩野モデル 50.アジャイルな開発の運営⽅法を知る 51.インセプションデッキでプロダクトとプロジェクトの⽅向性を整える 52.ユーザーストーリーマッピングでバックログを創出する 53.スプリント計画ミーティングでやるべきことの順番を決める 54.デイリースクラムに参加し、チームの状態を知る 55.スプリントレビューで、プロダクトの⽅向性を調整する 56.レトロスペクティブで、カイゼンを駆動する 57.バックログのリファインメントをする 58.プロダクトバックログのマネジメント 59.スプリントバックログのマネジメント 60.ロードマップをつくり続ける。 61.デザインプロセスを知っておく 62.プロセスタイム、リードタイム 63.⾮機能要件は考えたか 64.ドラッカー⾵エクササイズ 65.開発チームと向き合う 66.ビジョンを語る 67.問題 vs 私たち 68.チームが相談できるようにある 69.デザイナーと話せるようになっておく 70.チームに任せる 71.ユーザーテスト 72.PDCAサイクルは定型運⽤の基本 73.XPを宿す 74.カンバンの運⽤ 75.リーンの原則 76.アジャイル原則 思考 Copyright (c) Toshihiro Ichitani 77.メタファーを考える 78.ブレストの設計 79.オズホーンのチェックリスト 80.KJ法 81.5-Why 82.多くのアプリやサービスを実際に触っておく 83.ワークショップをデザインする 84.顧客の先にある顧客に向き合う 85.セットベースとポイントベース 86.時間軸を進めてみる 87.逆算して考える 88.相談できる外部の専⾨家とつながっておく 89.OODAサイクルは探索の基本 90.MKPを⾒極める 91.システム思考 92.フックモデル 93.いきなり事業をはじめない (ビジネスモデル検証 とビジネスの遂⾏は違う) 94.感情は細部に宿る 95.預⾔者にはなれない 96.バケツの⽳を塞ぐ 97.⽬的に忠誠を違う 98.Whyから始めよ。 99.ゼロベースで考える。 100.エフェクチュエーション的に考える 101.ボトルネックを飼い馴らす 102.何を、どんな意味に変えるのか。 103.サーヴァントリーダーシップ 104.最後は⾃分が決める 105.銀⾏にお⾦を借りてきてでも、やるか? 106.ワクワクするか? 107.ビジョンを語る 108.越境せよ

11.

この108は、⾃分の中から 出てきたものを、ベースにしています。 (なので世の中にとっての網羅性という 観点はないです) Copyright (c) Toshihiro Ichitani

12.

では、いってみましょう! Copyright (c) Toshihiro Ichitani

13.

(1) Copyright (c) Toshihiro Ichitani

14.

プロダクトは誰のものか、 顧客の仮説を⽴てる。 Copyright (c) Toshihiro Ichitani

15.

この知るべきことを知るためには キャンバスの話を踏まえなければならない Copyright (c) Toshihiro Ichitani

16.

今使っているキャンバス ⽬的 ビジョン ソリューション 優位性 評価指標 収益モデル 提案価値 顕在課題 代替⼿段 状況 潜在課題 チャネル 傾向

17.

私のキャンバス遍歴 Toshihiro Ichitani All Rights Reserved.

18.

ビジネスモデルキャンバス パートナー 主要活動 価値提案 顧客との関係 リソース チャネル コスト構造 http://businessmodelgeneration.com/ 収益の流れ 顧客セグメント

19.

ビジネスモデルキャンバス パートナー 主要活動 リソース 価値提案 顧客との関係 顧客セグメント チャネル コスト構造 収益の流れ ・扱う課題や要望を直接的に表現できない ・すでに⽴ち上がっている事業のモデル化に使う http://businessmodelgeneration.com/

20.

リーンキャンバス 課題 ソリューション 独⾃の価値提案 圧倒的な優位性 主要指標 チャネル コスト構造 収益の流れ 顧客セグメント

21.

リーンキャンバス 課題 ソリューション 主要指標 独⾃の価値提案 圧倒的な優位性 顧客セグメント チャネル ・顧客 - 課題 - 価値提案 - ソリューションの構造 コスト構造 収益の流れ 「課題解決のストーリー」を扱える ・第1次⻑期利⽤キャンバス

22.

仮説キャンバス ver1 ⽬的 ビジョン 課題 ソリューション 主要指標 コスト構造/リスク 価値提案 圧倒的な優位性 チャネル 収益の流れ/嬉しさ 顧客

23.

仮説キャンバス ver1 ⽬的 ビジョン 課題 ソリューション 価値提案 圧倒的な優位性 ・課題解決のストーリーを扱える ・⾃分たちがやるべき理由=⽬的、 主要指標 チャネル 顧客にどうなってもらいたいか=ビジョン を常に思考の範囲に⼊れる ・第2次⻑期利⽤キャンバス コスト構造/リスク 収益の流れ/嬉しさ 顧客

24.

仮説キャンバス ver2

25.

仮説キャンバス ver2 ・提案価値と課題を対応付けたい ・代替⼿段を明確に ・…エリアが多すぎて複雑、思い出せない

26.

仮説キャンバス ver3 ⽬的 ビジョン ソリューション 優位性 評価指標 収益モデル 提案価値 顕在課題 代替⼿段 状況 潜在課題 チャネル 傾向

27.

仮説キャンバス ver3 ⽬的 ビジョン ソリューション 優位性 評価指標 提案価値 顕在課題 代替⼿段 状況 潜在課題 チャネル 傾向 ・顧客ではなく、状況とそして傾向 ・課題は、顕在課題(状況から)と潜在課題(傾向から) 収益モデル ・第3次⻑期利⽤キャンバス

28.

キャンバスとの付き合い⽅ ここまで⾒てきたとおり、キャンバスは必要に応じて変えていく。 だったらチェックリストではダメなのか?と問われることがある。 私は「⼀枚絵」にすることに意味を⾒出している。 ①全体像がファーストビューで⾒渡せる。 つまり、観点(エリア)間のつながりが⾒やすい。 ②全部が書けない。 つまり、本当に⼤事なところに集中しやすい。 ⼀枚のキャンバスで表現できない観点として「時間軸」がある。 サービスの進展とともに”⼤事なところ”は移っていく。 それはキャンバス内の他のエリアかもしれないし、 キャンバスの外にあるかもしれない。

29.

仮説キャンバス ver3 ⽬的 ビジョン ソリューション 優位性 評価指標 収益モデル 提案価値 顕在課題 代替⼿段 状況 潜在課題 チャネル 傾向

30.

仮説キャンバス ver3 ⽬的 ビジョン ソリューション 優位性 提案価値 評価指標 顕在課題 代替⼿段 状況 潜在課題 チャネル 傾向 <WHAT> 対象を理解するために「属性」をあげる。 あくまで理解のため。順序的には「課題」をより 切実に持っている⼈は誰かという特定の仕⽅をす 収益モデル る。すなわち「課題」が起きる「状況」をあげる。 「属性」ベースでは、直接的に「課題」につなが らないため、判断を誤る可能性が⾼い

31.

仮説キャンバス ver3 ⽬的 ビジョン <HOW> 現時点で「誰向けのものか」を⾒⽴てて、補完や ソリューション 優位性 提案価値 顕在課題 代替⼿段 深掘りのために「ペルソナ」や「共感マップ」を 状況 使う。 ただし、ワークショップの結果は「仮説」でしか ない。インタビューでの探索が「発⾒」に繋がる。 潜在課題 評価指標 チャネル 傾向 <WHAT> 対象を理解するために「属性」をあげる。 あくまで理解のため。順序的には「課題」をより 切実に持っている⼈は誰かという特定の仕⽅をす 収益モデル る。すなわち「課題」が起きる「状況」をあげる。 「属性」ベースでは、直接的に「課題」につなが らないため、判断を誤る可能性が⾼い

32.

(2) Copyright (c) Toshihiro Ichitani

33.

傾向性を⾒つける Copyright (c) Toshihiro Ichitani

34.

傾向 = 置かれている状況から⾃ずと取られる⾏動 ユーザーが新たな⼿段を利⽤開始 するためには、切り替えするだけの 理由がなければならない。 その理由を探るためには、ユーザー のいる世界の状況を、ユーザーと 同じように、⾒る、聴く、感じる 必要がある。 カスタマージャーニーマップで新たな流れを⾒⽴てる Toshihiro Ichitani All Rights Reserved. Photo via Visual Hunt

35.

カスタマージャーニーマップ ユーザーの⾏動と感情を時系列で可視化する。 インタビューの結果得られた事実から、現状のフローを描く。 現状をベースに、新たな価値提案のためのフローを⾒⽴てる。 Toshihiro Ichitani All Rights Photo Reserved. credit: Dane Vandeputte via VisualHunt / CC BY-NC-SA

36.

⼿ぶらで描くのは難しい! ストーリーのアウトラインを借りてくる 「ストーリーマッピングをはじめよう」 https://www.amazon.co.jp/dp/4802510411/ Concept Story プロダクトの全体像 Origin Story 潜在顧客がはじめて顧客になるまで のストーリー Usage Story プロダクトの利⽤体験 Toshihiro Ichitani All Rights Photo Reserved. credit: Dane Vandeputte via VisualHunt / CC BY-NC-SA

37.

仮説検証 開発 1. プロダクトは誰のものか、顧客の仮説を⽴てる。 2. 傾向性を⾒つける 3. ⽚付けたいジョブは何か。 4. 課題仮説を⽴てる。顕在課題と潜在課題 5. 現状の代替⼿段とその満⾜状況を知る 6. PSfitのための検証 7. PMfitのための検証 8. 顧客とであるチャネルは検証できているか 9. 顧客は何に対価を払うのか 10.顧客のpainとgainを考える 11.顧客への提案価値を磨く 12.どうやってプロダクトの状況を判断するのか、評価指標を⽴てる 13.ビジョンを描く 14.⽬的を常に問う 15.ふりかえりとともに向き直る 16.ソリューションの仮説を⽴てる 17.サービスの差別化要因を探せ 18.圧倒的優位性を棚卸しする 19.ユーザーインタビューする 20.顧客のジャーニーマップを描く 21.仮説を更新し続ける 22.プロトタイプを⽤いてインタビューをおこなう 23.MVPを定める 24.予算を⾒⽴てる 25.ファネル分析し、計測する 26.コホート分析 27.アテンションとトラクションを⾒⽴てる 28.検証キャンバスで検証のプランニングをする 29.世の中のソリューションで何ができるか知っておく 30.何を分かるための検証かをあいまいにしない。 31.ドメイン知識に触れておく 32.業界の課題を知る 33.収益計画を⽴てる 34.ユーザーを⾃分に憑依させる 35.アーリーアダプターを理解する 36.パートナーシップの可能性 37.ランディングページで検証する 38.アンバサダー・マーケティング 39.インフルエンサー 40.ゲーミフィケーション 41.NPS 42.なりきりエスノグラフィー 43.お妻テスト 44.リーンブランディング 45.マーケティング技法を知っておく 46.プランB 47.ストーリーマップを描く 48.エレベータピッチが話せる 49.狩野モデル 50.アジャイルな開発の運営⽅法を知る 51.インセプションデッキでプロダクトとプロジェクトの⽅向性を整える 52.ユーザーストーリーマッピングでバックログを創出する 53.スプリント計画ミーティングでやるべきことの順番を決める 54.デイリースクラムに参加し、チームの状態を知る 55.スプリントレビューで、プロダクトの⽅向性を調整する 56.レトロスペクティブで、カイゼンを駆動する 57.バックログのリファインメントをする 58.プロダクトバックログのマネジメント 59.スプリントバックログのマネジメント 60.ロードマップをつくり続ける。 61.デザインプロセスを知っておく 62.プロセスタイム、リードタイム 63.⾮機能要件は考えたか 64.ドラッカー⾵エクササイズ 65.開発チームと向き合う 66.ビジョンを語る 67.問題 vs 私たち 68.チームが相談できるようにある 69.デザイナーと話せるようになっておく 70.チームに任せる 71.ユーザーテスト 72.PDCAサイクルは定型運⽤の基本 73.XPを宿す 74.カンバンの運⽤ 75.リーンの原則 76.アジャイル原則 思考 Copyright (c) Toshihiro Ichitani 77.メタファーを考える 78.ブレストの設計 79.オズホーンのチェックリスト 80.KJ法 81.5-Why 82.多くのアプリやサービスを実際に触っておく 83.ワークショップをデザインする 84.顧客の先にある顧客に向き合う 85.セットベースとポイントベース 86.時間軸を進めてみる 87.逆算して考える 88.相談できる外部の専⾨家とつながっておく 89.OODAサイクルは探索の基本 90.MKPを⾒極める 91.システム思考 92.フックモデル 93.いきなり事業をはじめない (ビジネスモデル検証 とビジネスの遂⾏は違う) 94.感情は細部に宿る 95.預⾔者にはなれない 96.バケツの⽳を塞ぐ 97.⽬的に忠誠を違う 98.Whyから始めよ。 99.ゼロベースで考える。 100.エフェクチュエーション的に考える 101.ボトルネックを飼い馴らす 102.何を、どんな意味に変えるのか。 103.サーヴァントリーダーシップ 104.最後は⾃分が決める 105.銀⾏にお⾦を借りてきてでも、やるか? 106.ワクワクするか? 107.ビジョンを語る 108.越境せよ

38.

2コト話したところで お時間となりましたので ⼤事なコトを最後に。 Copyright (c) Toshihiro Ichitani

39.

プロダクトオーナーが 知るべきたった1つのこと 1 Things Every Product Owner Should Know Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓

40.

仮説検証 開発 1. プロダクトは誰のものか、顧客の仮説を⽴てる。 2. 傾向性を⾒つける 3. ⽚付けたいジョブは何か。 4. 課題仮説を⽴てる。顕在課題と潜在課題 5. 現状の代替⼿段とその満⾜状況を知る 6. PSfitのための検証 7. PMfitのための検証 8. 顧客とであるチャネルは検証できているか 9. 顧客は何に対価を払うのか 10.顧客のpainとgainを考える 11.顧客への提案価値を磨く 12.どうやってプロダクトの状況を判断するのか、評価指標を⽴てる 13.ビジョンを描く 14.⽬的を常に問う 15.ふりかえりとともに向き直る 16.ソリューションの仮説を⽴てる 17.サービスの差別化要因を探せ 18.圧倒的優位性を棚卸しする 19.ユーザーインタビューする 20.顧客のジャーニーマップを描く 21.仮説を更新し続ける 22.プロトタイプを⽤いてインタビューをおこなう 23.MVPを定める 24.予算を⾒⽴てる 25.ファネル分析し、計測する 26.コホート分析 27.アテンションとトラクションを⾒⽴てる 28.検証キャンバスで検証のプランニングをする 29.世の中のソリューションで何ができるか知っておく 30.何を分かるための検証かをあいまいにしない。 31.ドメイン知識に触れておく 32.業界の課題を知る 33.収益計画を⽴てる 34.ユーザーを⾃分に憑依させる 35.アーリーアダプターを理解する 36.パートナーシップの可能性 37.ランディングページで検証する 38.アンバサダー・マーケティング 39.インフルエンサー 40.ゲーミフィケーション 41.NPS 42.なりきりエスノグラフィー 43.お妻テスト 44.リーンブランディング 45.マーケティング技法を知っておく 46.プランB 47.ストーリーマップを描く 48.エレベータピッチが話せる 49.狩野モデル 50.アジャイルな開発の運営⽅法を知る 51.インセプションデッキでプロダクトとプロジェクトの⽅向性を整える 52.ユーザーストーリーマッピングでバックログを創出する 53.スプリント計画ミーティングでやるべきことの順番を決める 54.デイリースクラムに参加し、チームの状態を知る 55.スプリントレビューで、プロダクトの⽅向性を調整する 56.レトロスペクティブで、カイゼンを駆動する 57.バックログのリファインメントをする 58.プロダクトバックログのマネジメント 59.スプリントバックログのマネジメント 60.ロードマップをつくり続ける。 61.デザインプロセスを知っておく 62.プロセスタイム、リードタイム 63.⾮機能要件は考えたか 64.ドラッカー⾵エクササイズ 65.開発チームと向き合う 66.ビジョンを語る 67.問題 vs 私たち 68.チームが相談できるようにある 69.デザイナーと話せるようになっておく 70.チームに任せる 71.ユーザーテスト 72.PDCAサイクルは定型運⽤の基本 73.XPを宿す 74.カンバンの運⽤ 75.リーンの原則 76.アジャイル原則 思考 Copyright (c) Toshihiro Ichitani 77.メタファーを考える 78.ブレストの設計 79.オズホーンのチェックリスト 80.KJ法 81.5-Why 82.多くのアプリやサービスを実際に触っておく 83.ワークショップをデザインする 84.顧客の先にある顧客に向き合う 85.セットベースとポイントベース 86.時間軸を進めてみる 87.逆算して考える 88.相談できる外部の専⾨家とつながっておく 89.OODAサイクルは探索の基本 90.MKPを⾒極める 91.システム思考 92.フックモデル 93.いきなり事業をはじめない (ビジネスモデル検証 とビジネスの遂⾏は違う) 94.感情は細部に宿る 95.預⾔者にはなれない 96.バケツの⽳を塞ぐ 97.⽬的に忠誠を違う 98.Whyから始めよ。 99.ゼロベースで考える。 100.エフェクチュエーション的に考える 101.ボトルネックを飼い馴らす 102.何を、どんな意味に変えるのか。 103.サーヴァントリーダーシップ 104.最後は⾃分が決める 105.銀⾏にお⾦を借りてきてでも、やるか? 106.ワクワクするか? 107.ビジョンを語る 108.越境せよ

41.

ビジョンを語る。 残りの107個を他のメンバーが持ったとしても 「ビジョンを語る」ことだけは、あなたが やらなければ、モノゴトが進むことは無いだろう。 Copyright (c) Toshihiro Ichitani

42.

ご武運を。 Copyright (c) Toshihiro Ichitani