用户不买功能，他只是雇你的产品干一件活

功能应该从用户任务里长出来，不是凭空堆出来。

这是"产品判断链"系列的第 6 篇。上一篇我们选定了入口用户。这一篇要解决一个很多团队跳过的步骤：选定用户后，先别急着列功能。

选定用户之后，最容易犯的错是直接列功能

团队一旦确定了"我们先服务小白创作者"，下一步往往就直接进入功能讨论：要不要做模板库？要不要做音色市场？配置项放几个？要不要做社区？要不要加一个评分系统？

会议室白板上很快就贴满了功能卡片，每个人都觉得自己很高效——毕竟，列功能这件事，看起来特别像"在推进产品"。

但这是一个很自然、却很危险的跳跃。

危险在哪？在于功能清单会给你一种"已经在做事"的错觉，而你其实跳过了一个更根本的问题。你把"产品该长什么样"当成了起点，可它根本不是起点，它是结论。

因为功能不该是凭空想出来的。在列功能之前，还有一个必须回答的问题：

用户到底"雇"这个产品，去完成什么任务？

这就是 JTBD（Jobs To Be Done）的核心思想——用户不是为了拥有一个功能而使用产品，而是在某个情境下，为了获得某个结果，"雇佣"一个解决方案。

注意"雇佣"这个词用得很妙。雇佣意味着两件事：第一，用户是为了"把一件活干完"才来找你的，不是为了收藏你这个工具；第二，雇佣关系是临时的、可替换的——只要出现一个更省事的干活方式，用户随时会把你"解雇"。这两层含义，恰好戳破了团队最容易有的两个幻觉：以为用户爱我们的功能，以为用户会一直用下去。

用户买的不是功能，是"把活干完"

举个生活里的例子。

一个人买电钻，他要的不是电钻，是墙上的那个洞。再往下追，他要的也不是洞，是把画挂上墙。再往下，他要的是一个布置得好看、住着舒服的家。

电钻只是他临时"雇"来干这件活的工具。如果有更好的方式能在墙上挂画——比如一种不用打孔的强力挂钩——他随时会换掉电钻。注意，这时候哪怕你的电钻马力更大、钻头更全、握感更好，都救不了你，因为用户要的从来不是"更好的电钻"，而是"墙上那幅画"。

再换个例子。麦当劳曾经研究为什么早高峰有那么多人单独买一杯奶昔。按功能思维，你会去优化奶昔本身：更浓、更甜、口味更多。但真去访谈才发现，这些人"雇"奶昔干的活是：开车上班的路上很无聊，一只手要握方向盘，需要一个能撑过四十分钟通勤、又不会弄脏手的东西打发时间。在这个任务里，奶昔的竞争对手不是别的饮料，而是香蕉、百吉饼和无聊本身。想清楚这个任务，你优化的方向就完全变了——你要的是更黏稠（喝得更久）、更方便单手拿，而不是更多口味。

产品也一样。用户打开你的声音工具，他要的不是"声音生成功能"，他要的是"这条短视频今天能发出去"。声音生成只是他雇来完成"发视频"这件活的工具。再往下追，他要的也不是"发出去"，是这条视频能涨粉、能接广告、能让他这个号活下去。

想清楚这一点，你看产品的视角就彻底变了：你不再问"我该提供什么功能"，而是问"用户想干完什么活，我怎么帮他干得更顺"。前一个问题会让你不停往产品里加东西；后一个问题会让你不停问自己"这一步是不是真的帮用户离他要的结果更近了"。

JTBD 的句式：情境、任务、结果

JTBD 有一个很好用的句式，把它套进去，能逼着你把任务想具体：

当用户处在某种情境下，他想完成某个任务，以便获得某种结果。

这个句式的价值在于它有三个槽位，每个槽位都不许你含糊。"情境"逼你说清楚是什么时候、什么状态下；"任务"逼你说清楚用户当下要做的那个动作；"结果"逼你说清楚他真正图的是什么。任何一个槽位填得空泛，你就知道自己其实还没想清楚。

我们用声音 AI 团队来填这个句式：

注意这张表里，"任务"和"结果"是两件事，千万别合并。任务是用户当下要做的动作，结果是他真正想要的东西。

为什么要把这两件事分开？因为它们会引向不同的产品决策。如果你只盯着"任务"，你会去优化生成速度、生成质量这些动作本身；但如果你盯着"结果"，你会发现用户要的是"涨粉"或"省钱"，于是你可能会去做完全不同的事——比如告诉用户"这种音色在你这个赛道更容易火"，或者干脆帮他算一笔账"用这个比你自己录省了多少时间"。一个好产品，既要帮他完成任务，更要帮他拿到结果。很多产品做得很顺手，用户却不买账，问题往往就出在：它把任务做得很漂亮，却没帮用户离结果更近一步。

这里还藏着一个区分维度：用户要的结果，有"物质预期"和"精神预期"两种。物质预期是看得见摸得着的好处——平台分成、广告收入、省下来的时间、提高的产量。精神预期是情绪上的满足——被点赞、被评论、被关注、被夸"这声音真好听"、猎奇被满足。

这两种预期对产品的牵引力完全不同。如果用户的核心结果是物质预期（比如靠有声内容拿平台分成），那产品就得围绕"效率"和"可发布"来组织，因为他是把这当生意做的。如果用户的核心结果是精神预期（比如发个用方言配音的搞笑视频博一乐、收获一堆评论），那产品就得围绕"差异化"和"好玩、好传播"来组织。同一句"我想用你的声音工具"，背后可能是两台完全不同的发动机在驱动，你得先搞清楚是哪一台。

任务，直接决定产品形态

这一步不是务虚。它会直接改变产品长什么样。

这话听起来抽象，我们把它落到声音 AI 上看。同样是"声音"，不同的任务，会长出完全不同的三个产品：

如果任务是"批量生产有声内容"，产品就要重视长文本上传、角色识别、批量生成、导出稳定性。这类用户是平台分成型创作者，一次要处理上万字的文本，他要的是效率和稳定。界面可以朴素，甚至有点像后台工具都没关系，但批处理绝对不能出错——生成到第 80 章崩了，前面 79 章白做，这种事一次就能让用户流失。所以这个产品的命门是"长流程的可靠性"，而不是"首屏好不好看"。

如果任务是"短视频特色配音"，产品就要重视短句生成、风格推荐、试听对比、快速导出。这类用户输入的是几十个字的短文案，他要的是快、是有特色。所以首屏就得让他听到不一样的声音——最好进来三秒内就"咦，这个音色有点东西"。这个产品的命门是"差异化的即时感知"和"出结果的速度"，长文本批处理那套对他毫无意义，他根本用不上。

如果任务是"短时陪伴"，产品界面反而不重要，关键是实时打断、表达方式、回复长度、情绪承接和安全边界。这类用户是在开车、做家务、深夜独处时打开你，他要的是"像个人"。这时候你 UI 做得再漂亮也没用，因为他可能根本不看屏幕。真正决定成败的是：AI 接话自不自然、会不会一开口就是"助手味"的长篇大论、能不能在用户倾诉时只共情而不急着给建议。这个产品的命门是"表达方式的真人感"，是一套对话 SOP，几乎和"功能"无关。

你看，三个任务对应三套完全不同的产品重心：一个拼可靠，一个拼速度和差异，一个拼真人感。它们要的技术侧重、界面形态、甚至团队该补的能力都不一样。（关于这三个方向各自最该先验证什么，本系列后面讲 MVP 的篇章还会展开。）

那如果没想清楚任务就开始堆功能，会怎么样？很可能把三套逻辑硬塞进一个产品里。我们来看这个反例长什么样：

一个"全能声音工作台"——首页既有长文本上传框（服务批量生产），又有短文案输入框和一排花哨音色（服务短视频），侧边栏还挂着一个"语音陪伴"入口（服务陪伴）。听起来很全，对吧？但实际体验是：来发短视频的小白被满屏的批处理设置和章节管理吓退了，觉得"这也太专业太复杂了"；来做有声书的创作者发现批量导出藏在三层菜单后面，还时不时和实时通话模块抢资源；想找人聊天的用户点进语音入口，发现 AI 说话还是那股工具味，因为团队的精力全花在配置项上了，根本没人去打磨对话 SOP。

结果就是经典的"四不像"：每一类用户都能在里面找到一点自己要的东西，但每一类都觉得"不够顺、不是给我做的"。功能上它什么都有，体验上它什么都不是。这不是因为团队不努力，恰恰相反，是因为团队太努力地把所有功能都做了，却没在最前面做那个最省力的动作——先想清楚，我们这一版到底服务哪个任务。

功能从任务里长出来，而不是反过来

这就引出这一篇最关键的一句话：

功能不是凭空来的。功能应该从用户任务里长出来。

一个健康的产品，它的每一个功能，都应该能追溯到某个用户任务。你应该能指着任何一个功能说："这个功能，是为了帮用户完成 XX 任务。"

我们拿声音工具具体走一遍这个"长出来"的过程。假设任务确定为"短视频特色配音"，那么功能就是这样一条条从任务里推出来的：

• • 用户要快——所以要有"快速预览、快速重生成"，不能让他等。
• • 用户要有特色但不能怪——所以要有"生成 2 到 4 个差异音色供挑选"，而不是只给一个。
• • 用户不懂参数——所以要"按目的组织选项"（选'搞笑''温柔''悬疑'），而不是丢给他一堆采样率、音高、语速的滑块。
• • 用户最后要发出去——所以要"一键导出 / 复制到创作平台"，闭环到他真正的下一步。

你发现没有，整张功能清单没有一个是"拍脑袋"加的，每一个都能回答"它帮用户完成了任务的哪一步"。这就是"从任务长出来"的样子——功能是任务的自然延伸，而不是功能列表的自我繁殖。

反过来，如果一个功能，你找不到它对应的用户任务，只能说"做了显得完整""竞品也有""万一有人要呢"——那它就是多余的。"竞品也有"尤其是个陷阱：竞品有它，可能是因为竞品服务的是另一个任务、另一群用户，你照搬过来，等于把别人衣柜里的衣服往自己身上套，尺码根本不对。

由此得到一条很硬的判断标准：

如果一个功能无法对应到用户任务，它就不该进入 MVP。

这条标准在后面做 MVP 时会反复用到。它是过滤功能的第一道闸门——而且是最省钱的一道，因为它在你写一行代码之前就把多余的功能挡在了门外。

一个常见误区：把"用户说想要的功能"当成任务

这里要澄清一个特别容易混淆的点，因为它会让上面那条标准失灵。

JTBD 不是"用户说想要什么就做什么"。用户经常会直接报一个功能给你："你们能不能加个一键去除背景音的功能？"

这时候不要急着记下来去做。要往后退一步，问几个"为什么"：

• • "你为什么需要这个？"
• • "你现在是怎么干这件事的？"
• • "你拿它去干什么？"

很可能你会发现，他真正的任务是"让我录的旁白听起来更专业，好涨粉"，而"去背景音"只是他能想到的、最朴素的一个解法。一旦你抓住了真正的任务，你可能会找到比"去背景音"更好的解法——比如干脆提供一个本来就干净、自带专业感的 AI 音色，让他根本不需要先录再去噪。用户绕了一大圈想解决的问题，你可能一步就帮他跨过去了。

这里的关键区分是：用户报的是"解法"，你要挖的是"任务"。

用户擅长描述他的问题和情境，但不擅长给产品方案。他给你的"功能请求"，本质上是他站在自己有限的认知里，对自己问题的一个临时翻译。如果你照单全收，你就把产品设计这件最该你做的事，外包给了一个比你更不懂产品的人。

但要注意，这不等于"用户的话不用听"。恰恰相反，用户报的功能是极好的线索——它是一个路标，指向背后那个真实的任务。你的工作不是无视这个路标，也不是径直冲向路标本身，而是顺着它往回找到那条真正的路。听用户的"情境"和"为什么"，别照抄用户的"怎么做"。

有一个简单的自检方法：当用户报一个功能时，你能不能用一句"当他处在……情境下，想完成……任务，以便获得……结果"把它翻译出来？如果能翻译得很顺，说明你抓到任务了；如果翻译不出来，或者翻译完发现"这功能其实没对应什么真实结果"，那这个功能请求大概率可以先放一放。

小结

用户不买功能，他只是雇你的产品干一件活。

用 JTBD 的句式——"当用户处在某种情境下，他想完成某个任务，以便获得某种结果"——把用户的任务想具体。记住任务和结果是两件事，结果还分物质预期和精神预期，它们会把产品拉向不同的方向。任务直接决定产品形态：批量生产、特色配音、短时陪伴，是三套完全不同的产品重心，硬塞进一个产品就会变成四不像。功能应该从任务里长出来，对应不到任务的功能，不进 MVP。而当用户直接报功能时，要往后退一步，从他的解法里挖出真正的任务。

现在我们知道了用户要完成什么任务。但还有一个鸿沟没跨过：我们手里的技术优势，怎么变成用户能感知、能用上的价值？技术团队最常说"我们模型更强"，可用户根本听不懂这句话。

下一篇，我们讲价值转译：用户听不懂"技术很强"，只听得懂"对我有什么用"。

这是"产品判断链"系列的第 6 篇。上一篇：《不要追最大的市场，要找最容易打穿的那群人》。下一篇：《用户听不懂"技术很强"，只听得懂"对我有什么用"》。