製品ストーリーテリングとは、顧客の状況、特定の問題、製品を変化させるメカニズム、および結果の証拠を通じて製品を説明する実践です。劇的な幕開けのある特集リストではありません。有益な製品ストーリーは、購入者がその製品が自分の仕事のどこに当てはまるのか、なぜ変更が重要なのか、行動する前に何を確認できるのかを理解するのに役立ちます。
お客様が主役です。プロダクトは顧客のできることを変えるツールです。この区別により、ストーリーの関連性が保たれ、購入者の本当の問題が消えてしまう一方で、商品が英雄的なキャラクターになってしまうというよくある間違いを防ぐことができます。
このガイドでは、5 ビートのフレームワーク、機能を信頼できる結果に変換する方法、および架空の小規模 SaaS 製品の例を示します。また、ストーリーが Web ページからセールスデッキや製品ビデオに移動するときにストーリーを保持する方法も示します。
01
製品ストーリーテリングとは何ですか？
製品ストーリーテリングでは、事実と物語を組み合わせて、製品が顧客の状況をどのように変えるかを伝えます。事実とは、製品の実際の機能、制約、画面、資産、証拠です。物語は、購入者が従うことができる因果関係の中でこれらの事実を結び付けます。
簡単な製品ストーリーは次のようになります。
> 複数のチームメイトがオンライン中にサポート リクエストが届いた場合、別のリクエストには所有者がいない間、2 人が同時に返信できます。ルーティング ルールにより、各リクエストが 1 つのチャネルと 1 人のユーザーに割り当てられるため、チームは次のステップの所有者を確認できます。ルールを 1 つ作成して、独自の受信トレイでワークフローをテストします。
ストーリーには、顧客のコンテキスト、摩擦、製品のメカニズム、観察可能な変化した状態、および次のアクションが含まれます。架空の創設者、悪役、映画のような言語は必要ありません。
よく練られた製品ストーリーに関する ProductPlan のガイダンスでは、ユーザーが主人公 という同じ中心的な選択が行われます。 Product Marketing Alliance も同様に、ストーリーテリングを事実と物語の組み合わせとして定義し、よく知られたストーリー構造を製品マーケティングに適応させます。有益な原則は、すべての製品に英雄の旅が必要であるということではありません。それは、聴衆の変化によってメッセージが整理されるはずだということです。
02
製品のストーリーテリングとブランドのストーリーテリング
製品のストーリーテリングとブランドのストーリーテリングは相互にサポートし合うことができますが、答えられる質問は異なります。
| フォーマット | 主な質問 | 典型的な証拠 | 最適な使用法 |
|---|---|---|---|
| 製品のストーリーテリング | この製品は特定の状況をどのように変えるのでしょうか？ | 製品画面、ワークフロー、デモンストレーション、仕様書、または承認結果 | 製品ページ、発売、セールスデッキ、デモ、説明ビデオ |
| ブランドのストーリーテリング | なぜこの会社が存在し、何を代表することを選んだのでしょうか？ | 起源の事実、会社の決定、人材、プロセス、または会社のマイルストーン | ページ、ブランドフィルム、採用情報、企業キャンペーンについて |
| 製品説明 | 何が含まれていますか？ | 属性、寸法、互換性、価格、またはパッケージの内容 | カタログ、eコマース出品、調達 |
| 製品デモ | 製品がメカニズムを実行するのを見ることはできますか？ | ライブまたは記録された製品の動作 | 評価、オンボーディング、販売証明 |
| ユーザーストーリー | 製品チームはユーザーのために何を構築すべきでしょうか？ | 要件、受け入れ基準、および製品のコンテキスト | 製品開発 |
ブランド ストーリーは、企業が包装廃棄物の削減を選択した理由を説明する可能性があります。製品ストーリーでは、特定のパッケージで何が変更されたのか、それが購入者の使用または廃棄にどのような影響を与えるのか、その主張を裏付ける証拠は何かを示す必要があります。 1つ目は、会社全体に意味を構築することです。 2 つ目は、誰かが製品を評価するのに役立ちます。
永遠に 1 つを選択する必要はありません。現在のページ、プレゼンテーション、またはビデオがどのジョブを完了する必要があるかを知っておく必要があります。製品ページのほとんどのスペースが創設者の子供時代に費やされている場合、購入者は製品を理解できないまま離れてしまう可能性があります。
03
5 ビートの製品ストーリーテリング フレームワークを使用する
以下のフレームワークは、ホームページのセクション、発売メッセージ、セールスナラティブ、または短い製品説明に機能します。各ビートに 1 つの仕事を与えます。
1. コンテキスト： 顧客の名前とトリガーを指定します。
製品が関連性を持つ瞬間から始めましょう。役割だけでは範囲が広すぎます。 「サポートチーム向け」には誰が、いつ、なぜということは書かれていません。
より強力なコンテキスト：
> 複数のチームメイトが同じ受信トレイでアクティブなときに、新しいサポート リクエストが届きます。
きっかけが物語を具体化します。後で見せるシーンも与えてくれます。別の製品の場合、トリガーとなるのは、新しい SKU の公開、財務チームの月末締め、または顧客が初めて機能を試す場合です。
2. 摩擦： 現在の回避策と結果を表示します。
お客様が現在何をしているのか、どこで問題が発生しているのかを説明します。 「仕事の効率が悪い」などの広範な苦痛表現は避けてください。目に見える結果に名前を付けます。
> チームメイトは受信箱をチェックし、お互いにメッセージを送り合い、別のリクエストが割り当てられていない間も重複した返信を返します。
これは感情をエスカレートさせるよりも効果的です。読者はワークフローを認識し、それが自分の経験と一致するかどうかを判断できます。
3.変更：製品の仕組みを説明する
メカニズムがストーリーに登場するときに製品を紹介します。実際の動作を説明する動詞 (ルート、比較、割り当て、ハイライト、変換、ロック、エクスポート) を使用します。
> ルーティング ルールは、各リクエストを正しいチャネルに送信し、誰かが応答する前に 1 人の所有者を割り当てます。
「サポートを楽にする」は仕組みではありません。購入者に、製品がどのように作成されるかを理解せずに結論を受け入れるように求めます。
4. 証明： 最初の状況に戻る
新しいプロセスで同じトリガーを表示します。証拠は、別の利点を導入するものではなく、問題の解決につながるはずです。
> 次のリクエストは 1 回表示され、正しい所有者に到達し、調整された 1 つの応答を受け取ります。
最も強力な証拠は、承認された画面、ライブアクション、文書化された比較、またはサポートされた顧客の結果など、観察可能です。結果データがない場合は、パーセンテージを考える代わりに、メカニズムと変化した状態を示します。
5. アクション： ストーリーを 1 ステップ続けます
読者が現在理解している内容に合った次のアクションを選択してください。
> 最初のルーティング ルールを作成します。
「今すぐサポートを変革する」というのは曖昧です。 「最初のルーティング ルールを作成する」により、購入者はストーリーで説明した正確なメカニズムをテストできます。
完全なフレームワークは次のとおりです。
| ビート | 質問 | 出力 |
|---|---|---|
| コンテキスト | いつニーズが現れるのでしょうか？ | 1 人の顧客、役割、トリガー |
| 摩擦 | 現在のプロセスでは何が起こるでしょうか？ | 1 つの回避策と目に見える結果 |
| 変更 | 製品は実際に何をするのでしょうか？ | 観察可能なメカニズムの 1 つ |
| 証明 | 同じ条件で何が違うのでしょうか？ | 1 つのサポートまたは実証可能な変更された状態 |
| アクション | 購入者は次に何をすべきでしょうか？ | 具体的な一歩 |
事例： 目に見えるノイズを意味のある変化に変える
TapVid の内部ケース Follow Builders: Where It All Began により、変更が到着する前にフリクション ビートが可視化されます。選択された 10 秒の抜粋は、誇張された情報ノイズから始まり、ストーリーの有用なシグナルに向かって進みます。このビデオが機能の一覧から始まっていないため、このコントラストが機能します。視聴者が認識できる状態を提供し、遷移を獲得します。
TapVid ケースを開く または 生成されたビデオを開く。
04
製品の特徴を信頼できるストーリーに変える
特徴を状況に関連付けて、それによって何が変わるかを示すことができれば、その特徴はストーリーに属します。このチェーンを使用します。
特徴→メカニズム→目に見える効果→証拠→境界
明確な制限により主張の信頼性が高まることが多いため、境界は重要です。それは、その機能がすべてを解決するということを暗示することなく、その機能が何をするのかを購入者に伝えます。
以下は架空の共有受信トレイの例です。
| 生の特徴 | 仕組み | 目に見える効果 | 示す証拠 | 境界線 |
|---|---|---|---|---|
| ルーティングルール | リクエスト条件をチャネルおよび所有者と照合する | 1 つのリクエストは 1 つの定義されたパスに従います | ルールの設定とその結果の割り当て | 応答品質を保証するものではありません |
| 共有ステータス | 同じ所有者と状態をチームメイトに表示する | 受信箱内の所有権に関する質問が少なくなる | 同じ状態を示す 2 つのユーザー ビュー | 共有ワークフローを使用するチームメイトに依存します |
| テンプレート | 承認された応答テキストを挿入する | 繰り返しの回答は同じ言葉遣いから始まる | テンプレートと挿入されたドラフトを並べて表示 | 人間が返信を確認する必要がある場合があります |
| アクティビティログ | 所有者とステータスの変更を記録する | チームメイトは何が変わったかを追跡できます | タイムスタンプ付きアクティビティパネル | すべての決定の背後にある理由ではなく、行動を記録します |
あまり宣伝的になることなく、ストーリーがより具体的になっていることに注目してください。製品には能力があるかもしれませんが、それでも限界があります。
同じチェーンを使用して弱いコピーを修復できます。
- 弱者： 「インテリジェントな自動化で作業を高速化します。」
- より良い方法： 「ルーティング ルールは、チームメイトが応答する前に、新しいリクエストをそれぞれチャネルと所有者に割り当てます。」
- より強力な証拠： 「請求リクエストが請求チャネルに移動し、指定された所有者が 1 名表示されるのを確認してください。」
最終バージョンでは、ページまたはビデオに視覚的なタスクが与えられます。見せたり、確認したり、議論したりすることができます。
05
完全な製品ストーリーテリングの例
小規模の SaaS チームが共有サポート受信トレイのルーティング ルールを起動すると仮定します。次の例では、同じファクトを 3 つの形式で使用しています。会社と製品は架空のものであるため、コピーは実際のパフォーマンスを主張するものではなく、構造を示しています。
ホームページ版
見出し： 1 つのリクエスト、1 つの所有者、1 つの明確な次のステップ
本文： 複数のチームメイトが同じサポート受信トレイで作業している場合、重複した返信や割り当てられていないリクエストは見落とされやすくなります。 RelayBox ルーティング ルールは、各リクエストを適切なチャネルに送信し、誰かが応答する前に 1 人の所有者を割り当てます。次のリクエストが到着から応答までの明確なパスをたどることを確認します。
CTA: 最初のルールを作成する
ホームページ版は5拍子を圧縮しています。馴染みのあるトリガーとの関連性を獲得し、メカニズムに名前を付け、購入者にテスト可能な次のアクションを提供します。
セールスデッキバージョン
- コンテキスト： 請求リクエストが到着すると、3 人のサポート チームメイトがアクティブになります。
- 摩擦： 2 人が返信を開始しますが、2 番目のリクエストには所有者がありません。
- 変更： 課金ルールは、最初のリクエストを課金チャネルに送信し、Maya を割り当てます。
- 証拠： すべてのチームメイトには、同じ所有者、ステータス、会話が表示されます。
- アクション： プロスペクトのリクエスト カテゴリを使用して 1 つのルールを構成します。
販売バージョンでは、ビートごとに一時停止して質問を促すことができます。製品の専門家は、洗練された主張に頼るのではなく、ルールと割り当てを示すことができます。
ショートビデオバージョン
| 時間 | ナレーション | ビジュアル系の仕事 |
|---|---|---|
| 0～5秒 | 2 人のチームメイトが同じリクエストに答えます。別のリクエストには所有者がありません。 | 1 つのリクエストが 2 つの応答に分割されて表示され、割り当てられていないリクエストを分離します |
| 5～12秒 | ルーティング ルールは、各リクエストを適切なチャネルに送信し、1 人の所有者を割り当てます。 | リクエストのタイプ、チャネル、所有者を接続する可視ルールを表示します |
| 12～20秒 | これで、すべてのチームメイトに同じ所有者、ステータス、次のステップが表示されます。 | 2 つのチームメイト ビューにわたる共有状態を表示する |
| 20～25秒 | 最初のルーティング ルールを作成します。 | ルールアクションとCTAを読める程度の長さにしてください |
ビデオ版では新たな申し立ては追加されません。それは同じ因果関係の連鎖に動きを与えます。タイミング列とソース列を備えた本番環境に対応した構造については、説明ビデオ スクリプト ガイド を使用してください。
06
ストーリー言語と製品の真実を分離する
ストーリーテリングは事実に順序と意味を与えます。事実をでっち上げることを許可するものではありません。
米連邦取引委員会は、広告主は客観的な主張を広める前に、その合理的な根拠が必要だと述べている。その 広告実証ポリシー は、明示的および黙示的な主張に適用されます。実用的なコンテンツをレビューするには、すべての重要な行を次の 4 つのレベルのいずれかに配置します。
| レベル | 意味 | 例 | 決定 |
|---|---|---|---|
| 正確な | 文言やデータは文字通りのままでなければなりません | 製品名、価格、型式、法定ライン、インターフェイスラベル | ロックしてください |
| サポートされています | 出典は意味を証明していますが、表現は変更される可能性があります | ルールは構成された条件に基づいてリクエストを割り当てます | 慎重に言い換える |
| 野心的な | 望ましい未来を目標として明確に提示する | より穏やかなサポートプロセスを構築する | 願望としてラベルを付ける |
| サポートされていません | 明示的または黙示的な主張を裏付ける情報源はありません | もう顧客のリクエストを見逃すことはありません | 証拠の削除または取得 |
このレビューは、発明された特異性を捉えています。 「チームの時間のロス」がそのまま「チームの 1 日 3 時間のロス」になることはあり得ません。 「オーナーを一人にする」では「ミスをなくす」ことはできません。正確な主張は物語ではより良く聞こえるかもしれませんが、正確であるほど証拠の必要性が高まります。
同じようにビジュアルを確認します。画像は、スクリプトでは決して述べられていない顧客、場所、製品の機能、または結果を暗示することがあります。ネット ストーリーは、言葉、画像、シーケンス、コンテキストの組み合わせから生まれます。
07
1 つの製品ストーリーをチャネル全体に適応させる
中心となる因果関係の連鎖は安定している必要がありますが、コンテキストと証拠の量はチャネルごとに変化します。
| チャンネル | キープする | 展開する | 削除 |
|---|---|---|---|
| 商品ページ | トリガー、メカニズム、目に見える証拠、CTA | 画面、仕様、異議、境界 | 長い会社の歴史 |
| ローンチポスト | 新しいトリガー、変更されたメカニズム、即時証明 | 以前のワークフローから変わった点 | 無関係なロードマップ項目 |
| セールスデッキ | 顧客固有の摩擦と証明 | 質問、比較、実装コンテキスト | 一般的なブランドの形容詞 |
| 製品デモ | 仕組みと変化した状態 | ライブ動作、エッジケース、セットアップ | 画面がサポートできないという主張 |
| 製品ビデオ | 1 つの因果チェーンと 1 つの CTA | 視覚的な対応、ペース調整、承認されたアセット | 高密度の機能インベントリ |
チャネルごとに異なる文字に書き換えないでください。 Web サイトではこの機能が「所有者を割り当てる」と書かれている一方、ビデオでは「サポートが自動的に実行される」と書かれている場合、話はメカニズムを超えて広がっています。
チャンネル アセットを作成する前にショート ストーリー ソースを作成します。
- 顧客とトリガー
- 現在の回避策と結果
- 製品の仕組み
- 承認された証拠
- 正確な文字列とアセット
- 境界と除外
- 次のアクション
このソースは 1 ページにすることができます。その目的は、すべてのバージョンを認識可能かつレビュー可能に保つことです。
08
製品を変更せずにビデオで製品ストーリーテリングを使用する
ビデオは、メカニズムが段落としてよりもシーケンスとして理解しやすい場合に役立ちます。リスクは、制作時に製品、言葉遣い、またはそれらの間の関係を変更することで、視覚的なドラマが追加されることです。
製品ストーリーのビデオを 3 つのパスで確認します。
- 資産の忠実度： 製品画像、ロゴ、UI、パッケージ、または映像は承認されたソースと一致していますか？
- 情報の忠実性： 名前、ラベル、番号、仕様、価格、および法的文言は正確のままですか？
- 対応： ナレーションが製品 A または機能 A について説明している場合、フレームには正しい製品、機能、および証拠が示されていますか？
TapVid は、この製品説明ジョブ用に構築された説明ビデオ エンジンです。提供された製品アセットと承認されたスクリプトをビデオに変換し、ソース素材をレビューに利用できるようにします。実際に約束されているのは、ストーリーテリングが自動的に行われるということではありません。価値があるのは、実際のアセットと選択した文言が、再描画されたり書き換えられるのではなく、ビデオの事実の背骨として残ることができることです。
ケース： 結果にスキップする代わりにメカニズムを表示する
内部の TapVid Launch Film ケースは、ソース アーティファクトをストーリーの背骨に変えます。選択された抜粋では、README から起動ビデオへの移行の一部が示されているため、視聴者は説明のない変換を受け入れるように求められる代わりに、入力、製品のアクション、出力を見ることができます。
TapVid ケースを開く または 生成されたビデオを開く。
ソース パケットとスクリプトがすでにある場合は、製品デモ ビデオ ワークフロー で、それらの素材がどのようにレビュー可能なビデオになるかを示します。納品前に最終的な成果物を確認してください。正しいスクリプトは、すべてのフレームが正しいことを証明するものではありません。
09
製品ストーリーテリングでよくある間違い
製品を主人公にする
買い手は自分の仕事、リスク、目標、アイデンティティを重視します。拍手を受けるキャラクターではなく、顧客の移動を助ける仕組みとして商品を提示する。
機能インベントリで開く
機能リストを使用すると、リーダーは機能から値への変換を実行できます。 1 つのトリガーから始めて、それを変更する機能を接続します。
メカニズムをスキップする
問題から結果に直接移行すると、説明のない約束が生まれます。このメカニズムによって理解と信頼が構築されます。
証拠の代わりに感情を使用する
感情は、顧客が矛盾した返答を受け取るなど、認識可能な結果から生じることがあります。裏付けのない緊急性、恐怖、劇的な統計は必要ありません。
複数のストーリーを一度に語る
1 つのメッセージでは、リリース、会社の使命、すべての機能セット、すべての対象者、すべての CTA を説明することはできません。顧客を 1 つ、トリガーを 1 つ、変更された状態を 1 つ選択します。
各チャネルに新しい主張を生み出せるようにする
長さと形式を調整しますが、因果関係の連鎖と事実の境界を安定させます。同じソースに対してページ、デッキ、デモ、ビデオを確認します。
10
製品ストーリーテリング テンプレート
最終コピーを作成する前に、この概要をコピーしてください。
> 顧客： [1 つの役割またはユーザー]>> トリガー: [製品が関連性を持つようになった瞬間]>> 現在のプロセス： [お客様が現在行っていること]>> 目に見える摩擦： [問題が発生したり、困難になったりすること]>> 製品の仕組み： [製品の実際の動作]>> 証明： [画面、アクション、仕様、比較、またはサポートされた結果]>> 境界： [製品が解決すると主張していないもの]>> 次のアクション： [1 つの具体的なステップ]>> 正確な文字列とアセット： [名前、番号、ラベル、法的コピー、ロゴ、製品画像]
次に、5 つの質問でドラフトをテストします。
- 読者は冒頭の状況を認識できるだろうか？
- 製品は観察可能なアクションを実行しますか？
- この証明は、最初に導入したのと同じ問題を解決しますか？
- すべての客観的な主張の出典を追跡できるでしょうか？
- CTA は購入者にメカニズムをテストまたは継続させますか？
5 つの答えがすべて明らかであれば、物語を適応させる準備ができています。仕組みや証明があいまいな場合、形容詞を増やしても修復できません。
11
よくある質問
製品ストーリーテリングを一言で表すと何でしょうか？
製品ストーリーテリングでは、実際の製品が、コンテキスト、摩擦、メカニズム、証拠、アクションの明確なシーケンスを通じて、特定の顧客の状況をどのように変化させるかを説明します。
製品ストーリーの主人公は誰になるべきでしょうか？
お客様が主役であるべきです。製品は、顧客が現在の状況からより良い、観察可能な状態に移行するのに役立つツールまたはメカニズムです。
製品のストーリーテリングはブランドのストーリーテリングとどう違うのでしょうか？
製品ストーリーテリングは、特定の製品が顧客の状況をどのように変えるかを説明します。ブランドのストーリーテリングは、企業が存在する理由、企業が何を信じているのか、またはどのような選択が企業を定義するのかを説明します。製品ストーリーには製品レベルのメカニズムと証明が必要です。
すべての製品ストーリーには感情的なストーリーが必要ですか？
いいえ、関連性と結果が必要です。感情は、イライラする瞬間や貴重な瞬間を認識することで生まれることがあります。テクニカルバイヤーは、劇的な物語よりも、明確なリスク、コントロール、証拠に強く反応する可能性があります。
AI は製品ストーリーを書くことができるでしょうか？
AI は、承認された事実を整理し、バリエーションを生成し、ストーリーをさまざまな形式に適応させるのに役立ちます。製品所有者は、機能、主張、資産、正確な文言、および最終成果物を検証する必要があります。より完全なコピーのように聞こえるようにするために、モデルに顧客の結果や製品の動作をでっち上げさせないでください。
製品ストーリーはどれくらいの長さが必要ですか？
チャンネルに必要な 5 ビートを保持する最も短いバージョンを使用します。ホームページ ブロックには、見出し、2 つの文、および CTA が必要な場合があります。セールス ナラティブやビデオでは、メカニズム、証拠、境界、質問にさらに時間がかかる場合があります。長さは購入者が決定する必要があります。
