名称: 新闻稿描述: 按照亚马逊的“倒推工作法”创建一个愿景新闻稿，以在构建产品前定义和沟通产品或特性。使用这个来对齐利益相关者关于客户价值主张、澄清解决的问题，并测试产品故事是否引起共鸣——将新闻稿作为清晰度和以客户为中心的强制工具。这不是发布当天的营销工件——这是一个规划工具，询问“如果我们完美地发布了这个，我们如何向世界解释它？”

目的

按照亚马逊的“倒推工作法”创建一个愿景新闻稿，以在构建产品前定义和沟通产品或特性。使用这个来对齐利益相关者关于客户价值主张、澄清解决的问题，并测试产品故事是否引起共鸣——将新闻稿作为清晰度和以客户为中心的强制工具。这不是发布当天的营销工件——这是一个规划工具，询问“如果我们完美地发布了这个，我们如何向世界解释它？”

关键概念

亚马逊倒推工作法框架

由亚马逊推广的倒推工作法从新闻稿和常见问题开始，在任何代码编写之前。新闻稿必须：

从客户的角度撰写
专注于解决的问题，而不是构建的特性
简短（1-1.5页）
足够引人入胜，以至于客户会想要这个产品

新闻稿结构

标准新闻稿遵循以下格式：

标题： 清晰、以收益为中心的产品公告
日期线： 城市、州、日期
引言段落： 正在发布什么、为谁、关键收益
问题段落： 产品解决的客户问题
解决方案段落： 产品如何解决问题（关注结果，而非特性）
公司领导引语： 愿景、客户承诺
附加细节： 支持性收益或数据
公司简介： 公司背景
行动号召： 如何了解更多
媒体联系人： 新闻联系信息

为什么这有效

以客户为先的思维： 强制从客户角度阐明价值
清晰强制工具： 如果你不能写出引人入胜的新闻稿，产品想法可能薄弱
对齐工具： 利益相关者可以在工程开始前阅读和反应愿景
决策过滤器： 如果一个特性不会进入新闻稿，质疑其优先级

反模式（这不是什么）

不是特性中心： 不要列出规格——专注于客户结果
不是内部行话： 为客户撰写，而非工程师
不模糊： “革命化生产力”是空话；“将报告生成时间从8小时减少到10分钟”是真实的
不是营销炒作： 诚实地描述产品功能

何时使用这个

定义新产品或主要特性
在开发前对齐利益相关者关于愿景
测试产品想法是否引人入胜
向高管推销或获取支持

何时不使用这个

用于琐碎特性（不要过度设计小调整）
在已经构建产品后（太晚）
作为实际发布当天的新闻稿（这是规划文档，而非最终营销副本）

应用

使用 template.md 获取完整的填充结构。

步骤 1: 收集上下文

在起草前，确保你有：

产品/特性描述： 你在构建什么？
目标客户/人物角色： 这是为谁？（参考 skills/proto-persona/SKILL.md）
问题陈述： 解决什么客户问题？（参考 skills/problem-statement/SKILL.md）
关键收益： 提供什么结果？
竞争上下文： 这与替代方案有何不同？（参考 skills/positioning-statement/SKILL.md）
公司使命/价值观： 这如何符合公司愿景？

如果缺少上下文： 运行发现、定义问题陈述或先澄清定位。

步骤 2: 起草标题

创建清晰、以收益为中心的标题：

"[产品/特性名称] 由 [公司] 旨在 [主要收益/目标]"

质量检查：

以收益为中心： 是否说明客户获得什么，而不仅仅是你构建了什么？
具体： “旨在简化工作流” 模糊；“旨在将发票处理时间减少60%” 具体
易记： 有人能在对话中重复这个标题吗？

示例：

✅ “Acme Workflows 推出发票自动化，为小型企业减少处理时间60%”
❌ “Acme 推出具有AI特性的新产品”

步骤 3: 撰写日期线和引言

[城市], [州], [国家], [日期] —

今天，[公司]，一个 [组织类型]，宣布 [关键新闻]，一个 [简要描述]。这个 [产品/特性] 旨在 [主要收益]，解决 [关键客户问题]。

质量检查：

简洁： 最多2-3句话
提及客户问题： 不要直接跳到解决方案——先命名问题

步骤 4: 解释问题

[产品/特性] 解决 [特定客户问题]。根据 [来源或客户洞察]，[支持数据或引语验证问题]。

质量检查：

具体问题： 不是“低效”，而是“手动发票处理每月花费8小时”
已验证： 包括数据、客户引语或研究证明问题真实

步骤 5: 描述解决方案（以结果为中心）

[产品/特性] 通过 [如何解决问题——专注于结果] 来解决这个问题。 [公司领导引语]："[插入强调客户价值，而非特性的引语]。"

质量检查：

以结果为先： “减少处理时间” 而非 “包括OCR技术”
引语有远见： 应反映客户同理心和公司价值观

步骤 6: 添加支持细节

除了 [关键收益]，[产品/特性] 还 [附加收益]。根据 [统计或来源]，[支持数据]。

质量检查：

数据驱动： 尽可能使用数字（时间节省、成本减少等）
以客户为中心： 仍专注于“他们获得什么”，而非“我们构建了什么”

步骤 7: 包括公司简介

[公司]，成立于 [年份]，是一个 [公司类型]，以 [主要产品/服务] 闻名。专注于 [公司使命或价值观]，[公司] 已 [成就或里程碑]。

步骤 8: 添加行动号召和媒体联系人

有关 [产品/特性] 的更多信息，请访问 [网站] 或联系 [媒体联系人姓名] 于 [联系信息]。

**媒体联系人信息：**
[姓名]
职位: [职位]
电话: [电话]
电子邮件: [电子邮件]

步骤 9: 测试新闻稿

询问这些问题：

客户会在意吗？ 如果你把这个发送给目标客户，他们会想了解更多吗？
问题清晰吗？ 从未听过你产品的人能理解痛点吗？
收益可衡量吗？ 你能证明声称（时间节省、成本减少等）吗？
无行话吗？ 你妈妈能理解吗？
通过“那又怎样？”测试吗？ 如果有人读了这个说“那又怎样？”，你就没有阐明价值。

如果任何答案是“否”，修订。

示例

参见 examples/sample.md 获取完整新闻稿示例。

迷你示例摘录：

**标题：** “Acme 推出SmartInvoice以减少处理时间60%”
**问题：** 小型企业每月花费8小时手动处理发票
**解决方案：** 自动化提取和批准以节省时间

常见陷阱

陷阱 1: 特性列表而非收益

症状： “包括AI、ML、OCR、NLP和实时同步”

后果： 客户不关心特性——他们关心结果。

修复： 将特性翻译为收益： “AI驱动的自动化减少发票处理时间60%。”

陷阱 2: 模糊问题陈述

症状： “解决工作流中的低效”

后果： 没人在这问题中认出自己。

修复： 具体化： “小型企业主每月花费8小时手动输入发票数据。”

陷阱 3: 行话重的语言

症状： “利用尖端ML模型优化企业级工作流”

后果： 客户无法理解你在说什么。

修复： 像向朋友解释一样写： “自动处理发票，所以你不必。”

陷阱 4: 通用高管引语

症状： “我们很高兴将创新推向市场”

后果： 引语不增加价值。可适用于任何产品。

修复： 以客户为中心： “企业主不应花费周末处理发票——他们应花那时间与家人在一起。”

陷阱 5: 无数据或验证

症状： “客户会喜欢这个革命性新解决方案”

后果： 未经证实的主张 = 营销空话。

修复： 添加数据： “Beta用户平均每月节省5小时” 或 “68%的SMB将发票处理列为首要行政负担。”

参考

外部框架

亚马逊的倒推工作法 — 新闻稿优先方法论的起源
Ian McAllister在Quora上关于亚马逊新闻稿模板的答案（2012） — 广泛引用的解释
Colin Bryar & Bill Carr, Working Backwards（2021） — 关于亚马逊产品开发过程的书籍

迪恩的工作

愿景新闻稿提示（受亚马逊倒推工作法启发）

出处

改编自 prompts/visionary-press-release.md 在 https://github.com/deanpeters/product-manager-prompts 仓库中。

技能类型： 组件 建议文件名： press-release.md 建议位置： /skills/components/ 依赖项： 参考 skills/problem-statement/SKILL.md, skills/positioning-statement/SKILL.md, skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md

新闻稿撰写（倒推工作法）技能Skill press-release

目的

关键概念

亚马逊倒推工作法框架

新闻稿结构

为什么这有效

反模式（这不是什么）

何时使用这个

何时不使用这个

应用

步骤 1: 收集上下文

步骤 2: 起草标题

步骤 3: 撰写日期线和引言

步骤 4: 解释问题

步骤 5: 描述解决方案（以结果为中心）

步骤 6: 添加支持细节

步骤 7: 包括公司简介

步骤 8: 添加行动号召和媒体联系人

步骤 9: 测试新闻稿

示例

常见陷阱

陷阱 1: 特性列表而非收益

陷阱 2: 模糊问题陈述

陷阱 3: 行话重的语言

陷阱 4: 通用高管引语

陷阱 5: 无数据或验证

参考

相关技能

外部框架

迪恩的工作

出处