所属している会社で昨年Great Demo!のトレーニングが開催され参加しました。この記事は同書の私なりの解釈と要約です。
Great Demoって何?
私は"最も大切なことを最初にやる"と解釈しています。人は誰でも自分が最も興味を持っていることや質問に答えて欲しいと思います。最も興味を持っていることに触れる前に、興味のない機能のデモを見せられるとつまらなくなって、デモ中にスマートフォンを見る等、別のことをしたくなるかと思います。以下、Great Demoの3つの鉄則です。
- デモ参加者の方が最も興味を持っていることに関連する画面を最初(可能であればデモセッション開始から2分以内)に見せます。最初に見せることで"How(これ、どうやって動くんだろう)?"をデモ参加者の頭に入れることができて、興味を引いてもらえる可能性が高くなります。
- デモ参加者の興味を引くことができたら、どのように動くのかをいくつかのアクションでデモします。アクションの間に挟むトークは極力シンプルに断定的に行い、アクションはスムーズに素早く行い、トークとアクションが分断されないようにします。
- デモ参加者が最も興味を持っていることに答えることができたら、デモ参加者は次に興味を持っている幾つかのシナリオ(可能な限り事前にヒアリングしておきデモの準備をしておく)について、デモで見せて欲しいと要求してきます。2と同じように極力シンプル・スムーズなアクションとトークでデモを進めます。
よくある理由
以下は著者のPeter E. Cohanが過去に実施した営業・SE向けのワークショップ参加者から得たデモがうまくいかない理由です。私もこれまで多数のデモを見込み客向けに実施してきて両手では数え切れないぐらいの失敗をしてきましたが、今振り返って考えてみると概ねこれらの理由が当てはまると思います。
- デモ担当者が見込み客の課題を理解していない
- デモ担当者が自社製品のコンセプトや解決できる課題を理解していない
- デモにストーリーが無い、またはストーリーはあるが複雑でわかりにくい
- デモ担当者のデモスキルが不十分でトークとアクションをこなすのに必死
- デモ担当者(SE)と営業が一枚岩になっていない、営業が我関せずになっている
- 長い、つまらない
- 製品が持っている全ての機能をデモしている
- 一方通行で聞き手に質問を投げかけない
- 答えに屈する質問の雨あられで進行を妨げられる
お客様の課題
デモを成功させるための初めの第一歩は、お客様の課題を理解することであると言い切れると思います。Softwareだけに限らず、”Solution”とはお客様の課題を解決できることが証明されて初めて”Solution” になります。お客様の課題を理解しないまま、製品が持っている機能を説明してもお客様には響きません。
Chain of Pain
先ずはじめに、デモに参加するお客様の所属部署と役職、現在抱えている課題とその理由、個々人の課題と理由の関連性を把握します。お客様は例外無く組織に所属しており、個々で違う課題を抱えています。しかしながら組織としての目標は1つのため、個々人の課題と理由には関連性があります。以下、例です。
所属
サービス開発部
役職
部長
課題
厚生労働省および監査事業者からユーザ様から取得した個人情報の取り扱い状況について、GDPRで規程しているルールに沿っていないことについて指摘を受けていて2020年9月末に予定している次回監査委員会ミーティングにて明確な改善方針を説明することを約束しているが、改善方針案の具現化に苦慮している。
理由
現状の自社開発しているCustomer ID Platformで個人情報のプライバシー管理に対応するには膨大な追加開発工数が発生し、新機能をリリースできる時期が読めない。
所属
製品開発技術部
役職
プロジェクトマネージャ
課題
現状の自社開発しているCustomer ID Platformで個人情報のプライバシー管理に対応するには膨大な追加開発工数が発生し、新機能をリリースできる時期が読めない。
理由
開発担当チームから明確なスプリント計画とバックログタスクの共有が無い。
Pain Focus
個々人が持っている課題と理由、各々の関連性が明確になれば後は難しくありません。デモでは初めに課題に対するSolutionを見せます。お客様は、自身の課題を解決してくれるSolutionに興味があり、Software製品が持つ機能に興味があるわけではありません。
デモセッション頭出しロールプレイ
売り手
前回までのお打ち合わせで、製品開発部プロジェクトマネージャxx様の課題は、自社で開発されているCustomer ID Platformで個人情報のプライバシー管理に対応するには膨大な追加開発工数が発生し、新機能をリリースできる時期が読めないことであると理解しました。正しいでしょうか?
買い手
正しいです。開発担当チームからスプリント計画が上がってこなくて。。。
売り手
背景に、厚生労働省および監査事業者からユーザ様から取得した個人情報の取り扱い状況について、GDPRで規程しているルールに沿っていないことについて指摘を受けていらっしゃると認識しています。
買い手
そうです。改善方針案を具現化しなければならないのですがなかなか具現化できなくて。。。
売り手
了解しました。こちらが本日のデモセッションアジェンダです。まず初めに、弊社の製品がOOTBで持っている個人情報管理のデモをお見せします。こちらが本日のデモでご準備したサンプルのWeb Applicationです。こちらを皆様が開発・運用されているApplicationに置き換えてデモをご覧頂ければと思います。
お客様の課題と理由をしっかり理解しないまま、何となく製品の機能をダラダラと説明すれば何か興味は持ってもられるだろうと淡い期待を持ちながらデモを行い、何も質問や意見を得られないままミーティングが終わってしまうことは多いと思います。デモは課題にフォーカスして最も興味を持っていることに最初に答えます。
ストラテジー
書籍の中ではGreat Demo!のストラテジーは以下の5つと断定しています。物事に100%は無いので当然議論の余地はありますが、私もこの5つに集約されると思います。
- お客様の課題と理由、売り手側が提供できるSolutionをシンプル(できれば1Slide)に説明する
- デモでSolutionを端的に説明してまとめる
- How?を意識して更に一歩踏み込んでSolutionを説明してまとめる
- お客様に質問を投げかけて他に興味を持っていることを引き出す、デモで興味や疑問に答える
- お客様の課題と理由に戻り、売り手側がこれらの課題を解決できることを証明したか確認する
デモはお客様の課題を中心に行い、お客様が興味を持っていることだけに注力するようにします。製品機能中心のデモは、予期せぬ動作不良、ミーティング時間の超過、退屈な空気を引き起こしてしまう恐れがあるため絶対に避けるべきです。また、製品中心のデモは必要以上に製品が複雑に見えてしまい、お客様が、"うちには合わないのでは?"、"高そうだなぁ。。。"、"他のベンダーにも声をかけてみようか"といった致命的な感情を掘り起こしてしまう危険性もあります。
おわりに
あらゆるヒトがSoftwareを使いこなしあらゆるモノやコトがSoftwareで定義される昨今、お客様の事業環境は複雑になりお客様自身も何が課題でその理由は何なのか理解できていないケースは多いかと思います。営業やSEも、お客様の課題や理由は何なのか?と一般的な興味はあるものの、お客様自身も理解していない課題を発掘することは時間と労力がかかるため、 ”とりあえずデモ!”といった安易な発想になってしまうことは少ないないかと思います。しかしながら、”とりあえずデモ!”はSoftwareのデモがうまくいかない最たる理由だと思います。常にお客様の課題と理由に着目して、デモは課題を解決するSolutionについて説明したり議論したりする場にしたいですね。