user-research-synthesis

用途

User Research Synthesis 是一个面向创始人或产品经理的技能，用于把原始定性研究数据综合为结构化、可执行的洞察。当用户提供客户访谈记录、调查开放题回答、支持工单日志、NPS 文本、销售通话笔记、应用商店评论或社区论坛帖子等材料，并需要提炼结论时激活。触发语包括“总结这些访谈”“客户在告诉我们什么”“综合这些反馈”“帮我分析这些客户对话”等。

主要能力

该技能的工作流包括：

1. 通读完整记录——在开始总结前，从头到尾阅读整个记录或数据源，避免近因偏差并确保不遗漏内容。
2. 记录元数据——记录访谈日期、参与者、参与者背景及对话上下文。
3. 识别当前解决方案——记录参与者当前使用的解决方案及其满意度，从用户视角揭示竞争格局。
4. 提取问题与痛点——用参与者自己的语言记录每个提到的问题，区分症状与根因。
5. 应用 Jobs to Be Done 框架——将每个主要发现表述为 JTBD：“当[情境]时，我想要[动机]，以便[预期结果]。”
6. 标记意外发现——记录任何令人惊讶的洞察、矛盾或挑战现有假设的发现。
7. 定义后续行动——列出具体下一步及负责人。
8. 评估置信度——根据数据量和跨来源一致性，将每条洞察评为高/中/低置信度。

输出格式分为两部分：单份访谈摘要（含元数据、当前解决方案、用户喜欢之处、识别的问题、关键发现、后续行动）和跨访谈综合（含 JTBD 地图、可执行洞察、开放问题）。JTBD 地图以表格呈现，包含 Job Statement、Frequency、Segments、Confidence 列。可执行洞察使用固定句式：“We learned that [finding] which means [implication] so we should [recommendation]。”

使用方式

需要从 startup-context 获取：产品阶段、当前客户细分、正在测试的已知假设、现有用户画像（如有）。需要用户提供：原始数据源（记录、笔记、录音）、正在研究的研究问题、参与者背景信息、需要验证或证伪的具体假设。

适用场景

适用于创始人或 PM 手头有原始定性数据、需要将其综合为结构化洞察的场景，包括客户访谈记录、调查开放题、支持工单、NPS 文本、销售通话笔记、应用商店评论、社区论坛帖子等。

框架与最佳实践

• Jobs to Be Done (JTBD)：将每个发现表述为客户试图完成的任务，而非他们想要的功能。
• 先读后总结：始终处理完整记录后再写摘要，部分阅读会产生有偏差的综合。
• 平实语言优于术语：摘要应让团队中任何人都能理解，包括非技术利益相关者。
• 保留直接引语：最有力的数据点是捕捉参与者情绪、具体性和语言的原话。
• 区分满意度与问题：明确记录用户喜欢当前解决方案的哪些方面，同时记录令他们沮丧之处。
• 当前解决方案揭示竞争对手：记录参与者今天使用什么（包括电子表格、手动流程和变通方法）可揭示真实竞争格局。
• 频率不等于重要性：被 10 位用户中 2 位提到的问题，如果这 2 位代表理想客户画像，可能比 8 位提到的问题更关键。
• 偏差意识：注意招募偏差（谁未被访谈）、引导性问题偏差（审查访谈脚本）和幸存者偏差（当前用户 vs 流失用户）。
• 最小可行样本：定性研究通常每个细分 5-8 次访谈达到主题饱和，低于此阈值应标记。
• 三角验证：跨数据类型交叉引用发现，由访谈、支持工单和调查数据共同支持的洞察比单一来源更强。
• 持续发现：将访谈综合视为持续实践而非一次性项目。

相关技能

• prd-writing：将研究综合直接链接到 PRD 的背景和市场细分部分。
• competitive-analysis：将客户洞察与竞争数据结合，识别竞争对手不足的未满足任务。
• feedback-synthesis：当同时有结构化反馈数据（工单、NPS）和访谈记录时链接使用。

示例

示例 1：单份访谈摘要。用户提供物流经理的发现访谈记录并要求总结。输出包含元数据（2026 年 3 月 10 日 | Sarah Chen，MidCo 物流经理，150 名员工）、当前解决方案（Excel 电子表格和邮件链协调发货，满意度 3/10）、识别的问题（无单一发货状态真相来源，提到 4 次；无法实时查看司机可用性；每周五需手动汇总数据向管理层报告）、关键发现（团队已建立非正式 Slack 频道作为实时更新的变通方法，这未在研究计划中预料到，表明消息集成可能比仪表板功能优先级更高）。

示例 2：多访谈综合。用户完成 8 次 B2B 排程工具客户访谈并提供记录，询问关键要点。输出包含 JTBD #1（7/8 访谈，高置信度）：“当我在 3 个以上时区协调会议时，我想要在一个视图中看到所有人的可用性，以便无需 6 封来回邮件就能预订时段。”洞察：我们了解到多时区排程是主要任务，而非广义的日历管理。这意味着我们的定位应主打“全球团队协调”而非“智能日历”。我们应在下个冲刺优先考虑时区叠加功能。开放问题：8 位参与者中没有独立用户，我们仍不知道产品对没有团队的个人是否有价值。

限制

资料未提供该技能的具体安装方式、平台支持范围、收费模式或价格信息。