Toshihiro Ichitani All Rights Reserved.
プロダクトオーナーが
知るべき97のこと
Ichitani Toshihiro
市⾕聡啓
97 Things Every Product Owner Should Know
Toshihiro Ichitani All Rights Reserved.
http://about.me/papanda0806
Ichitani Toshihiro
市⾕聡啓
ソフトウェア開発16年
SIer→サービス→受託→起業
仮説検証とアジャイル開発
ギルドワークス株式会社 代表
株式会社エナジャイル 代表
⼀般社団法⼈ 越境アジャイルアライアンス 代表理事
DevLOVE コミュニティ ファウンダ
0 → 1
Toshihiro Ichitani All Rights Reserved.
仮説検証型のサービス企画開発、
現場改善、組織改善コーチ
年間80本の企画開発及びコーチ
ギルドワークス
https://guildworks.jp/service/value/
Copyright (c) Toshihiro Ichitani
97
Copyright (c) Toshihiro Ichitani
しまった…
Copyright (c) Toshihiro Ichitani
全97のうち
今⽇は5とか
Copyright (c) Toshihiro Ichitani
プロダクトオーナーが
知るべき9.7のこととか
Copyright (c) Toshihiro Ichitani
結論
Copyright (c) Toshihiro Ichitani
108
Copyright (c) Toshihiro Ichitani
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.アジャイル原則
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.越境せよ
仮説検証 開発 思考
Copyright (c) Toshihiro Ichitani
この108は、⾃分の中から
出てきたものを、ベースにしています。
(なので世の中にとっての網羅性という
観点はないです)
Copyright (c) Toshihiro Ichitani
では、いってみましょう!
Copyright (c) Toshihiro Ichitani
(1)
Copyright (c) Toshihiro Ichitani
プロダクトは誰のものか、
顧客の仮説を⽴てる。
Copyright (c) Toshihiro Ichitani
この知るべきことを知るためには
キャンバスの話を踏まえなければならない
今使っているキャンバス
⽬的 ビジョン
ソリューション 優位性
評価指標
提案価値 顕在課題 代替⼿段
チャネル
状況
収益モデル
傾向潜在課題
Toshihiro Ichitani All Rights Reserved.
私のキャンバス遍歴
ビジネスモデルキャンバス
パートナー 主要活動
リソース
価値提案 顧客との関係
チャネル
顧客セグメント
コスト構造 収益の流れ
http://businessmodelgeneration.com/
ビジネスモデルキャンバス
パートナー 主要活動
リソース
価値提案 顧客との関係
チャネル
顧客セグメント
コスト構造 収益の流れ
http://businessmodelgeneration.com/
・扱う課題や要望を直接的に表現できない
・すでに⽴ち上がっている事業のモデル化に使う
リーンキャンバス
課題 ソリューション
主要指標
独⾃の価値提案 圧倒的な優位性
チャネル
顧客セグメント
コスト構造 収益の流れ
リーンキャンバス
課題 ソリューション
主要指標
独⾃の価値提案 圧倒的な優位性
チャネル
顧客セグメント
コスト構造 収益の流れ
・顧客 - 課題 - 価値提案 - ソリューションの構造
 「課題解決のストーリー」を扱える
・第1次⻑期利⽤キャンバス
仮説キャンバス ver1
課題 ソリューション
主要指標
価値提案 圧倒的な優位性
チャネル
顧客
コスト構造/リスク 収益の流れ/嬉しさ
⽬的 ビジョン
仮説キャンバス ver1
課題 ソリューション
主要指標
価値提案 圧倒的な優位性
チャネル
顧客
コスト構造/リスク 収益の流れ/嬉しさ
⽬的 ビジョン
・課題解決のストーリーを扱える
・⾃分たちがやるべき理由=⽬的、
 顧客にどうなってもらいたいか=ビジョン
 を常に思考の範囲に⼊れる
・第2次⻑期利⽤キャンバス
仮説キャンバス ver2
仮説キャンバス ver2
・提案価値と課題を対応付けたい
・代替⼿段を明確に
・…エリアが多すぎて複雑、思い出せない
仮説キャンバス ver3
⽬的 ビジョン
ソリューション 優位性
評価指標
提案価値 顕在課題 代替⼿段
チャネル
状況
収益モデル
傾向潜在課題
仮説キャンバス ver3
⽬的 ビジョン
ソリューション 優位性
評価指標
提案価値 顕在課題 代替⼿段
チャネル
状況
収益モデル
傾向潜在課題
・顧客ではなく、状況とそして傾向
・課題は、顕在課題(状況から)と潜在課題(傾向から)
・第3次⻑期利⽤キャンバス
キャンバスとの付き合い⽅
ここまで⾒てきたとおり、キャンバスは必要に応じて変えていく。
だったらチェックリストではダメなのか?と問われることがある。
私は「⼀枚絵」にすることに意味を⾒出している。
①全体像がファーストビューで⾒渡せる。
 つまり、観点(エリア)間のつながりが⾒やすい。
②全部が書けない。
 つまり、本当に⼤事なところに集中しやすい。
⼀枚のキャンバスで表現できない観点として「時間軸」がある。
サービスの進展とともに”⼤事なところ”は移っていく。
それはキャンバス内の他のエリアかもしれないし、
キャンバスの外にあるかもしれない。
仮説キャンバス ver3
⽬的 ビジョン
ソリューション 優位性
評価指標
提案価値 顕在課題 代替⼿段
チャネル
状況
収益モデル
傾向潜在課題
仮説キャンバス ver3
⽬的 ビジョン
ソリューション 優位性
評価指標
提案価値 顕在課題 代替⼿段
チャネル
状況
収益モデル
傾向潜在課題
<WHAT>
対象を理解するために「属性」をあげる。
あくまで理解のため。順序的には「課題」をより
切実に持っている⼈は誰かという特定の仕⽅をす
る。すなわち「課題」が起きる「状況」をあげる。
「属性」ベースでは、直接的に「課題」につなが
らないため、判断を誤る可能性が⾼い
仮説キャンバス ver3
⽬的 ビジョン
ソリューション 優位性
評価指標
提案価値 顕在課題 代替⼿段
チャネル
状況
収益モデル
傾向潜在課題
<HOW>
現時点で「誰向けのものか」を⾒⽴てて、補完や
深掘りのために「ペルソナ」や「共感マップ」を
使う。
ただし、ワークショップの結果は「仮説」でしか
ない。インタビューでの探索が「発⾒」に繋がる。
<WHAT>
対象を理解するために「属性」をあげる。
あくまで理解のため。順序的には「課題」をより
切実に持っている⼈は誰かという特定の仕⽅をす
る。すなわち「課題」が起きる「状況」をあげる。
「属性」ベースでは、直接的に「課題」につなが
らないため、判断を誤る可能性が⾼い
Copyright (c) Toshihiro Ichitani
(2)
Copyright (c) Toshihiro Ichitani
傾向性を⾒つける
Toshihiro Ichitani All Rights Reserved.
傾向
= 置かれている状況から⾃ずと取られる⾏動
ユーザーが新たな⼿段を利⽤開始
するためには、切り替えするだけの
理由がなければならない。
その理由を探るためには、ユーザー
のいる世界の状況を、ユーザーと
同じように、⾒る、聴く、感じる
必要がある。
カスタマージャーニーマップで新たな流れを⾒⽴てる
Photo via Visual Hunt
Toshihiro Ichitani All Rights Reserved.
カスタマージャーニーマップ
ユーザーの⾏動と感情を時系列で可視化する。
インタビューの結果得られた事実から、現状のフローを描く。
現状をベースに、新たな価値提案のためのフローを⾒⽴てる。
Photo credit: Dane Vandeputte via VisualHunt / CC BY-NC-SA
Toshihiro Ichitani All Rights Reserved.Photo credit: Dane Vandeputte via VisualHunt / CC BY-NC-SA
⼿ぶらで描くのは難しい!
https://www.amazon.co.jp/dp/4802510411/
ストーリーのアウトラインを借りてくる
「ストーリーマッピングをはじめよう」
Concept Story
 プロダクトの全体像
Origin Story
 潜在顧客がはじめて顧客になるまで
 のストーリー
Usage Story
 プロダクトの利⽤体験
Copyright (c) Toshihiro Ichitani
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.アジャイル原則
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.越境せよ
仮説検証 開発 思考
Copyright (c) Toshihiro Ichitani
2コト話したところで
お時間となりましたので
⼤事なコトを最後に。
Toshihiro Ichitani All Rights Reserved.
プロダクトオーナーが
知るべきたった1つのこと
Ichitani Toshihiro
市谷聡啓
1 Things Every Product Owner Should Know
Copyright (c) Toshihiro Ichitani
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.アジャイル原則
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.越境せよ
仮説検証 開発 思考
Copyright (c) Toshihiro Ichitani
ビジョンを語る。
残りの107個を他のメンバーが持ったとしても
「ビジョンを語る」ことだけは、あなたが
やらなければ、モノゴトが進むことは無いだろう。
Copyright (c) Toshihiro Ichitani
ご武運を。

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

  • 1.
    Toshihiro Ichitani AllRights Reserved. プロダクトオーナーが 知るべき97のこと Ichitani Toshihiro 市⾕聡啓 97 Things Every Product Owner Should Know
  • 2.
    Toshihiro Ichitani AllRights Reserved. http://about.me/papanda0806 Ichitani Toshihiro 市⾕聡啓 ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 ギルドワークス株式会社 代表 株式会社エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス 代表理事 DevLOVE コミュニティ ファウンダ 0 → 1
  • 3.
    Toshihiro Ichitani AllRights Reserved. 仮説検証型のサービス企画開発、 現場改善、組織改善コーチ 年間80本の企画開発及びコーチ ギルドワークス https://guildworks.jp/service/value/
  • 4.
  • 5.
    Copyright (c) ToshihiroIchitani しまった…
  • 6.
    Copyright (c) ToshihiroIchitani 全97のうち 今⽇は5とか
  • 7.
    Copyright (c) ToshihiroIchitani プロダクトオーナーが 知るべき9.7のこととか
  • 8.
    Copyright (c) ToshihiroIchitani 結論
  • 9.
    Copyright (c) ToshihiroIchitani 108
  • 10.
    Copyright (c) ToshihiroIchitani 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.アジャイル原則 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.
    Copyright (c) ToshihiroIchitani この108は、⾃分の中から 出てきたものを、ベースにしています。 (なので世の中にとっての網羅性という 観点はないです)
  • 12.
    Copyright (c) ToshihiroIchitani では、いってみましょう!
  • 13.
  • 14.
    Copyright (c) ToshihiroIchitani プロダクトは誰のものか、 顧客の仮説を⽴てる。
  • 15.
    Copyright (c) ToshihiroIchitani この知るべきことを知るためには キャンバスの話を踏まえなければならない
  • 16.
    今使っているキャンバス ⽬的 ビジョン ソリューション 優位性 評価指標 提案価値顕在課題 代替⼿段 チャネル 状況 収益モデル 傾向潜在課題
  • 17.
    Toshihiro Ichitani AllRights Reserved. 私のキャンバス遍歴
  • 18.
  • 19.
    ビジネスモデルキャンバス パートナー 主要活動 リソース 価値提案 顧客との関係 チャネル 顧客セグメント コスト構造収益の流れ http://businessmodelgeneration.com/ ・扱う課題や要望を直接的に表現できない ・すでに⽴ち上がっている事業のモデル化に使う
  • 20.
  • 21.
    リーンキャンバス 課題 ソリューション 主要指標 独⾃の価値提案 圧倒的な優位性 チャネル 顧客セグメント コスト構造収益の流れ ・顧客 - 課題 - 価値提案 - ソリューションの構造  「課題解決のストーリー」を扱える ・第1次⻑期利⽤キャンバス
  • 22.
    仮説キャンバス ver1 課題 ソリューション 主要指標 価値提案圧倒的な優位性 チャネル 顧客 コスト構造/リスク 収益の流れ/嬉しさ ⽬的 ビジョン
  • 23.
    仮説キャンバス ver1 課題 ソリューション 主要指標 価値提案圧倒的な優位性 チャネル 顧客 コスト構造/リスク 収益の流れ/嬉しさ ⽬的 ビジョン ・課題解決のストーリーを扱える ・⾃分たちがやるべき理由=⽬的、  顧客にどうなってもらいたいか=ビジョン  を常に思考の範囲に⼊れる ・第2次⻑期利⽤キャンバス
  • 24.
  • 25.
  • 26.
    仮説キャンバス ver3 ⽬的 ビジョン ソリューション優位性 評価指標 提案価値 顕在課題 代替⼿段 チャネル 状況 収益モデル 傾向潜在課題
  • 27.
    仮説キャンバス ver3 ⽬的 ビジョン ソリューション優位性 評価指標 提案価値 顕在課題 代替⼿段 チャネル 状況 収益モデル 傾向潜在課題 ・顧客ではなく、状況とそして傾向 ・課題は、顕在課題(状況から)と潜在課題(傾向から) ・第3次⻑期利⽤キャンバス
  • 28.
  • 29.
    仮説キャンバス ver3 ⽬的 ビジョン ソリューション優位性 評価指標 提案価値 顕在課題 代替⼿段 チャネル 状況 収益モデル 傾向潜在課題
  • 30.
    仮説キャンバス ver3 ⽬的 ビジョン ソリューション優位性 評価指標 提案価値 顕在課題 代替⼿段 チャネル 状況 収益モデル 傾向潜在課題 <WHAT> 対象を理解するために「属性」をあげる。 あくまで理解のため。順序的には「課題」をより 切実に持っている⼈は誰かという特定の仕⽅をす る。すなわち「課題」が起きる「状況」をあげる。 「属性」ベースでは、直接的に「課題」につなが らないため、判断を誤る可能性が⾼い
  • 31.
    仮説キャンバス ver3 ⽬的 ビジョン ソリューション優位性 評価指標 提案価値 顕在課題 代替⼿段 チャネル 状況 収益モデル 傾向潜在課題 <HOW> 現時点で「誰向けのものか」を⾒⽴てて、補完や 深掘りのために「ペルソナ」や「共感マップ」を 使う。 ただし、ワークショップの結果は「仮説」でしか ない。インタビューでの探索が「発⾒」に繋がる。 <WHAT> 対象を理解するために「属性」をあげる。 あくまで理解のため。順序的には「課題」をより 切実に持っている⼈は誰かという特定の仕⽅をす る。すなわち「課題」が起きる「状況」をあげる。 「属性」ベースでは、直接的に「課題」につなが らないため、判断を誤る可能性が⾼い
  • 32.
  • 33.
    Copyright (c) ToshihiroIchitani 傾向性を⾒つける
  • 34.
    Toshihiro Ichitani AllRights Reserved. 傾向 = 置かれている状況から⾃ずと取られる⾏動 ユーザーが新たな⼿段を利⽤開始 するためには、切り替えするだけの 理由がなければならない。 その理由を探るためには、ユーザー のいる世界の状況を、ユーザーと 同じように、⾒る、聴く、感じる 必要がある。 カスタマージャーニーマップで新たな流れを⾒⽴てる Photo via Visual Hunt
  • 35.
    Toshihiro Ichitani AllRights Reserved. カスタマージャーニーマップ ユーザーの⾏動と感情を時系列で可視化する。 インタビューの結果得られた事実から、現状のフローを描く。 現状をベースに、新たな価値提案のためのフローを⾒⽴てる。 Photo credit: Dane Vandeputte via VisualHunt / CC BY-NC-SA
  • 36.
    Toshihiro Ichitani AllRights Reserved.Photo credit: Dane Vandeputte via VisualHunt / CC BY-NC-SA ⼿ぶらで描くのは難しい! https://www.amazon.co.jp/dp/4802510411/ ストーリーのアウトラインを借りてくる 「ストーリーマッピングをはじめよう」 Concept Story  プロダクトの全体像 Origin Story  潜在顧客がはじめて顧客になるまで  のストーリー Usage Story  プロダクトの利⽤体験
  • 37.
    Copyright (c) ToshihiroIchitani 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.アジャイル原則 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.
    Copyright (c) ToshihiroIchitani 2コト話したところで お時間となりましたので ⼤事なコトを最後に。
  • 39.
    Toshihiro Ichitani AllRights Reserved. プロダクトオーナーが 知るべきたった1つのこと Ichitani Toshihiro 市谷聡啓 1 Things Every Product Owner Should Know
  • 40.
    Copyright (c) ToshihiroIchitani 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.アジャイル原則 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.
    Copyright (c) ToshihiroIchitani ビジョンを語る。 残りの107個を他のメンバーが持ったとしても 「ビジョンを語る」ことだけは、あなたが やらなければ、モノゴトが進むことは無いだろう。
  • 42.
    Copyright (c) ToshihiroIchitani ご武運を。