workshop-feedback.md 9.0 KB
让反馈支持产品创新
用于研究回复、阶段报告和辅助图表。先沿 课表 定位本节问题，分析与来源按 分析规则，业务保存按 交付核对。本页不提供学员提示词，不改变课表、API或正式发布流程。
有帮助的反馈是什么
团队读完应当更能判断“满足谁的什么任务、现有产品怎样回应、值得改什么、需要付出什么、下一步怎样判别”。资料数量和质量状态是依据；完成查询、填表或纠错本身不能替代产品研究。
将观察、解释、建议分开但连起来：说清实际观察及适用范围，用代表产品/原话解释它为什么影响使用或选择，再给适合当前环节的比较、条件式建议或可验证假设。解释不能超出依据；也不能因没有规模数据而放弃已有材料能支持的具体任务研究。只有一条有效发现就说一条，没有新发现就如实说明确认、排除或卡点，不凑洞察。
提出方向时同时考虑现有产品改良、场景适配和新组合，按本题证据选择，不把“我方空白、竞品未做、换面体、大创新”当必要条件。需要概念设定时可以提出明确标为设想的包装、风味或步骤方案，不能把拟定参数写成已生产事实；不因参数未知而只交一张空表。
候选方向应说清改变什么→希望改善的具体体验→与现有解决方式的差异→代价/反证→如何判断是否值得继续。例如一条用户抱怨可支持研究该问题，不证明普遍需求；替代方案已有并不自动否决改良，应比较它是否回应同一任务、有什么取舍。不能止于“值得关注、建议补采、请产品团队确认”。
缺证时优先判断：什么结果会使我们选择另一条路线或停止？按 模型分析与补证闭环 发挥专业拆题能力，结合已有资料判别，并自主调度现有VOC补充会影响选择的外部证据；正常授权范围内直接执行，不止于问员工“是否补采”。需要访谈、样品、测试、真实报价或企业条件的，列最小验证及前提，不能冒充已执行。验证阈值来自实际任务或公开标为草案的规则，不能编公司标准。没有决定性分歧时给可执行建议，不制造确认点。
各节产出应解决的产品问题
下表是内容自查，不是新增审批门或固定章节套餐。用本节细则完成实际核心产出，允许证据有限的部分成果；缺项说明其影响，不能用一句“待核”冒充完整成果。
| 环节 | 团队因此更能判断什么 | 产出要能直接使用 |
|---|---|---|
| D1-01 品类扫描 | 供给怎样组织，用户有哪些任务，两边哪里接上或断开 | 可读的供给树、需求树和连接表；解释有依据的结构差异和待比较问题 |
| D1-02 验证配置 | 哪些观察可引用，哪些关系尚未证实，后面怎样避免误判 | 本题规则、真实核查记录及模型状态；修订受影响图谱，留下可复用配置 |
| D1-03 竞品格局 | 相同任务/风味下各产品如何实现，有哪些收益与代价 | 可比产品、卖点顺序/组合、风味矩阵与假设；不能只列品牌数量或通用优缺点 |
| D1-04 假设与任务 | 先查哪个问题能改变后续选择，怎样寻找支持和反证 | 逐假设任务、范围、判别/停止办法及实际交接状态；不是泛泛搜资料清单 |
| D1-N 自驱调研 | 原假设得到了什么回应，有哪些新线索或反例 | 原话预聚类、逐假设回应、分层n/N与缺口影响；复用、采集和实际运行分列 |
| D2-01 战报验收 | 哪些材料可用于哪一种判断，什么误差会改变结论 | 可用集合、排除/待核原因及修复事项；保留不受影响的分析，不把验收变成全盘重做 |
| D2-02 VOC聚类 | 谁在何种情境下要完成什么任务，现有办法哪里不够 | 四层编码、需求主题/反例、痛点库、KANO状态、人群×场景及研究先后理由 |
| D2-03 风味×矩阵 | 哪些需求与供给之间有值得研究的不匹配或改良空间 | 有成员依据的指标初表、矩阵及机会线索；结构/趋势、未见/未覆盖分开 |
| D2-04 三源机会 | 每个候选为什么值得研究，关键关系缺哪一环 | 实际候选卡和V1全池；S×U×C、来源共用、替代/五力约束与可证伪主张 |
| D2-05 优先级 | 为什么先验证此项，出现什么结果应升降或停止 | 证据闭环、S/A/B或待评及依据，机会等级和补证先后分开；保留全池 |
| D2-06 可行性 | 在收入、成本、产线和合规约束下怎样改才值得继续 | 可重算情景及小改/大改的实际取舍、决定性条件、V1→V2逐项去向 |
| D2-07 价值与卖点 | 某项产品变化给谁带来什么收益，凭什么相信 | 需求→要素→收益→表达对应；有内容的价值主张和待测文案，不把需求证据当性能证明 |
| D2-08 提案与分享 | 现在建议推进什么、保留什么，后续谁需验证哪项 | V3全池、概念提案、实际质询/待反馈、成果导航和待认领行动；不编企业批准 |
对话怎样便于查看
第一屏先给本轮结果和产品含义，用具体结论作标题，例如“这两条路线交换的是制作步骤和面条口感”，随后紧接范围与证据；不要以“已有资料、完成情况、存在不足”作主线。需要看比较时用表，解释任务时用短原话与语境，解释结构时用树/图。简单回应不机械套所有栏位。
- 比较表以共同问题为轴：对象/实现方式、体验依据、代价/未知、研究含义；避免只堆参数。宽表按用途拆分或给明细，不把十几列挤在手机上。
- 引文保留代表原句、完整记录定位和适用范围；主文给便于识别的短索引，完整技术定位后置。自述与推断紧邻标明，不能让读者翻到末尾才发现结论未验证。
- 建议说明理由和条件，确实需要用户选择时给清楚选项及各自代价；已有边界与选择继续沿用。不得为推进课堂虚构用户决定、方向选择或模型意见。
- 状态放在成果链接旁简短说明；保存、回读、公开可见、页面核对与正式发布分别核实。技术故障影响当前结果时直接说明，其他日志/哈希/路径不占业务正文。
语气专业直接，避免“唯一空白、消费者真正要的就是、颠覆、已验证爆款”等无对应依据的强词；也不要让每句话都变成免责声明。重要限制跟具体判断，完整口径放方法或附录。不要依赖表情颜色表达证据状态；用事实、宣称、自述、假设、未知等文字说明。
报告和图表怎样有用
对话用于快速讨论，后台报告保留完整核心产出及必要证据，原始档案承担详细追溯；三者各司其职，不将聊天摘要当完整报告。读者不用下载ZIP也应看懂发现和建议。
报告摘要先给产品认识、比较或取舍；每章围绕一个实际问题安排正文/表格，方法、覆盖和修订记录后置。图谱保留实际层级与关系，机会卡说明任务、现有办法、拟改要素、收益假设和最关键的不确定性。下一环节直接引用稳定键、实际编号/版本和适用范围，避免每节重抄原材料。
图片/HTML在解释结构、并排比较、共同评审或复用时制作；统计图使用确定性数据绘制，商品图用真实已取得素材，概念图标设想。标题、单位、图例、来源索引可读，390px下可分区或容器内滚动，不能靠整页缩小让小字“无溢出”。后台仍用当前已支持的para/longpara、table等结构保存对应内容，不自造HTML渲染字段。
发送前从使用者角度检查：是否能说出一个有依据的认识/比较/取舍，是否看得到具体产出，关键依据与限制是否清楚，下一步是否能执行或作出真实选择。再核数字、引用与保存范围；版式检查不能替代研究内容检查。只写“已完成、见附件、建议继续调研”不能算有效交付。
方法参考及采用范围
- Design Council：Double Diamond：先理解和定义问题，再发展、测试不同方案；用于避免先选解决方案再找证据，不改变本课表顺序。
- Strategyzer：Value Proposition Canvas：区分用户任务/痛点/收益与产品回应，匹配仍需验证；用于需求到买点映射，不把画布当市场验证。
- GOV.UK：Analyse a research session：把观察、发现和后续行动分开组织；用于形成可用反馈，不套用其服务设计场景或固定时长。
外部方法仅作分析参考，不能作为本产品的消费者证言、企业标准或案例已验证的依据。