先把产品范围写成一句话

产品开始收到真实反馈以后，功能列表通常会很快变长。有人希望增加一种导出格式，有人需要批量处理，有人要求团队权限，还有人觉得只要接入另一个平台，产品就会更完整。

这些反馈都值得记录，却不需要逐条实现。产品范围是一项经营决定：它规定产品先为哪类人完成哪项任务，结果做到什么程度，同时也规定当前不解决什么。范围过窄，主要任务可能无法完成；范围过宽，开发、维护、客服和表达都会被拉向不同方向。

核心用户在这里承担一个很具体的作用。人物画像只有进入功能取舍，才会真正影响产品。每次决定都需要回到同一组问题：谁会使用，发生在什么场景，任务有多频繁，功能对主要结果有多少贡献，是否增强产品差异，以及团队能否长期交付和维护。

早期产品可以先写一条范围句：

产品帮助【一类明确用户】，在【具体触发场景】中完成【主要任务】，交付【可观察结果】；当前通过【产品形态】提供，并暂不覆盖【主要非目标范围】。

例如，一项面向独立站运营者的商品图工具，可以写成：帮助每周需要发布新品的小团队，把现有商品照片处理成符合商城规格的成套图片；首版提供网页端单商品处理和常用尺寸导出，暂不包含完整素材管理、多人审批和广告投放。

这句话同时约束六件事：

• 服务对象是谁；
• 任务在什么时候发生；
• 用户希望完成什么；
• 怎样判断结果可用；
• 产品以什么方式交付；
• 哪些相邻需求暂时不承担。

如果一句话里出现「所有创作者」「一站式」「全流程」或多个差异很大的任务，范围通常还没有收紧。平台拥有大量用户也不代表这些用户共享同一项需求。产品需要进入更小的交集：某类人、某个场景、某项已经发生的任务。^[1]

从核心用户定义推导范围

核心用户至少要落实到以下信息：

产品范围里的每一项主要功能，都应能回到这张表中的一行真实任务。若功能只来自竞品页面、创始人的开发兴趣或宽泛趋势，它可以进入观察清单，还不适合直接进入首版。

一套产品运营框架把用户分为知道产品、真正获得价值和愿意付费三个层次。^[2] 这个分法也能帮助检查范围。功能可能让产品更容易被看见，却不一定帮助用户完成任务；也可能提高使用量，却没有进入付款人愿意购买的结果。功能取舍需要同时看触达、使用和交易，不能把其中一个数字代替全部判断。

建立「人 × 场景 × 问题 × 结果」矩阵

抽象功能很容易看起来人人需要。放进具体场景以后，差异会清楚很多。

这三类人都可能要求「增加样式能力」，背后的产品却并不相同。第一类需要低学习成本和稳定结果；第二类会带来权限、模板管理、审核和客户支持；第三类需要代码编辑、兼容性和调试。若产品的核心用户是第一类，后两类需求不能因为表达相似就一起进入路线图。

现场案例中，一项 AI 招聘产品原本可以被描述为一串功能：口述岗位、生成职位描述、设计候选任务、完成对话、记录过程并输出报告。把它放入物业公司批量招聘的场景后，范围变得具体：先用普通话自我介绍和简单网页任务，筛查沟通与基础逻辑能力。^[2] 同一套能力还可以服务其他岗位，首版仍需先完成一个行业任务，无法同时承担所有招聘流程。

矩阵适合在三个时候更新：第一次决定首版范围时；出现连续功能请求时；产品的主要用户或渠道发生变化时。它的价值不在于表格完整，而在于让每项功能回到一个可观察的任务。

先画任务，再列功能

功能列表常按页面或技术模块排列：登录、工作台、AI、导出、团队空间。用户实际经历的是一条任务路径。范围判断前，可以先画出任务：

触发事件
→ 准备输入
→ 完成主要处理
→ 检查结果
→ 交付或进入下一项工作
→ 保存、复用或再次购买

然后给每一步标出三类内容：完成任务不可缺少的步骤；当前可以人工或外部工具完成的步骤；方便但不影响主要结果的步骤。

例如，商品图工具的主要任务是从一组原图得到可以上架的图片。尺寸检查、主体不被裁切、批量下载和失败说明可能属于完整结果；素材评论、团队审批和广告数据回传属于更远的协作流程。后者有价值，却可能把首版从图片处理工具变成数字资产管理系统。

任务图还能发现表面上不起眼的缺口。用户完成生成却不知道选哪张、导出后文件命名混乱、结果无法进入商城，这些都可能阻断主要任务。相反，一项在演示中很醒目的能力，若不影响后续使用，只适合保留为实验。

范围讨论应以用户能否从触发走到结果为主线。技术模块仍然需要规划，只是不能用内部模块替代外部任务。

用户反馈先翻译成任务

用户提出的解决方案，不能直接等同于需求。「增加 Excel 导出」「接入 Slack」「加一个 AI 助手」都只是建议。团队仍要了解建议背后的事件。

一次有效的追问通常包含：

1. 最近一次遇到问题是什么时候；
2. 当时要完成什么任务；
3. 现有流程停在了哪一步；
4. 没有这个功能时怎样处理；
5. 问题多久发生一次；
6. 失败会造成多少时间、费用或业务风险；
7. 建议中的功能如果实现，用户下一步会做什么；
8. 结果怎样进入后续工作。

漫画翻译产品的早期版本只处理单张图片。后来出现批量上传、更多语言和其他处理要求，这些反馈说明用户正在把产品放入更完整的工作中。^[3] 团队需要区分主任务不可缺少的步骤、可以手工绕过的步骤，以及会把产品带入新领域的要求。请求次数只能说明有人表达过，不能单独决定优先级。

用户也可能很擅长描述问题，却不了解实现成本、兼容风险和其他用户的流程。团队应当保留原始说法，再将它转成「用户—触发—任务—阻力—期望结果」的记录。这样即使最终没有采用用户建议的形式，问题本身仍然不会丢失。

用四个状态管理需求

功能列表只写「待办」和「完成」，会把所有需求推向实现。更合适的做法是给每项需求一个明确状态。

现在做

直接影响核心用户完成主要任务，且缺失时产品无法兑现承诺。首版需要优先完成这些内容，包括必要的输入、主要处理、可用输出，以及最基本的失败说明。

继续观察

问题可能存在，证据还不够。可以通过访谈、手工代办、页面入口、假的门或小范围试验了解频率和结果，不急着开发完整功能。

暂缓

需求明确，但不属于当前最短交付路径，或目前的实现、维护成本太高。暂缓需要写明重新考虑的条件，例如核心用户连续出现、已有客户因此无法续费、平台接口稳定，或交付成本降到可接受范围。

拒绝

需求会改变产品服务对象、引入另一套支持体系、削弱主要差异，或无法在可接受条件下长期兑现。拒绝不等于否认用户问题，只表示当前产品不承担这项任务。

每个状态都要附带理由和证据日期。否则「暂缓」会变成没有期限的愿望池，「拒绝」也可能只是当时的直觉。

状态变化也要有规则。观察项只有出现新的核心用户行为、交易或交付证据，才进入「现在做」；开发兴趣和竞争对手发布不自动触发升级。暂缓项到了复查时间仍没有新证据，可以继续暂缓或转为拒绝。已经拒绝的需求若对应的用户、产品阶段和经营条件发生变化，也可以重开。

这样处理以后，路线图不再是一条不断变长的愿望清单。它更接近一组带证据的决定，其中大部分内容都可能保持不做。

功能评估不必压成一个分数

RICE、Kano 等框架可以帮助讨论，但早期样本和成本估计常常不稳定。把所有因素乘成一个总分，容易制造精确的感觉。功能评估可以保留多个字段，让决定过程清楚可复查。

这些字段不要求得到统一答案。某项功能使用频率不高，却可能是财务数据导出、备份、权限或安全流程中不可省略的一环；另一项功能请求很多，却可能来自非目标用户。决定需要结合主要任务和失败后果。

做一次实际评估

假设商品图工具连续收到四类请求，可以先形成下面的判断：

表里没有统一分数。批量导出可能实现工作不小，却直接决定结果能否使用；自由尺寸看起来只是一个输入框，实际会引入大量比例、裁切和质量问题；团队评论会把个人工具带入协作产品；自动投放则改变了产品承诺。

评估完成后，团队还需要检查一个反方向的问题：如果这项功能永久不做，核心用户还能否得到承诺结果？若答案是可以，暂缓或拒绝往往比立即实现更合适。