產品講故事：帶有範例的實用指南

01

什麼是產品故事？

產品故事敘述結合了事實和敘述來傳達產品如何改變客戶的處境。事實是產品的真實功能、限制、螢幕、資產和證據。敘述以買家可以遵循的因果順序將這些事實連結起來。

一個簡單的產品故事聽起來像這樣：

> 當多個隊友在線上時收到支援請求時，兩個人可以同時回复，而另一個請求則沒有所有者。路由規則將每個請求分配給一個通道和一個人，以便團隊可以看到誰負責下一步。建立一項規則以使用您自己的收件匣測試工作流程。

這個故事有客戶背景、摩擦、產品機制、可觀察的變化狀態和下一步。它不需要虛構的創始人、惡棍或電影語言。

ProductPlan 對精心製作的產品故事的指導做出了相同的中心選擇：使用者是英雄。產品行銷聯盟同樣將說故事定義為事實和敘述的結合，然後將熟悉的故事結構應用於產品行銷。有用的原則不是每個產品都需要英雄的旅程。應該根據受眾的變化來組織訊息。

02

產品故事與品牌故事

產品故事和品牌故事可以互相支持，但它們回答不同的問題。

品牌故事可以解釋為什麼公司選擇減少包裝浪費。產品故事應顯示特定包裝中的變化、變化如何影響購買者的使用或處置，以及支持該主張的證據。第一個是圍繞公司建構意義。第二個幫助某人評估產品。

您不必永遠選擇其中之一。您確實需要知道目前頁面、簡報或影片必須完成哪些作業。如果產品頁面的大部分空間都花在創辦人的童年上，買家仍然可能在不了解產品的情況下離開。

03

使用五拍產品說故事框架

下面的框架適用於主頁部分、啟動訊息、銷售敘述或簡短的產品說明。給每個節拍一份工作。

Inspect image

1. 情境：命名客戶並觸發

從產品變得相關的那一刻開始。單獨一個角色就太廣泛了。 「對於支援團隊」說的是誰，但沒有說何時或為什麼。

更強的背景：

> 當多個隊友在同一收件匣中處於活動狀態時，收到新的支援請求。

觸發器使故事變得具體。它還為您提供了稍後展示的場景。對於不同的產品，觸發因素可能是新的 SKU 上線、財務團隊結束月份或客戶首次嘗試某項功能。

2.摩擦：顯示目前的解決方法和後果

描述客戶現在做了什麼以及哪裡出了問題。避免使用寬泛的痛苦語言，例如「工作效率低」。說出可見的後果。

> 團隊成員檢查收件匣、互相傳送訊息，並且在另一個請求仍未分配時仍然會產生重複的回應。

這比讓情緒升級更有用。讀者可以辨識該工作流程並判斷它是否符合自己的經驗。

3.變更：解釋產品機制

當機制進入故事時介紹產品。使用描述真實行為的動詞：路由、比較、分配、反白、轉換、鎖定或導出。

> 路由規則將每個請求發送到正確的頻道，並在任何人回覆之前分配一個所有者。

「讓支援變得毫不費力」不是一種機制。它要求買家在不了解產品如何得出結論的情況下接受結論。

4.證明：回到開局狀況

在新流程下顯示相同的觸發器。證明應該解決開局問題，而不是引入不同的好處。

> 下一個請求出現一次，到達正確的所有者，並收到一個協調回應。

最有力的證據是可觀察到的：經過批准的螢幕、實際操作、記錄的比較或支持的客戶結果。如果您沒有結果數據，請示範機制和變更的狀態，而不是發明百分比。

5.動作：將故事繼續一步

選擇符合讀者現在理解的下一步。

> 建立您的第一個路由規則。

「今天就轉變你的支持」是模糊的。 「創建您的第一個路由規則」讓買家測試剛剛解釋的故事的確切機制。

完整的框架是：

案例：將可見的雜訊轉化為有意義的改變

內部 TapVid 案例 專注於建造者：一切開始的地方 讓摩擦在變化到來之前就可見。選定的 10 秒摘錄以誇張的訊息噪音開始，然後轉向故事的有用信號。這種對比之所以有效，是因為影片並不是以功能清單開始的。它給觀眾一種他們可以識別的狀態，然後贏得過渡。

Inspect image

開啟TapVid案例或開啟產生的影片。

04

將產品功能變成可信的故事

當您可以將某個功能與某個情況連結並顯示它的變化時，該功能就屬於故事。使用這個鏈：

特徵→機制→可見效果→證據→邊界

界線很重要，因為明確的界線通常會使主張更可信。它告訴買家該功能的用途，但並不意味著它可以解決周圍的所有問題。

這是一個虛構的共享收件匣範例：

請注意故事如何變得更加具體而不變得更具宣傳性。產品可以有能力，但仍有邊界。

您可以使用相同的鏈來修復弱副本：

• 弱點：“透過智慧自動化更快地工作。”
• 更好：“路由規則在隊友回復之前將每個新請求分配給頻道和所有者。”
• 更有說服力的證據：“觀察計費請求移動到計費管道並與指定所有者一起出現。”

最終版本為頁面或影片提供了視覺任務。它可以被展示、檢查和討論。

05

一個完整的產品講故事範例

假設一個小型 SaaS 團隊正在為共用支援收件匣啟動路由規則。以下範例以三種格式使用相同的事實。該公司和產品都是虛構的，因此文案展示的是結構而不是真實的性能聲明。

首頁版本

標題： 一個請求，一個擁有者，一個明確的下一步

正文： 當多個團隊成員在同一個支援收件匣中工作時，很容易錯過重複的回覆和未分配的請求。 RelayBox 路由規則將每個請求傳送到正確的通道，並在任何人回覆之前分配一個擁有者。查看下一個請求遵循從到達到回應的清晰路徑。

CTA： 建立您的第一條規則

首頁版本壓縮了五拍。它透過熟悉的觸發器獲得相關性，命名機制，並為買家提供可測試的下一步。

销售平台版本

• 上下文： 當計費請求到達時，三名支援團隊成員處於活動狀態。
• 摩擦： 兩個人開始回复，而第二個請求沒有所有者。
• 變更： 計費規則將第一個請求傳送到計費通道並指派 Maya。
• 證明： 每個隊友都看到相同的擁有者、狀態和對話。
• 操作： 使用潛在客戶的請求類別設定一條規則。

銷售版本可以在每個節拍暫停並邀請提問。產品專家可以展示規則和任務，而不是依賴完美的聲明。

短视频版

視訊版本沒有添加新的聲明。它為同一個因果鏈帶來運動。對於包含時間和來源列的生產就緒結構，請使用解釋視訊腳本指南。

06

將故事語言與產品真相分開

說故事賦予事實順序和意義。它不允許發明事實。

Inspect image

美國聯邦貿易委員會表示，廣告商在傳播客觀主張前需要有合理的依據。其廣告證實政策 適用於明示和暗示的聲明。對於工作內容審查，請將每個重要的行放在四個層級之一：

這篇評論抓住了發明的特殊性。 「團隊損失時間」不能悄悄變成「團隊每天損失三小時」。 「指定一個所有者」不能成為「消除錯誤」。精確的主張在故事中可能聽起來更好，但精確性增加了對證據的需求。

以同樣的方式查看視覺效果。圖像可以暗示腳本從未提及的客戶、位置、產品功能或結果。網路故事由文字、圖像、序列和上下文共同構成。

07

跨通路改編一個產品故事

核心因果鏈應該保持穩定，而上下文和證據的數量會因管道而改變。

不要為每個管道將產品重寫為不同的字元。如果網站說該功能“指定所有者”，而影片說它“自動運行支援”，那麼故事就已經超出了該機制。

在製作頻道資產之前創建短篇故事來源：

• 客戶和觸發器
• 目前的解決方法和後果
• 產品機理
• 批准證明
• 精確的字串和資產
• 界限和排除
• 下一步行動

該來源可以是一頁。其目的是使每個版本都可識別和可審查。

08

在影片中使用產品講故事而不改變產品

當機製作為序列比作為段落更容易理解時，影片就很有用。風險在於製作透過改變產品、措辭或它們之間的關係來增加視覺戲劇性。

分三次查看產品故事影片：

• 資產保真度： 產品影像、標誌、UI、包裝或鏡頭是否與核准的來源相符？
• 資訊保真度： 名稱、標籤、數字、規格、價格和法律措詞是否準確？
• 對應： 當敘述討論產品 A 或特徵 A 時，框架是否顯示了正確的產品、特徵和證明？

TapVid 是專為產品解釋工作而建構的解釋視訊引擎。它將提供的產品資產和批准的腳本轉換為視頻，同時保持源材料可供審查。實際的承諾並不是講故事變得自動。其價值在於，您的真實資產和所選措辭可以保留影片的事實主幹，而不是被重新繪製或重寫。

案例：展示機製而不是跳到結果

內部 TapVid Launch Film 案例將原始工件轉變為故事的主幹。其選定的摘錄顯示了自述文件到發布影片過渡的一部分，因此觀眾可以看到輸入、產品操作和輸出，而不是被要求接受無法解釋的轉換。

Inspect image

開啟TapVid案例或開啟產生的影片。

如果您已經擁有來源資料包和腳本，產品示範影片工作流程 展示如何將這些資料變成可審查的影片。交貨前檢查最終工件。正確的腳本並不能證明每一幀都是正確的。

09

常見的產品說故事錯誤

讓產品成為英雄

買家關心他們的工作、風險、目標和身分。將產品呈現為幫助顧客移動的機制，而不是接受掌聲的角色。

以功能清單開頭

功能清單使讀者能夠進行從功能到價值的轉換。從一個觸發器開始，然後連接改變它的功能。

跳躍機制

直接從問題轉向結果會產生無需解釋的承諾。此機制是建立理解和可信度的地方。

用情感代替證據

情緒可能來自可識別的結果，例如客戶收到相互矛盾的答案。它不需要毫無根據的緊迫感、恐懼或戲劇性的統計數據。

同時講幾個故事

一則訊息無法解釋發布、公司使命、完整的功能集、每一位受眾和每一個 CTA。選擇一位客戶、一種觸發器和一種更改狀態。

讓每個管道發明一個新的主張

調整長度和格式，但保持因果鍊和事實邊界穩定。根據同一來源查看頁面、簡報、簡報和影片。

10

產品說故事模板

在撰寫最終副本之前複製此摘要：

Inspect image

> 客戶： [一個角色或使用者]>> 觸發因素： [產品變得相關的那一刻]>> 目前流程： [客戶現在做什麼]>> 可見的摩擦： [出現問題或變得困難]>> 產品機制：【產品實際作用】>> 證明： [螢幕、操作、規範、比較或支援的結果]>> 邊界： [產品未聲稱解決的問題]>> 下一步行動： [一個具體步驟]>> 精確的字串和資產： [名稱、數字、標籤、合法副本、標誌、產品圖片]

然後用五個問題測試草稿：

• 讀者能認出開頭的情況嗎？
• 產品是否執行了可觀察到的操作？
• 該證明是否解決了開始時引入的相同問題？
• 每一個客觀主張都能追溯到源頭嗎？
• CTA 是否讓買方測試或繼續該機制？

如果所有五個答案都明確，那麼故事就可以改編了。如果機製或證據含糊不清，再多的形容詞也無法修復它。

11

常見問題