产品定位说明要解决的是团队对“为谁做、解决什么问题、凭什么选我们”各说各话的问题。把答案收进一张表，逐项写成可评审的表述，比写一篇长文更容易对齐。本文提供可直接复制的空白表、逐字段填写口径、必填与选填划分、一份完整填写示例，以及定位文档的维护方法。
要点总览（TL;DR）
- 产品定位说明用一张表把目标客户、使用角色、核心问题、现有替代方式、差异化价值、边界与成功信号写成可评审的共识文档，配套一句可独立传播的定位句式。
- 字段说明给出每个字段的填写口径与常见错误，例如目标客户要写可筛选条件、差异化价值要落到客户结果、证据不足时标注待验证。
- 早期版本只需九项必填字段即可支撑方向讨论，价值证据、成功判断信号和前提与假设可在进入正式评审前补齐。
- 填写示例以演示情景展示字段如何落到具体表述，读者可按同样颗粒度替换为自己产品的内容。
- 定位说明需要版本记录、跨角色评审和明确的更新触发信号，并与需求排序、项目组合管理分工，避免写完即过期。
可复制空白模板：产品定位说明表
下面这张表是本文的核心交付物，可以直接复制到文档工具中填写。字段顺序在后续的字段说明、必填对照和填写示例中保持一致，方便逐行对照。表格按“一行一个字段”组织，左列是字段名，右列是填写内容；如果团队习惯横向排版，把两列转置即可，字段本身不变。
| 字段 | 填写内容 |
|---|---|
| 产品名称与版本 | |
| 一句话定位 | |
| 目标客户 | |
| 使用角色 | |
| 核心问题 | |
| 现有替代方式 | |
| 差异化价值 | |
| 价值证据 | |
| 边界与不做什么 | |
| 成功判断信号 | |
| 前提与假设 | |
| 负责人、评审人与更新日期 |
表格之外，配一句可独立传播的定位句式，用于对外介绍和内部对齐：
“我们为【目标客户】中的【使用角色】，解决【核心问题】；相比【现有替代方式】，我们提供【差异化价值】，依据是【价值证据】；我们当前不做【边界】。”
这句话不是表格的替代品，而是表格填完后自然收敛出的结论。填写时先完成表格各行，再回头把关键内容压缩进句式，能避免一句话定位写成口号。
每个字段填什么：字段说明与判断口径
同一张表由不同的人填写，结果常常无法比较：有人把目标客户写成“所有企业”，有人把差异化价值写成功能清单。下面逐字段给出填写口径和常见错误，目的是让不同角色填出的内容处在同一颗粒度上。
目标客户与使用角色
目标客户描述购买或采用决策所指向的组织类型，写清规模、行业或业务形态中真正起筛选作用的条件，例如“50至500人、以项目制交付为主的软件服务公司”。使用角色描述日常操作产品的人及其任务场景，例如“项目经理负责排期与进度同步，交付负责人关注资源冲突”。两者分开写，是因为买单的人和天天用的人经常不是同一群。常见错误是把客户写成“有需求的团队”，这个描述无法排除任何人，也就无法指导后续决策。
核心问题与现有替代方式
核心问题写客户在当前状态下遭遇的具体损失或阻碍，落到可观察的现象，例如“多项目并行时进度信息分散在表格和聊天记录里，周会前需要人工汇总”。现有替代方式写客户今天实际怎么解决，包括手工表格、通用工具、内部流程或干脆不解决。写清替代方式，才能判断新方案要跨过的门槛是什么。常见错误是只写问题不写替代，导致差异化价值缺少比较对象。
差异化价值与证据
差异化价值回答“相比替代方式，客户为什么选我们”，写成对客户结果的影响，例如“把跨项目进度汇总从每周半天压缩到随时可查”。价值证据是支撑这句话的事实来源，可以是试用反馈、访谈记录、历史数据或可演示的能力，写清证据类型和时间范围。常见错误是把功能罗列当价值，或写了价值却没有可核对的依据。证据不足时，如实标注“待验证”，比编一个数字更有利于后续评审。
边界与不做什么
边界写清当前阶段明确不覆盖的客户类型、场景或能力方向，例如“暂不覆盖纯个人任务管理场景”。这一行的作用是减少误接需求和对外承诺偏差。常见错误是把边界写成永久战略，边界应随阶段调整，并注明适用版本或时间。
成功判断信号
成功信号写定位成立时可观察到的变化，尽量选团队已有数据能反映的指标，例如目标角色的周活跃比例、试用转正式使用的比例、销售场景中被客户主动引用的价值点。信号用于定期回看定位是否仍然成立，不承担完整指标体系的功能。
前提与假设
把定位成立所依赖的条件写出来，例如“目标客户已具备基本的数字化协作习惯”“渠道合作方能在本季度完成接入”。假设被推翻时，定位需要重新讨论，这一行是触发更新的重要线索。
必填与选填：最小可用版本怎么定
定位说明不必一次填满。早期版本的目标是让核心判断显性化，正式评审版本才需要完整证据。下表给出建议划分，团队可以按自身阶段调整，这里不构成统一强制要求。
| 字段 | 早期版本 | 正式评审版本 | 说明 |
|---|---|---|---|
| 产品名称与版本 | 必填 | 必填 | 标明适用版本，便于后续比对 |
| 一句话定位 | 必填 | 必填 | 早期可先写草稿，评审时定稿 |
| 目标客户 | 必填 | 必填 | 需具备可筛选条件 |
| 使用角色 | 必填 | 必填 | 至少写清一个主要角色 |
| 核心问题 | 必填 | 必填 | 落到可观察现象 |
| 现有替代方式 | 必填 | 必填 | 缺少替代方式时差异化无从比较 |
| 差异化价值 | 必填 | 必填 | 写成对客户结果的影响 |
| 价值证据 | 选填 | 必填 | 早期可标注“待验证” |
| 边界与不做什么 | 必填 | 必填 | 至少写一条明确边界 |
| 成功判断信号 | 选填 | 必填 | 正式版本需可回看 |
| 前提与假设 | 选填 | 必填 | 作为更新触发线索 |
| 负责人、评审人与更新日期 | 必填 | 必填 | 明确维护责任 |
早期版本的最小集合是：产品名称与版本、一句话定位、目标客户、使用角色、核心问题、现有替代方式、差异化价值、边界与不做什么、维护信息。这九项足以支撑一次方向讨论。价值证据、成功判断信号和前提与假设可以在有数据或进入正式评审前补齐。需要提醒的是，选填不等于可以不写，而是允许先以“待验证”占位，并在文档中标注补齐时间。
填写示例：一份完整的产品定位说明
以下示例为演示情景，用于说明字段如何落到具体表述，不代表任何真实产品或真实案例。示例产品设定为一款面向项目制服务公司的项目协作工具，处于正式评审阶段。
| 字段 | 填写内容 |
|---|---|
| 产品名称与版本 | 协作工具 X，2.0 版本定位说明 |
| 一句话定位 | 为项目制服务公司的交付团队提供跨项目进度与资源视图，让周会准备从半天缩短到随时可查 |
| 目标客户 | 50至500人、同时运行多个客户项目的软件与咨询服务公司 |
| 使用角色 | 项目经理负责排期与风险上报；交付负责人关注多项目资源冲突；一线成员更新任务状态 |
| 核心问题 | 多项目并行时进度分散在表格和聊天记录中，周会前需人工汇总，资源冲突往往在延期后才被发现 |
| 现有替代方式 | 电子表格加即时通讯群；部分团队使用通用任务工具，但缺少跨项目资源视图 |
| 差异化价值 | 把跨项目进度与人员负载放在同一视图，冲突在排期阶段即可识别，减少周会前的汇总工作 |
| 价值证据 | 12家试用团队的访谈记录（本季度），其中9家反馈周会准备时间明显下降；演示环境可复现资源冲突提示 |
| 边界与不做什么 | 当前不覆盖个人任务管理场景；不提供财务结算与合同管理；暂不支持跨组织的外部协作 |
| 成功判断信号 | 目标角色周活跃比例、试用转正式使用比例、客户在续约沟通中主动引用资源视图价值 |
| 前提与假设 | 目标客户已使用统一的任务记录方式；渠道伙伴能在本季度完成首批客户接入 |
| 负责人、评审人与更新日期 | 产品负责人张某；评审人含交付负责人与销售负责人；更新日期为本次评审日期 |
对应的一句话定位成稿：
“我们为50至500人的项目制服务公司中的交付团队，解决多项目并行时进度分散、资源冲突发现滞后的问题；相比表格加聊天群的替代方式，我们提供跨项目进度与资源负载的统一视图，依据是本季度试用团队的访谈反馈；我们当前不做个人任务管理、财务结算与跨组织外部协作。”
对照示例可以看出，每个字段都写成了可核对的具体表述：目标客户有筛选条件，核心问题有可观察现象，证据标注了来源类型和时间范围，边界列出了三条明确排除项。读者可以按同样颗粒度替换成自己产品的内容。
调整与维护：版本、评审与更新触发条件
定位说明写完即过期是常见问题。把维护规则一并写进文档，比事后补救更省力。以下规则清单可按团队情况取舍。
版本与变更记录
在文档末尾保留变更记录表，记录版本号、修改字段、修改原因、修改人和日期。修改原因要写清是证据变化、假设被推翻还是边界调整，便于后来者理解判断依据。每次正式评审后升一个版本号，草稿阶段的修改可合并记录。
评审参与角色与节奏
评审至少覆盖产品、交付或服务、销售三类角色，分别对应“能不能做”“交付是否可行”“客户是否买账”三个视角。节奏上，建议在版本规划启动时评审一次，在阶段性复盘时回看一次；节奏由团队按发布周期确定，不必固定为统一频率。评审的产出是明确的结论：维持、修订或重写，而不是一次讨论会。
触发更新的信号
出现以下情况时，应主动发起定位回看：目标客户的实际构成与表中描述明显偏离；价值证据被新数据推翻或长期无法补齐；边界内出现高频需求，说明边界可能需要调整；前提与假设中的条件不再成立；成功判断信号连续多个周期未出现变化。把这些信号写进文档，能让更新从被动救火变成有据可依的动作。
与需求排序、项目组合管理的分工
定位说明回答方向问题，不承担具体需求的排序与价值评估，也不负责项目投资组合的取舍与资源分配。实践中，定位说明常作为需求评审的输入：需求是否符合目标客户与核心问题，可以直接引用表中字段判断；而多个项目之间如何分配资源，属于项目组合管理的范围。把这两类决策分开记录，能避免定位文档被写成需求清单。
当定位说明需要在多人之间协作评审、并与具体需求建立关联时，可以把它放进支持文档协作与工作项关联的工具中管理。例如在 ONES 中，定位说明可作为文档承载评审意见与版本记录，相关需求以工作项形式关联到对应文档，评审结论和后续需求讨论留在同一处，减少定位文档与需求列表各存一份、彼此脱节的情况。是否采用工具承载取决于团队已有的协作方式，文档本身的结构与字段不受工具影响。
常见问题
早期版本只有九项必填字段，评审时会不会因为证据不足被质疑？
早期版本的作用是让核心判断显性化，评审关注的是目标客户、核心问题与差异化价值之间是否自洽，而不是证据是否齐全。价值证据一栏可以先写“待验证”，并在文档中标注计划补齐的时间和数据来源，例如计划在下一轮试用访谈后补充。这样评审时讨论的是判断本身，而不是被空缺字段卡住。
如果评审方要求完整证据，可以把正式评审版本的字段要求提前，先补齐价值证据与成功判断信号再上会。
目标客户一栏写到什么颗粒度才算可筛选？
判断标准是这行描述能否直接排除一部分对象。写“50至500人、以项目制交付为主的软件服务公司”，就能排除个人用户、非项目制团队和规模明显不符的组织；写“有协作需求的团队”则无法排除任何人。
如果团队对行业或规模还没有把握，可以先写当前已成交客户中重复出现的共同特征，并在前提与假设中注明这一判断尚待验证。
定位说明和需求排序、项目组合管理之间怎么衔接？
定位说明回答方向问题，需求评审时可以引用表中的目标客户与核心问题判断某条需求是否符合当前方向；多个项目之间如何分配资源，属于项目组合管理的范围。两类决策分开记录，定位文档就不会被写成需求清单。
实践中可以在需求评审材料中直接引用定位说明的字段，评审结论回写到定位文档的变更记录里，形成可追溯的衔接。
边界与不做什么写成了永久战略，后续怎么调整？
边界应随阶段调整，填写时注明适用版本或时间范围，例如“当前版本不覆盖个人任务管理场景”。当边界内出现高频需求，或目标客户构成发生变化时，就应发起定位回看，把边界调整作为一次正式变更记录下来。
调整边界时同步检查差异化价值是否仍然成立，避免只改排除项而留下前后矛盾的表述。
定位说明放在文档里协作评审，和放在表格里各存一份有什么区别？
定位说明需要多人评审、保留版本记录，并与具体需求建立关联。放在支持文档协作与工作项关联的工具中管理，评审意见、版本记录和相关需求可以留在同一处，减少文档与需求列表各存一份、彼此脱节的情况。例如在 ONES 中，定位说明可作为文档承载评审意见与版本记录，相关需求以工作项形式关联到对应文档。
是否采用工具承载取决于团队已有的协作方式，文档本身的结构与字段不受工具影响。
