PR/FAQ 是亚马逊 Working Backwards(逆向工作法)的核心:在写第一行代码之前,先写一篇假想的新闻稿,宣布产品已经做成,再配一组 FAQ 反复拷问它。它逼团队从客户和结果出发,而不是从待办列表出发。方法本身是真的好——这不是问题所在。问题在于这份产物。PR/FAQ 是一份静态文档,定稿那天,就是它开始和你真正交付的产品脱节那天。这篇文章先教你把它写对,再讲清 Draftlize 如何让里面的决策——定价、范围、卖给谁——不悄悄变成空话。
PR/FAQ 分两半:一页假想新闻稿,描绘上线那天;一组 FAQ,把它逐条压力测试。在动工前写。如果你既写不出一篇打动人的新闻稿,又扛不住 FAQ 的拷问,说明这个想法还没成熟——你刚好省下一个季度。下面是每个部分到底装什么。
一篇简短、像真的一样的产品上线公告,日期写在上线那天。标题、副标题、用客户原话描述的痛点、你的解法、一句来自负责人的引言、一句来自满意客户的引言,以及怎么开始用。大白话,不堆术语——如果它打动不了一个陌生人,就打动不了市场。
先点客户和痛点,再讲产品。逆向工作法意味着这篇稿子读起来是客户拿到的结果,而不是你做了哪些功能。痛点不锋利,后面一切都白搭。
客户或记者会问的问题:这是什么、卖多少钱、和别家有什么不同、什么时候能用、我的数据安全吗。这些答案就是对外的决策——定价、定位、可用性——写到能直接公开发布的程度。
管理层会问的硬问题:为什么是我们、为什么是现在、这块蛋糕多大、可能出什么岔子、我们必须相信什么、我们坚决不做什么。范围、目标客户、那些有风险的假设,都在这里被钉死——它们是此后每一份 spec 的源头决策。
把整个计划赖以成立的信念明确写出来。「我们假设客户愿意按用量付费,而不是按席位。」把它们摆上台面正是这个练习的意义——每一条都是一个决策,你要么之后确认它,要么被迫回头重议。
刻意定下的非目标。亚马逊坚持要写这一条,因为范围是一个决策,而一个没写明的非目标,三个迭代后就会变成范围蔓延。这是一个团队是否真的「决定了」最清楚的信号。
方法讲完了。下面:为什么这份文档一定稿就开始漂移——以及我们怎么解决。
PR/FAQ 记录的是签字那天你相信的东西。但产品一直在动——定价调整、范围收窄、目标客户变清晰。文档不会跟着动。到上线时,新闻稿描述的是一个已经不存在的产品,FAQ 用上个季度的决策回答着今天的问题。
PR/FAQ 正是你拍定价、定范围、定「坚决不做什么」的地方。然后 PRD、各份 spec、工程工单全都默认了这些决策。可你之后改了定价决策,没有任何东西把它链回 PR/FAQ,也没链向那些依赖它的 spec——于是它们悄无声息地错了。
PR/FAQ 只在评审会上干了一次活,然后就归档了。它当初暴露的那些假设,本该随着你的认知更新被反复回看。可一份静态文档不是读者,它没法察觉自己记下的某个假设早已被证伪。于是漂移在无人盯防中越积越多。
在 Draftlize 里写新闻稿和 FAQ,里面那些承重的决策——定价、范围、目标客户、各条非目标、每个有风险的假设——都成为有类型的卡片:结构化、有 ID 可寻址、能被 PRD 引用,而不是埋在文档里。叙事仍是叙事,但决策有了脊梁。
改了定价决策,所有依赖它的卡片——那条外部 FAQ 答案、那段 PRD、那份默认按用量计费的 spec——都会自动变 stale,就像构建系统会让一个被改文件的所有下游失效一样。PR/FAQ 不再是一张快照,而是开始跟踪现实。
Claude Code 或 Cursor 通过 MCP,在起草 PRD 之前先读完新闻稿和内外部 FAQ,再把新决策按同样的结构写回去。你在前期做的逆向工作法思考,变成 agent 每一轮都遵守的活上下文——而不是一份读者永远不会再打开的文档。
逆向工作法是正确的思考方式。错在于:刚思考完,就把它冻进一份文档里。方法照旧。让 substrate 替你把决策保持最新。
按亚马逊的方式写出新闻稿和 FAQ,让 agent 把里面的决策变成卡片,再帮你把每一个决策——以及依赖它们的 PRD——随着认知更新保持最新。
注册送 $5,免费开始