产品调研

product-research
分类编程
作者Alireza Rezvani
许可MIT
评分4.30/5
使用6.4K

product-research

将产品/用户研究作为一种运营学科：选择正确的方法，诚实地确定规模，并将研究结果综合为受管控的洞察。核心原则：方法必须与目标匹配，且洞察必须在独立参与者之间具有重复性 —— 单个引用仅视为轶事。

目的

产品研究员、ResearchOps 团队以及进行探索工作的 PM 需要方法论的严谨性和一个可信的洞察仓库。本技能构建了三个决策维度：

三个确定性工具：

1. study_designer.py —— 将（研究目标 × 产品阶段）映射到合适的方法，并输出匹配方法的计划骨架（目标、参与者标准、指南结构、成功标准）。将实时 A/B 测试重定向至 product-team/experiment-designer。
2. saturation_planner.py —— 提供基于方法的样本量指导，并附带明确的置信标签：Nielsen 问题发现（每细分群体 5 人）、Guest 等人的主题饱和度（约 12 人）以及评估覆盖率。绝不在小样本可用性测试中声称某种流行率。
3. insight_synthesizer.py —— 按标签对编码后的观察结果进行聚类，统计独立参与者人数，按跨参与者的重复次数排序，并将任何低于来源阈值的候选结果标记为轶事 (ANECDOTE)，绝不将其提升为洞察。

使用场景

在以下情况调用此技能：

  • 你正在规划一项研究，且需要方法与目标匹配（生成式 vs 评估式 vs 验证式）。
  • 你需要一个具有可证明的样本量/饱和度依据及明确的置信度。
  • 你拥有原始的编码观察结果，需要综合洞察且避免过度解读。
  • 你正在建立或审计研究仓库，需要区分“洞察”与“观察”的纪律。

不要使用此技能来：生成用户画像/旅程图（使用 product-team/ux-researcher-designer）、规划探索冲刺或验证机会（使用 product-team/product-discovery）、设计或分析实时产品 A/B 实验（使用 product-team/experiment-designer），或进行市场规模测算/问卷调查（使用同级技能 market-research）。

工作流

1. 界定研究 —— 填写 assets/research_plan_template.md（研究问题、方法依据、参与者标准、分析计划、仓库标签方案）。
2. 选择方法 —— 运行 study_designer.py --goal {discovery|evaluative|validation} --stage {concept|prototype|beta|live} --profile {b2b-saas|consumer-app|enterprise|marketplace|hardware|platform}。如果路由至外部工具，请遵循重定向。
实验设计者。
3. 确定规模 — 运行 saturation_planner.py --method {usability|thematic|evaluative-coverage} --segments N。记录置信度标签和限制。
4. 综合分析 — 调研结束后，对观察结果进行编码并运行 insight_synthesizer.py --input observations.json --min-sources 3。将标记为 ANECDOTE（轶事）的聚类视为需要进一步探究的信号，而非可直接交付的结论。
5. 归档至仓库 — 在综合分析时，将洞察（insights）与其证据和置信度一起标记到原子模式（atomic schema）中。

脚本

| 脚本 | 用途 | 配置方案 (Profiles) |
|---|---|---|
| scripts/study_designer.py | (目标 × 阶段) → 方法 + 计划框架 | b2b-saas, consumer-app, enterprise, marketplace, hardware, platform |
| scripts/saturation_planner.py | 基于方法的样本指导 + 置信度 | 不适用 (由方法驱动) |
| scripts/insight_synthesizer.py | 聚类观察结果，标记轶事 | 不适用 (由证据驱动) |

以上三个脚本均：仅依赖标准库，支持 --help、--sample、--output {human,json}。

入职引导与自定义

在开始前运行一次入职问卷 —— 它会记录你的默认设置，以便该技能中的每个工具都能预先配置。自定义是核心：你的回答会实际改变工具的行为（例如洞察的来源阈值）。

bash
python3 scripts/onboard.py            # 交互式 (支持: --defaults, --set key=value, --reset)
python3 scripts/onboard.py --show     # 查看问题及当前生效的配置

答案保存至 ~/.config/research-ops/product-research.json (全局) 或 ./.research-ops/product-research.json (--scope project)，并由 config_loader.py 自动读取。这些设置决定了默认的产品 profile、洞察来源阈值（多少个独立参与者能使一项发现成为“洞察”而非“轶事”）、默认的 饱和度方法 以及 高风险 (high-stakes) 标志。CLI 标志始终覆盖保存的配置；设置 RESEARCH_OPS_NO_CONFIG=1 可忽略配置。

四个问题： 产品 profile · 洞察来源阈值 · 饱和度方法 · 高风险标志。

使用 autoresearch 优化 (可选)

本技能提供了一个隔离的、可选的桥接接口，连接至 engineering/autoresearch-agent。只有当你要求“优化综合分析”或“运行循环”时，autoresearch 实验才会迭代地细化固定证据集的编码/聚类，从而挖掘出更多跨参与者的模式。scripts/ar_evaluator.py 是基准评估器；它会打印 validated_insights: <int> (数值越高越好)。它优化的是编码过程，绝不会伪造证据。

bash
/ar:setup --domain custom --name insight-synthesis \
  --target observations.json \
  --eval "python3 ar_evaluator.py --target observations.json" \
  --metric validated_insights --direction higher
/ar:loop custom/insight-synthesis

隔离性：无硬性依赖 —— autoresearch 仅在按需时运行，且循环仅修改 observations.json，绝不修改评估器。

参考资料

  • references/research_methods_canon.md — Portigal 的 *Interviewing Users*；Christensen/Ulwick 的 JTBD；Rohrer 的 UX 研究方法图谱 (NN/g)；Sauro & Lewis 的 *Quantifying the User Experience*；Goodman/Kuniavsky。
  • references/sampling_and_saturation.md — Nielsen 的“5 用户测试”；Guest, Bunce & Johnson 的饱和度理论；Faulkner 关于 5 人以上样本的论述；Sauro 的可用性样本量；Braun & Clarke 的主题分析法。
  • references/repository_and_synthesis.md — ResearchOps / 原子研究 (Tomer Sharon "Polaris")；洞察与观察的区分原则；仓库治理；亲和图 (affinity)
映射；民主化护栏。

核心假设

  • 方法选择：假设你能诚实地定义目标；如果目标模糊，请先对其进行质询（目标决定一切）。
  • 饱和度指导：基于方法而非样本量计算——可用性测试是为了发现问题，而非计算发生率。
  • 综合分析器：仅对你提供的证据进行计数；编码质量决定分析结果。标签混乱 $\rightarrow$ 聚类混乱。
  • 洞察阈值 (--min-sources)：默认为 3；针对高风险场景或异质群体请调高此值。

反模式

  • 方法与目标不匹配：可用性测试无法发现未满足的需求；访谈无法衡量任务成功率。
  • 将可用性问题以百分比形式报告：小样本测试旨在揭示问题，而非统计人群发生率。
  • 将轶事误认为洞察：单个参与者的反馈是进一步挖掘的信号，而非结论。
  • 将访谈问题设定为对功能的反应：应探究“待办任务”（Job-to-be-done）和近期的真实行为，而非假设性的观点。
  • 在没有仓库方案的情况下进行综合分析：必须在综合分析时打标签，否则洞察将因无法检索而失效。

区分

| 邻近领域 | 范围 | 区别 |
|---|---|---|
| product-team/ux-researcher-designer | 与设计产出挂钩的用户画像、旅程图、可用性框架 | 该角色产出交付物；本方案关注方法 + 仓库纪律 |
| product-team/product-discovery | 机会验证、探索冲刺（Discovery Sprint）规划 | 该角色规划探索冲刺；本方案设计并综合研究 |
| product-team/experiment-designer | 线上产品 A/B 假设 + 样本量 | 该角色运行线上实验；本方案运行定性/评估性研究 |
| market-research (同级) | 市场规模测算、问卷调查、市场细分 | 该领域研究市场；本方案研究用户 |

快速示例

bash
python3 scripts/study_designer.py --sample
python3 scripts/saturation_planner.py --method thematic --segments 3
python3 scripts/insight_synthesizer.py --sample --min-sources 3

综合分析器示例正确地将 "import-confusion"（3 名独立参与者）提升为“洞察”（INSIGHT），并将 "wants-slack"（1 名参与者）标记为“轶事”（ANECDOTE）。

强制质询库 (Matt Pocock 质询纪律)

由 /cs:grill-research-ops 或编排器逐一引导。每道问题配有推荐答案 + 权威引用。严禁打包提问。

1. “这项研究是生成性的（发现问题）还是评估性的（测试方案）？”
推荐：先定义性质——方法由目标决定。
权威引用：Rohrer, *When to Use Which User-Experience Research Methods* (NN/g)。

2. “你的样本量和饱和度依据是什么——置信度是多少？”
推荐：基于方法的 n 值（可用性测试每组 5 人；主题分析饱和度约 12 人），并说明置信度。
权威引用：Nielsen; Guest, Bunce & Johnson (2006); Faulkner (2003)。

3. “每个洞察由多少名独立参与者支持——还是仅为单一来源的轶事？”
推荐：要求在 $\ge 3$ 个来源中重复出现后才定义为洞察；标记单一来源项。
权威引用：atomic research / ResearchOps; Braun & Clarke 主题分析法。

4. “你的访谈/可用性任务是基于结果（任务）还是基于对功能的反应？”
推荐：围绕“待办任务”和近期的真实行为构建，而非假设性观点。
权威引用：Christensen/Ulwick Jobs-to-be-Done; Portigal *Interviewing Users*。

5. “该结果存储在仓库的哪个位置，如何打标签以便复用？”
建议：在合成阶段即标记至原子模式（atomic schema），而非事后标记。
规范：参考 Tomer Sharon, *Polaris* / ResearchOps 仓库实践。

采用深度优先遍历。在开启 3-5 之前，先锁定 1-2。全部回答完成后，依次调用 study_designer.py → saturation_planner.py → (实地调研后) insight_synthesizer.py。