feedback-synthesis

反馈综合分析

适用场景

当创始人或产品负责人需要梳理来自多个渠道的客户反馈时，可启用此流程——例如支持工单、NPS 调查、用户访谈、应用商店评论、社交媒体、销售通话记录、功能请求日志、电子表格或 CSV。这包括诸如“分析我们的客户反馈”“用户最常提出什么需求”“确定功能请求的优先级”“整理这个待处理事项列表”或“我们的支持工单中出现了哪些主题”等提示。

所需上下文

• 来自 startup-context： 产品类型、客户群体、当前产品路线图优先级、公司阶段、战略目标和产品目标。
• 来自用户： 原始反馈数据（或其访问权限）、待分析的来源、时间范围、用于指导优先级排序的产品目标或预期结果，以及本次分析将为哪项决策提供参考。

工作流

1. 了解目标——确认将用于指导优先级排序的产品目标和预期结果。缺少战略视角的反馈分析只会产生噪声，而非有效信号。
2. 收集并规范化数据——汇总所有来源的反馈。如果数据采用结构化格式（CSV、电子表格），则创建汇总表。每条反馈作为一行，包含来源、日期、客户群体、原文引用和情绪倾向。
3. 归纳主题——将相关请求和反馈归为一组，并为每个主题命名。重点在于识别潜在机会（问题），而不是表面上的功能请求。
4. 评估战略契合度——针对每个主题，评估其与既定产品目标和公司战略的契合程度。
5. 使用机会得分进行评分——使用机会得分框架（Dan Olsen）：机会得分 = 重要性 ×（1 - 满意度），归一化到 0-1。此方法优先考虑最重要且目前满足程度最低的问题。
6. 确定优先机会——根据影响力（客户价值和受影响用户范围）、投入（所需开发和设计资源）、风险（技术和市场不确定性）以及战略契合度（与产品愿景的契合程度），选出排名靠前的 3 个主题。
7. 深入分析重点事项——针对每个重点机会，记录：理由、值得考虑的替代方案、高风险假设，以及如何以最小投入验证这些假设。
8. 呈现发现——提交结构化综合分析，先给出执行摘要，再提供支持数据，最后提出建议措施。

输出格式

综合分析报告模板

# Customer Feedback Synthesis -- [Period]

## Executive Summary
3-5 key findings. Lead with the most surprising or actionable insight.

## Product Goal Alignment
The stated product objective and how feedback themes map to it.

## Theme Map
| Theme | Frequency | Segments Affected | Opportunity Score | Strategic Alignment | Priority |
|-------|-----------|-------------------|-------------------|---------------------|----------|
| [Theme] | [Count] | [Segments] | [Score] | [High/Med/Low] | [H/M/L] |

## Top 3 Opportunities (Deep Dives)
### Opportunity 1: [Theme Name]
- **Rationale:** Customer needs and strategic alignment
- **Representative quotes:** Direct user language
- **Alternative solutions:** Other ways to address this need
- **High-risk assumptions:** What must be true
- **Cheapest test:** How to validate with minimal effort

## Quick Wins
Actions that address frequent feedback with low implementation effort.

## Not Prioritized (and Why)
Themes explicitly deprioritized with reasoning.

## Appendix: Raw Data Summary
Breakdown by source, segment, and time period.

框架与最佳实践

优先关注机会，而非功能

不要让客户设计解决方案。优先考虑机会（问题），而非功能。用户说“我想要甘特图”时，其潜在机会可能是“我需要直观呈现项目时间线，并向利益相关者传达状态”。务必深入挖掘请求背后的待完成任务。

机会得分（Dan Olsen）

为每个主题评分：机会得分 = 重要性 ×（1 - 满意度），归一化到 0-1。此方法能发现既重要又未得到充分满足的问题。重要性高、满意度也高的领域已经得到了很好的满足，不应优先于重要性高、满意度低的差距。

信号与噪声判断规则

• 一位客户提出不代表普遍问题。 将某个主题视为信号前，至少需要 3 条独立反馈。例外：如果这位客户是提出该问题可能导致客户流失的大客户。
• 检查近期偏差。 最近大量关于某个问题的反馈可能会掩盖长期存在的问题。务必与上一时期对比。
• 声音最大不等于最重要。 高级用户和积极发声的客户会产生不成比例的反馈。应根据客户群体规模和收入贡献进行加权，而不能只看反馈数量。
• 赞扬也是数据。 记录用户喜爱的方面。了解自身优势，能避免在重新设计时不慎破坏这些优势。

假设测试

针对每个优先级最高的机会，找出风险最高的假设，并设计成本最低的测试。不要为了验证一个可以通过原型、问卷或绿野仙踪实验来测试的假设，就构建完整解决方案。

针对不同来源的指导

来源	优势	注意事项
支持工单	信号明确，问题具体	容易偏向漏洞问题，遗漏满意用户
NPS/问卷	覆盖面广，可量化	回复率低可能导致结果偏差
功能请求板	组织有序，可获取投票数	高级用户可能主导投票
销售通话记录	与收入相关，体现潜在客户视角	潜在客户请求的功能可能永远不会使用
应用商店评论	公开可见，包含竞品对比	容易偏向负面，抱怨往往笼统
社交媒体	未经筛选，实时性强	噪声大，难以细分

避免常见错误

• 挑选支持既有假设的引述。 呈现完整分布，包括相互矛盾的反馈。
• 混淆频率与重要性。 低频但会导致用户流失的问题，比用户能够容忍的高频小烦恼更重要。
• 只提供数据，不给建议。 没有行动项的主题图谱只是报告，不是综合分析。务必以接下来该采取的行动收尾。
• 忽视沉默的大多数。 从不抱怨的用户可能很满意，也可能已经不再投入。细分分析有助于区分这两种情况。

相关技能

• user-research-synthesis —— 当反馈分析发现需要专门用户研究（访谈、可用性测试）的空白时，与此技能串联。
• churn-analysis —— 当反馈主题与流失模式相关，需要深入分析留存情况时，与此技能串联。
• prd-writing —— 当综合分析发现明确机会，需要将其编写为 PRD 规格时，与此技能串联。

示例

示例 1：功能请求优先级排序

用户：“我们的功能请求板上有 150 项。帮我确定下个季度该开发什么。”

良好输出摘录：

执行摘要： 150 项请求可归为 9 个主题。首要机会并非请求最多的功能（SSO，34 票），而是最未得到满足的需求：“对共享文档进行实时协作”（机会得分：0.82）。SSO 得分较低（0.45），因为现有替代方案已能充分满足大多数用户。

机会 1：实时协作

• 理由： 来自 4 个细分群体的 22 项请求。在 3 笔企业交易中被列为扩展业务的障碍，涉及金额共计 85K ARR。当前满意度：2/10。
• 替代方案：（a）完整的实时编辑；（b）轻量级评论和在线状态指示；（c）带通知的异步审阅工作流
• 高风险假设： 用户想要同时编辑，而不只是了解他人的更改
• 成本最低的测试： 仅添加在线状态指示（显示谁正在查看文档），并衡量与协作相关的工单是否减少

示例 2：多来源综合分析

用户：“我们有 200 张支持工单、50 份 NPS 回复，以及上个月 10 次客户访谈的记录。客户在告诉我们什么？”

良好输出摘录：

主题 1：大型数据集的 CSV 导出失败（机会得分：0.91）

• 47 张支持工单、8 份 NPS 贬损者回复、3 次访谈。用户遇到 10K 行限制时，会通过手动拆分导出来规避问题。
• 战略契合度： 高——数据导出是我们“开放平台”定位的核心。
• 成本最低的测试： 无需测试；这是明确的漏洞/限制，直接修复即可。
• 速赢项： 将 CSV 导出上限提高到 100K 行（工程预估：2 天）。