7.5
深览指数
产品人人都是产品经理·君安··AI 生成
为什么明明确认过需求，方向还是做错了？
产品需求评审通过了，PRD也写好了，临上线却发现方向跑偏，根本不是用户要的。作者将这种错误定义为“窄框架陷阱”——不是伪需求或优先级判断失误，而是在定义问题时把开放问题压缩成了封闭的解法。文章以亲身经历的教案功能案例拆解了窄框架的形成机制：路径依赖的隐性预设、群体共识的无声强化、以及“确认需求”与“锚定目标”之间的层级差异。给出了3个可立即嵌入日常工作的避坑方法：将解法型问题转换为目标型问题、采访用户时不问“要什么”而问“怎么做”、警惕“我见过”带来的认知确定感。适合有1-5年经验的产品经理、运营、项目负责人阅读。原文 ↗
核心观点
- ▍方向做错的核心原因不是执行不力或伪需求，而是“窄框架陷阱”——定义问题时，不自觉地把一个开放问题压缩成了封闭的解法，直接跳到“怎么做”，跳过了“真正要解决什么”。
- ▍确认需求不等于锚定目标。只验证解法（需求）而不锚定目标，会本能地落到自己最熟悉的那条解法上，即使需求真实，方向也可能完全跑偏。
- 01作者负责教育SaaS的教案功能时，基于对行政标准教案的认知，设计了包含教学目标、重难点等字段的结构化表格。但老师朋友反馈：行政式教案只用于交检查，真正上课用的是“讲什么、怎么展开、用什么例子”的教学实操型教案。
- 02窄框架问题示例如：“老师需要教案功能”——已预设了解法（做教案），把思考锁在“教案长什么样”。宽框架问题示例如：“老师在什么场景下、为了解决什么问题需要教案？”——不预设解法，回到目标本身。
- 03决策链条有四个层级：最终目标（为什么做）→ 问题定义（要解决什么）→ 解决方案（怎么做）→ 需求验证（做得对不对）。窄框架跳过了前两层，直接进入后两层。
- 04职场里的窄框架比生活里更隐蔽，因为它包裹着“行业经验”“专业判断”“目标导向”的外衣，让人觉得自己在理性决策。隐蔽性来自路径依赖的隐形预设和群体共识的无声强化。
- 053个避坑方法：① 接需求时，把“解法型问题”强制转换为“目标型问题”（如“要不要做签到积分？”→“怎么提升留存？”）；② 采访用户不问“要什么”，而问“你平时怎么做”；③ 警惕“我见过”带来的确定感，多问“我理解的需求和用户真实使用场景是一回事吗”。
反方 / 局限
- — 文章主要从产品经理视角出发，对组织层面如何制度化地防止窄框架（如评审环节强制加宽阶段、OKR对目标层级的校验）未做深入讨论。
- — “窄框架陷阱”在技术方案、商业模式选择等非产品设计场景中同样普遍，文章未延伸。
9 分钟 · 4 卡片 · 9 资料
读原文 →