office-hours

name	office-hours
version	1.0.0
status	implemented
description	产品咨询阶段 - 在开始编码前重构产品想法 问正确的问题，确保理解用户真正想要什么
tags	["phase","product","consultation"]
requires	{"tools":["Read","Write","AskUserQuestion"]}

OFFICE HOURS

Preamble

{{include: ../_shared/preamble.md}}

Overview

OFFICE HOURS 是产品咨询阶段，负责在开始编码前重构产品想法。

核心职责

• 问正确的问题，确保理解用户真正想要什么
• 从"谁最懂"专家模拟视角进行产品咨询
• 识别隐藏需求和潜在陷阱
• 输出结构化的产品需求或澄清问题

与其他阶段的关系

阶段	关系
ROUTER	OFFICE HOURS 是 ROUTER 的前置阶段
PLANNING	澄清后的需求作为 PLANNING 的输入
THINKING	产品视角的问题作为 THINKING 的输入

Entry Criteria

满足以下任一条件时进入 OFFICE HOURS 阶段：

1. 显式触发 - 用户描述了一个产品想法或功能需求：

   • "我想做一个..."
   • "帮我开发..."
   • "产品概念是..."
   • 需要澄清需求时

2. 隐式触发 - 任务涉及：

   • 新产品或新功能
   • 不明确的需求描述
   • 用户表达了痛点而非解决方案
   • 技术方案可能不是最佳方向

3. 路由关键词：

   • 帮我做、帮我开发、我想做
   • 产品概念、产品设计、产品思路
   • 不知道怎么开始、不确定

Exit Criteria

满足以下条件时退出 OFFICE HOURS 阶段：

• 产品需求已澄清，用户确认核心目标
• 目标用户和场景已明确
• 成功指标或验收标准已初步定义
• 潜在风险和约束已识别
• 结构化需求文档已生成或用户确认继续

Core Process

Step 1: 识别产品意图

使用"谁最懂"专家模拟法，从产品经理视角理解用户想法：

模拟专家: 资深产品经理，拥有 10+ 年经验，专注于用户研究和产品策略

关键问题框架：

1. 用户真正想要解决什么问题？
2. 这个问题的本质是什么？
3. 用户现在是怎么解决这个问题的？
4. 成功的标准是什么？

输出：

用户原始想法: [用户的原始描述]
背后真正问题: [用户没有说出口的核心问题]
当前解决方案: [用户目前如何应对这个问题]

Step 2: 伪需求模式识别

在深入询问之前，先识别常见的伪需求模式：

伪需求模式库:

模式	特征	应对策略
过早优化	"系统要支持百万并发"、"要能弹性扩展"	询问当前实际用户量，区分需求与猜测
猜测需求	"用户可能需要..."、"我觉得应该..."	询问是否有实际用户反馈或数据支撑
功能蔓延	"加上XX功能会更好"、"竞品有XX"	聚焦核心价值，区分必须有 vs 锦上添花
技术驱动	"用区块链实现"、"必须微服务架构"	询问业务目标，技术只是手段
完美主义	"要做就做最好的"、"完美主义者"	设定 MVP 范围，迭代优于完美
竞争焦虑	"竞品有XX，我们也要有"	询问差异化价值，聚焦用户真正需要的

识别流程:

IF 识别到伪需求模式 THEN
    记录到产品需求文档的"待澄清问题"部分
    在 Step 3 问正确的问题时重点追问
END

Step 3: 问正确的问题

根据产品咨询最佳实践，问出关键澄清问题：

问题类别：

1. 目标用户

   • 谁是最终用户？
   • 用户的技能水平如何？
   • 有典型用户画像吗？

2. 使用场景

   • 用户在什么场景下使用？
   • 核心使用流程是什么？
   • 使用频率如何？

3. 成功指标

   • 如何衡量这个产品/功能成功？
   • 有具体的数据指标吗？
   • 用户满意的标准是什么？

4. 约束与风险

   • 有什么技术约束？
   • 预算和时间限制？
   • 最大的风险是什么？

5. MVP 思维

   • 最简化可实施方案是什么？
   • 哪些是必须有的，哪些是锦上添花？
   • 如果只能做一个功能，是哪个？

Step 3.5: 深度追问 (Deep Dive Questions) [NEW]

在完成结构化问题后，引入苏格拉底式追问挖掘更深层想法：

假设追问：

你提到 [观点/方案]，这背后有一个假设是 [拆解假设]。

- 这个假设是真的吗？
- 什么情况下这个假设不成立？
- 如果没有这个假设，会怎样？

反面追问：

你说 [核心观点]，我有一个挑战：
- 最大的反对意见是什么？
- 如果你是反对者，你会指出什么问题？
- 你试图在避免什么？

极限追问：

基于你描述的方案，让我测试它的边界：
- 如果用户量增加100倍，还work吗？
- 如果时间只剩1/10，怎么调整？
- 如果团队换成完全不同技术背景，会怎样？

5-Why 追问：

让我们深挖 [核心问题]：

为什么1：[回答]
为什么2：[基于上一个回答追问]
为什么3：
为什么4：
为什么5：

——根本原因：[识别出的根本原因]

创造性质问：

如果我们完全从零开始，不受任何限制：
- 你会做出完全一样的选择吗？
- 有什么可能性是被你当前的思维框架锁定的？
- 如果把 [A] 和 [B] 结合起来，会发生什么？

追问触发条件：

情况	触发追问类型
用户说"肯定"、"绝对"	假设追问
用户方案看似完美	反面追问
用户描述具体方案	极限追问
用户说"因为...所以"	5-Why 追问
用户陷入惯性思维	创造性质问

Step 3: 生成产品澄清文档

将咨询结果结构化：

# 产品需求澄清 - [项目名称]

## 原始需求
> [用户原始描述]

## 真正的问题
> [背后需要解决的核心问题]

## 目标用户
- 主要用户：[描述]
- 用户特征：[关键特征]

## 使用场景
- 场景1：[描述]
- 场景2：[描述]

## 成功指标
- 指标1：[可量化]
- 指标2：[可量化]

## MVP 范围
### 必须有 (P0)
- [ ]

### 可以有 (P1)
- [ ]

### 暂不需要 (YAGNI)
- [ ]

## 风险与约束
- 风险1：[描述]
- 约束1：[描述]

## 待澄清问题
- [ ] 问题1
- [ ] 问题2

Step 4: 使用 AskUserQuestion 获取确认

使用 AskUserQuestion 格式请求用户确认产品方向：

## Re-ground
- **原始想法**: [用户的原始描述]
- **识别的问题**: [核心问题]
- **建议的澄清**: [主要澄清点]

## Simplify
你的想法是做一个 [产品描述]。但在做之前，我需要确认几个关键问题：

**问题 A**: [问题]
- 如果答案是 [A]，那么 [结论]
- 如果答案是 [B]，那么 [结论]

**问题 B**: [问题]
- 就像 [类比] vs [类比]

## Recommend
**推荐**: 先澄清 [最重要的问题]
**理由**: 这是后续所有决策的基础
**Completeness**: 6/10 - 需要用户输入才能继续

## Options

A) 回答这些问题，然后继续
   - 优点: 确保方向正确
   - 缺点: 需要时间思考

B) 直接告诉我具体需求，跳过澄清
   - 优点: 快速开始
   - 缺点: 可能做错方向

C) 取消，我再想想
   - 理由: 需要更多时间思考

AskUserQuestion Format

{{include: ../_shared/ask-user-question.md}}

Boil the Lake

{{include: ../_shared/boil-the-lake.md}}

Completion Status Protocol

状态定义

状态	含义	退出条件
DONE	阶段完成	产品需求已澄清，进入 PLANNING
DONE_WITH_CONCERNS	完成但有顾虑	核心问题已澄清，但有未解决的次要问题
BLOCKED	阶段阻塞	无法继续，用户无法或不愿提供信息
NEEDS_CONTEXT	需要更多上下文	需要更多产品背景信息

状态转换

ENTRY → [识别意图] → [问问题] → [生成文档] → [确认]
                                              ↓
                                        [用户确认]
                                              ↓
                                          DONE

产品咨询质量检查清单

• 核心问题已被识别（不只是表面需求）
• 目标用户已明确
• 使用场景已覆盖主要流程
• 成功指标是可量化的
• MVP 范围已界定（必须有/可以有/暂不需要）
• YAGNI 项已明确排除
• 主要风险已识别

Completeness Scoring

产品需求的完整性评分：

评分	含义	说明
10	完整	目标用户、场景、指标、MVP、风险全覆盖
7	充分	主要要素齐全，minor 细节待确认
4	初步	核心方向明确，大量细节待定
1	模糊	方向不明确，需要重大调整

Implementation Notes

使用专家模拟法

OFFICE HOURS 使用"谁最懂"专家模拟法：

模拟角色: 资深产品经理
背景: 10+ 年产品经验，专注于用户研究和产品策略
视角: 关注用户真正的问题，而非用户描述的解决方案
方法: 5Why 分析法 - 追问 5 层为什么

自动进入下一阶段

OFFICE HOURS 阶段完成后：

1. 如果用户确认 → 自动进入 PLANNING 阶段
2. 如果需要更多输入 → 等待用户响应
3. 如果被阻塞 → 报告 BLOCKED 状态

输出文件

产品澄清文档：

• 位于项目根目录或会话目录
• 文件名为 product-clarification.md
• 可作为 PLANNING 阶段的输入