价值主张提炼的核心，是把三块输入拼成一句可验证的话：用户反复出现且愿意付出代价解决的痛点、用户当前实际使用的替代方案及其缺口、自身相对替代方案能被感知的收益。本文按“收集痛点—盘点替代方案—写候选表述—用户验证”的顺序给出操作步骤、记录字段、角色分工和完成检查，适用于产品负责人或产品经理为一款已有初步方向的产品定稿价值主张。
要点总览（TL;DR）
- 价值主张提炼需要三类可追溯的输入：用户痛点证据、现有替代方案清单、相对替代方案的差异化收益证据，最终收敛为一句包含目标用户、场景、痛点和可感知结果的话。
- 痛点按统一字段记录并综合出现频次、代价大小、用户愿意改变的程度排序；替代方案覆盖手工流程、表格、内部自建、竞品和放弃不做，从对照中找出用户在意且普遍未被解决的缺口。
- 差异化收益需同时满足可感知、可说明、用户在意三个条件；同一产品面向不同角色应分别写版本，各自对应独立的证据。
- 验证采用用户复述测试、文案A/B或方案介绍反馈，观察能否复述、是否认同痛点、是否愿意尝试；不通过时按失败类型回到对应步骤调整并复测。
- 定稿前逐项核对痛点证据、替代方案完整性、收益成立性、用户验证结果和复测计划，全部通过后归档陈述卡与验证记录。
先明确价值主张的输入与产出
开始访谈或写文案之前，先把要准备的材料和最终交付物定清楚，能避免团队各写各的、讨论时缺少共同依据。价值主张提炼的最终产物是一句话，但支撑这句话的是三类可追溯的证据。
价值主张一句话建议包含四个成分：目标用户是谁、在什么场景下、遇到什么问题、使用后获得什么可感知的结果。四个成分缺一项，表述就容易变成口号。例如“为需要每周汇总多项目进度的项目经理，在跨团队汇报前，解决信息分散在多个表格导致汇总耗时的问题，把汇总准备时间从半天压缩到一小时内”，比“提升协作效率”更容易被用户判断真假。
三类输入及其最低要求如下：
| 输入类别 | 要回答的问题 | 最低证据要求 |
|---|---|---|
| 痛点证据 | 哪些用户在什么场景下反复遇到什么问题，付出了什么代价 | 来自真实用户的访谈记录或场景观察，含具体事件，而非内部推测 |
| 替代方案清单 | 用户现在用什么办法解决，为什么仍不满意 | 覆盖手工流程、表格、内部自建、竞品、放弃不做等形态，逐个记录不满点 |
| 差异化收益证据 | 相对这些替代方案，我们带来什么用户在意且能感知的变化 | 能说明对比对象、变化内容和用户可观察的结果 |
产出物建议固定为两份：一份价值主张陈述卡，写明目标用户、场景、痛点、替代方案、差异化收益和一句话表述；一份验证记录表，记录每轮验证的对象、方式、用户反馈和修订内容。两份材料放在团队可共同访问的位置，后续讨论以它们为准。
第一步：从用户场景中收集痛点证据
痛点证据的质量决定后面所有步骤是否成立。收集时以“最近一次发生”的具体事件为入口，请用户描述当时做了什么、卡在哪里、花了多少时间或付出了什么其他代价，避免直接问“你觉得这个功能有用吗”这类引导性问题。
取样上，优先覆盖正在经历该场景的用户，而不是泛泛的潜在用户。访谈数量以能听到重复模式为准，当新增访谈不再出现新的痛点类型时，可以暂停补充。场景观察适合补充用户说不清的部分，例如用户已经习惯的绕行做法，往往在访谈中不会被主动提起。
每条痛点按统一字段记录，便于后续排序和比对：
| 字段 | 记录内容 | 示例（演示情景） |
|---|---|---|
| 用户角色 | 岗位、职责范围、使用频率 | 项目经理，同时跟进4个项目，每周做一次跨团队汇报 |
| 场景 | 发生的时间、地点、协作对象 | 每周五下午汇总各团队进度，准备周会材料 |
| 触发事件 | 什么情况让问题暴露出来 | 某团队临时调整排期，原表格未同步，会上被追问 |
| 当前做法 | 用户现在怎么应对 | 逐个私聊负责人收集进度，手工粘贴到汇总表 |
| 代价 | 时间、返工、沟通成本或风险 | 每次约3小时，且信息滞后一天 |
痛点排序综合三个依据：出现频次（多少受访者提到同类问题）、代价大小（时间、返工或业务风险）、用户愿意改变的程度（是否已经在寻找替代办法、是否愿意试用新方案）。三项都强的痛点进入候选清单前列；只有频次高但用户明确表示“凑合能用、不想换”的痛点，优先级下调。排序结果形成痛点清单，标注每条痛点的证据来源，供后续评审核对。
第二步：盘点现有替代方案与未满足缺口
用户解决痛点的方式往往不止竞品一种。替代方案的范围应至少覆盖五类：手工流程、电子表格、内部自建工具、外部竞品、以及“放弃不做、接受现状”。前四类决定用户对成本和体验的参照系，最后一类说明痛点的紧迫程度是否足够。
对每个替代方案记录三项内容：使用方式（用户具体怎么操作）、成本（采购或维护费用、人力投入、学习成本）、用户不满点（用户明确抱怨或绕开的地方）。不满点要引用用户原话或具体行为，例如“每次都要手动导出再合并”，而不是概括为“体验不好”。
| 替代方案 | 使用方式 | 成本 | 用户不满点 |
|---|---|---|---|
| 手工汇总 | 私聊收集后粘贴到表格 | 每周约3小时 | 信息滞后，容易漏项 |
| 共享表格 | 各团队自行填写 | 搭建成本低 | 格式不统一，需要人工核对 |
| 内部自建看板 | 技术团队开发维护 | 开发与维护人力 | 字段固定，业务调整后跟不上 |
| 外部竞品 | 采购标准化工具 | 订阅费用与迁移成本 | 与现有流程衔接需要额外配置 |
| 放弃不做 | 会上口头同步 | 无直接成本 | 决策依据不足，返工多 |
缺口从对照中推导：把痛点清单与替代方案的不满点逐条比对，找出“用户在意、现有方案普遍没解决或解决得代价很高”的位置。缺口描述要具体到场景和结果，例如“跨团队进度在汇报前无法自动汇总，导致每次汇报都要人工核对”，这样的缺口才能直接支撑下一步的收益表述。若某个缺口只有单一用户提及且代价有限，先标记为待观察，不进入价值主张主线。
第三步：把差异化收益写成可检验的价值主张
差异化收益的判定有三个条件，同时满足才写入价值主张：相对用户当前使用的替代方案可感知（用户能说出前后差别）、可说明（团队能用事实或演示解释清楚）、用户在意（对应痛点清单中排序靠前的问题）。只满足“我们做得更好”而用户感知不到的改进，适合放在产品说明里，不适合作为价值主张的主句。
组装时套用句式：“为【目标用户】，在【场景】下，解决【痛点】，带来【可感知结果】。”写完后逐项检查：目标用户是否具体到角色和处境；场景是否是真实发生的事件；痛点是否来自证据清单；结果是否可以被用户观察或衡量。常见写法错误有两类：一是用空泛形容词代替结果，如“更高效、更智能”；二是把功能清单塞进一句话，如“支持看板、报表、提醒和权限管理”，用户无法从中判断自己能得到什么。
同一产品面向不同角色时，应分别写版本。仍以进度汇总为例：面向项目经理的版本强调汇报准备时间和信息准确性；面向团队负责人的版本强调减少被反复催问、填报一次即可复用。两个版本共享同一产品能力，但痛点、场景和结果各自对应不同角色的证据，不能互相套用。
本步骤的交付物是1至3条候选价值主张陈述，每条附上对应的痛点编号、替代方案缺口和收益证据来源，填入价值主张陈述卡，进入验证环节。
用用户反馈验证价值主张
价值主张是否成立，由目标用户判断，内部讨论只能筛掉明显不合格的表述。验证方式可选三种，按成本从低到高排列：用户复述测试，向受访者读出候选表述，请其用自己的话复述并指出哪部分符合其实际情况；文案A/B，将两条候选表述分别用于介绍页或方案文档，观察用户的理解和询问方向；落地页或方案介绍反馈，用真实材料收集用户是否愿意留下联系方式或预约演示。
观察三个指标：用户能否准确复述主张的核心意思；用户是否认同所描述的痛点（能补充自己的类似经历）；用户是否表达愿意尝试或进一步了解。三项中复述失败通常说明表述本身有问题，认同失败说明痛点选择有偏差，愿意尝试比例低则需要检查收益是否足够具体。这里不设统一的量化阈值，团队应结合受访者数量和业务阶段自行约定判断口径，并记录在验证记录表中。
不通过时按失败类型调整：复述失败，改写句式和用词，减少抽象名词；痛点不认同，回到第一步补充访谈，替换痛点；收益无感，回到第二步核对替代方案缺口，换一个用户更在意的结果。每次调整后保留原版本，用同一批问题复测，避免不同轮次口径不一致导致结论无法比较。
痛点记录、替代方案调研和每轮验证反馈需要被团队持续查阅和追溯。在ONES中，可以将访谈记录和调研结论整理为文档，将待验证的候选表述和用户反馈登记为工作项，按轮次关联，使每次修订都能对应到具体证据和反馈来源，评审时直接查看记录即可。
角色分工与交付物清单
提炼过程涉及多个角色，分工不清时容易出现访谈做了但没人整理、表述写了但没人验证的情况。以下分工按步骤划分，团队规模较小时可由一人兼任多个角色，但职责和交付物仍需明确。
| 角色 | 主要职责 | 参与的步骤 |
|---|---|---|
| 产品负责人 | 牵头组织提炼，主持评审，对最终价值主张定稿 | 全流程，重点在S1、S4、S6 |
| 用户研究 | 设计访谈提纲，执行访谈与场景观察，整理痛点清单 | S2，协助S5 |
| 市场/销售 | 提供客户反馈和竞品使用情况，补充替代方案信息，参与验证材料投放 | S3、S5 |
| 设计 | 负责表述的可读性打磨和验证材料呈现 | S4、S5 |
各阶段交付物与交接方式：S2结束时交付按优先级排序的痛点清单，由用户研究提交产品负责人确认；S3结束时交付替代方案对照表与缺口清单，由产品负责人组织市场/销售共同核对；S4结束时交付候选价值主张陈述卡，进入评审；S5结束时交付验证记录与修订版本。评审节点建议设在候选表述形成后和首轮验证完成后两处，由产品负责人决策是否进入下一阶段或退回补充证据。所有交付物集中存放，版本按轮次标注。
示例：一款协作工具的价值主张提炼过程
以下为演示情景，用于说明方法步骤，不代表真实客户案例或实测结果。
某协作工具团队计划面向中型研发团队推广。用户研究访谈了8位项目经理和团队负责人，按字段整理出痛点清单，排序靠前的两条是：跨团队进度汇总依赖人工收集，每周耗时数小时且信息滞后；任务状态更新后，相关人无法及时获知，导致返工。两条痛点均有多次提及和具体事件记录。
替代方案盘点发现，用户主要使用共享表格加即时通讯工具组合：表格负责记录，沟通工具负责催办。不满点集中在格式不统一需人工核对、状态变化靠人主动询问。内部自建看板的用户则抱怨字段调整需要排开发资源。缺口因此定位为“状态变化无法自动同步到相关人，汇总仍需人工完成”。
候选表述初稿为：“为研发项目经理，在每周跨团队汇报前，解决进度信息分散、汇总耗时的问题，让汇报材料自动生成。”首轮复述测试中，多位受访者能复述“自动汇总”，但对“自动生成”是否包含格式调整提出疑问，且部分团队负责人表示自己更关心被催办的次数。团队据此拆分为两个版本：项目经理版改为“把汇总准备时间从半天缩短到一小时内，信息与各团队最新状态一致”；团队负责人版改为“任务状态更新一次，相关人自动获知，减少重复催问”。修订版在第二轮复述测试中复述准确率明显提升，受访者能补充自己的类似经历，并有多人愿意进一步了解。团队将两版表述和验证记录归档，约定产品上线后一个月复测一次。
完成检查：价值主张是否可用
定稿前逐项核对以下清单，任一项不满足则退回对应步骤补充，不带着缺口进入对外传播。
- 痛点是否有用户证据支撑：每条痛点能追溯到具体访谈记录或场景观察，含角色、场景、触发事件、当前做法和代价。
- 替代方案是否盘点完整：覆盖手工流程、表格、内部自建、竞品和放弃不做，每个方案有使用方式、成本和不满点记录。
- 差异化收益是否相对替代方案成立：能指出对比对象，说明变化内容，且该结果在痛点清单中排序靠前。
- 表述是否通过用户验证：目标用户能准确复述，认同痛点描述，并表达愿意尝试或进一步了解。
- 多角色版本是否分别验证：面向不同角色的表述各自有对应证据和反馈，未互相套用。
- 是否有明确的后续复测计划：约定复测时间、对象和判断口径，并指定负责人。
清单全部通过后，将价值主张陈述卡、替代方案对照表和验证记录表一并归档，作为后续产品说明、销售材料和定位讨论的共同依据。
常见问题
团队规模较小、没有专职用户研究时，痛点证据怎么收集才够用？
可以由产品经理兼任访谈执行，但取样和记录方式不能省。优先找正在经历目标场景的用户，以“最近一次发生”的具体事件为入口提问，按角色、场景、触发事件、当前做法、代价五个字段逐条记录。访谈数量以不再出现新的痛点类型为暂停信号。需要留意的是，兼任访谈的人容易在提问中带入自己的方案假设，建议请一位同事旁听或复核访谈记录，检查问题是否带有引导性。
用户说现有方案“凑合能用”，这类痛点还要不要写进价值主张？
要看用户愿意改变的程度。频次高但用户明确表示不想更换方案的痛点，排序时应下调，不宜作为价值主张主句。可以把它标记为待观察，继续收集是否有用户已经在主动寻找替代办法、是否愿意试用。若后续访谈中出现愿意改变的用户群体，再重新评估其优先级。价值主张面向的是有改变意愿的那部分目标用户。
验证时受访者出于礼貌说“挺好的”，如何判断反馈是否真实？
把问题从评价改为复述和行为意向。请受访者用自己的话复述主张的核心意思，并补充自己是否有类似经历，能补充具体事件说明痛点被认同。行为意向方面，观察用户是否愿意留下联系方式、预约演示或进一步了解，比口头认可更能反映真实兴趣。同时记录受访者提出的疑问和追问方向，这些往往指向表述中含糊或收益不具体的部分。
产品同时服务多个角色，价值主张需要写几版，怎么保证不互相冲突？
每个有独立痛点和场景证据的角色写一版，通常控制在两到三版。各版本共享同一产品能力，但目标用户、场景、痛点和可感知结果分别对应各自角色的证据，不能互相套用。为避免冲突，在陈述卡中标注每版对应的痛点编号和证据来源，评审时逐版核对；若某版找不到独立的痛点证据，说明该角色暂不需要单独表述。
价值主张定稿后，什么情况下需要重新提炼？
出现以下情况时建议启动复测或重新提炼：目标用户群体发生变化，原有痛点证据不再覆盖新用户；主要替代方案发生明显变化，例如用户大规模转向新的解决方式；产品能力调整后差异化收益的对比基础改变；复测中用户复述准确率或愿意尝试的比例明显下降。复测沿用原有的问题口径和记录表，便于与上一轮结果比较，避免因口径不同得出错误结论。
