产品定位说明要回答四个问题：为谁解决什么问题、提供什么独特价值、凭什么做到、不做什么。编写时先收集客户与竞品证据，用一句话定位句收敛方向，再展开目标客户、问题场景、价值主张、差异化依据与边界，最后经跨部门评审确认并纳入版本管理。本文按编写步骤、字段口径、角色分工、示例和完成检查展开，交付一份可被销售、研发、市场共同引用的文档，篇幅控制在一到三页。
要点总览（TL;DR）
- 产品定位说明要回答四个问题：为谁解决什么问题、提供什么独特价值、凭什么做到、不做什么，四项缺一项就容易写成功能清单或口号。
- 编写顺序从证据到判断：先收集客户访谈、赢单丢单原因和竞品资料，再用一句话定位句收敛方向，随后展开字段并组织跨部门评审。
- 字段固定为目标客户、问题场景、价值主张、差异化依据、不做什么、成功判据六项，每项写清口径和颗粒度，并做定位句与字段的一致性核对。
- 评审以目标客户可识别、价值可验证、边界清晰、与路线图一致为通过标准；目标客户过宽、差异化无依据、与现有产品线冲突属于阻断项。
- 定稿后约定版本记录与更新触发条件，让销售、研发、市场引用同一份口径，并按成功判据定期复盘定位是否仍然成立。
产品定位说明的核心答案与编写步骤
产品定位说明是一份方向性文档，作用是在团队内部形成对“这个产品为谁存在、靠什么赢”的共同判断。它需要同时回答四个问题：目标客户是谁、在什么场景下遇到什么问题；产品提供的独特价值是什么；凭什么能够兑现这个价值；明确不做什么。四个问题缺一项，文档就容易变成功能罗列或口号。
编写顺序建议从证据到判断、从一句话到展开字段。先用一句话定位句把方向收敛，再逐字段展开，可以避免写到一半发现方向摇摆。常用定位句结构为：面向[目标客户]，在[问题场景]下，提供[核心价值]，区别于[替代方案]，因为[差异化依据]。例如演示情景：“面向20至200人规模的项目型团队，在跨部门任务交接频繁、进度信息分散的情况下，提供统一的任务与文档协作空间，区别于以即时消息为主的沟通工具，因为产品把任务状态、文档版本和责任人放在同一工作项下流转。”这句话中的规模、场景和对比对象都是示例设定，实际编写时须替换为本产品的真实证据。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集证据 | 客户访谈记录、流失与赢单原因、竞品资料、销售一线反馈 | 按客户类型和问题场景归类，标注每条证据的来源与出现频次 | 证据清单，含客户画像线索与竞品替代关系 | 每个目标客户类型至少有若干条独立证据支撑，而非单一客户印象 |
| 2. 写定位句 | 证据清单 | 按“面向……在……下，提供……区别于……因为……”结构写出一到三版候选句 | 候选定位句 | 每句都能对应到证据清单中的具体条目 |
| 3. 展开字段 | 候选定位句、证据清单 | 逐字段填写目标客户、问题场景、价值主张、差异化依据、不做什么、成功判据 | 定位说明初稿 | 字段之间相互一致，定位句中的每个成分都能在展开字段中找到对应 |
| 4. 跨部门评审 | 初稿 | 组织销售、研发、市场、客户成功评审，逐条确认或提出修改 | 评审意见与修订稿 | 阻断项清零，争议点有明确结论 |
| 5. 定稿与版本管理 | 修订稿 | 确认最终版本，记录版本号、生效日期与变更说明 | 可发布的定位说明 | 文档进入团队共享位置，相关角色知晓引用方式 |
常见误区有三类。第一类是功能清单化：把产品功能逐条列出，读者看完仍不知道产品为谁服务。判断方法是检查每个功能描述能否回答“这对哪类客户解决什么问题”，不能回答的应删除或改写。第二类是口号化：使用“行业领先”“极致体验”等无法验证的表述，替代了具体的客户与场景。第三类是目标客户过宽：把“所有企业”或“所有团队”写进定位，导致后续价值主张和差异化依据无法聚焦。目标客户应写到可被销售用来判断“这个客户是不是我们的客户”的颗粒度。
定位说明的字段结构与填写要点
字段结构决定文档能否被不同角色直接引用。建议固定六个字段，每个字段写清口径和颗粒度，避免同一份文档里有的字段写得很细、有的只有一句话。
| 字段 | 填写口径 | 颗粒度要求 | 示例（演示情景） |
|---|---|---|---|
| 目标客户 | 描述客户的组织特征、角色特征与使用情境，而非笼统行业名称 | 销售能据此判断客户是否匹配；通常写一到两类核心客户 | 20至200人、以项目交付为主的中小团队，主要使用者为项目经理与执行成员 |
| 问题场景 | 写客户在什么工作环节、遇到什么具体阻碍、造成什么后果 | 场景可被复述，后果可被观察或度量 | 跨部门任务交接依赖群聊和表格，进度信息分散，交接遗漏导致返工 |
| 价值主张 | 产品帮助客户获得的结果，用客户语言表达 | 一条主张对应一个核心结果，避免并列堆叠多个卖点 | 任务、文档与责任人在同一工作项下流转，减少交接遗漏 |
| 差异化依据 | 说明凭什么做到，包括能力、资源、数据或组织方式 | 每条依据可被验证或至少可被内部举证 | 产品将任务状态与文档版本绑定在同一工作项，替代方案通常需要多个工具拼接 |
| 不做什么 | 明确当前阶段不覆盖的客户类型、场景或能力方向 | 写出边界及原因，便于销售和研发据此拒绝或转交 | 当前阶段不面向以个人轻量记录为主的用户，也不做通用即时通讯 |
| 成功判据 | 定位生效后可观察的信号，如目标客户赢单率、使用深度、转介绍比例 | 指标与定位直接相关，可在一定周期内观察 | 目标客户类型的赢单原因中，“交接与进度可见”出现频次上升 |
字段填写时需区分证据与判断。目标客户、问题场景、差异化依据应尽量引用证据，例如访谈记录、赢单分析或竞品对比；价值主张和成功判据更多是团队判断，需要在评审中达成共识。判断类内容不必伪装成数据，但应写明判断依据，方便后续复盘时修正。
定位句与展开字段的一致性检查是定稿前的必要动作。逐项核对：定位句中的目标客户是否与“目标客户”字段一致；问题场景是否在“问题场景”字段中有对应描述；核心价值是否与“价值主张”字段同义；差异化依据是否在对应字段中有展开；“不做什么”是否与定位句的边界不冲突。任何一项对不上，优先修改定位句或字段，而不是在两处各写一套说法。
角色分工与交付物
定位说明写完却无人认账，通常是因为角色分工不清。建议由产品负责人主笔并对最终内容负责，其他角色提供输入和确认，评审责任与主笔责任分开：主笔负责整合与成文，评审角色负责在自己熟悉的领域确认事实与可行性。
| 角色 | 提供的输入 | 确认事项 | 交付物 |
|---|---|---|---|
| 产品负责人 | 产品方向判断、路线图约束、历史定位资料 | 对全文内容与边界负最终责任 | 定位说明初稿与定稿 |
| 市场 | 市场细分信息、竞品传播口径、客户认知调研 | 价值主张与对外表达是否一致、差异化依据是否可公开使用 | 市场侧评审意见 |
| 销售 | 赢单与丢单原因、客户异议、目标客户实际画像 | 目标客户是否可识别、边界是否可用于客户筛选 | 客户证据清单与销售侧确认 |
| 研发 | 能力现状、技术约束、交付节奏 | 差异化依据是否有能力支撑、成功判据是否可观测 | 能力可行性确认 |
| 客户成功 | 使用深度数据、续约与流失原因、典型使用场景 | 问题场景是否与实际使用一致、成功判据是否可跟踪 | 使用侧证据与复盘输入 |
文档版本与更新触发条件应提前约定。常见触发条件包括：目标客户类型发生调整、核心价值主张变化、主要竞品替代关系改变、路线图出现与定位冲突的重大调整。版本记录至少包含版本号、变更内容、变更原因和生效日期，避免不同角色引用不同时期的旧版本。更新时保留历史版本，便于回溯定位判断的演变过程。
当定位说明需要在多个角色之间反复确认时，可以把评审意见、修订任务和版本记录放进统一的工作项与文档空间。以ONES为例，定位说明可作为文档承载，评审意见以工作项或评论形式挂接到对应章节，修订状态和责任人可见，定稿后版本记录与关联需求保持在同一处，减少销售、研发、市场各自保存副本造成的口径不一致。这一衔接适用于需要跨角色确认和版本追溯的团队；规模很小、角色重合的团队用共享文档加简单版本记录也能完成。
示例：一份消费级与一份企业级定位说明
以下两份示例均为演示情景，用于展示不同业务形态下字段写法的差异，不对应真实企业或真实数据。
示例一：面向中小团队的协作工具
目标客户：20至200人、以项目交付为主的中小团队，主要使用者为项目经理与执行成员。问题场景：任务分配依赖群聊，文档散落在个人网盘，交接时找不到最新版本，返工频繁。价值主张：任务、文档与责任人在同一工作项下流转，交接有据可查。差异化依据：工作项与文档版本绑定，替代方案通常需要沟通工具加网盘拼接。不做什么：当前阶段不面向以个人轻量记录为主的用户，不做通用即时通讯。成功判据：目标客户类型中，因“交接清晰”产生的赢单原因占比上升，新客户首月活跃使用工作项的比例提升。
这份示例的取舍在于：目标客户写到规模和业务形态，便于销售筛选；问题场景聚焦交接这一具体环节，没有铺开所有协作痛点；差异化依据落在产品结构而非功能数量上；“不做什么”明确排除了两类容易分散方向的对象。
示例二：面向大型企业的数据平台
目标客户：具有多业务线、需要统一数据口径的大型企业，主要使用角色为数据治理团队与业务分析人员。问题场景：各业务线分别建设报表，指标定义不一致，管理层看到的数字互相矛盾。价值主张：提供统一的指标定义与权限体系，让跨业务线的数据口径可对齐、可追溯。差异化依据：指标定义与权限模型在同一平台内配置，变更留痕，替代方案多为各业务线自建后人工对账。不做什么：当前阶段不承接单业务线的临时取数需求，不替代业务系统自身的交易处理。成功判据：接入业务线数量、指标口径争议工单数量下降、治理团队对账工时减少。
企业级示例的差异体现在：目标客户以组织特征和治理需求描述，而非规模数字；问题场景指向跨部门的口径冲突；差异化依据强调权限与留痕这类企业采购关心的能力；成功判据包含组织层面的协作成本变化。两份示例共同的写法规律是：每个字段都指向可识别的对象或可观察的结果，定位句与展开字段一一对应。这套写法适用于产品方向相对清晰的阶段；产品尚在探索期时，可以先写目标客户与问题场景两节，价值主张和差异化依据随证据积累再补全。
评审与完成检查
评审时点建议安排在初稿完成之后、对外使用之前。参与角色包括产品负责人、市场、销售、研发和客户成功，评审以逐字段确认为主，避免变成对文档措辞的泛泛讨论。评审前把初稿和证据清单提前发给参与者，评审中只处理有分歧或缺少依据的条目。
通过标准可归纳为四条：目标客户可识别，销售能据此判断客户是否匹配；价值可验证，价值主张能对应到可观察的客户结果；边界清晰，“不做什么”能用于拒绝不匹配的需求；与路线图一致，差异化依据有当前或规划中的能力支撑。四条同时满足才可发布使用。
| 检查项 | 核验方式 | 结论 |
|---|---|---|
| 目标客户是否可识别 | 请销售用一句话判断某客户是否属于目标客户 | 通过 / 需修改 |
| 问题场景是否有证据 | 抽查证据清单，每个场景至少对应若干条独立来源 | 通过 / 需修改 |
| 价值主张是否可验证 | 确认成功判据可被跟踪，且有观察周期 | 通过 / 需修改 |
| 差异化依据是否有支撑 | 研发确认能力现状或规划，市场确认可公开使用 | 通过 / 需修改 |
| 边界是否清晰 | 用“不做什么”测试若干真实需求，判断能否直接答复 | 通过 / 需修改 |
| 与路线图是否一致 | 对照当前路线图，确认无方向冲突 | 通过 / 需修改 |
| 定位句与字段是否一致 | 逐项核对定位句各成分在字段中的对应 | 通过 / 需修改 |
阻断项包括：目标客户过宽，导致价值主张无法聚焦；差异化无依据，仅凭主观判断宣称优势；与现有产品线冲突，造成内部定位重叠或客户混淆。出现任一阻断项，文档不进入发布环节，先补充证据或调整方向。
发布后的使用方式应明确：销售在客户筛选和方案沟通中引用目标客户与价值主张；市场对外表达以定位说明为口径来源；研发在评估需求时用“不做什么”判断是否属于当前方向。复盘可结合成功判据按季度或半年度进行，观察定位是否仍然成立，并据此触发版本更新。定位说明的价值在于被持续引用和修正，定稿只是开始。
常见问题
产品还处在探索期，定位说明要不要等方向清晰了再写？
不必等。探索期可以先写目标客户和问题场景两节，这两节依赖客户访谈和一线反馈，证据相对容易获得；价值主张和差异化依据可以写成待验证的假设，并标注验证方式与时间点。这样文档能先用于客户筛选和访谈提纲，随着证据积累再补全其余字段。需要避免的是在证据不足时把假设写成确定结论，导致后续评审无法区分哪些是已验证事实、哪些是团队判断。
定位说明和产品路线图出现冲突时，应该改哪一个？
先判断冲突的性质。如果路线图上的投入与定位中的差异化依据方向一致，只是节奏不同，通常调整路线图排期即可；如果路线图正在投入定位中明确“不做什么”的方向，说明两者必有一方需要修正。处理方式是把冲突条目带到评审中，由产品负责人判断是定位边界需要放宽，还是路线图中的需求应移出当前范围。无论哪种结论，都要同步更新文档和版本记录，避免两个文件长期各说一套。
销售和市场对价值主张的表述不一致，怎么收敛？
先确认分歧来自事实还是措辞。可以让双方各自用一句话说明目标客户最关心的结果，再对照证据清单看哪种表述有客户原话或赢单原因支撑。有证据支撑的表述作为基准，另一方调整为同一含义的不同场景说法，而不是另起一套卖点。若分歧涉及对外可公开使用的范围，由市场确认合规口径，销售在方案沟通中使用同一核心主张。收敛结果写回定位说明的价值主张字段，并在评审意见中记录结论。
团队规模小、角色高度重合，还需要走完整的评审流程吗？
可以简化形式，保留关键动作。角色重合时，评审可以合并为一次集中确认，但仍建议完成三件事：用证据清单核对目标客户和问题场景是否有支撑；请负责交付的成员确认差异化依据在能力上成立；用若干真实需求测试“不做什么”能否直接答复。完成检查清单中的核验方式可以照常使用，只是参与人减少。文档篇幅和版本记录也可相应精简，但更新触发条件仍应写明，避免产品方向调整后无人更新。
定位说明定稿后，怎么判断它是否真的在起作用？
看成功判据是否出现可观察的变化，以及文档是否被实际引用。可观察的信号包括目标客户类型的赢单原因中定位所述价值出现频次上升、销售在客户筛选中使用目标客户描述、研发用“不做什么”答复范围外需求。若文档定稿后无人引用，或各角色仍按各自理解对外表达，说明定位尚未真正落地，需要检查评审是否达成共识、文档是否放在大家都能找到的位置。复盘周期可按季度或半年度安排，结合成功判据判断是否需要触发版本更新。
