Back to Details

synthesize-feedback

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Synthesize Feedback

反馈整合

Overview

概述

Perform Voice of Customer (VoC) analysis by clustering raw feedback into themes, quantifying frequency and sentiment, and separating signal from noise. Connects feedback patterns to product roadmap items.
通过将原始反馈聚类为主题、量化提及频率和情绪、区分有效信号与噪音，执行VoC（客户之声）分析。将反馈模式与产品路线图项关联起来。

Workflow

工作流程

  1. Read product context — Scan 
    .chalk/docs/product/
    for the product profile, existing PRDs, and roadmap docs. These anchor the analysis by providing the product's current priorities and known gaps.
  2. Gather feedback data — Parse 
    $ARGUMENTS
    to identify the feedback source and time period. If the user provides raw feedback inline, use that directly. If they reference files, read them. If no data is provided, ask the user to supply feedback data before proceeding.
  3. Clean and normalize — For each feedback item, extract the core request or complaint. Strip duplicate phrasing, normalize terminology (e.g., "crash" and "app freezes" map to the same theme), and tag the source channel (support, NPS, review, social, interview).
  4. Cluster into themes — Group feedback into 5-10 themes using affinity mapping. Each theme gets a label, a one-sentence description, and representative quotes. Avoid single-item themes unless the signal is strong (e.g., a security concern).
  5. Quantify each theme — For each theme, calculate: mention count, percentage of total feedback, average sentiment (positive / neutral / negative), and trend direction (new, growing, stable, declining) if historical data is available.
  6. Separate signal from noise — Flag themes that are: (a) high frequency + negative sentiment (urgent), (b) low frequency but high severity (monitor), (c) feature requests from power users vs. casual users (weight accordingly), (d) already addressed in the roadmap (acknowledge).
  7. Connect to roadmap — Cross-reference themes against existing PRDs and roadmap items in 
    .chalk/docs/product/
    . Mark themes as: addressed, partially addressed, unaddressed, or contradicting current direction.
  8. Determine the next file number — Read filenames in 
    .chalk/docs/product/
    to find the highest numbered file. Use 
    highest + 1
    .
  9. Write the synthesis — Save to 
    .chalk/docs/product/<n>_feedback_synthesis_<period>.md
    .
  10. Confirm — Share the file path and highlight the top 3 themes by urgency.
  1. 读取产品上下文 — 扫描
    .chalk/docs/product/
    目录获取产品概况、现有PRDs（产品需求文档）和路线图文档。这些内容将为分析提供锚点，明确产品当前的优先级和已知差距。
  2. 收集反馈数据 — 解析
    $ARGUMENTS
    以确定反馈来源和时间范围。如果用户直接提供了原始反馈内容，直接使用该内容；如果用户引用了文件，则读取对应文件；若未提供任何数据，请用户先提供反馈数据再继续。
  3. 清洗与标准化 — 针对每条反馈，提取核心请求或投诉。去除重复表述、统一术语（例如，将“crash”和“app freezes”映射为同一主题），并标记反馈来源渠道（支持工单、NPS、评论、社交媒体、用户访谈）。
  4. 主题聚类 — 使用亲和图法将反馈分为5-10个主题。每个主题需包含标签、一句描述性语句和代表性引用。除非信号极强（例如安全问题），否则避免仅包含单条反馈的主题。
  5. 主题量化 — 针对每个主题，计算：提及次数、占总反馈的百分比、平均情绪（正面/中立/负面）；若有历史数据，还需计算趋势方向（新增、增长、稳定、下降）。
  6. 区分信号与噪音 — 标记以下类型的主题：(a) 高提及频率+负面情绪（紧急），(b) 低提及频率但高严重程度（需监控），(c) 来自核心用户 vs 普通用户的功能请求（按权重区分），(d) 路线图中已规划解决的（需确认）。
  7. 关联路线图 — 将主题与
    .chalk/docs/product/
    中的现有PRDs和路线图项进行交叉比对。标记主题状态：已解决、部分解决、未解决或与当前方向冲突。
  8. 确定下一个文件编号 — 读取
    .chalk/docs/product/
    中的文件名，找到编号最大的文件，使用“最大编号+1”作为新文件编号。
  9. 撰写整合报告 — 将报告保存至
    .chalk/docs/product/<n>_feedback_synthesis_<period>.md
    。
  10. 确认结果 — 分享文件路径，并重点突出前3个最紧急的主题。

Output

输出

  • File: 
    .chalk/docs/product/<n>_feedback_synthesis_<period>.md
  • Format: Markdown with a summary table of themes, detailed theme sections, and a roadmap alignment section
  • Key sections: Executive Summary, Theme Table (theme / count / sentiment / trend), Theme Details (with quotes), Signal vs Noise Assessment, Roadmap Alignment, Recommended Actions
  • 文件：
    .chalk/docs/product/<n>_feedback_synthesis_<period>.md
  • 格式：Markdown格式，包含主题汇总表、详细主题章节和路线图对齐章节
  • 核心章节：执行摘要、主题表（主题/提及次数/情绪/趋势）、主题详情（含引用）、信号与噪音评估、路线图对齐、建议行动

Anti-patterns

反模式

  • Counting without context — Raw frequency is misleading. Ten mentions from one angry user is not the same as ten mentions from ten different users. Always deduplicate by user.
  • Ignoring sentiment polarity — A theme with 50 mentions that are mostly positive ("love the new search") is not the same as 50 negative mentions. Always report sentiment alongside frequency.
  • Treating all sources equally — NPS detractors and churned-user exit interviews carry more weight than a casual app store review. Weight signals by source reliability and user commitment level.
  • Missing the silent majority — Vocal users are not representative. Note when feedback comes from a small, self-selected group and flag the survivorship bias.
  • Synthesizing without connecting to action — A synthesis that does not recommend what to do next is just a report. Every synthesis should end with prioritized recommendations.
  • 无上下文计数 — 单纯的提及频率具有误导性。一位愤怒用户的10条反馈与十位不同用户各一条反馈的意义不同。务必按用户去重。
  • 忽略情绪极性 — 50条正面提及的主题（如“喜欢新的搜索功能”）与50条负面提及的主题完全不同。务必同时报告情绪和提及频率。
  • 同等对待所有来源 — NPS贬损者和流失用户的退出访谈比普通应用商店评论更具权重。需根据来源可信度和用户忠诚度对信号进行加权。
  • 忽略沉默的大多数 — 活跃发声的用户不具有代表性。需注明反馈是否来自小范围的自我选择群体，并标记生存偏差。
  • 未关联行动的整合 — 未给出后续行动建议的整合报告只是一份文档。每份整合报告都应包含优先级明确的建议。