需求评审通过、PRD完成、设计稿出炉，临上线却发现方向跑偏——这不是执行问题，而是从一开始就在解一道错题。作者将这种隐蔽失误定义为“窄框架陷阱”，用亲身经历拆解如何把开放问题压缩成封闭解法，并给出3个可立即落地的避坑方法，帮你跳出思维惯性。

你有没有遇到过这种情况：

需求评审通过了，PRD写完了，设计稿也出来了，结果临上线前突然发现——方向跑偏了，用户要的根本不是这个。

不是执行环节出了问题，不是细节没打磨到位，而是从一开始，你就在解一道错题。

更要命的是，你甚至做过需求调研，团队也讨论过可行性，一切看起来都很专业、很严谨。你以为自己在”解决用户的真实需求”，实际上只是在”解决你理解的需求”。

这种错误我把它定义为”窄框架陷阱”。

它不是伪需求，不是优先级判断失误，而是一个更隐蔽的问题：你在定义问题的时候，不自觉地把一个开放的问题，压缩成了一个封闭的解法。

我刚入行时就栽在这上面。

一、我是怎么把需求做窄的

这件事发生在我负责的第一个功能：教案模块。

我们做的是教育SaaS，服务中小学老师。上级给的方向很明确：老师需要教案功能。

这个需求完全没问题。教案是教师工作的刚需，我上学时也见过老师填那种标准格式的教案本，行业里还有学校的官方模板可以参考。

于是我很快确定了方案：做一个结构化的表格式教案，包括：

• 教学目标
• 教学重难点
• 教学过程
• 板书设计
• 课后反思

这些字段都是学校行政要求的标准项，逻辑严密，专业度拉满。

直到一次朋友聚会，我遇到一位当老师的朋友。

闲聊时我提到在做教案功能，顺口问了句：”你平时用的教案是什么样的？”

她的回答让我愣住：

“确实有那种行政式的教案，但那是交给教导处检查的。我真正上课用的，90%以上都是’这节课要讲什么、怎么给学生呈现、怎么上好这堂课’。”

她接着说：

“你们如果做的是那种有教学目标、重难点的标准教案，交检查肯定够了，但我上课要的是’这节课讲哪几个知识点、每个点怎么展开、用什么例子、学生容易错在哪’——那种太空了，我还得自己再做一份。”

当时我脑子里只有一个念头：完了。

我们确实在做”教案”，但我们做的是行政检查场景下的教案，而老师真正高频使用的，是课堂教学场景下的教案。

这是两个完全不同的东西。

二、问题到底出在哪：窄框架 vs 宽框架

回公司后我又采访了另一位老师，得到了几乎相同的反馈。

复盘时我才意识到，问题不是出在执行层面，而是出在最开始定义问题的方式。

我以为我在解决的问题是：

“老师需要教案功能”

这是一个窄框架问题——它看起来像个需求，但实际上已经预设了解法（做教案功能），把思考范围锁死在”教案该长什么样、有哪些字段”这个层面。

我真正应该问的问题是：

“老师在什么场景下、为了解决什么问题需要教案？”

这是一个宽框架问题——它不预设任何解法，而是回到目标本身，打开所有可能的路径。

这两个问题的区别在于：

• 窄框架：把”解法”当成了”问题本身”，你的思考直接跳到了”怎么做”
• 宽框架：先搞清楚”要达成什么目标”，再从多种可能性中选最优解

当我把问题定义成”做教案功能”时，我的视野就被锁在”教案”这个词上了。我下意识调用了自己见过的教案样式（学校的行政模板），以为这就是”专业”和”标准”。

我从来没有问过自己：

• 老师在什么场景下会用教案？
• 不同场景下，老师真正要解决的问题是什么？
• 如果没有我们的产品，老师现在是怎么做的？

我以为自己在做需求调研，实际上只是在验证我脑海中已有的那个”教案”概念——这就是典型的路径依赖式窄框架。

三、更隐蔽的误区：选解法 ≠ 决策本身

如果你问我：”立项前你有没有做需求分析？”

我会说有——我参考了行业案例，甚至亲眼见过老师填教案。

但现在回看，这些所谓的”分析”，都停留在验证”教案功能该不该做”，而不是搞清楚”要解决什么问题”。

我潜意识里觉得：

• 需求方向是明确的（老师要教案）
• 接下来就是产品设计和执行的事

所以我压根没想过要去深挖使用场景，因为在我的认知里，需求已经明确了，现在只是把它做出来。

这就是窄框架最隐蔽的地方：你不会觉得自己在跳过步骤，你会觉得自己在高效决策。

绝大多数人对”决策能力”的理解，都停留在”选方案的眼光好不好”——也就是在A方案和B方案之间做判断。

但真正拉开差距的，不是”选得准不准”，而是“问题定义对不对”。

你以为自己在做决策，实际上只是在一个被预先划定的边界里选选项。而那个边界本身对不对，你连问都没问。

四、还有一层更深的区分：确认需求 ≠ 锚定目标

可能有人会说：”我每次都会验证需求是不是真实的，不会做伪需求啊。”

这一步确实能帮你避开很多坑，但它其实还停留在“验证解法对不对”的层面。

而宽框架思维要做的，是在验证解法之前，先问“我们真正要解决的问题到底是什么”。

这两件事处在决策链条的不同层级：

最终目标（为什么做）

↓

问题定义（要解决什么）

↓

解决方案（怎么做）

↓

需求验证（做得对不对）

用我的教案案例来拆解：

如果我只做了”需求验证”：

我会去问老师：”你需要教案功能吗？” 老师大概率会说”需要”——这个需求100%是真的，不是伪需求。

然后我就按照自己理解的”教案”去做了。

如果我做了”目标锚定”：

我会先问自己：”做教案功能，最终是为了解决老师的什么问题？”

可能的目标有：

• 帮老师应对学校的行政检查（降低被扣分的风险）
• 帮老师提升课堂教学质量（备课更高效、上课更顺畅）
• 帮老师沉淀教学经验（形成可复用的知识库）

目标不同，最优解完全不一样：

• 如果目标是”应对检查” → 表格式行政教案就是对的
• 如果目标是”上好课” → 需要的是教学实操型教案
• 如果目标是”沉淀经验” → 可能需要的是结构化的知识管理工具

尽管需求是同一个（老师要教案），但目标一变，正确的方向天差地别。

只确认需求，不锚定目标，你就会本能地落到自己最熟悉的那条解法上，还会觉得”我是按用户需求做的，肯定没错”——这就是它最隐秘的地方。

五、职场里的窄框架，披着”专业”的外衣

生活里的窄框架大多由情绪驱动，你能明显感觉到自己在较劲、在钻牛角尖。

但职场里的窄框架完全不同——它往往包裹着”行业经验””专业判断””目标导向”的外衣，连你自己都会觉得”我这是在理性决策”。

它的隐蔽性主要来自两点：

1. 路径依赖的隐形预设

经历过某种成功经验的人，下次再遇到类似问题，会下意识把那条路径当成默认解法。

比如我因为见过学校的行政教案，就默认”教案=那种表格格式”，根本不会觉得这是自我设限，反而会认为这是”专业”和”标准”。

2. 群体共识的无声强化

当团队开会，所有人都默认”我们来讨论下教案功能的设计”，这个问题本身就成了不容置疑的前提。

质疑设计方案很正常，但质疑”为什么要做教案功能、要解决什么问题”，反而会显得偏离主题、浪费时间。

这就是为什么很多方向性错误，在复盘时特别明显，但当时所有人都没察觉——因为大家都在一个被集体默认的窄框架里高效协作。

六、3个可以立刻用的避坑方法

这次翻车后，我总结了几个最小成本的刻意练习动作，完全可以嵌入日常工作：

1. 接需求时：做10秒句式转换

只要听到”我们做个XX功能””要不要上XX方案”这类夹带解法的需求，先别急着评估可行性，强制在心里做一次转换：

把”解法型问题”转换成”目标型问题”

• 窄问题：要不要做签到领积分？ → 宽问题：怎么提升用户留存率？
• 窄问题：要不要重做导出功能？ → 宽问题：怎么解决用户数据导出效率低的痛点？
• 窄问题：要不要加大投放预算？ → 宽问题：怎么提升新增用户的获取效率？

这个动作单次只需要十几秒，但每做一次，就是在打破”默认解法=问题本身”的思维惯性。

2. 采访用户时：不问”要什么”，问”怎么做”

如果我当时去问老师”你需要什么样的教案功能”，大概率还是会得到”教学目标、重难点”这些标准答案——因为用户也会下意识给你一个”专业”的回答。

但如果我问的是：

• 你平时怎么备课的？
• 上课前会准备什么材料？
• 这些材料里，哪些是给学校检查的，哪些是你自己上课用的？

我就能看到真实的使用场景，而不是概念化的需求描述。

用户不一定能准确说出自己要什么，但他一定知道自己怎么做的。

3. 警惕”我见过”带来的确定感

我之所以没去深挖场景，很大原因是”我见过老师填教案”——这让我产生了一种我已经理解需求的错觉。

但”见过”和”理解”完全是两回事。

我见过的是行政场景下的教案，但我要服务的是教学场景——同一个词，在不同场景下可能指向完全不同的东西。

所以当你觉得”这个需求我懂”的时候，恰恰是最该多问一句的时候：

“我理解的这个需求，和用户真实的使用场景，是同一回事吗？”

七、写在最后

这件事给我最大的触动是：很多时候，不是你做得不够好，而是你从一开始就在解一道错题。

需求调研、用户访谈这些事，我们都知道要做，但很容易在”觉得需求已经明确了”的时候跳过。

而这，恰恰是最危险的时刻。

因为当你觉得”需求明确”的时候，你大概率是在用自己的经验、认知和假设，给一个开放的问题划了一个边界，然后在这个边界里高效执行。

但那个边界对不对，你根本没问过。

如果你也在做产品，不妨在下次接到需求时，多问自己一句：

“我现在要解决的，是用户的真实问题，还是我理解的问题？”

这一句话，可能帮你避开很多弯路。