功能清单可以列出账户、仪表板、通知和报告，却不一定说明用户为什么会再次使用产品。沿着工作从起始需求走到有用结果，范围会更清楚。以一个假设的 SaaS 构想为例：面向小型设施维护团队的共享服务请求跟踪工具。它的首要目的，是让团队看到每个请求的负责人和当前状态。这个目的为版本提供了实际边界。
本页内容
明确初始用户与结果
通过工作内容描述首批受众。在跟踪工具的例子中，协调人员目前从消息中汇总请求，向同事询问更新，再手动报告进度。有用的结果是一个包含足够背景信息、明确负责人员和可见状态的请求。应识别谁录入信息、谁据此行动，以及谁需要看到结果。这有助于区分协调人员的需求与技术人员的视图，也避免把所有潜在客户都当作首批受众。
- 什么事件会让用户需要打开产品？
- 一次有价值的使用过程中，用户必须完成什么？
- 什么信息会促使用户回来继续工作？
梳理首条使用路径并划定边界
在这个例子中，协调人员创建工作空间、邀请同事、登记请求并分配任务。同事打开请求、更新状态并记录结果，协调人员随后可以查到该结果。这些步骤构成一条连贯的初始使用路径。还应决定如何处理错误分配或误关闭的请求。高级报告、自动路由和公开供应商市场可以暂不纳入这个示例版本。请记录这些暂缓项，避免后续讨论将它们悄然视作已经承诺的内容。
- 纳入：工作空间访问、请求详情、分配、状态和基本历史记录。
- 纳入：保持该流程可用所需的纠错功能。
- 暂缓：额外工作流程，除非它们能解决首条使用路径中已经证实的缺口。
确定运营产品所需的工作范围
规定账户责任、邀请、撤销访问权限，以及各角色能够查看或修改的信息。如果不同客户使用同一服务，应定义并验证其工作空间之间的边界。让支持人员能够在约定的权限规则内调查问题。规划恢复检查，并明确重要记录的责任归属。如果包含订阅，应描述所选的计费与访问状态；如果暂缓订阅，则记录首版如何管理访问。这些与可见界面一样，都是产品决策，不应当作上线前再处理的细节。
- 用户失去访问权限时由谁协助？
- 谁可以修正或重新打开请求？
- 团队如何发布更新并响应故障？
决定希望从首版学到什么
写下假设以及团队如何检验它们。对于跟踪工具，协调人员能否无需外部帮助就创建并分配请求？同事能否理解要做什么？协调人员之后能否找到有用的结果？观察完整路径，记录哪些地方需要协助。应区分约定流程中的失败与要求产品转向的新需求。只有证据表明分配工作确实是初始用户的重要问题时，才重新考虑自动路由，而不是因为这项功能听起来先进。