[po meetup 4th] プロダクトを描きストーリーを語ろう

プロダクトを描き

ストーリーを語ろう

プロダクトの課題を発見する試み

POMeetup #4

2013/9/11

プロダクトオーナーって難しくないですか

アジャイルな開発ってビジネスで活きてますか

プロダクトオーナーの責任って重くないですか

既存のルールや習慣と折り合いついてますか

プロダクトオーナーが、より優れた開発と高いビジネ

ス価値を達成するための実践知を交換できる場所

を作っていきたい

3 POMeetupの開催主旨

はじめに

5

(前回のPOMeetupを振り返って)

ビジョンを描く、 そして次の一手を考えたい

うまいやり方はないのか

曖昧で、言葉として語れていないのではないか

プロダクトの課題をつかみ損ねているのでは

ゴールイメージと目先の選択とでズレていないか

新しい事実を知る仕組みが欠けていないか

6

もしかして、

もう少し手間に問題があるのかもしれません

こんなことに思い当りませんか？

テーマにするプロダクトを選ぶ

キャンバスを描いてみる

ストーリーを語ってみる

課題を見つける

まとめ

本日のコンテンツ

扱ってみたいプロダクトがあれば提供

してください

フィクションに変更してください

なければ、空想で作ってください

8 プロダクトを選びます

キャンバスを描いてみる

10

11 Lean Canvas

スタートアップのビジネスモデルをビジュアル化し、仮説検証

フレームワークとして利用するツール

顧客、解決、価値にフォーカス

とてもシンプルな1枚の絵

高速、簡潔、携帯性

今日は、スタートアップとしてではなく、

製品の開発戦略のテンプレートとして利用してみます

書ける人は、どんどん書いてください

初めての人は、これから説明します

※書けないところは空欄でいいです

雑談や相談しながら書いてOKです

ただし、制限時間内に。

12

どんなプロダクトにしたいか

１枚のキャンバスに描く

13 1,2. 顧客と課題

1. 顧客は誰ですか

ユーザーと顧客(購入者)を区別してみる

積極的に使って意見をくれるユーザ層(アー

リー・アダプター)も考えてみましょう

2. 顧客の抱える課題は何ですか

ソリューションを前提にしないように

×「レストラン予約をスマホ端末でやりたい」 ○「映画の待ち時間にレストランを予約したい」

既存の代替品/代用品もあげておきます

14 3. 独自の価値提案(UVP)

3.プロダクトが、独自で注目に値する理由

即効性のある言葉、明快に

顧客の成功ストーリーに注目

15 4,5. ソリューション、圧倒的な優位性

4.それは何ですか

課題を解決する、UVPを達成するモノ

大切なのは機能仕様ではありません

5.プロダクト(または会社)の優位性は何ですか

他社が簡単には真似できないような要素

ユーザー/購入者にとって、優位性のないもの

を列挙しないよう注意

16 6,7. 主要活動、チャネル

6.どうやって顧客に接触しますか

顧客にどこで会えますか

顧客はどのようにプロダクトを見つけますか

アーリー・アダプターをどうやって探しますか

7.成功に達するために何をしますか

顧客をどうやって増やすか

狙い通りに進んでいるかをどう評価するか

17 8,9. 収益の流れ、コスト構造

8.いくらですか

売り切り/リース/広告収入…

(誰から)何に対して対価を得ますか

9.いくらかかりますか

プロダクトが世に送り出されるまでの

コスト

継続的に販売するために必要なコスト

18

描いてみて気づいたことはありますか

photo by Giorgio Montersino http://www.flickr.com/photos/novecentino/

(休憩)

19

ストーリーを語ってみる

20

キャンバスからストーリーを作ってください。

客観的事実と根拠を列挙するよりも、具体的で複雑な体験として連想

させる

聞き手にとって、’見える’・’感じる’ストーリーにする

時間、場所、人物、行動、結果を盛り込む

ユーザー視点から

誰が、いつ、どのように使うのか

それによってどんな効果を得るのか

開発視点から

どのようなものを、どうやって実現するのか

そのために何が必要なのか

企業視点から

なぜそれを開発するのか

それを提供することで、どのような利益を得るのか

21 プロダクトの物語をつくる

聞き手のルール

疑問、質問

黙って手を挙げる(割り込まない)

あてられたら話す。いつ質問に答えるかは発表者が決める

後で「?」を感じた点を伝える

「話の流れとして、そこは本当につながるの？」

「その推測って本当にそうだろうか？」

「何か言葉尻に曖昧さを感じた」

22

さぁ、プレゼンしましょう

23

新しい発見(気づき)はありましたか

プロダクトの課題/リスクを 見つける

24

問題がある個所 抜けているところ(空欄)

仮説として書かれた個所 なかでも、影響の大きい重要なものは

思い込みはないか

他に指摘されたところ

バランスの悪いところ 顧客課題と解決は一致しているか

UVPは実現されているか

チャネルは顧客に正しくたどり着けるか

収益/コストは成立しているか

25 課題/リスクは見つかりましたか

(赤で囲む)

青で下線

赤(マズいところ) や

青(工夫がいる) でコメントを追記

参考：リーンスタートアップで示されるリスク 26

解決に 値するか

課題に 適切か

反応は 期待どおりか

進んで いるか

価格は 妥当か コストは

見合っているか

特定 できるか

接触 できるか

拡散 できるか

製品のリスク

市場のリスク

顧客のリスク

27

どうやって解決しますか

(最後に) 私の考えを聞いてください

28

29 提案：課題をバックログにして計画する

------------

------------

------------

------------

課題の一覧

------------

------------

------------

------------

------------

(達成したいこと)

プロダクトバックログ

伝えられたことだけが計画にのる チームはそれを順守しようとする 過ちはできるだけ見逃される

←コレが議論の俎上に上がることがない プロダクトは危ないつり橋？

30 提案：課題をバックログにして計画する

------------

------------

------------

------------

課題バックログ

------------

------------

------------

------------

------------

(達成したいこと)

（最重要課題）

------------

------------

------------

------------

------------ ------------

------------ ------------

------------ 順に並べる

プロダクトバックログ

ひとりではムリ！ ステークホルダや開発者の意見が必要