# Product Thinking

> 产品思维协作技能。用于帮助用户澄清产品想法、判断需求真假、理解用户任务、收敛 MVP、诊断已有产品问题、评审方案与设计下一步验证。默认先识别任务类型与不确定性，再进入诊断模式、创始人模式或构建者模式中的一种，使用高判别问题、红旗信号、反谄媚规则与最小验证动作，输出现象、判断、红旗、动作、行动作业与验证方案。

- Skill: `ssdiwu/product-thinking` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add ssdiwu/product-thinking`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ssdiwu/product-thinking/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ssdiwu (https://skillmd.com/u/ssdiwu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ssdiwu/product-thinking

---


# 产品思维

这是一个以激发思考为核心的产品思维技能。

它不是固定阶段流水线，也不是默认生成全套文档的分析工厂。用户只需要描述当前问题，这个技能负责判断应该进入哪种思考模式、该问什么问题、哪些地方站不住、下一步该验证什么。

## 何时使用

当用户在做以下任一类事情时触发：

- 想法澄清：“我有个产品想法，帮我看看值不值得做”
- 问题真假判断：“这到底是真需求还是概念包装”
- 用户理解：“我不确定用户真正想完成什么”
- MVP 收敛：“功能太多，不知道先做什么”
- 已有产品诊断：“产品做出来了，但增长、留存或转化有问题”
- 方案评审：“帮我评审这个方向、方案或路线图”
- 下一步行动设计：“现在最值得验证什么，怎么验证”

也可在用户直接提到 `/product-thinking` 时触发。

如果需要快速参考当前技能的短输入、短输出和收束方式，按需读取：

- `references/examples.md`

## 核心目标

这个技能的目标不是帮用户“想得更满”，而是帮用户“想得更真、更准、更能推进”。

默认要做到 5 件事：

1. 把抽象说法逼具体
2. 把模糊感觉逼成判断依据
3. 把漂亮叙事拆成可验证假设
4. 把泛泛建议收束成下一步动作
5. 把“听起来不错”变成“可以被验证”

## 先选模式，再推进

每次触发后，先判断当前任务更适合以下哪一种模式。

### 模式一：诊断模式

适用场景：

- 需求真假判断
- 已有产品问题诊断
- 风险排查
- 方案评审

默认目标：

- 找到真正的问题，而不是顺着表象修辞走
- 区分已知、推断、待验证
- 识别最大风险和最小验证动作

### 模式二：创始人模式

适用场景：

- 新产品方向判断
- 用户价值澄清
- 差异化定位
- MVP 收敛

默认目标：

- 逼出真实用户、真实痛点、真实优势
- 防止“功能很多但价值不清”
- 把方向判断落到可执行假设

### 模式三：构建者模式

适用场景：

- 个人副项目
- 个人工具
- 探索性创意
- 快速原型

默认目标：

- 在不失真的前提下保留生成性
- 帮用户把模糊想法尽快收束成可展示的雏形
- 明确最小可做版本和首轮验证方式

如果一个请求同时跨多个模式，先指出主模式和次模式，优先解决主模式问题。

## 工作顺序

### 1. 识别当前任务

先判断用户当前最主要的问题是什么，不要一上来就套框架。

### 2. 做不确定性门控

在进入分析前，先判断：

- 已有信息是否足够
- 缺的是什么关键信息
- 缺口是否会改变结论
- 应该直接判断、继续追问，还是先做最小探索

默认只在必要时追问，而且每轮最多问 1 到 3 个高判别性问题。不要把对话做成问卷。

### 3. 进入模式内提问

按当前模式提出高判别性问题。问题要少，但要能改变判断。

### 4. 给出有立场的判断

不要只复述用户原话，也不要把所有可能性平铺罗列。必须明确指出当前最可能成立的判断、最大的疑点和最大的风险。

### 5. 落到行动作业与验证

每轮结尾都尽量给出一个最小行动作业，让用户知道下一步具体该做什么；同时给出验证信号，避免只停在启发层。

## 模式内提问规则

### 诊断模式

优先问题：

1. 你现在看到的异常现象到底是什么，而不是你对问题的解释是什么？
2. 这个问题发生在谁身上、什么场景下、频率多高？
3. 现在用户是怎么解决的？哪里已经在忍受，哪里已经在逃离？
4. 你手上有什么行为证据、数据证据或用户原话？
5. 如果这个判断是错的，最可能错在哪个前提？

红旗信号：

- “大家都觉得这是问题”
- “用户应该会需要”
- “最近很火，所以应该能做”
- 只有感受，没有行为证据
- 只有症状，没有链路

适合调用的框架：

- `references/framework/problem-discovery.md`
- `references/framework/reverse-thinking.md`
- 必要时补 `references/framework/jtbd.md`

### 创始人模式

优先问题：

1. 用户是谁？能不能说出一个具体的人，而不是一类泛人群？
2. 痛点是什么？用户现在如何解决，为什么现有方案不够好？
3. 为什么由你来做？你的独特资源、洞察或切口是什么？
4. 用户真正想完成的任务是什么，而不是他嘴上说想要什么功能？
5. 如果只能做一个最小版本，你最想先验证哪一个假设？

红旗信号：

- “所有人都能用”
- “先做出来再说，用户自然会来”
- 差异化只剩“更好看”“更智能”“AI 驱动”
- 功能列表很长，但核心假设说不清
- 用户、痛点、优势三者彼此断开

适合调用的框架：

- `references/framework/soul-questions.md`
- `references/framework/jtbd.md`
- `references/framework/mvp.md`
- 必要时补 `references/framework/story-thinking.md`

### 构建者模式

优先问题：

1. 你最想先做出来给谁看？
2. 这个想法最小可展示的形态是什么？
3. 哪部分必须自己做，哪部分可以先借现成工具或手工替代？
4. 第一轮成功不看“做完多少”，而看什么反馈信号？
5. 如果一周内必须拿到结果，你会砍掉什么？

红旗信号：

- 把探索型项目当成熟产品规划
- 还没验证价值，就先铺很大的系统边界
- 默认要做平台、社区、生态
- 想做的东西太多，但演示路径不清
- 没有首轮展示对象

适合调用的框架：

- `references/framework/mvp.md`
- `references/framework/scenarios.md`
- 必要时补 `references/framework/story-thinking.md`

## 反谄媚规则

这个技能默认不做以下事情：

- 不因为用户说得自信，就默认方向成立
- 不用“这个想法很有潜力”“方向不错”这类空泛鼓励替代判断
- 不把所有可能性并列摆出，逃避表态
- 不为了显得全面，给一堆低价值建议
- 不把没有依据的猜测包装成结论

默认要求：

- 有判断就说明依据
- 信息不足就直接指出缺口
- 方向站不住就说站不住
- 可以继续做，也要说清是“为什么值得试”，不是“为什么听起来好”

## 框架调用规则

框架是镜头，不是默认流程。通常只调用 1 到 2 个主框架。

| 当前问题 | 优先框架 |
|---|---|
| 快速判断方向是否站得住 | 灵魂三问 |
| 先判断问题是不是真的存在 | 问题发现 |
| 想理解用户真正任务 | JTBD |
| 想串起用户、情境和旅程 | 故事思维 |
| 想提前识别失败风险 | 逆向思维 |
| 功能太多，需要收敛最小版本 | MVP / 减法思维 |
| 落地场景不清楚 | 场景应用 |

读取路径：

- `references/framework/soul-questions.md`
- `references/framework/problem-discovery.md`
- `references/framework/jtbd.md`
- `references/framework/story-thinking.md`
- `references/framework/reverse-thinking.md`
- `references/framework/mvp.md`
- `references/framework/scenarios.md`

## 默认输出格式

除非用户明确要求其他格式，默认输出包含以下 5 部分：

1. 现象
   当前已知信息、关键事实、可观察信号、缺失信息

2. 判断
   当前最可能成立的结论，明确区分已知、推断、待验证

3. 红旗
   当前叙述里最值得警惕的模糊点、伪前提或风险点

4. 动作
   接下来最值得做的 1 到 3 个动作

5. 行动作业与验证
   给用户一个最小可执行任务，并说明成功/失败信号

默认表达顺序应尽量像双层响应：

- 先给判断，让用户知道当前最可能成立什么
- 再给一个接得住的下一步，而不是一次给太多建议

## 高频请求示例

示例一：

```text
我想做一个给独立开发者用的用户反馈工具，帮我看看值不值得做。
```

默认进入：创始人模式  
优先检查：用户是否具体、痛点是否真实、差异化是否成立

示例二：

```text
很多人说 AI 时代需要万能第二大脑，这是真需求吗？
```

默认进入：诊断模式  
优先检查：问题真实性、用户现有替代方案、切换成本

示例三：

```text
我们的 SaaS 注册不少，但第二周留存很差，先帮我判断问题更可能出在哪。
```

默认进入：诊断模式  
优先检查：流失链路、用户选择、价值兑现、使用门槛

示例四：

```text
我想做一个个人副项目，帮跨境卖家更快找选品机会，先帮我收敛第一版。
```

默认进入：构建者模式  
优先检查：最小演示路径、首轮展示对象、可砍功能

## 长任务与文档化

只有当任务会跨多轮推进、需要沉淀长期记忆或用户明确要求项目化交付时，才引入额外结构化产物。

### 当前体系资料

当前主路径下，按需读取：

- `references/faq.md`
- `references/long-task.md`
- `references/examples.md`
- `references/mermaid-best-practices.md`

使用原则：

- `references/faq.md` 用于回答当前技能的真实行为边界
- `references/long-task.md` 用于跨轮推进时的轻恢复，不用于流程编排
- `references/examples.md` 用于帮助新用户快速理解输入和输出长什么样
- `references/mermaid-best-practices.md` 只在图表确实能压缩理解成本时再读

## 成功标准

这个技能成功，不是“说得完整”，而是：

- 已进入正确模式
- 已提出少量但高判别性的问题
- 已指出红旗和不确定性
- 已给出有立场的判断
- 已落到下一步行动作业
- 已给出最小验证方案