大客户需求和定制边界
早期的一笔大订单可能明显影响收入，也可能要求产品进入专属流程。此时不适合简单地把需求归为「核心」或「不做」，还要区分产品能力和定制交付。
可以依次检查：
- 这项需求是否也会出现在其他相似客户中；
- 它是否加强现有主要任务；
- 实现后能否由标准产品维护；
- 是否需要专属数据、权限、部署或服务；
- 客户支付的价格能否覆盖开发和长期支持；
- 接受以后会不会影响其他用户的体验和路线图。
若需求只服务一个客户，可以单独报价为实施、集成或服务，并明确产权、维护期、变更和退出条件。若团队决定将它产品化，应当等待更多相似证据，不能让一笔收入悄悄改变全部用户的产品。
企业客户要求的权限、审计和合规有时属于进入该市场的基础条件，不能简单归入「特殊功能」。问题仍然回到产品选择：团队是否真正准备服务这类客户。若答案为否，承诺一个无法持续维护的企业版本会留下更大风险。
写一份功能决策记录
每个有争议的功能可以保留一页简短记录：
| 字段 | 记录内容 |
|---|---|
| 请求 | 用户原话和提出日期 |
| 用户与场景 | 哪类人在什么任务中遇到 |
| 当前替代 | 现在怎样绕过，成本是什么 |
| 主要结果 | 功能完成后改变什么 |
| 证据 | 访谈、使用、订单、支持或失败记录 |
| 影响范围 | 输入、流程、输出、权限、数据和渠道 |
| 实现与维护 | 开发、测试、依赖、客服和长期成本 |
| 当前状态 | 现在做／观察／暂缓／拒绝 |
| 决定理由 | 与核心用户和产品承诺的关系 |
| 重开条件 | 什么新证据出现时重新讨论 |
| 负责人和日期 | 谁作出决定，何时复查 |
这份记录可以避免同一个需求每隔几周重新争论，也让团队知道当时依据是什么。新证据出现后，决定可以改变，但应说明改变来自用户、任务、平台、成本还是产品阶段。
功能进入「现在做」以后，还要写成交付规格和验收条件。那是下一章处理的内容。当前记录只负责回答为什么做、为谁做，以及为什么现在做。
记录范围债务
产品为了验证需求，常会采用手工步骤、临时接口、有限格式或只支持少数场景。这些选择本身没有问题，但要形成范围债务清单，说明当前限制、用户影响、人工成本和处理方式。
常见范围债务包括：
- 只支持一种输入格式，其他格式由人工转换；
- 生成以后需要后台人工检查；
- 某个平台接口失败时没有自动恢复；
- 退款、迁移或删除依赖人工处理；
- 某项高级能力只对少数客户开放；
- 页面承诺已经收窄，旧用户仍保留历史功能。
范围债务与普通开发待办不同。它直接影响当前承诺能否稳定兑现，需要记录每次发生的频率、成本和风险。债务开始阻断成交、造成连续失败或占用大量支持时，应进入「现在做」；长期没有实际影响时，可以继续保持明确限制。
下线功能也属于范围管理。团队需要确认受影响用户、已有数据、替代路径、通知时间和迁移方式。可逆实验可以快速停止，涉及用户数据和工作流程的能力则应谨慎退出。产品做减法时，仍要履行已经作出的承诺。
常见的五种范围漂移
按声音大小排路线图
高价值客户的意见重要，但单个客户也可能要求专属流程。需要判断它代表一类核心用户，还是一项需要单独定价的定制服务。公开投票同样会偏向活跃用户和容易理解的功能。
按竞品清单补齐功能
成熟竞品可能服务不同阶段、不同价格和不同客户。复制功能会连带复制复杂度，却未必复制其渠道、品牌和支持能力。竞品功能应回到用户任务解释。
按开发兴趣选择功能
新模型、新框架和新平台容易激发实现兴趣。技术演示可以作为探索，但进入正式范围前仍要证明它改善核心任务，并评估稳定性和成本。
用已有投入证明继续投入
已经完成一半的功能会产生很强的继续冲动。判断时仍应比较未来成本和未来价值。无法支持核心结果的功能，即使已经投入，也可能适合停止。
用更多功能掩盖主要失败
如果用户不能完成核心流程，增加模板、主题和设置通常不会解决问题。先检查输入、处理、输出、错误和首次价值路径。主要任务稳定以后，扩展才有基础。
定期复查，而不是每日改方向
功能反馈应持续记录，范围不必随着每条消息即时改变。早期产品可以按两到四周，或按一个自然使用周期做一次范围复盘。低频产品需要更长窗口。
复盘主要回答：
- 最近完成主要任务的核心用户是谁；
- 他们反复卡在哪一步；
- 哪些问题导致任务失败、退款、流失或无法成交；
- 哪些请求来自非目标用户；
- 当前功能的使用、维护和支持成本怎样；
- 平台、模型和竞品条件是否变化；
- 哪项决定需要保持，哪项需要重开；
- 下一周期只解决哪一个主要范围问题。
适合重新打开决定的证据包括：多位核心用户在相同任务中反复失败；明确订单或续费因为缺失能力而流失；平台接口和成本发生实质变化；产品从个人工具进入团队流程；原先的手工步骤已经稳定到可以产品化。
点赞、一次问卷或泛泛的「有这个会更好」适合进入观察，不必立即改变范围。
产出一页产品范围说明
完成本章后，可以把决定压缩成一页：
核心用户
写清角色、阶段、能力条件、付款关系和可达渠道。
主要场景
写清触发事件、当前流程、最困难步骤和使用频率。
产品承诺
写清输入、主要动作、可观察输出和成功条件。
首版范围
列出完成主要任务不可缺少的能力，以及必要的失败处理。
当前非目标
列出相邻但不承担的用户、任务、平台、权限和交付方式，并写明原因。
功能状态
分别列出现在做、继续观察、暂缓和拒绝的内容。
经营边界
记录开发、维护、客服、人工交付、第三方依赖和风险条件。
复查条件
写明下一次复盘时间，以及什么证据会让范围改变。
产品范围不会永久固定。它应当随着证据调整，但每次调整都需要知道服务对象、主要任务和经营条件发生了什么变化。明确边界以后，产品更容易兑现承诺，用户也更容易判断它是否适合自己。
下一步需要把已经选定的能力写成可交接、可验收的任务。范围回答「做什么和为什么」，交付规格继续回答「做到什么程度才算完成」。