题目与范围
Working Backwards 从客户体验和问题开始，再反推产品方案。PR/FAQ 用面向客户的新闻稿描述核心价值，用 FAQ 暴露客户和内部利益相关者会追问的细节。题目考察机会验证、范围控制、指标和跨团队对齐，分类为 product。它不是要求套用固定模板，也不能把一份文案当成需求已经被验证。
面试官考察点
应先定义目标客户和痛点，再把承诺写成可证伪的价值主张。回答要覆盖采用条件、数据与隐私、成本、支持、失败模式、成功指标和停止条件。还要说明如何用客户访谈、原型或小规模试点验证 FAQ，而不是闭门制作漂亮文档。
先澄清的问题
- 目标客户是谁，他们现在怎样完成数据导出？
- 最昂贵或最危险的痛点是等待时间、格式兼容、权限还是合规？
- 哪些数据可以导出，谁有权发起、审批和撤销？
- 客户愿意为哪项结果付费，现有替代方案是什么？
- 预期采用量、SLA、存储和支持成本是多少？
- 哪个假设若被证伪，应立即停止项目？
30 秒答题框架
“先限定客户和问题，再写一段只描述客户结果的 PR。把 FAQ 分成价值、使用流程、边界、隐私、安全、定价和运营，并为每个关键假设指定证据。用访谈和可点击原型验证最难的问题，定义采用率、完成率、失败率、支持工单和成本上限；证据不足时缩小范围或停止，而不是直接承诺完整平台。”
分步作答
步骤 1：定义客户与问题
选一个具体角色和场景，例如管理员在合同终止前需要把租户数据迁移到新系统。记录当前流程、耗时、错误和合规约束，避免把“所有企业都需要”当作问题定义。
步骤 2：写客户语言的 PR
标题和首段只承诺客户获得的结果，例如在权限可审计的前提下完成一次可恢复导出。不要写内部架构、技术名词或夸大的“行业首创”，也不要在没有证据时承诺百分之百成功。
步骤 3：用 FAQ 暴露约束
FAQ 应回答数据范围、格式、保留期、权限、审批、取消、重试、通知、价格、SLA、支持和责任边界。每个答案标记已知事实、待验证假设或明确不支持的场景，并将高风险问题排在前面。
步骤 4：设计证据与试点
访谈不同规模客户，观察他们完成一次真实迁移；用原型验证授权、进度和失败恢复。试点只开放有限数据类型和租户，记录完成率、重复尝试、人工介入、支持工单及每次导出的基础设施成本。
步骤 5：设定决策门槛
在文档中写出继续、缩小或停止的条件。例如，若目标客户无法在不增加人工审批的情况下完成导出，或单位导出成本超过预算，则先改范围。评审后把 FAQ 的变化映射到路线图、运营手册和后续实验。
参考答案
“我会先选定一个有明确迁移任务的企业管理员，量化现有流程的时间、错误和合规风险，再写一段客户能理解的 PR。FAQ 逐项回答权限、格式、恢复、保留期、SLA、定价和支持，并把未知项变成可验证假设。通过客户访谈、原型和受限试点收集完成率、失败率、人工介入、工单及单位成本。只有达到预设门槛才扩大范围，否则缩小承诺或停止；PR/FAQ 会随证据迭代，而不是一次性批准完整平台。”
常见错误
- 先写技术架构 → 客户价值和问题仍模糊 → 先写可证伪的客户结果。
- 把 FAQ 写成营销文案 → 风险、边界和成本被隐藏 → 优先回答最难的反对问题。
- 默认所有客户同样需要 → 试点信号不可解释 → 限定角色、场景和替代方案。
- 只看采用率 → 人工介入和支持成本被遗漏 → 同时跟踪完成、失败、工单和单位成本。
- 没有停止条件 → 试点会自动膨胀 → 预先写出继续、缩小、停止门槛。
- 文档定稿后不更新 → 决策与证据脱节 → 让 FAQ 版本进入评审和路线图流程。
追问
追问 1：PR 和需求文档有什么区别？
PR 先说明客户得到的结果和价值，FAQ 说明客户及内部会追问的细节；需求文档才进一步定义实现范围。PR/FAQ 用来验证机会和对齐，不代表实现已经获批。
追问 2：怎样避免挑选支持结论的客户？
按预先定义的角色、规模和现有方案抽样，记录拒绝和无法完成的案例。访谈脚本同时询问替代方案、付费意愿和停止理由，并把反例写进 FAQ。
追问 3：什么时候应该停止？
当核心痛点不够强、授权或合规无法满足、试点完成率低于门槛，或单位成本持续超预算时停止或缩小。停止条件应在试点前写下，避免事后改变标准。
追问 4：如何把文档连接到路线图？
将每个 FAQ 假设映射到一个验证任务、负责人和截止日期；已验证的承诺进入版本范围，未验证或失败的承诺保留为风险，不直接排入开发。