product-lens

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Product Lens — Think Before You Build

产品视角——先思考再开发

This lane owns product diagnosis, not implementation-ready specification writing.

If the user needs a durable PRD-to-SRS or capability-contract artifact, hand off to

product-capability

该技能专注于产品诊断，而非撰写可直接用于实施的规范文档。

如果用户需要将PRD转化为SRS或生成能力契约类文档，请转交至

product-capability

。

When to Use

使用场景

Before starting any feature — validate the "why"
Weekly product review — are we building the right thing?
When stuck choosing between features
Before a launch — sanity check the user journey
When converting a vague idea into a product brief before engineering planning starts

开始任何功能开发前——验证需求的“初衷”
每周产品评审——我们是否在做正确的事？
难以在多个功能间做选择时
产品发布前——对用户旅程进行合理性检查
在进入工程规划前，将模糊想法转化为产品简报时

How It Works

工作机制

Mode 1: Product Diagnostic

模式1：产品诊断

Like YC office hours but automated. Asks the hard questions:

1. Who is this for? (specific person, not "developers")
2. What's the pain? (quantify: how often, how bad, what do they do today?)
3. Why now? (what changed that makes this possible/necessary?)
4. What's the 10-star version? (if money/time were unlimited)
5. What's the MVP? (smallest thing that proves the thesis)
6. What's the anti-goal? (what are you explicitly NOT building?)
7. How do you know it's working? (metric, not vibes)

Output: a

PRODUCT-BRIEF.md

with answers, risks, and a go/no-go recommendation.

If the result is "yes, build this," the next lane is

product-capability

, not more founder-theater.

类似YC办公时间的自动化版本，提出尖锐问题：

1. 这是面向谁的？（具体的人，而非“developers”这类泛称）
2. 用户的痛点是什么？（量化描述：发生频率、严重程度，用户当前的解决方式是什么？）
3. 为什么是现在？（哪些变化让这件事成为可能/必需？）
4. 理想的10分版本是什么样的？（假设时间和资金不受限制）
5. 最小可行产品（MVP）是什么？（能验证核心假设的最小功能集合）
6. 反目标是什么？（明确说明哪些内容不会去开发？）
7. 如何判断它有效？（用指标衡量，而非主观感受）

输出：一份包含答案、风险以及是否推进建议的

PRODUCT-BRIEF.md

文档。

如果结果是“可以推进开发”，下一步应转交至

product-capability

，而非继续停留在创始人层面的讨论。

Mode 2: Founder Review

模式2：创始人视角评审

Reviews your current project through a founder lens:

1. Read README, CLAUDE.md, package.json, recent commits
2. Infer: what is this trying to be?
3. Score: product-market fit signals (0-10)
   - Usage growth trajectory
   - Retention indicators (repeat contributors, return users)
   - Revenue signals (pricing page, billing code, Stripe integration)
   - Competitive moat (what's hard to copy?)
4. Identify: the one thing that would 10x this
5. Flag: things you're building that don't matter

通过创始人的视角评审当前项目：

1. 阅读README、CLAUDE.md、package.json以及近期提交记录
2. 推断：该项目的定位是什么？
3. 评分：产品市场契合度指标（0-10分）
   - 使用量增长趋势
   - 留存指标（重复贡献者、回头用户）
   - 营收信号（定价页面、计费代码、Stripe集成）
   - 竞争壁垒（哪些内容难以被复制？）
4. 识别：能让项目价值提升10倍的核心举措
5. 标记：正在开发但无关紧要的内容

Mode 3: User Journey Audit

模式3：用户旅程审计

Maps the actual user experience:

1. Clone/install the product as a new user
2. Document every friction point (confusing steps, errors, missing docs)
3. Time each step
4. Compare to competitor onboarding
5. Score: time-to-value (how long until the user gets their first win?)
6. Recommend: top 3 fixes for onboarding

映射真实的用户体验：

1. 以新用户身份克隆/安装产品
2. 记录每个摩擦点（步骤混淆、错误、文档缺失）
3. 统计每个步骤的耗时
4. 与竞品的入门流程进行对比
5. 评分：价值交付时长（用户获得首次正向反馈所需的时间）
6. 建议：入门流程的三大优化方案

Mode 4: Feature Prioritization

模式4：功能优先级排序

When you have 10 ideas and need to pick 2:

1. List all candidate features
2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5)
3. Rank by ICE score
4. Apply constraints: runway, team size, dependencies
5. Output: prioritized roadmap with rationale

当有10个想法需要选出2个时：

1. 列出所有候选功能
2. 按以下公式评分：影响力（1-5分）× 置信度（1-5分）÷ 投入成本（1-5分）
3. 按ICE分数排序
4. 应用约束条件：资金储备、团队规模、依赖关系
5. 输出：带有决策依据的优先级 roadmap

Output

输出结果

All modes output actionable docs, not essays. Every recommendation has a specific next step.

所有模式都会输出可落地的文档，而非空泛的论述。每一条建议都包含明确的下一步行动。

Integration

集成搭配

Pair with:

```
/browser-qa
```
to verify the user journey audit findings
```
/design-system audit
```
for visual polish assessment
```
/canary-watch
```
for post-launch monitoring
```
product-capability
```
when the product brief needs to become an implementation-ready capability plan

搭配使用：

```
/browser-qa
```
：验证用户旅程审计的发现
```
/design-system audit
```
：评估视觉优化程度
```
/canary-watch
```
：发布后监控
```
product-capability
```
：当产品简报需要转化为可实施的能力规划时