价值主张要回答的是：目标用户在什么场景下，为什么愿意选择你而不是现有做法。提炼时可以从三类信息入手：用户真实痛点、用户当前的替代方案及其缺口、你的方案能带来的差异化收益。本文按操作顺序给出提炼步骤、可填写的字段表、角色分工、用户反馈验证方法和定稿检查清单，帮助产品经理或产品负责人把一句听起来正确的口号，变成能被用户复述、被行为数据支持的定位表述。
要点总览（TL;DR）
- 提炼价值主张按四步推进：锁定目标用户与场景并收集痛点证据，盘点替代方案及其缺口，把差异化收益转写为用户可感知的结果，最后合成一句话并做内部一致性检查。
- 用字段表把痛点、替代方案缺口、差异化收益和验证指标逐行对应，每条痛点必须有证据来源，每条收益必须对应一个缺口。
- 初稿形成后用访谈复述、原型或落地页测试、行为数据三类反馈交叉验证，用户无法用自己的话复述通常说明表述偏内部视角。
- 验证不通过时按缺口回溯：检查痛点证据是否来自目标用户、替代方案缺口判断是否有误、收益表述是否可感知，每次只改一个变量并记录原因。
- 定稿前逐项核对痛点证据、缺口真实性、收益可验证性、用户反馈支持和内部理解一致，任何一项不通过都回到对应步骤修订。
提炼价值主张的核心步骤
提炼价值主张是一项有输入、有动作、有输出的工作，按四步推进即可形成可讨论的初稿。每一步都要留下书面产物，避免讨论停留在印象层面。
第一步：锁定目标用户与场景，收集痛点证据
输入是用户访谈记录、客服工单、销售丢单原因、行为数据等原始材料。动作是先明确一类具体用户和一类具体场景，例如“三人以下内容团队在每周选题会上整理素材”，再从材料中摘出用户描述困难的原话和可观察的行为。输出是一组带证据来源的痛点条目。完成标志是：每条痛点都能指回一条访谈原话、一条工单或一组数据，团队无法仅凭猜测新增条目。
这一步的关键是收窄。用户群体越宽，痛点越容易写成“效率低”“协作难”这类无法验证的判断。把场景写到具体任务和具体环节，痛点才会变得可核对。
第二步：盘点现有替代方案及其缺口
输入是第一步的痛点清单。动作是逐条问：用户现在怎么解决这个问题？替代方案包括竞品、自建表格或脚本、人工流程、外包，也包括用户干脆不解决、忍受现状。然后记录每种替代方案在哪些环节让用户不满意，例如需要重复录入、信息分散在多个文件、交接时容易遗漏。输出是“替代方案—缺口”对照记录。完成标志是每个缺口都能说明是哪类用户在哪个环节遇到的，而不是笼统的“体验不好”。
替代方案分析常被简化为竞品对比，实际上用户“不解决”也是一种强替代方案。如果用户愿意长期忍受某个问题，说明这个痛点的紧迫程度有限，价值主张就需要重新评估切入点。
第三步：把差异化收益转写为用户可感知的结果
输入是替代方案缺口清单和自身方案的能力。动作是把每项能力翻译成用户完成任务时的变化：少做哪一步、少等多久、少维护哪份表格、交接时多拿到什么信息。输出是“缺口—收益”一一对应的条目。完成标志是收益描述中不出现内部术语，用户读完能说出自己的哪项工作会发生变化。
例如“支持自定义字段”是功能描述，对应的收益应写成“新成员按现有表格结构录入，不需要为每个团队单独维护一套模板”。收益写得越接近用户的具体动作，后续验证越容易设计问题。
第四步：合成一句话价值主张并做内部一致性检查
输入是前三步的工作表。动作是按“为谁、在什么场景、解决什么缺口、带来什么可感知结果”的结构合成一句话，再检查这句话是否与痛点证据、替代方案缺口逐条对应。输出是价值主张初稿和一张三步提炼工作表。完成标志是产品、市场、销售三方对这句话的理解一致，且每个关键词都能在工作表中找到依据。
初稿不追求文采，追求可核对。一句话里如果出现无法对应到具体缺口的形容词，就删掉或替换成具体结果。
三步提炼工作表
| 模块 | 需要填写的内容 | 完成标志 |
|---|---|---|
| 痛点证据 | 用户角色、场景、痛点原话、证据来源 | 每条痛点可追溯到原始材料 |
| 替代方案缺口 | 当前做法、使用环节、留下的缺口 | 缺口能对应到具体用户和环节 |
| 差异化收益 | 对应缺口、用户可感知的结果、验证指标 | 每条收益对应一个缺口，且有指标 |
| 价值主张初稿 | 一句话表述、适用对象、适用场景 | 内部理解一致，可进入用户验证 |
痛点、替代方案与收益的对应表怎么填
把三类信息放进同一张表，是为了让每条收益都能追溯到痛点和缺口。表格按行组织，一行代表一个“用户—场景—缺口—收益”的完整链条，避免痛点、方案、收益各写各的。
字段设计与填写规则
| 字段 | 填写内容 | 填写规则 |
|---|---|---|
| 用户角色 | 具体岗位或身份，如“内容团队负责人” | 写到能对应一类真实用户，不写“所有用户” |
| 场景 | 具体任务和环节，如“每周选题会前整理素材” | 包含时间、任务和协作对象 |
| 痛点描述 | 用户遇到的具体困难 | 优先使用用户原话，避免内部概括 |
| 证据来源 | 访谈编号、工单号、数据口径 | 每条痛点必须有来源，无来源的条目单独标记待验证 |
| 当前替代方案 | 竞品、自建工具、人工流程或不解决 | 写清用户实际怎么操作 |
| 替代方案缺口 | 现有做法在哪个环节让用户付出额外成本 | 描述具体环节和代价，不写“不好用” |
| 差异化收益 | 用户完成任务时的可感知变化 | 对应一个缺口，写成结果而非功能 |
| 可验证指标 | 能观察到的行为或数据，如试用转化、任务完成时间 | 指标要能在验证阶段实际采集 |
填写时把握两条规则：每条痛点必须有证据来源，每条收益必须对应一个缺口。前者防止把团队猜测当成用户需求，后者防止收益写成功能清单。没有证据的痛点可以先放入“待验证”区，但不能直接进入价值主张初稿。
常见填写错误
- 把功能当收益：写“提供模板库”，应改为“新成员不用从空白页开始，按现有结构直接录入”。
- 把猜测当痛点：写“用户希望更快”，应替换为访谈中出现的具体等待环节和原话。
- 替代方案只写竞品：遗漏人工流程、表格和不解决，导致缺口判断不完整。
- 收益与缺口脱节：收益描述很吸引人，但对应不到任何一条替代方案缺口，说明它可能不是用户当前最在意的问题。
角色分工与各阶段交付物
价值主张提炼需要多角色参与，但不必设复杂流程。小团队可由产品经理牵头并兼任用户研究，大团队再按下列分工拆分。关键是每个阶段有明确负责人和交接物，避免访谈记录停留在个人手里。
| 阶段 | 主要负责角色 | 交付物 | 交接节点 |
|---|---|---|---|
| 痛点收集 | 用户研究主导，产品经理、销售配合 | 带来源的痛点清单 | 痛点清单评审通过后进入替代方案分析 |
| 替代方案分析 | 产品经理主导，市场与销售提供竞争和客户信息 | 替代方案—缺口对照表 | 缺口确认后进入收益转写 |
| 收益转写 | 产品经理主导，研发确认可实现性 | 缺口—收益对应表及验证指标 | 研发确认后合成初稿 |
| 初稿合成与评审 | 产品经理撰写，市场、销售、研发参与评审 | 价值主张初稿 | 评审通过后进入用户验证 |
| 用户验证 | 用户研究主导，产品经理参与 | 验证记录与修订说明 | 验证结论支持后进入定稿检查 |
评审时重点看三件事：痛点条目是否都有证据、缺口是否对应真实使用环节、收益表述是否让非产品岗位也能听懂。研发参与评审的价值在于提前指出哪些收益当前无法兑现，避免价值主张承诺了交付不了的结果。
痛点收集、评审记录和验证结论通常分散在访谈文档、工单和会议纪要中。使用 ONES 时，可以把痛点条目建为工作项并关联来源文档，把价值主张初稿放入项目文档，评审意见和验证结论在同一处留痕，方便定稿时回溯每条表述的依据。
用用户反馈验证价值主张
初稿形成后，需要用外部反馈判断它是否成立。建议同时使用访谈复述、原型或落地页测试、行为数据三类方法，交叉验证。单一方法容易得出偏乐观的结论。
访谈验证：用户能否用自己的话复述
向目标用户展示价值主张表述，请对方用自己的话说明这句话对他意味着什么、对应他哪项工作。判断标准是用户能说出具体场景和变化，而不是复述你的原句或礼貌性认可。样本应覆盖不同使用深度的用户，具体人数和轮次结合产品阶段确定，原则是连续多轮访谈不再出现新的理解偏差。
原型或落地页测试：用户是否愿意选择
用原型、试用邀请或落地页呈现价值主张，观察用户是否愿意留下联系方式、预约演示或开始试用。判断标准是目标用户群体的选择行为明显高于泛人群，且用户在留言或咨询中提到的理由与你的收益表述一致。如果用户愿意点击但咨询的问题集中在其他方面，说明价值主张抓错了重点。
行为数据验证：试用、转化、留存是否支持
在真实使用中观察与收益对应的指标，例如完成首次任务的时间、关键步骤的放弃率、试用转付费比例、次周留存。指标应在填表阶段就已确定，验证时按同一口径采集。数据支持的表现是：使用你方案的用户在对应环节的表现优于使用替代方案的对照组，或优于自身使用前的基线。
验证不通过时的调整路径
验证结果不理想时，按缺口回溯而不是直接换方向：用户无法复述，通常是表述偏内部视角，回到第三步改写收益；用户理解但不选择，检查替代方案缺口是否判断有误，或收益对应的代价是否被低估；行为数据不支持，回到第一步核对痛点证据是否来自真正的目标用户。每次调整只改一个变量，并记录修订原因，避免多轮修改后无法判断哪项变化起了作用。
完整示例：一款协作工具的价值主张提炼
以下为演示情景，用于说明方法如何落地，数据为示例设定，不代表真实产品表现。
示例背景与目标用户
某协作工具团队准备面向小型内容团队推广任务协作能力。目标用户锁定为五到十人内容团队的负责人，场景是每周选题会后的任务分派与进度跟踪。
痛点与替代方案缺口填写
| 用户角色 | 场景 | 痛点描述 | 证据来源 | 当前替代方案 | 替代方案缺口 |
|---|---|---|---|---|---|
| 内容团队负责人 | 选题会后分派任务 | “会开完了，谁做什么还要在群里再问一遍” | 访谈记录 A-03 | 群聊加共享表格 | 任务散落在聊天记录，表格靠人工同步，容易漏项 |
| 内容团队成员 | 跟踪稿件进度 | “不知道上一篇改到哪一步了” | 访谈记录 A-05 | 共享表格 | 状态更新不及时，负责人需要逐个询问 |
差异化收益与价值主张初稿
对应第一个缺口，收益写为“会后任务直接落到具体负责人，不需要在群里二次确认”；对应第二个缺口，收益写为“每篇稿件当前状态在同一个列表可见，负责人不用逐个询问”。据此合成初稿：“为五到十人内容团队提供选题会后任务分派与进度跟踪，让任务从会议直接落到负责人，进度在一处可见，减少群聊追问和表格人工同步。”
验证结果与修订
访谈中部分用户能复述“任务落到人”，但对“进度在一处可见”反应平淡，进一步询问发现他们更在意截稿前的提醒。团队据此把第二条收益改为“临近截稿自动提醒负责人”，并在原型测试中观察试用邀请的接受率。修订后表述更贴近用户实际动作，验证记录中保留了修改前后的版本和原因，供定稿时对照。
完成检查：价值主张定稿前逐项核对
定稿前逐项核对以下条目，全部通过再对外使用。任何一项不通过，回到对应步骤修订，而不是在表述上做修饰。
- 痛点是否有证据支撑：每条痛点都能指回访谈原话、工单或数据，待验证条目已单独标注。
- 替代方案缺口是否真实存在：缺口对应具体用户和具体环节，且已覆盖竞品、自建工具、人工流程和不解决等形态。
- 差异化收益是否可感知、可验证：收益写成用户完成任务时的变化，每条都有对应指标，研发已确认可实现。
- 用户反馈是否支持：访谈复述、选择行为和试用数据三类证据方向一致，或分歧已有解释和修订记录。
- 内部团队是否理解一致：产品、市场、销售对同一句话的理解相同，对外话术与初稿一致。
- 表述是否可核对：一句话中的每个关键词都能在工作表中找到依据，没有无法对应的形容词。
这份清单同时可以作为后续复盘的依据。产品方向、目标用户或替代方案格局发生变化时，重新核对相关条目，比直接改写口号更能保持价值主张与用户实际感受一致。
常见问题
用户访谈中收集到的痛点很多，如何判断哪些值得写进价值主张？
先看证据强度：能指回具体访谈原话、工单记录或行为数据的痛点优先保留，仅有团队推测的条目放入待验证区。再看场景集中度：同一类用户在相似任务环节反复提到的困难，比零散抱怨更值得进入初稿。最后看替代方案缺口：如果用户当前的做法已经能较好解决该问题，这个痛点的紧迫程度有限，可以暂缓纳入。
替代方案分析时只对比竞品够不够？
不够。用户的替代方案还包括自建表格或脚本、人工流程、外包，以及干脆不解决、忍受现状。只对比竞品容易遗漏用户实际使用的土办法，而这些土办法留下的缺口往往正是差异化收益的落点。建议逐条问用户“现在怎么解决这个问题”，把回答原样记录后再归类。
价值主张初稿在内部评审时，产品和市场理解不一致怎么办？
先回到字段表核对分歧点：是痛点证据的解读不同，还是收益表述对应了不同缺口。把双方的理解分别写下来，对照同一行记录找差异来源。如果分歧来自收益表述过于抽象，改写成用户完成任务时的具体变化；如果来自目标用户范围不同，先统一用户角色和场景再讨论表述。评审记录保留修改前后的版本和原因，方便后续追溯。
用户反馈验证需要多少样本、做几轮才算够？
样本量和轮次应结合产品阶段、用户规模和验证目的确定，没有统一数值。判断标准是连续多轮访谈不再出现新的理解偏差，或原型测试中目标用户的选择行为与收益表述一致。验证方案在填表阶段就应写明计划采集的指标和口径，避免验证时临时调整导致数据不可比。
价值主张定稿后，什么情况下需要重新提炼？
目标用户群体、核心使用场景或替代方案格局发生明显变化时，建议重新核对相关条目。例如主要竞品调整了做法、用户开始普遍采用新的替代工具，或产品能力范围有较大调整。重新提炼时沿用原有字段表和证据来源，逐项核对哪些条目仍然成立，比直接改写口号更能保持价值主张与用户实际感受一致。
