明确企业软件的目标用户和核心使用场景，最终要落成一份可验证的定位假设：先按业务角色、任务和约束切分用户群，选出优先服务的一到两类；再沿真实业务链条还原关键任务的触发、动作、交接与结果；最后用访谈、行为数据和试点收敛判断。本文按这一顺序给出可填写的模板、分工与检查标准，定位假设和验证记录在团队内的流转可借助 ONES 的工作项与文档协作完成。
要点总览（TL;DR）
- 定位工作的第一份产物是一页定位假设，写明目标用户群、业务角色、核心任务、触发条件、关键约束与期望结果，作为后续讨论和验证的共同起点。
- 用户切分从业务角色与职责、任务频率、组织规模与行业合规约束三个维度展开，再依据痛感强度、可触达性和交付成本选出优先服务的一到两类用户群。
- 场景还原沿真实业务链条记录触发事件、输入、关键动作、交接对象、产出与结果，并单独记录异常与约束，避免写成功能清单。
- 验证用访谈与跟岗观察、行为数据与既有记录、小范围试点三条证据线；证据冲突时优先采信可重复观察的行为证据，并写入修订记录。
- 定位说明通过完成检查后纳入版本管理，用于需求取舍与路线讨论；项目投资组合取舍与具体需求优先级排序属于后续环节。
先产出一页定位假设：目标用户与核心场景怎么写
定位工作的第一份产物是一页定位假设。它把团队对“为谁解决什么问题”的分散判断集中到同一张纸上，供讨论、质疑和后续验证。篇幅控制在一页，字段齐全比文字漂亮更重要。
建议使用下表结构，每个字段按给定口径填写：
| 字段 | 填写口径 | 颗粒度要求 |
|---|---|---|
| 目标用户群 | 用“组织类型＋部门＋角色”描述，如“中型制造企业的质量工程师” | 能据此判断谁在名单内、谁在名单外 |
| 业务角色 | 该用户在业务流程中承担的职责与决策权限 | 写职责，不写职级头衔 |
| 核心任务 | 用户需要反复完成、且当前完成得不理想的一件事 | 动词开头，一次只写一件任务 |
| 触发条件 | 什么事件或时间点让任务开始 | 可观察的事件，如“客户投诉登记后”“月度结账前” |
| 关键约束 | 完成任务时必须满足的合规、时限、系统或协作条件 | 列出会改变方案设计的约束 |
| 期望结果 | 任务完成后用户可观察到的状态或产出 | 写结果，不写功能 |
填写时注意两点。其一，核心任务只写一件，多任务并列会让后续场景梳理失去焦点；其二，期望结果要能被用户自己判断是否达成，例如“投诉在当天分派到责任人并留痕”，而不是“提升处理效率”。
这一页纸的使用方式是：作为定位讨论的起点，在评审中逐字段接受挑战，任何字段被推翻都记录修订原因。它同时是后续用户群切分表和场景卡片的摘要页，保持三者一致。
切分目标用户：从角色、任务和约束三个维度筛选
“中小企业”“一线业务人员”这类描述无法指导产品决策。切分的目标是得到若干互有差异、可以排序的用户群，再从中选出优先服务对象。
按业务角色与职责切分
同一部门内，角色不同，任务和约束往往差别很大。例如采购部门中，采购专员关注比价与下单，采购经理关注审批与供应商绩效，财务则关注对账与付款合规。切分时以职责和决策权限为线，而不是以职级为线。
按任务频率区分主用户与偶发用户
高频使用某功能的角色是主用户，低频但关键节点必须使用的角色是偶发用户。主用户决定产品的日常体验和留存，偶发用户决定关键流程能否闭环。两类都要识别，但产品设计重心应放在主用户身上，偶发用户通过流程衔接和引导来覆盖。
用组织规模、行业约束和合规要求收窄范围
组织规模影响部署方式、权限复杂度和集成需求；行业约束影响术语、流程和报表口径；合规要求会直接排除某些设计选项。把这些条件写进用户群描述，可以避免“所有企业都能用”的模糊定位。
完成切分后，用下表整理并排序：
| 用户群 | 业务角色与职责 | 任务频率 | 规模/行业/合规约束 | 优先级 |
|---|---|---|---|---|
| 用户群A | 填写职责与决策权限 | 高频/偶发 | 填写适用条件 | 优先/观察/暂不覆盖 |
| 用户群B | 同上 | 同上 | 同上 | 同上 |
优先服务对象的取舍依据通常包括：任务痛感是否足够强、用户群规模与可触达性、与现有能力的匹配度、商业价值与交付成本。取舍结论要写明理由，并明确哪些用户群暂不优先，避免后续需求讨论中反复摇摆。
还原核心使用场景：沿业务链条梳理触发、动作与交接
场景写不具体，通常是因为只写了功能而没写过程。一个可用的场景描述应包含六个要素：触发事件、输入、关键动作、交接对象、产出与结果，以及过程中出现的异常与约束。
通过跟岗观察和访谈还原真实流程
先请用户按最近一次真实任务从头讲一遍，记录他打开哪些系统、找谁要数据、在哪个环节等待、最后把结果交给谁。跟岗观察可以补上用户自己没意识到的操作，例如线下表格、即时消息确认和口头审批。访谈中追问“上一次是什么时候”“当时卡在哪里”，比询问“你希望有什么功能”更能得到可用信息。
区分核心场景、支撑场景与边缘场景
核心场景是目标用户高频发生、直接决定产品价值成立的任务链条；支撑场景为核心场景提供输入或承接输出，例如数据准备、权限配置；边缘场景发生频率低或只影响少数用户。优先级判断可参考发生频率、业务影响、当前替代方案的糟糕程度和实现成本。
场景卡片与异常记录
每个核心场景用一张卡片记录：
- 场景名称与所属用户群；
- 触发事件与前置输入；
- 关键动作序列，标注涉及的系统与角色；
- 交接对象与交接物；
- 产出与用户判断完成的标准；
- 常见异常，如数据缺失、审批退回、跨部门等待，以及当前的应对方式。
异常与约束要单独记录，它们往往决定产品设计的关键细节。场景卡片完成后，按优先级排序，形成核心场景清单，作为需求讨论的共同参照。
角色分工与交付物：谁来做、交付什么、何时评审
定位工作容易变成产品经理一个人的文档。要让结论被组织接受，需要明确各角色在不同阶段的输入和确认责任。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 产品负责人 | 确定定位工作的范围与优先级取舍，主持评审并确认结论 | 定位说明的最终确认 |
| 产品经理 | 起草定位假设，组织用户切分与场景梳理，维护修订记录 | 一页定位假设、用户群切分表、场景卡片 |
| 用户研究 | 设计访谈与跟岗方案，执行取样，整理证据 | 访谈记录、观察笔记、证据汇总 |
| 销售与客户成功 | 提供售前异议、流失原因、典型客户画像等一线信息 | 客户反馈摘要、典型客户名单 |
| 研发 | 评估场景的技术约束与实现成本，参与场景可行性讨论 | 约束说明与成本初判 |
评审节点建议设置为三次：定位假设初稿完成后评审字段是否齐全、判断是否有依据；用户切分与场景卡片完成后评审优先服务对象和核心场景排序；验证结果回收后评审定位是否修订、是否可写入产品决策。每次评审形成结论和待办，指定责任人和时间。
定位结论的变更要有机制：任何字段调整需说明触发原因，例如新证据出现、目标市场变化或试点结果不符；变更记录保留旧版本，避免团队按过期结论做需求。定位说明通常按季度或重大版本节点复核，不必频繁改动。
验证定位假设：访谈、行为数据与试点三条证据线
定位假设写得再完整，也只是假设。验证的任务是找出哪些判断站得住、哪些需要修正。
访谈与跟岗观察
取样覆盖优先用户群中的典型用户和边缘用户，数量以能听到重复模式为准。提问围绕最近一次真实任务展开：任务从何开始、用了哪些工具、在哪里等待、结果如何被确认。避免让用户评价功能设想，那容易得到礼貌性肯定。
行为数据与既有记录
产品内的使用路径、功能使用频次、任务完成时长可以检验“高频任务”的判断是否成立。工单、售前异议记录、流失访谈则能反映用户真正卡住的地方。把数据结论与访谈结论对照，注意区分“用户说的重要”和“用户实际反复做的”。
小范围试点或灰度验证
选择一小组符合目标用户特征的真实用户，在真实业务中运行一段时间。试点前写明要验证的判断和观察指标，试点中记录使用障碍和流程断点，试点后形成结论。试点范围小、周期短，目的是检验场景链条是否成立，而非评估完整产品。
当三条证据线出现冲突时，优先采信可重复观察的行为证据，其次是一线记录，最后是用户表述。冲突本身要写入修订记录，说明调整了哪个字段、依据是什么。若证据不足以支撑原判断，宁可缩小目标用户范围或降低场景优先级，也不要用模糊表述维持原结论。
定位假设、场景卡片和验证记录需要在产品、销售、研发之间流转和评审。ONES 研发项目管理平台遵循 IPD 的理念和方法，通过对市场管理、需求管理的流程支撑，让企业“做正确的事”，其 IPD 解决方案支持从需求挖掘、收集、结构化，到开发决策、研发落地的全流程管理；在概念阶段聚焦产品包需求的完整性和产品概念的匹配度，确保技术方案满足市场与客户需求。团队可以把定位假设和场景卡片作为需求输入沉淀在文档与工作项中，让后续需求讨论引用同一份依据。
示例：一款企业协作软件如何收敛定位
以下为演示情景，用于说明方法如何落地，不代表真实客户案例。
初始假设与用户群切分
某企业协作软件团队最初把目标用户写为“需要提升协作效率的企业”。经过切分，识别出三类用户群：项目型团队的项目经理，高频使用任务分配与进度跟踪；职能部门的行政与人事，偶发使用审批与通知；IT 管理员，负责账号与权限配置。团队初步选择项目经理为优先服务对象，约束条件为五十至五百人规模、已有即时通讯工具的企业。
场景梳理得到的核心场景
跟岗观察发现，项目经理最高频的任务是每周汇总多个来源的进展并向管理层汇报。触发事件是周会前一天，输入分散在即时消息、表格和口头同步中，关键动作包括逐个询问、手工汇总、调整口径，交接对象是部门负责人，产出是一页进展报告。异常包括成员延迟更新、口径不一致和临时插入事项。团队据此把“周度进展汇总与汇报”确定为核心场景，把权限配置列为支撑场景。
验证中发现的偏差与调整
行为数据显示，任务分配功能使用率低于预期，而文档协作和评论讨论的使用集中在汇报前两三天。访谈进一步发现，项目经理真正花时间的环节是收集和核对信息，而非分配任务。团队据此调整定位：核心任务从“任务分配与跟踪”改为“跨来源进展收集与汇报口径统一”，目标用户收窄为同时管理三个以上并行项目的项目经理。
最终定位说明的表述
修订后的定位说明写为：为五十至五百人规模、同时管理多个并行项目的项目经理，解决周度进展收集与汇报口径不一致的问题；触发条件是周期性汇报节点；关键约束是成员分散在不同工具中、汇报口径需与管理层对齐；期望结果是项目经理在一次汇总中完成进展收集、口径核对和报告输出。该说明随后被用于需求取舍，与汇报无关的功能请求进入观察列表。
完成检查：定位说明是否可用于产品决策
定位工作是否完成，不看文档篇幅，而看它能否在需求讨论和路线评审中被直接引用。逐项核对以下清单：
- 目标用户具体到组织类型、部门和业务角色，并写明规模、行业或合规约束；
- 明确列出优先服务的用户群，以及暂不优先的用户群和理由；
- 核心场景包含触发事件、输入、关键动作、交接对象、产出与结果；
- 核心场景、支撑场景与边缘场景已区分并排序；
- 异常与约束有单独记录，且与场景描述对应；
- 每条关键判断能指向访谈、行为数据或试点中的具体证据；
- 修订记录完整，写明调整字段、原因和依据；
- 定位说明已被用于至少一次需求取舍或路线讨论，并能说明取舍结果。
若目标用户仍停留在行业或规模层面、场景仍以功能列表呈现、或没有任何证据支撑，说明定位工作尚未完成，应回到用户切分和场景梳理补充。定位说明通过检查后，作为产品决策的基准文档纳入版本管理，按既定节点复核。项目投资组合的取舍与具体需求的优先级排序属于后续环节，可在定位说明的基础上另行展开。
常见问题
团队规模较小、没有专职用户研究岗位时，定位工作怎么推进？
可以由产品经理承担用户研究的主要工作，把访谈与跟岗观察安排在已有的客户拜访、售前支持和客户成功回访中，避免另起一套流程。取样上优先覆盖优先用户群中的典型用户，数量以能听到重复模式为准。销售与客户成功提供典型客户名单和一线反馈，研发参与场景可行性讨论。分工可以简化，但定位假设、切分表、场景卡片和修订记录这几份产物建议保留，否则结论难以被组织复用和检验。
定位假设与已有产品路线图冲突时，应该先改哪一个？
先判断冲突的性质。如果路线图中的需求无法指向任何优先用户群或核心场景，说明路线图需要按定位说明重新取舍；如果定位假设本身缺乏证据支撑，则应先补充验证再调整路线。处理时把冲突写入修订记录，写明涉及哪个字段、依据是什么、由谁确认。定位说明通常按季度或重大版本节点复核，不必因单个需求频繁改动，但持续出现的冲突是定位需要修订的信号。
面向多个行业销售的企业软件，是否必须收窄到一个行业？
不必须。收窄的对象可以是用户群和场景，而不一定是行业。可以保留多个行业客户，同时明确优先服务的业务角色与核心任务，把行业差异作为约束条件写入用户群描述，例如术语、报表口径和合规要求。这样既保持覆盖面，又让产品设计有明确重心。需要避免的是把目标用户写成“所有行业的相关部门”，那会让后续的场景梳理和需求取舍失去判断依据。
验证结果与初始判断不一致时，如何避免团队反复摇摆？
把修订过程制度化：每次调整都记录调整了哪个字段、触发原因和证据来源，保留旧版本。证据冲突时按可重复观察的行为证据、一线记录、用户表述的顺序采信，并在记录中说明取舍理由。若证据不足以支撑原判断，缩小目标用户范围或降低场景优先级，比用模糊表述维持原结论更有利于后续决策。定位说明确认后作为基准文档纳入版本管理，需求讨论引用同一版本。
定位说明完成后，如何与需求优先级排序衔接？
定位说明提供判断基准：需求是否服务于优先用户群、是否落在核心场景链条上、是否触碰已记录的关键约束。符合这些条件的需求进入候选池，再按价值、成本和紧迫程度排序。定位说明本身不承担排序职责，具体需求的优先级与价值评估、项目投资组合的取舍属于后续环节，可在此基础上另行展开。ONES 研发项目管理平台遵循 IPD 的理念和方法，通过对市场管理、需求管理的流程支撑，让企业“做正确的事”，团队可以把定位说明作为需求输入沉淀下来，让后续讨论引用同一份依据。
