产品讲故事：带有示例的实用指南

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

常见问题