尤其让我印象深刻地是，他还特别准备了问题清单，结构层次也很清晰，而我们都知道：问题清单，往往就是指向答案路径的机会清单。

因此，今天熬夜复盘下沟通内容，发现对我们产品经理最有启发，也是很多产品新人最容易陷入的两个认知陷阱：「弱思考」与「凭直觉」。

严格来说，「弱思考」与「凭直觉」有着内在的强关联，很多时候都是有机的统一：「弱思考」往往催生「凭直觉」，「凭直觉」也往往受制于「弱思考」。

其实在职业发展中，我们有很多产品工作做得不够完美，背后的底层逻辑往往都是懒于思考、弱于思考，因为，在这样的背景下，即便是有成熟的产品方法论做行动指南，也无济于事。

而关于凭直觉，镜同学则认为这是最常见的产品认知错误，比如，我们在很多产品需求调研时，往往会“自以为是”的凭直觉为需求设定自我标签，俗称闭门造车。

我记得，之前给大家也分享过37 signals关于“正确决策”的38条铁律，其中就明确提到“正确决策要基于数据，而不是凭直觉”，对了，37 signals还出版了一本畅销书，就是我反复推荐大家阅读的那本《Rework》。

不妨试着回忆下，你们之前的公司决策，是不是有不少是“凭直觉”，而非基于数据呢？

不妨试着回忆下，你们之前的个人决策，是不是有不少是“凭直觉”，而非基于深思呢？

因此，镜同学想结合上周的两个产品案例，分享一些关于向上发展的思考，希望能带给你一些启发和参考。

01 运营反馈需求：用户想要删除系统数据

上周我们产品运营同学向我们提交反馈了一个需求：企业用户想要删除掉系统中“待办”、“整改”的系统数据，请我们产品经理设计需求，研发同学执行下开发任务。

这个需求背景是：企业使用我们的信息管理系统，他们的上级监管部门要检查企业的信息化使用情况，但他们系统上存在很多待办数据、整改数据等，这些数据暴露出企业安全生产管理的执行不力，因此，这个企业就想要我们帮忙删除掉这些数据。

镜同学相信，应该有不少B端产品同学都遇到过类似问题，当时我们一个产品经理在群里收到该需求后，不假思索地就答应了，还凭直觉承诺当天就会完成产品设计，当然，这类技术性需求本身并不复杂，只要定义描述好需求后，开发同学分分钟就可以搞定。

听完该产品同学的反馈汇报后，我有两点清晰的感受，一是该同学工作很积极，响应很快；二是，该同学掉入了“弱思考陷阱”，越是简单的事越容易凭本能、按感觉去做事。

我便引导着问他，在正常的产品设计流程中，收集到需求之后应该做什么？他回答说，应该先做需求调研，论证需求。

是的，他很清楚需求流程，也具备方法论，只是忘记了思考，由本能主宰了理性，凭直觉做出了行动决策。

那我们多维度论证下这个需求：从技术实现上来说，并没有任何难度，但从公司价值来说，我们作为技术服务的供应商，我们竟然能删除用户数据，帮助用户“造假”，既违反用户隐私，也有损公司口碑。

从需求调研本身上来说，这就是典型的“伪需求”，既没必要做，也不能做，更是技术性公司应该坚持的底线，而从产品同学的思考逻辑来看，他并非不知道需求调研的方法论，也不是没有能力识别，而是，在这个小需求面前，忽略了“思考”的必要和价值。

所以你看，弱思考，往往会导致流程性的错误。

02 客户提出需求：想要批量开通用户

大家都知道，在日常工作中，产品经理与客户沟通需求的场景非常普遍，用户往往也会反馈很多有价值的真实需求，而有些需求通常很着急，做完整的产品设计则会耽误用户使用。

比如，上周我们的机构客户就提出一个需求，他们在使用我们的一款SaaS产品，其中有个功能是可以添加自己所服务的企业，当时，他们临时有个集中汇报会，需要快速为即将要服务的200多家企业开通账号。

不过，按照现有的功能，他们需要逐一去添加账号，为服务的企业开通系统，这样很慢、效率很低，我们系统又没有批量导入功能，他们就希望我们通过技术手段后台为这些企业用户批量开通下账号。

这个需求不同于上面删除用户数据的案例，该需求是有真实价值的，只是我们产品暂时没有该功能，因此，我觉得这样没有问题，就没再深度思考，作为产品研发中心负责人，我就准备随后安排后台开发人员进行技术处理。

刚好我们要开周总结会，我就顺便把该事情给总裁汇报了一下，领导当时就强调：先不要直接答应客户，让客户提交一个书面申请，授权我们为他们批量开通账号，这样既能解决客户问题，还能避免后续扯皮，更能对外表现我们的技术张力和专业正规性。

果然，客户并没有反感，也没有认为我们的“多此一举”，反正发来信息赞赏我们的技术管理很专业，也很配合地提交了“授权申请”。

事后我总结，我在这件事情处理上认知有偏差，单纯认为是缺乏经验也不准确，事实上，我当时深度思考不足，也在凭直觉来处理新事物，至少没有寻求多方沟通的主动意识。

是的，往往越是简单的新事务，越容易陷入“直觉”陷阱。

03 产品同学需要写《产品操作说明书》吗？

上周还有一件事，有个产品同学询问我产品经理需要写《产品操作说明书》吗？那不是测试或者运营的工作吗？和他沟通后对我的启发也是：面对问题，我们的本能不应该是回答答案，而应该先深度思考。

我当时也在小报童「镜同学的产品驿站」做了分享，在这里也给大家做下简单的复盘：

首先，有问题就会有答案，这对很多人来说，都是本能认知、也是基本常识，所以你看，这句标语甚至成了“知乎”的slogan。

但是，据镜同学观察，很多产品同学在面对职场问题时总显得缺乏定力和静气，难以周全的兼顾，本能的直接回复，生怕答案过期，而且，越是简单的问题就越是轻敌。

那么，面对问题，我们的本能反应既然不是“回答答案”，那应该是什么呢？

很简单，是思考。

底层认知逻辑也很朴素：问题→思考→答案。

思考是催生答案的必备过程，面对问题我们最重要的便是深度思考：思考功能定义、思考问题要点、思考本质解。

我们说回这个问题，我当时并没有直接回答，因为我深知定义问题是找到答案前提，而且，我过往也踩过类似的坑，遇到过类似事情，比如，我们之前公司的《产品操作说明书》就不需要产品经理来编写，于是，我和他做了沟通交流，解题思路如下：

1）定义清楚《产品操作说明书》

你们公司对《产品操作说明书》的定义是什么？

产品生命周期后半程会有很多文档，如，《产品手册》、《产品说明书》、《产品操作说明书》、《产品培训手册》、《用户使用指南》等等，这些文件在不同公司语境下作用不同，承建岗位也各异。

而《产品操作说明书》顾名思义，主要是对现有的产品功能、操作步骤进行解释说明，以便用户更快地理解产品、上手使用产品。

2）搞清楚该文档的目标用户

那么，这个文档是给公司内部人员（如，业务、运营）使用还是给外部客户使用？

当时，我们之前公司定义的《产品操作说明书》是外部文档，因此，这个不需要由产品经理来写，而是由客户成功部门来编写，他们是直接面客的。

但是，产品经理需要编写《产品手册》，客户成功同事会依此为基础编写《产品操作说明书》。

3）以价值重新理解

好了，明白了该文档的内部价值，我们就更好理解为何我们当时公司没有定义产品经理来写的原因：

之所以这样安排，一是客户成功需要深度了解产品；二是很多客户关注的产品功能尚在研发中，但客户成功部门可以提前剧透，他们会结合市场动态进行放大表述；

而产品经理所写的《产品手册》更多只是从产品角度对现有产品功能进行的内部分析，以便公司其他部门人员学习了解。

我们再次回到问题本身：《产品操作说明书》这个小问题，似乎很好回答，我相信一定有不少产品同学会说，肯定是产品经理来写啊，不用怀疑的，甚至会列出网上答案，或者，ChatGPT的回复，以证自己说得对。

诚然，绝大多数情况下《产品操作说明书》由产品经理来编制并无不妥，但总有例外，本能回答并非最优解，正确的解题思路应该先进行深度思考。

其实，这多复杂问题的正确的答案都不是从书面上可以直接回答的，而是在不断互动、碰撞过程中修正完善的。

问题→思考→答案，面对问题先不要急着回答。

这个认知习惯也许能帮助你从问题中积蓄成长的力量。

最后，镜同学想说的是，产品经理本质上是设计岗位，是创造性的工作，华为曾说过，创新是最大的护城河，对产品同学也一样，核心竞争力来源于对新事物的达成效率。

因此，我们再强调总结下，在产品工作中应该要竭力避免「弱思考」和「凭直觉」的错误认知，想把「问题清单」转化为「解决方案」更应牢记：深度思考、基于理性。