老板说“做个功能”时，先用一张卡把目标和成功标准问清楚

教程定位

这篇教程解决什么问题

产品团队最怕的不是老板不提需求，而是老板在群里说一句“我们加个会员等级功能吧，这个很重要”，然后所有人开始排期。你问“为什么做”，老板说“先做出来看看”；你问“怎么做算成功”，老板说“用户用起来就知道了”。需求进了池子，开发排了两个月，上线后没人说得清它到底解决了什么。

这篇教程教你做一张高层需求入池澄清卡：在老板的一句话需求进入排期前，把业务目标、目标用户、触发场景、预期指标和待确认问题补全。你会用 AI 帮你起草澄清卡，但最终由产品负责人和老板确认。

做完之后，你手里的需求不再是一句“做个功能”，而是一张能拿去评审、能判断优先级、能定义成功标准的入池卡。

使用场景

什么情况下最适合用这一套

你是产品负责人或创业团队的产品经理。你的老板可能是创始人、CEO，也可能是业务线负责人。他提需求的方式通常是：

这些需求不是不能做，而是缺少进入需求池的“最小契约”：目标、用户、场景、指标和边界。没有这些，产品评审会变成吵架会，开发排期会变成赌局。

• “我看到竞品有这个功能，我们也做”；
• “客户一直说要批量导入，下周排期”；
• “把首页改一下，感觉现在太满了”；
• “AI 现在这么火，我们产品里也要有 AI 功能”。

材料准备

开始前先把材料和边界备齐

做澄清卡前，准备这些材料：

准备时注意：不要拿着空白表格去找老板填，老板会烦。先根据已有信息填 80%，只留三到五个必须由老板拍板的问题。

1. **老板的原话**：不要二次加工，把原话和时间记下来，最好带上下文（哪次会、哪个竞品、哪个客户）。
2. **相关数据**：如果需求涉及现有功能，准备使用量、留存、转化或客诉数据。
3. **用户反馈**：客户或用户的原话、工单、访谈记录，判断需求是老板观察到的还是真实用户提出的。
4. **当前排期和资源**：接下来一到两个月的开发容量，判断这个需求插进来会挤掉什么。
5. **业务目标**：公司本季度的核心目标，例如新签、活跃、续费或毛利，用来判断需求服务于哪个目标。

实操流程

按这套步骤把工作跑起来

【第一步：把“原话”变成“问题”】

老板的原话通常是结论，不是需求。先把它还原成问题：

每一条需求都先问“它在解决谁的什么问题”，答不上来就留在“待确认”，不进入排期。

【第二步：填业务目标和成功指标】

给需求写一句业务目标，再写一个可测量的成功指标。例如：

指标要能反驳：“做完了但指标没动”意味着需求方向错了或没做好。如果写不出指标，说明需求还没想清楚。

【第三步：圈定目标用户和触发场景】

不要写“所有用户”。写清楚：

【第四步：列影响范围和待确认问题】

影响范围包括：涉及哪些页面、哪些角色、哪些现有流程，会不会影响已有功能。待确认问题只列三到五个，例如：

【第五步：用 AI 起草澄清卡】

把你收集到的原话、数据和背景输入 AI，让它按固定格式生成澄清卡初稿。AI 帮你补全表达和拆解问题，但“老板到底想要什么”只能由你和老板确认。

【第六步：拿着卡去找老板确认】

把 80% 已填好的卡给老板，只问剩下的三到五个问题，并要求给出答复时限。老板确认后，需求才正式进池。

• “加会员等级” → “哪些用户应该被区别对待？区别对待之后我们希望他们做什么？”
• “做批量导入” → “现在手动创建慢在哪里？谁最痛？”
• “首页改版” → “用户现在找不到什么？首页的目标动作是什么？”
• 目标：提升企业客户的续费率。
• 指标：会员等级上线后 90 天内，企业客户续费率从 82% 提升到 86%。
• 目标用户：哪个角色、什么规模、什么付费档位；
• 触发场景：用户在什么时刻会需要这个功能；
• 不做场景：明确这个版本不服务谁，避免范围膨胀。
• “这个功能服务付费客户还是所有用户？”
• “优先级比正在做的 X 高还是低？”
• “如果指标没达到，什么时候叫停？”

输入示例

可以直接参考的输入材料

下面是可复制改写的输入样例：

请帮我起草一张高层需求入池澄清卡。

【老板原话】8 月 3 日周会上，老板说：“我看竞品都做了会员等级，我们也做一个，不然大客户觉得我们不够专业。”

【现有信息】
- 产品：企业协同 SaaS，现有付费套餐为企业版和专业版。
- 数据：专业版客户 90 天续费率 82%；大客户（50 人以上）续费率 78%，低于整体。
- 用户反馈：三家大客户提到“希望有更多管理权限”，但没有直接提“会员等级”。
- 当前排期：未来 8 周开发容量已排满，含权限体系重构和移动端改版。
- 公司季度目标：专业版续费率提升到 86%。

请按业务目标、目标用户、触发场景、预期指标、影响范围、待确认问题六部分输出，待确认问题只写 5 个以内。

提示词

可复制使用的提示词

你是产品需求澄清助手。下面是我收集到的老板原话、现有数据和排期情况：{材料}。

请输出一张高层需求入池澄清卡：
1. 业务目标：用一句话说明这个需求要服务哪个业务结果；
2. 目标用户：具体角色和条件，不写“所有用户”；
3. 触发场景：用户在什么时刻、因为什么触发这个需求；
4. 预期指标：一个可测量的核心指标，含基线、目标和观察周期；无法测量时说明为什么；
5. 影响范围：涉及页面、角色、流程和可能受影响的现有功能；
6. 待确认问题：最多 5 个必须由需求提出人回答的问题，优先问“目标、优先级、叫停条件”。

要求：不编造我提供材料之外的数据；不要把“想做功能”当成已确认的目标；如果信息不足，标“待确认”而不是推测。

输出样例

AI 应该输出到什么程度

这张卡已经足够拿去评审。注意：AI 写的“目标用户”和“预期指标”是基于你给的数据推断的，必须由产品负责人确认。

【澄清卡字段速查模板】

如果你不想从零设计卡片，可以直接用下面这套字段，每个字段都配一句填写要求：

| 字段 | 要求 | 合格示例 | 不合格示例 | | --- | --- | --- | --- | | 需求来源 | 谁、什么时候、原话 | 8 月 3 日周会，老板说“竞品都做了会员等级，我们也做” | 老板要的 | | 业务目标 | 服务哪个业务结果，一句话 | 提升 50 人以上专业版客户续费率 | 让产品更专业 | | 目标用户 | 具体角色和条件，不写“所有用户” | 50 人以上企业管理员，已购专业版 | 所有用户 | | 触发场景 | 用户在什么时刻需要 | 管理员要按部门管成员权限、看用量时 | 用户有需求时 | | 预期指标 | 基线、目标、观察周期 | 90 天续费率 78% → 84% | 提升续费率 | | 影响范围 | 页面、角色、流程、受影响功能 | 新增成员分级管理；影响权限体系入口 | 改动不大 | | 待确认问题 | 3-5 个必须由提出人回答 | 服务企业版还是全部付费客户 | 怎么做 | | 叫停条件 | 什么时候停、怎么停 | 90 天未达 84% 时复盘并决定调整或叫停 | 看情况 | | 负责人与时限 | 澄清卡谁跟进、何时确认 | 产品负责人，8 月 10 日前 | 尽快 |

填写时有三个原则：

这套字段可以直接作为 AI 提示词里的输出格式，也可以做成团队需求池的公共模板。只要每个进池需求都带上这张卡，产品评审会就能从“吵该不该做”变成“核对这张卡缺什么”。

1. **先填 80%，再问 20%**。你能从数据、反馈、竞品和排期里推断的内容自己填好，只把真正需要老板拍板的问题留给他，比如优先级、目标用户范围、叫停条件。
2. **一张卡只装一个需求**。老板一次说了三个功能，就拆成三张卡，每张卡独立评审。混在一起会导致目标、指标和影响范围互相污染。
3. **没有指标就标“待确认”**。不要为了让卡片好看编一个指标。写“预期指标：待与老板确认基线数据”比写一个没人认的数字更诚实，也更符合评审需要。

【业务目标】提升 50 人以上专业版客户的续费率，让大客户感受到管理能力和专属价值。
【目标用户】50 人以上企业的管理员（采购决策人/IT 管理员），已有专业版付费。
【触发场景】管理员需要按部门管理成员权限、查看成员用量、区分不同层级成员时，发现当前产品无法满足，续费评估中产生流失风险。
【预期指标】上线后 90 天内，50 人以上专业版客户续费率从 78% 提升到 84%（基线来自 2026 年 Q2 数据，需数据组复核）。
【影响范围】
- 新增：成员分级管理、管理员用量看板、分级权益配置。
- 影响：现有权限体系的入口和组织结构页；移动端管理后台。
- 风险：与权限体系重构排期重叠，需要合并设计或调整顺序。
【待确认问题】
1. 这个功能服务企业版还是全部付费客户？
2. 它比权限体系重构优先级更高还是更低？
3. 90 天续费率如果没到 84%，什么时候叫停或调整？
4. “会员等级”的对外命名是否必须叫会员，还是可以用“组织层级管理”？
5. 竞品的这个功能，我们是要对标，还是只解决大客户续费这一个问题？

人工验收

人要怎么检查和改到可用

澄清卡定稿前，检查这些点：

特别提醒：澄清卡不是用来反驳老板的工具，而是用来对齐的。你的目标是让老板的需求变成可评审、可执行、可复盘的项目，而不是证明老板说得不对。

1. **目标是否忠于业务结果**：如果老板的原话是“对标竞品”，而卡上写的是“提升续费率”，要确认这是你的翻译还是老板的意图。
2. **指标是否有基线**：没有基线的指标等于没有指标。AI 给的 78% 必须由数据组复核。
3. **目标用户是否太宽**：出现“所有用户”“全员”就要拆分场景，缩小到第一个版本能服务的群体。
4. **待确认问题是否真的需要老板**：自己能查证的问题不要拿去问老板，老板只回答必须拍板的。
5. **叫停条件是否写清**：如果指标不达预期，什么时候停、怎么停，避免“先做出来看看”变成无底洞。

失败反例

这些失败反例要提前避开

反例 1：老板说完直接排期，不做澄清卡。 结果：团队花两个月做完“会员等级”，上线后发现大客户真正要的是权限管理，功能没人用，续费率没变化，还要花一个月下架。

反例 2：澄清卡只写目标和用户，没有成功指标。 结果：功能上线后，产品经理说“感觉用户反馈不错”，但没有任何数据能证明。没有指标，就没有复盘依据。

反例 3：把“所有用户”当成目标用户。 结果：为了覆盖所有用户，功能越做越大，第一版上线时间从两个月拖到五个月，最需要的大客户反而没等到。

反例 4：拿空白表格让老板填。 结果：老板没时间填，觉得产品经理在推脱，需求仍然以口头形式直接进了开发。澄清卡要自己先填 80%。

反例 5：确认了目标但没有确认优先级和叫停条件。 结果：新功能插队挤掉权限体系重构，两个都做了一半；指标没达到也没人敢叫停，团队陷入长期维护。优先级和叫停条件必须在入池前写清。

主题边界

它和相邻主题的区别

这篇解决的是“高层一句话需求在进需求池前怎么澄清”，产出是入池澄清卡。它和需求池日常清理（`product-research-demand-pool-source-status-cleanup`）不同，那篇解决的是存量需求的来源和状态治理；它和用户访谈提纲（`product-research-interview-guide-not-feature-list`）也不同，那篇解决的是怎么从真实用户收集需求。澄清卡是它们之间的衔接点：老板需求先澄清成可评审条目，再和其他需求一起进池管理。

如果团队经常被一句话需求打乱排期，先从澄清卡开始；如果澄清卡已经有了但需求池还是乱，再检查需求池的优先级规则。