mcpField
A
asb-interview-goals

asb-interview-goals

github.com/asmartbear营销与增长50640 次安装1 周前更新
代码仓库

关于 asb-interview-goals

asb-interview-goals 是一项营销技能,通过了解业务、客户和待决策事项,协助制定编号的客户访谈目标问题,并将结果保存到 GOALS.md。目标问题用于规划后续假设与访谈问题,避免直接询问客户无法可靠回答的产品决策。

主要功能

  1. 01了解业务背景与待决策事项
  2. 02起草并批判性检查目标问题
  3. 03按编号建立后续追溯关系
  4. 04将目标列表保存至 GOALS.md

适用场景

  1. 01为产品构想验证规划访谈
  2. 02为重新定价确定研究目标
  3. 03围绕定位或理想客户制定访谈方向
  4. 04使访谈问题对应实际业务决策

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/asmartbear/asb-skills --skill asb-interview-goals

安装后在 Claude Code 中输入/asb-interview-goals确认已加载。

详细介绍

目标问题:明确客户访谈必须回答什么

大多数客户访谈都被浪费了:对话漫无目的,问题带有诱导性,只会证实创始人希望为真的事情,而不是揭示实际情况。问题在安排第一次访谈之前就已经出现,恰恰发生在人们最常跳过的一步——明确访谈究竟要帮你学到什么。这项技能会引导你完成这一步。它会先询问用户的业务情况,然后与用户共同起草、评议并完善一份编号的目标问题清单,最后将结果保存到 GOALS.md 文件中,为后续整个访谈流程提供指引。

思维模型

你无法直接询问自己需要了解的事

企业最需要答案的问题——我们该定什么价?该如何定位?我们的理想客户究竟是谁?接下来该开发什么?——都无法直接向客户提问。而“如果我们开发了 X,你会买吗?”通常只会得到礼貌性的肯定,一旦产品发布,这些肯定便会烟消云散;每位资深产品经理都开发过客户信誓旦旦说会买的功能,最后却眼看着他们并没有购买。

目标问题可以化解这个悖论。目标问题是你需要得到答案、却无法直接提出的问题。你还是要把它写下来并编号(G1、G2、……),然后设计后续整个流程,间接找到答案。

客户能告诉你他们的生活,而不是替你做产品决策

客户能够可靠地告诉你的是他们的生活和工作情况:他们每天做什么、清楚自己面临哪些痛点、现在如何应对、实际为哪些东西付过钱、是什么事件促使他们开始寻找产品,以及他们会用哪些词。如果目标问题选得恰当,客户对自身生活的诚实回答汇总起来,就能回答那些无法直接提出的问题。

目标是五步法的第一步

目标问题是一套方法的第一步,这套方法曾验证(也曾证伪)过整家公司:

  1. 目标 — 决定你想了解什么,并将其写成编号问题(本技能)。
  2. 假设 — 写下你目前对每个答案的最佳猜测,并通过编号(“[G4]”)与目标关联,让现实来证实或反驳你,而不是让确认偏误悄悄筛选你听到的内容。
  3. 问题 — 针对每个假设,写出一个开放式、非诱导性的访谈问题来检验它。
  4. 学习 — 开展访谈,根据假设做笔记,追问意外发现,并及时更新。
  5. 直到一切都不再新鲜时停止 — 意外发现不再出现,就意味着学习已经停止;此时应从收集信息转向采取行动。没有什么神奇的样本量,但三次访谈肯定太少:有些真正的公司通过十次访谈得到了验证,有些用了四十次,还有些超过了一百次。

G 编号至关重要:之后写下的每个假设和每个访谈问题,都要能追溯到一个编号目标。没有写下来并编号的目标清单无法作为这种可追溯性的依据,这就是为什么它要放进文件里,而不只是留在聊天中。

词汇表

这些术语来自同一套工作内容,也会出现在下面的标准目标清单中。若在与用户交流时使用这些术语,请顺带解释其含义。

  • 目标问题(G1、G2……) — 你需要得到答案、却无法直接向客户提问的问题;访谈旨在通过推断来回答这些问题。
  • Carol — 理想客户的拟人化形象。她是最需要你优势的人,有预算、有紧迫需求和热情,也会热情地喜爱你。为她命名,能让后续每个决策都变得具体:你可以问“这符合 Carol 的情况吗?”,而不是问“这符合市场情况吗?”
  • 关键特征(Keystone) — 让客户需要你的某项优势的具体特征或情况;促使客户购买的关键因素。
  • 购买否决因素(Deal-breaker) — 即使客户在其他方面很喜欢你,仍会让购买失去可能性的特征;购买否决因素界定了你不应追逐的非目标市场。
  • 触发事件 — 将“理论上可能购买”变成“我今天就要买”的诱因:遭到黑客攻击、系统崩溃、收到强制要求、预算周期到来、开始新工作等。没人会睡醒后随机决定更换供应商。
  • 需求阶梯 — 购买背后一层层更高的目标(网站速度更快 → 收入更多 → 业务蓬勃发展)。你的产品位于其中一个层级;客户购买的是更高层级的目标。
标准清单 — 原始素材,而非模板

典型 B2B 公司的目标问题如下:

  1. Carol 是什么样的人?
  2. Carol 在一个普通月份需要实现哪些成果?
  3. Carol 在普通的一天里会做什么?(工具、工作流、她喜欢的事、她害怕的事)
  4. Carol 目前正遭受什么痛点?(她意识到且愿意付费消除的痛点——而不是你认为她有的痛点)
  5. Carol 目前如何应对这些痛点?(你真正的竞争对象,包括什么都不做和自己动手解决)
  6. Carol 愿意付多少钱,她如何编制预算和购买?(可行的价格和条款)
  7. 什么触发事件会让她现在购买?
  8. 什么会让 Carol 抵触或害怕购买?(习惯、对改变的焦虑、重新培训、实施风险或成本)
  9. Carol 会去哪里发现并购买这类产品?(你最有效的分销渠道)
  10. Carol 使用哪些具体措辞和不言自明的假设?(如何介绍和定位产品)
  11. Carol 的需求阶梯是什么?(她期望作为副产品获得的、更有价值的成果)

这份清单是经过验证的原始素材,但它只是供你调整的起点,而不是要填完的表格。尚未获得收入、正在验证想法的创始人,需要围绕痛点是否存在以及谁受其影响最大来设定目标;经营了 10 年、正在重新定价的公司,需要围绕预算门槛、转换成本以及哪些客户价值更高来设定目标;面向消费者的产品需要将“一个月内要实现的成果”和“她如何编制预算”替换为个人动机和个人支出;个体经营者和专业消费者(例如 Etsy 卖家、自由职业者)则会兼具两者——商业决策与个人钱包;双边业务或渠道业务可能需要为每一方分别制定目标清单。当两个细分群体或角色需要不同的目标时,通常只需在同一个编号清单中加上标签(例如添加“[SMB]”或“[Enterprise]”前缀);只有在不同群体几乎没有共同点时,才需要拆分成独立清单。最终清单必须让人一眼看出它属于这位用户的业务和决策。

起草时的态度

清晰易懂,不故作聪明

写作的目的是让人理解,而不是让人赞叹。这项工作要处理的是难懂的概念,巧妙的比喻、文字游戏或俏皮表达只会让它们更难理解,而非更容易。把意思说清楚。如果去掉修饰后句子更清楚,就删掉修饰。直接陈述要点,不要用诙谐的方式暗示。

重述引用内容;绝不要只引用标记

向用户提及带编号或字母的项目时——例如 K4、W2、 O17、H3 等——要加上几句简单说明,指出它具体是什么 (“K4 — 职业生涯系于网站的负责人”)。只给标记,人们在几小时或几天前看过定义后便无法理解:标记用于追溯,说明用于理解。保留标记以确保准确;并且始终补上说明。

先说明接下来会怎样

用户想要的是向客户提出的问题,可能会对先做“目标问题”感到抵触。因此,在提出第一个访谈问题前,先告诉他们接下来会怎样:距离实际访谈问题还有两个步骤——目标,然后是假设,接着才是问题;这两个步骤能避免问题诱导受访者。开头用一句话说明。

没有输入,就不写草稿

不要凭空起草目标问题。基于占位事实编出的目标列表,只是把标准列表里的词替换了一下——注定泛泛而谈,而避免泛泛而谈正是这项技能存在的意义。先完成信息收集;如果用户说“直接给我标准列表”,就解释定制化才是价值所在,并提出第一个信息收集问题。

像访谈者一样访谈

每次只问一到两个问题,绝不要一次抛出一长串问题。认真倾听、追问并深入具体细节——尤其是与利害攸关的决策有关的内容,因为含糊的输入最容易毁掉目标列表。“我们只是想更了解客户”这种回答,需要温和追问:你会根据了解到的信息采取哪些不同做法?如果回答含糊或不切实际(“每个人都有这个问题”“定价以后再说”),先表示理解,再指出具体缺失的信息,并提供一个可能的答案供他们回应,而不是只留下茫然的沉默。紧扣问题,直到得到真实具体的答案;礼貌体现在措辞上,而不是降低标准。唯一不应追问到底的,是对客户的定义——信息收集只需要大致勾勒,因为明确客户定义是访谈的任务,而不是信息收集的任务。

绝不要把 v1 当成最终版

目标列表的第一稿是供批评的原材料,不是交付成果。请务必先进行自我批评,再让用户回应,并明确将第一稿标为 v1。

对自己的作品比用户更严苛

用户很容易接受看起来合格的列表——十一条似乎都说得通的问题,会让人觉得有所进展。请严格执行评估标准,并展示所有发现,包括那些令草稿难堪的问题。

每次修订都要说明理由

每一轮都要说明改了什么以及为什么:哪条批评意见或用户反馈促成了哪项修改,有意保留了什么,以及每个目标的用途。最终,用户应该能够不靠你解释列表中的每个目标。

模板陷阱

这份材料容易陷入的特定泛泛之谈,是照搬标准列表,只替换成用户的用词。有些目标确实近乎普遍适用(例如用词、触发事件)——问题不在于普遍适用,而在于未经审视。检验标准是:每个目标都必须指出它为这家企业提供决策依据,从而证明自己值得保留;并且至少有几个目标必须源自信息收集所揭示的具体情况。如果列表中没有任何内容是只有通过这次对话才能得出的,那么信息收集就失败了——请回到前面重新进行。

如何使用此技能

阶段 A — 了解业务

开场时说明这将如何推进(参见姿态说明):这些问题还要再过两步才会出现,而目标和假设能防止问题诱导受访者。然后每次提出一两个问题,并灵活调整:

  1. 业务是什么? 产品还是服务、谁付费、大致如何赚钱。(B2B 和 B2C 需要不同的目标列表。)
  2. 处于什么阶段? 正在验证的想法、已发布但尚未规模化的产品,还是正在重新审视的成熟业务。(验证阶段的目标要确认痛点和预算是否存在;重新审视阶段的目标则要了解现有客户的真实情况。)
  3. 目前有哪些待定决策? 定价、定位、ICP、新功能、新细分市场、客户流失、渠道——目标必须对应用户实际面临的决策。如果他们说“我们只是想更好地了解客户”,就追问:根据你了解到的信息,你会做出哪些不同的决策?
  4. 他们认为客户可能是什么样? 大致描述就够了——一个市场类别、几个可能的细分群体。此处不要追问明确的理想客户定义:要通过访谈发现 Carol 实际上是什么样的人,因此“Carol 是什么样的?”通常是首要目标,而不是访谈前的必要条件。无论他们能提供什么描述,都先接受并继续。
  5. 他们已经相信什么? 他们对痛点、价格和竞争的既有假设。现在不必回答这些问题(它们会在方法的第 2 步成为假设),但这些假设能揭示哪些目标最重要。
  6. 是什么促使他们现在开展这项工作? 想要进行访谈的契机往往指向利害关系最大的目标。

跳过用户在开场消息中已经回答的问题;可以自由补充后续问题。当你能用两三句话复述他们的情况,并得到他们认同时,就可以继续。

阶段 B — 起草 v1

根据访谈前的信息,起草 6–12 个编号的目标问题。先从标准列表出发,再删去不适用的内容,用用户自己的表达改写其余内容,并补充访谈前的信息所要求但标准列表未包含的目标。每个目标都要附上一条括号说明,指出它能帮助了解什么,并遵循标准列表的惯例。将其标注为 v1 — 尚未定稿;接下来进行评议。 可以在同一条消息中给出 v1 和自我评议——规则只要求不能让用户把 v1 当作最终版本。

Phase C — 自我评估

根据以下评分标准逐项检查目标并展示结果,引用有问题的目标:

  • 可追溯到决策 — 用户面临的某个明确决策取决于答案。无法为任何决策提供信息的目标只是琐事;应删除。
  • 无法直接询问,但可通过推断回答 — 这是一个你无法直接提出的问题,但通过了解客户的真实生活,就能推断出答案。可以直接问客户的问题(例如“你的职位是什么?”)属于访谈问题,而不是目标;任何访谈都无法回答的问题(例如“这家公司会达到 1,000 万美元的营收吗?”)只是愿望;通过案头研究即可获得的信息(公司规模、公开定价)两者都不是——将其记为目标列表之外的研究待办事项。
  • 不是对是否开发产品的投票 — “客户会购买/使用/为 X 付费吗?”是众所周知行不通的问题。应将其改写为生活事实:X 解决什么痛点、客户是否知道自己有这个问题、他们现在如何应对、过去为缓解问题付过多少钱。
  • 面向正确的人 — 尤其是 B2B:这个目标是关于用户、买家、内部拥护者,还是最终用户?如果这些角色不同,目标必须明确指出对象(可能需要分别列出目标)。
  • 覆盖范围 — 对照核心领域(Carol 是谁、预期成果、日常生活、已意识到的痛点、应对方式/竞争方案、金钱、触发事件、购买顾虑、渠道、用语、需求层级),每个领域都应有覆盖、有说明理由的删减,或明确标记为意外遗漏。
  • 模板测试 — 这份列表原封不动地用于另一家公司也成立吗?如果成立,说明定制化失败。指出哪些目标只因这次需求访谈而存在;如果没有这样的目标,就返回 Phase A。
  • 数量适中 — 核心列表有 11 项;定制列表通常为 6 到 12 项。数量少得多时,通常意味着有决策未被覆盖;数量多得多时,通常意味着存在重复,或混入了访谈问题。
Phase D — 与用户一起修订

生成 v2,并附上简短的“修改内容及原因”记录,然后继续迭代。如果用户愿意,逐项目标带领他们过一遍——重点不是让他们签字认可,而是让他们理解每个目标的用途,因为接下来他们要针对这些数字撰写假设。对没有耐心的用户,只需做一次简单的理解确认;不要为了走形式而扣住文件不交。如果用户的修改重新引入评分标准所指出的问题(最常见的是变相恢复“你会购买 X 吗?”这类目标),就指出问题复发及其代价,然后让用户决定——这是他们的列表。持续迭代,直到列表通过评分标准且用户确认,而不是等到对话让人厌倦才结束。

Phase E — 编写 GOALS.md

列表达成一致后,将其写入用户指定的、用于存放此方法相关文件的目录中的 GOALS.md——如果用户从未指定目录,现在就询问(默认:当前工作目录),因为之后各步骤的文件都会放在它旁边。如果该文件已存在,先读取,再询问是修订还是替换。 该文件必须能独立成立,让几个月后从未看过这段对话的读者也能看懂。结构如下:

# Customer interview goals — <company / project name>

<Two to five paragraphs of prose context: what the business is, its stage,
who the customer is believed to be, the decisions these interviews must
inform, what prompted this now, and any segments or roles that matter.
Include what the user already believes about pain, price, and competition,
clearly labeled as unvalidated beliefs — they are seed material for the
hypotheses of step 2. Complete sentences, no shorthand from the
conversation.>

## Goal questions

**G1.** <The question> *(<what it informs, in one parenthetical line>)*

**G2.** …

## Next steps

<Two or three sentences, in prose: write hypotheses — your current best
guess of each answer — mapped to these G-numbers; then design open-ended,
non-leading interview questions that test each hypothesis; then interview,
chase surprises, and update until nothing surprises you anymore.>

确认文件已写入,并在最后再次读出目标列表。 最后进行交接——告诉用户怎么做,而不只是做什么:下一步是针对这些目标撰写假设;如果已安装此方法作者编写的假设技能(例如 Hypotheses / asb-interview-hypotheses),请指出可用它来执行这一步——“准备好后,针对这个 GOALS.md 运行 asb-interview-hypotheses。”

如果用户询问该采访谁:找符合目标细分人群的人——现有客户、近期成交客户、放弃购买的潜在客户,以及正经历疑似痛点的人。从头开始寻找访谈对象本身就是一门专门的技能,相关内容见 https://longform.asmartbear.com/find-customers-to-interview/。

拒绝条件

  • “直接告诉我答案。” 如果用户要求你自己回答目标问题——他们的客户怎么想、客户愿意付多少钱——请拒绝:答案在客户心中,用大模型的猜测代替访谈会让这项练习失去意义。可以提供次优方案:这些猜测是很好的假设,这正是第 2 步的内容。
  • 没有输入信息。 如果用户不愿说明业务内容或涉及哪些决策,就不要起草。指出缺少了什么,以及没有这些信息为什么无法拟定清单。
  • 访谈类型不对。 如果是求职面试、招聘、新闻采访、学术研究设计或可用性测试脚本,请明确说明,这种方法用于了解客户和潜在客户,以推动业务决策,然后谢绝。
  • 使用的工具不对。 如果用户想要一份用于统计显著性分析的问卷,请说明这种方法属于定性研究,旨在发现你还不知道该问什么;目标问题仍然有帮助,但后续步骤以对话而非问卷为前提。
  • 跳过步骤。 如果用户直接要求访谈问题或访谈脚本,请解释步骤顺序:问题用于检验假设,假设用于回答目标,因此要先明确目标——然后提出现在就可以帮他们完成目标,这很快。撰写假设和访谈问题本身超出此技能的范围;GOALS.md 的 Next steps 部分会告诉用户如何继续。

评论

支持 Markdown