我做产品不过也才一年多，本来以为自己所掌握的很“easy”，毕竟像用户需求场景这几个词人人好像都会说。直到遇到没有产品思维的人才发现差距：原来不是会说用户需求场景的人就具有产品思维，原来还有人连用户需求场景都不知道就做着产品，原来产品经理并不是人人都可以做的。
我查找了一些关于解释什么是产品思维的文章，从中也更好的印证了自己的一些想法。接下来我会根据自己的产品经验按照自己的想法整理一下我理解的产品思维。
首先解释一下，我这里所说的产品思维指的是产品经理在工作中指导思考和行动的一个内核。直白一点就是：想什么，怎么想。以下的例子全部来自于真实工作中发生的场景。
1，明确目标用户
用户是一个产品的根本，没有人用的最多只能称之为东西。所以在产品的整个生命周期，甚至在还没有产品概念的阶段，都应该围绕着用户去思考。思考什么呢？思考能为用户提供什么价值。那有产品思维和没有产品思维的人是如何思考用户的呢？
举例：我们有一个运营系统的产品，因为商家上线后会产生很多数据，所以
没有产品思维的人：我看我们有什么数据，我们先把有的数据做成报表放上去，肯定有人来用。
有产品思维的人：首先调研我们的数据有哪些人会关注，不同的角色关注哪些数据，观察这些数据是为了什么（比如为了排查问题还是提升指标），最后到达表现层才会知道如何呈现数据。
2，挖掘真实需求
一个真正的产品熟悉业务的目的就是为了找到产品的需求。最差的人是等着需求来找你；入门产品是记录一下用户埋怨产品时暴露的产品需求；一般的产品是去调研用户，把问出来直接记录并照做；合格的产品是会调研用户后，分析业务流程在角色之间的扭转关系，并以提升产品价值为核心挖掘最深层次的需求。
举个例子：我们需要做一个case排查的工具，因为历史原因，现在排查一个问题，需要在至少3个模块里去输入内容去查不同的内容才能真正定位到问题，并且这些个模块直接的关系也没有一定的逻辑性。运营人员操作起来倒是很顺畅了，但是第一麻烦，第二学习成本太高。其实是个产品就会发现这个痛点，但是就真的有人完全没发现，甚至不觉得这是个问题。现在是确认要做，需要去调研一下具体的流程用以梳理背后的逻辑。
有产品思维的人（一个5年产品工作经验的老人）：首先找到覆盖了80%的基本case，，因为这些case常见并且十分标准化。然后将每个case现在在哪些模块的查询逻辑全部理清，也就是在哪一步做什么会到哪一步，脑图画的非常清晰。这样的话，就把逻辑做在产品后面，在排查问题的时候运营只需要在前端点击case类型，输入ID即可得到问题原因。
没产品思维的人（小朋友）：业务说他们现在用的很好，没有需求，我们不需要做。
以上是真真实实发生在我面前的一段场景和对话，这段话一出来让我很想讲那个更快的马的故事。这件事发生之后，因为不是我负责的产品，我也不好说什么。后来又发生一件事，是因为是我负责的，所以我就回怼了。要不是我老大拦着，我当场就想好好“教育”他一番。可是后来老大问我要不要和他再沟通一下的时候，我就觉得这种事在他身上发生不是一次两次了，他做的产品完完全全也代表了他的思维方式了。除非我能改变他的思维方式，否则两个人的沟通始终不会在一个频道上。而他，并不是像我之前向我师父学习一样谦虚（自夸了一下，勿喷），他不会主动问，更没有主动学。因为很多会议上有经验的前辈他不懂尊重和学习，所以才会一错再错。我个人觉得还没有那个资格和能力去颠覆他的思维。
举例：我这边负责的是一个对接的平台，将需要对接的供应商的流程线上化。主要目的是为了系统化和自动化管理，实现更快和更高效率的对接。因为我这边对业务还不是特别熟悉，标准对接中有两个分类，然而我只规划了其中一个。当我去调研另外一个类型的时候刚好那个小朋友是这个类型的产品对接负责人。于是
他：这个流程很简单的，我这边都不需要做什么，不用放在系统上，这只会让流程更加复杂化。
我：首先系统的定位是对接系统，不管流程简单与否，从产品定位上也应该接入系统，如果流程简单自会有简单的产品设计；再者你是我系统的一部分用户，你这边做的少，并不代表这个流程简单，也许其他人承担了很多工作；再简单人工还是要跟进，我的系统只会让它更简单更方便。
后面了解下来，确实是因为业务运营看产品人手不够，帮忙承担了大部分的工作。期间还有个小问题也让我觉得可笑，我从业务运营那里了解到一个需求反馈出来，他突然想到说这个需求不满足他的产品设计，不能这么做。我就回了他一句话：我们做产品是来满足用户的需求，不是你前期没调研清楚做的有问题，别人就不能提你产品满足不了的需求了，因为这个需求是真真实实存在的。
这篇文章就先讲到这里，因为之前有朋友留言说我的每篇文章都太长了，所以我把这篇文章分成上下两部。上部最重要，因为是它们才激发了我想写这篇文章，下部作为补充，将产品思维中还需要关注的点也顺带说一下。
3，场景
4，商业价值
5，主人翁意识
6，数据
