频率要和重要性一起看

高频任务通常值得优先，因为改善会反复产生价值。但频率不能单独决定范围。

• 高频且直接影响主要结果：通常优先进入首版；
• 高频但不影响结果：先检查它是否只是操作偏好；
• 低频但失败代价高：可能是必要的信任、备份或合规能力；
• 低频且容易绕过：适合暂缓；
• 只在极少数特殊流程出现：判断是否属于核心用户边界。

例如，导出审计记录可能每月只用一次，却是企业客户完成采购和合规的必要条件。如果当前产品面向个人用户，它可以暂缓；如果产品承诺进入企业流程，就不能当成边缘需求。功能的优先级取决于产品承诺，而非通用的高低频分类。

边缘情况也需要区分。无法处理一种罕见输入格式，可能只需明确限制；若失败会破坏文件、泄露数据或让用户误以为结果已经完成，就必须在首版提供检测和提示。首版可以能力有限，不能让用户在未知条件下承担不可见风险。

一个做减法的案例

Notion Converter 起初来自创作者自己的公众号排版问题。这说明问题真实存在，却不能证明市场规模、使用频率和付费结构已经成立。^[1]

早期用户提出过自定义 CSS、自定义图片等要求。逐项响应会让工具同时服务普通公众号作者和希望完全控制样式的开发者。两类人的学习成本、期望和客服问题不同。产品后来把核心用户收紧为日常发布公众号、确实受排版效率限制的人，重点转向普通用户可以直接使用的样式，并放弃面向程序员的自定义 CSS。^[1]

这个取舍可以拆成三个检查：

1. 它是不是核心用户反复遇到的问题；
2. 它会增强当前差异，还是稀释产品表达；
3. 它是否引入一个支持成本更高的新用户群。

拒绝自定义能力会失去一部分用户，但也让产品更容易使用、解释和维护。产品范围的作用本来就包含放弃。只写「服务更多人」，实际往往会让任何一类人都难以快速确认产品是否适合自己。

同一个项目后来还在插件和模板之间做过经营形态调整。模板对开发和客服依赖较低，也更适合创作者通过内容获客；插件需要持续维护产品和技术支持。^[1] 这说明范围不只由市场愿望决定，还受团队能力和长期运营方式约束。

使用量不等于产品范围正确

一项小红书文案工具曾获得较多使用和访谈反馈，但大部分用户的目标停留在「做大账号」或「做副业」，没有明确收入、粉丝、行业和投入时间。^[2] 功能被频繁使用，仍不代表用户拥有稳定任务，也不代表产品能够形成合适的商业结果。

这类产品很容易被高使用量带着继续增加功能：更多文案类型、更多平台、更复杂的生成控制。真正需要补充的证据是，哪类用户在什么工作中持续使用，输出帮助他们完成了什么，以及谁愿意为什么结果付款。

因此，功能评估至少要把三件事分开：

• 有人打开或使用；
• 用户完成了真实任务；
• 任务产生了可持续的交易。

免费、低门槛的生成能力可能带来很高使用，却吸引到目标含糊、预算较弱的人群。此时扩大功能范围会增加模型、支持和维护成本，不一定改善经营。团队需要先收窄用户和结果，再决定功能。

已经上线的功能也应接受同样检查。团队可以按核心用户使用率、主要任务完成、付费或留存变化、支持工单和维护时间观察它的实际贡献。使用率低的功能不一定立即下线，可能只是入口难找；使用率高的功能也可能主要服务免费用户，并持续制造成本。数据需要与访谈、任务观察和交易一起解释。

功能上线前最好写下预期：哪类用户会在什么场景使用，哪项行为或结果应当变化，多久复查。上线后若结果没有发生，先检查功能是否被正确理解和使用，再决定修正、收回或停止继续投入。没有预期的功能很容易因为「已经上线」而永久留在产品里。

平台依赖会改变范围

建立在 Notion、Shopify、X、Slack 或应用商店上的产品，会同时受到平台能力和平台边界影响。平台的大盘用户数只能说明潜在环境，不能说明具体交集有多大。

ReadNotion 的案例服务于 Notion 用户中的一个更窄场景：用户已经把待读内容保存在 Notion，希望在移动端继续阅读。^[3] 产品早期还可以扩展到阅读、笔记、播客和待办等方向，但这些任务放在一起会让产品逐渐碎片化。范围需要回到已经发生的行为：用户是否原本就把内容保存进 Notion，以及稍后阅读是否足够频繁。

平台型产品在决定功能前，还应检查：

• 用户是否已经采用上游平台，而非要求他们先建立一种新习惯；
• API 是否允许稳定获得所需数据；
• 权限、审核、额度和价格会不会变化；
• 平台原生功能或政策变化会怎样影响产品；
• 用户能否导出数据或迁移；
• 接口中断时怎样说明和恢复；
• 团队是否有能力持续跟进兼容问题。

平台 API、价格、审核和竞品状态都具有时效性，产品决策时需要重新核对当时规则。历史案例适合说明判断过程，不能代替当前平台文档。

首版范围要形成一条完整路径

首版并不等于功能越少越好。它需要用尽量小的范围交付一次完整结果。

一条可用的首版路径通常包含：

1. 用户知道产品适合什么任务；
2. 能够提供一份真实输入；
3. 完成最主要的处理动作；
4. 获得可进入下一步工作的输出；
5. 失败时知道原因、限制和是否可以重试；
6. 团队能够观察用户是否完成任务。

以文件处理工具为例，上传按钮和模型调用并不构成完整产品。输出格式、下载、失败提示、文件限制、隐私说明和必要的重试，都可能属于主要任务。多人空间、历史版本、复杂权限和全部第三方集成则要看核心用户是否真的需要。

企业产品还需要额外谨慎。流程、权限、审计、合规和集成往往决定能否进入真实工作。独立开发者若首版服务个人或小团队，不宜因为「企业市场更大」就提前复制整套企业软件；若选择企业客户，也不能只做演示界面而忽略采购与部署条件。^[3]

产品形态也是范围决定

同一个问题可以用软件、服务、模板、数据产品或混合方式交付。早期团队容易把「产品」默认理解成完整软件，随后才发现专业判断、数据维护和客服占据了大部分工作。

选择形态时可以检查：

• 任务能否稳定标准化；
• 输入和输出是否足够一致；
• 哪些步骤仍需要人工判断；
• 用户愿意自助完成，还是希望直接获得结果；
• 每次交付需要多少支持；
• 第三方依赖由谁维护；
• 客单价能否覆盖服务和异常处理；
• 内容、销售或渠道是否与这种形态匹配。

服务可以先确认用户愿意为结果付费，也能帮助团队理解真实流程。模板适合结构稳定、用户能够自行执行的任务。软件适合重复、可标准化并需要持续使用的流程。混合模式可以保留关键人工步骤，但应如实记录，避免把后台服务包装成已经自动化的能力。

范围和形态还会影响获客。需要长时间解释和配置的产品，很难只靠一个自助页面成交；低价模板若复购弱，需要持续内容和新产品支持；高价服务虽然客户少，却可能承担更重的销售和交付。产品、用户和渠道需要一起成立。^[1][3]