product-lens

Product Lens — Think Before You Build

本工具专注于产品诊断，不负责编写可直接用于实现的规格文档。如果用户需要持久的 PRD-to-SRS 或能力契约产物，应移交给 product-capability。

何时使用

在开始任何功能之前——验证“为什么”。 每周产品复盘——我们是否在做正确的事？ 在功能之间难以取舍时。 发布前——检查用户旅程是否合理。 在工程规划开始前，把模糊想法转化为产品简报。

工作方式

模式 1：产品诊断 类似自动化的 YC office hours，提出尖锐问题：

1. 这是为谁做的？（具体的人，而不是“开发者”）
2. 痛点是什么？（量化：频率、严重程度、他们现在怎么做？）
3. 为什么是现在？（发生了什么变化让这件事成为可能或必要？）
4. 十星版本是什么？（如果资金和时间无限）
5. MVP 是什么？（能证明论点的最小东西）
6. 反目标是什么？（明确不做什么？）
7. 如何知道它有效？（指标，而非感觉） 输出：一份 PRODUCT-BRIEF.md，包含答案、风险和 go/no-go 建议。 如果结论是“是，构建它”，下一条路径是 product-capability，而不是继续创始人表演。

模式 2：创始人复盘 以创始人视角审阅当前项目：

1. 阅读 README、CLAUDE.md、package.json、近期提交
2. 推断：这个项目想成为什么？
3. 评分：产品市场契合信号（0-10）
   • 使用增长轨迹
   • 留存指标（重复贡献者、回访用户）
   • 收入信号（定价页、计费代码、Stripe 集成）
   • 竞争护城河（什么是难以复制的？）
4. 找出：能让这个项目增长十倍的那一件事
5. 标记：正在构建但不重要的事情

模式 3：用户旅程审计 映射真实用户体验：

1. 以新用户身份克隆/安装产品
2. 记录每一个摩擦点（令人困惑的步骤、错误、缺失文档）
3. 为每一步计时
4. 与竞品引导流程对比
5. 评分：首次价值达成时间（用户多久获得第一次成功？）
6. 建议：引导流程的前三项修复

模式 4：功能优先级排序 当有十个想法但需要选出两个时：

1. 列出所有候选功能
2. 对每个功能按 影响（1-5）× 置信（1-5）÷ 工作量（1-5）评分
3. 按 ICE 分数排序
4. 应用约束：资金跑道、团队规模、依赖关系
5. 输出：带理由的优先级路线图

输出 所有模式输出可执行的文档，而非长篇论文。每条建议都有具体的下一步。

集成 可搭配： /browser-qa 验证用户旅程审计发现 /design-system audit 进行视觉打磨评估 /canary-watch 进行发布后监控 product-capability 在产品简报需要变成实现就绪的能力计划时使用