Back to Details

voice-of-customer-miner

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Voice-of-Customer Miner

Voice-of-Customer Miner

Purpose

用途

Mine public customer voice — review sites, app stores, Reddit and practitioner forums, community boards — for unmet needs, competitor weaknesses, and switching triggers: search plan → source sweep → verbatim capture → need themes → so what → next-step options. This bridges competitive intelligence and discovery: it delivers customers' exact words without waiting on an interview cycle. But public voice skews toward the angry and the vocal, so every theme it surfaces is a hypothesis to validate, never a verdict — the output's last stop is always a real conversation.
挖掘公开的客户声音——包括评论网站、应用商店、Reddit和从业者论坛、社区板块——以发现未被满足的需求、竞品劣势以及用户转换触发因素：搜索计划 → 来源扫描 → 原文捕获 → 需求主题 → 意义解读 → 下一步选项。这将竞争情报与需求发现连接起来：无需等待访谈周期，就能获取客户的原话。但公开声音往往偏向愤怒和活跃的用户，因此它呈现的每个主题都只是一个待验证的假设，而非定论——输出结果的最终落脚点始终是真实的用户对话。

Input

输入

Works best with: the product(s) or competitor(s) to mine — yours, a rival's, or a set — and the decision this should inform. Also useful: a theme to focus on (onboarding, pricing, reliability) if you have one; otherwise the sweep runs open.
Input supplied inline with the invocation — text after the skill name, a pasted context dump, or an appended 
ARGUMENTS:
line — counts as answers already given. Use it against the question budget; don't re-ask.
Arriving empty-handed? That works too. The skill opens with at most 3 questions (whose voice, what decision, theme or open sweep) and proceeds on labeled assumptions if they go unanswered.
Example invocation: 
Mine voice-of-customer for [Competitor A] and [Competitor B], focus on onboarding — informs whether our Q1 bet is a migration tool.
最适用场景：指定要挖掘的产品（或竞品）——可以是自家产品、竞品，或是一组产品，以及本次挖掘要支撑的决策。 额外有用信息：如果有特定主题（如入门引导、定价、可靠性）可以聚焦，否则将进行开放式扫描。
调用时提供的内联输入——技能名称后的文本、粘贴的上下文内容，或附加的
ARGUMENTS:
行——将被视为已给出的答案。利用这些信息，避免重复提问。
空手而来也没问题。该技能最多会先提出3个问题（针对谁的客户声音、要支撑什么决策、聚焦特定主题还是开放式扫描），如果未得到回答，将基于标记的假设继续执行。
调用示例：
Mine voice-of-customer for [Competitor A] and [Competitor B], focus on onboarding — informs whether our Q1 bet is a migration tool.

Key Concepts

核心概念

  • Governing protocol: honors the 
    autonomous-investigation
     contract — question budget of 3, search-plan gate, Fact/Inference/Assumption labels, Just Enough Mode, stable schema, 4-option Final Step. Discipline: OSINT's review-and-community layer (see 
    intelligence-collection-disciplines
    ).
  • Theme by need, not by feature. "Exports are broken" is a feature complaint; "I can't get my data where my team works" is the underlying need. Theming by need is the same solution-free discipline as JTBD and painstorming — and it's what makes themes portable into discovery.
  • Verbatims are the product. Short, real, quoted customer language with URLs. Verbatims teach persona language: the exact words customers use become interview probes and positioning copy. Never fabricate quotes, ratings, review counts, or reviewer roles.
  • Every source has a known skew. Reviewers skew negative; vendor communities skew loyal; app stores over-represent update anger. Note the bias per source — public voice is evidence with a known skew, not ground truth.
  • Honest frequency. Recurring across sources ≠ concentrated in one thread ≠ isolated but vivid. Say which; one articulate ranter is not a theme.
  • When NOT to use: no meaningful public footprint (early-stage, niche enterprise) → run 
    discovery-interview-prep
     instead; you need your users' voice on a private area → mine your own tickets and research; statistical confidence required → this is qualitative theming.
  • 管理协议：遵循
    autonomous-investigation
    协议——最多3个问题的提问限制、搜索计划审核、事实/推论/假设标记、极简模式、稳定架构、4选项最终步骤。所属领域：开源情报（OSINT）的评论与社区层（详见
    intelligence-collection-disciplines
    ）。
  • 按需求而非功能归类主题。“导出功能损坏”是功能投诉；“我无法将数据同步到团队协作平台”是背后的核心需求。按需求归类主题与JTBD（Jobs To Be Done）和痛点风暴一样，是一种不预设解决方案的原则——这也是让主题能够被灵活应用到需求发现中的关键。
  • 原文引用是核心产出。简短、真实的客户原话引用，并附带URL。原文引用能帮助塑造用户画像语言：客户使用的精确措辞可作为访谈问题和定位文案的素材。切勿编造引用、评分、评论数量或评论者身份。
  • 每个来源都有已知偏差。评论者往往偏向负面；厂商社区用户偏向忠诚；应用商店中对更新的不满被过度呈现。需标注每个来源的偏差——公开声音是带有已知偏差的证据，而非绝对事实。
  • 如实呈现出现频率。跨来源反复出现 ≠ 集中在一个帖子中 ≠ 孤立但生动。需明确说明；一个言辞激烈的发帖者不能代表一个普遍主题。
  • 不适用场景：产品没有有意义的公开足迹（早期阶段、小众企业）→ 改用
    discovery-interview-prep
    ；需要获取自家用户在私有领域的声音→挖掘自家工单和调研数据；需要统计置信度→此工具仅做定性主题归类。

Application

应用流程

  1. Credit inline context, then ask only the unanswered questions (max 3):
    1. Whose customer voice — yours, a competitor's, or a set?
    2. What decision should this inform?
    3. Any specific theme to focus on, or open sweep?
  2. Show the 3-bullet search plan — which voice sources you'll sweep, how you'll select representative verbatims, how observation will be separated from interpretation. Continue unless revised.
  3. Sweep mixed voice sources — review sites (G2, Capterra, TrustRadius), app stores, Reddit and practitioner forums, community boards, social threads — capturing short real quotes with URLs and noting each source's bias.
  4. Emit the schema below exactly.
  1. 认可内联上下文，仅提出未被回答的问题（最多3个）：
    1. 针对谁的客户声音——自家产品、竞品，还是一组产品？
    2. 本次挖掘要支撑什么决策？
    3. 是否有特定主题要聚焦，还是进行开放式扫描？
  2. 展示3点搜索计划——将扫描哪些客户声音来源、如何选择有代表性的原文引用、如何区分观察与解读。除非被修改，否则继续执行。
  3. 扫描多类型客户声音来源——评论网站（G2、Capterra、TrustRadius）、应用商店、Reddit和从业者论坛、社区板块、社交帖子——捕获简短的真实引用并附带URL，同时标注每个来源的偏差。
  4. 严格按照以下架构输出。

Output schema (do not reorder)

输出架构（请勿调整顺序）

markdown
undefined
markdown
undefined

Voice-of-Customer Snapshot

Voice-of-Customer Snapshot

1. Scope

1. 范围

Products mined: | Decision supported: | Sources swept: | As-of date:
挖掘的产品: | 支撑的决策: | 扫描的来源: | 截至日期:

2. Need Themes

2. 需求主题

For each of the top 3-5 themes:
针对排名前3-5的主题：

Theme: [Underlying need, solution-free, 4 to 8 words]

主题: [底层需求，不涉及解决方案，4-8个词]

  • Frequency: [recurring across sources / concentrated / isolated]
  • Verbatim: "[short real quote]" — [source, URL]
  • Verbatim: "[short real quote]" — [source, URL]
  • Who says it: [role/segment, if evident — labeled]
  • Reading: [Inference — what this suggests]
  • 出现频率: [跨来源反复出现 / 集中出现 / 孤立出现]
  • 原文引用: "[简短真实引用]" — [来源, URL]
  • 原文引用: "[简短真实引用]" — [来源, URL]
  • 发言者: [角色/细分群体，如有明确信息——需标记]
  • 解读: [推论——该主题表明的内容]

3. Competitor Weak Points

3. 竞品劣势

  • [Competitor]: [weakness in customers' words; frequency; URL]
  • [Max 5, strongest evidence only]
  • [竞品名称]: [客户原话描述的劣势；出现频率；URL]
  • [最多5条，仅保留最有力的证据]

4. Switching Triggers

4. 用户转换触发因素

  • [What pushes customers off a product; what pulls them; labeled, cited]
  • [推动客户放弃某产品的因素；吸引客户转向的因素——需标记并引用来源]

5. So What?

5. 意义解读？

  • 3 opportunity hypotheses (phrased as problems, not features)
  • 2 battle-card-ready weaknesses (with evidence quality noted)
  • 3 assumptions to validate in real interviews Each bullet: label, confidence, URL where relevant.

A copy/paste fill-in version of this schema, with quality checks, lives in [`template.md`](template.md).
  • 3个机会假设（以问题形式表述，而非功能）
  • 2个可用于竞争话术卡的劣势（需标注证据质量）
  • 3个需在真实访谈中验证的假设 每个项目：标记、置信度、相关URL（如有）

该架构的可复制填充版本（含质量检查）位于[`template.md`](template.md)中。

Final Step (offer exactly 4 options)

最终步骤（提供恰好4个选项）

  1. Generate discovery interview questions from the top theme (
    discovery-interview-prep
    )
  2. Feed the weaknesses into a competitive battle card (
    battle-card-builder
    )
  3. Build an opportunity solution tree from the top hypothesis (
    opportunity-solution-tree
    )
  4. Re-run scoped to one theme in Verbose Mode
Accept 
1
, 
2
, 
3
, 
4
, 
1 and 2
, 
Verbose Mode
, or a custom path.
  1. 基于排名第一的主题生成需求发现访谈问题（
    discovery-interview-prep
    ）
  2. 将劣势信息导入竞争话术卡生成工具（
    battle-card-builder
    ）
  3. 基于排名第一的假设构建机会-解决方案树（
    opportunity-solution-tree
    ）
  4. 针对单个主题以详细模式重新运行
接受
1
、
2
、
3
、
4
、
1 and 2
、
Verbose Mode
，或自定义路径。

Examples

示例

A theme done right (fictional product, illustrative verbatims):

Theme: getting historical data out at contract end

  • Frequency: recurring — 9 reviews across two sites plus a forum thread, past 6 months
  • Verbatim: "export took three support tickets and still dropped custom fields" — [G2-style review, URL]
  • Verbatim: "we stayed a year longer than we wanted because leaving meant losing our audit trail" — [forum thread, URL]
  • Who says it: ops managers at 50-200-person firms — Inference (reviewer titles where shown)
  • Reading: exit friction is functioning as involuntary retention — Inference; a rival with effortless migration turns this from their moat into their churn event.
Notice the theme name contains no feature ("export tool") — it names the need, so discovery can explore solutions the reviews never imagined.
See 
examples/sample.md
 for a complete worked mining run (fictional FSM-software market) where frequency honesty caps a vivid theme at low confidence and each source's bias becomes a reading instruction. 
examples/sample-industrial.md
 shows the thin-voice case — what honest mining looks like when the market barely posts reviews.
正确的主题归类（虚构产品，示例引用）：

主题: 合同到期时导出历史数据

  • 出现频率: 反复出现——过去6个月内，两个网站的9条评论加上一个论坛帖子
  • 原文引用: "导出操作提交了三次支持工单，仍丢失了自定义字段" — [类G2评论, URL]
  • 原文引用: "我们多留了一年，因为离开意味着丢失审计追踪记录" — [论坛帖子, URL]
  • 发言者: 50-200人企业的运维经理 — 推论（基于显示的评论者头衔）
  • 解读: 退出障碍起到了非自愿留存的作用——推论；如果竞品提供顺畅的迁移功能，这将从对方的护城河变为其客户流失的诱因。
注意主题名称不包含任何功能（如“导出工具”）——它聚焦需求，因此需求发现可以探索评论中从未提及的解决方案。
完整的挖掘运行示例（虚构的现场服务管理软件市场）请见
examples/sample.md
，其中如实呈现的频率将一个生动的主题限定为低置信度，每个来源的偏差成为解读的依据。
examples/sample-industrial.md
展示了声音稀少的场景——当市场几乎没有评论时，如实挖掘的结果是什么样的。

Common Pitfalls

常见误区

  • Feature-name theming. Clustering by the feature customers blame instead of the need underneath hands your roadmap to the loudest UI complaint.
  • Verbatim laundering. Paraphrasing a review and quoting it. If it has quote marks, it must be a real excerpt at a real URL — this domain's do-not-invent list exists because fabricated customer quotes are both tempting and toxic.
  • Rant amplification. One vivid one-star review presented as a theme. Frequency honesty is the discipline: recurring, concentrated, or isolated — say which.
  • Skew blindness. Reading review sites as a census. The angry and the vocal are over-sampled; the satisfied-and-silent majority never posts. Bias notes per source are mandatory.
  • Skipping the validation handoff. Shipping themes straight into the roadmap. The output's "assumptions to validate in real interviews" section is the bridge to discovery — use it.
  • 按功能名称归类主题。按客户抱怨的功能而非背后的需求进行聚类，会让你的 roadmap 被最响亮的UI投诉主导。
  • 原文引用篡改。paraphrase评论后再引用。如果使用引号，必须是真实的摘录并附带真实URL——本领域禁止编造内容，因为编造客户引用既诱人又有害。
  • 放大极端言论。将一条生动的一星评论当作普遍主题。如实呈现频率是基本原则：反复出现、集中出现还是孤立出现——明确说明。
  • 忽视来源偏差。将评论网站视为全面的用户普查。愤怒和活跃的用户被过度采样；满意但沉默的大多数从不发帖。必须标注每个来源的偏差。
  • 跳过验证环节。直接将主题纳入roadmap。输出中的“需在真实访谈中验证的假设”部分是连接到需求发现的桥梁——务必使用它。

References

参考资料

  • autonomous-investigation
     (Workflow) — the governing protocol
  • intelligence-collection-disciplines
     (Component) — OSINT review-mining sources and bias tradecraft
  • jobs-to-be-done
     (Component) — the solution-free framing themes should land in
  • discovery-interview-prep
     (Interactive) — where the validation happens
  • opportunity-solution-tree
     (Interactive) — structures the opportunity hypotheses
  • battle-card-builder
     (Workflow) — consumes the weak points
  • Adapted from 
    market-intelligence/voice-of-customer-miner-prompt.md
    in the 
    https://github.com/deanpeters/product-manager-prompts
    repo.
  • autonomous-investigation
    （工作流）——管理协议
  • intelligence-collection-disciplines
    （组件）——开源情报评论挖掘来源与偏差处理技巧
  • jobs-to-be-done
    （组件）——主题应采用的无解决方案框架
  • discovery-interview-prep
    （交互工具）——验证环节的执行工具
  • opportunity-solution-tree
    （交互工具）——构建机会假设的结构工具
  • battle-card-builder
    （工作流）——处理劣势信息的工具
  • 改编自
    https://github.com/deanpeters/product-manager-prompts
    仓库中的
    market-intelligence/voice-of-customer-miner-prompt.md
    。