前两个文章都很虚，只是一些很泛泛的东西，很空洞。但我想分享的不止于此，我会把我学到的，领悟到的精髓记录下来，总结出自己的一套方法论，帮助自己构建一个自己的逻辑体系。

逻辑是什么？

我不是哲学家，不是数学家，所以我不可能上升到一个高度去解读这个名词，所以我说描述的只是我的看法。就产品而言，逻辑是一个很重要的东西，什么是逻辑？在我看来逻辑就是条理性，合理性的结合。带入到产品中来说，整体框架是否合理？技术架构是否合理？用户体验是否合理？功能架构是否有条理性？市场定位是否合理？都是逻辑的一种体现，虽然这样说有点儿狭义，但是我感觉产品的逻辑思维就是要这样服务于产品。（欢迎Diss，交换意见）

我老大在这一点上就让我非常崇拜，我有技术的底子，自认为逻辑已经很好了，但是在产品岗位上工作了一段时间后，我发现我对于产品局部逻辑还好，但是产品整体的逻辑还是有所欠缺，这也是我下一步需要让自己成长的一方面，大局观。我经常陷入一种困境就是我可以很快而好的输出一个方案，然后被打回了。只看方案的话其实没什么问题，真正的问题存在于这个方案是否符合目前的架构，在项目的大背景之下，是否合理。当然，我经常是不合理的，但是正所谓吃一堑长一智，我在日后的工作一直在规避这样的“坑”出现，并且，我养成了“多嘴”的好习惯，总是习惯先和开发聊聊，这个是怎么实现的？是否符合我们之前的预想？如果要改应该如何去改？

沉下心，慢慢来

其实做产品，尤其是我这种入门级的产品，对于时间会有许多“浪费”，我总是会去细化我所要梳理的东西，我需要去了解整个项目的框架，结构。（其实我并不推崇想转行的小伙伴从文档方面入手，因为我觉得最应该提升的首先是自己的逻辑思维，至于原型，文档什么的，抽出一个礼拜来好好了解就OK了）但是有时候，我真的会很急，为什么我只能做这些？为什么我不能去控制一个项目的进度？其实下来想想自己挺傻叉的，不能自以为是，有一点儿感觉了，入了一点儿门道了就开始飘飘然。

刚入门，我一直告诫自己你是个“白痴”，别装聪明人。我很少在公开的场合发表自己的意见，因为我怕错，但是我会记录了下来，会下问问我老大，为什么要这样？是不是有更好的方法？还别说，我还真就提对了几次建议。这一方面增长了我的信心，一方面也促使着我遏制自己的野心。还不到你掌握话语权的时候，别急。其实我知道每个人都渴望着成功，渴望着那种产品是由自己创造出来的那种感觉，但是功夫不到位，到头来吃亏的是自己。

什么是方法论？

说了怎么多，到底什么才叫方法论？其实这个和逻辑一样，没人可以准确的定义，只能说这就是你做事的一些准则，一些套路，一些方法的集合。每个产品的方法论都不一样，却又很像，因为我们最终追求的东西，本质都是一样的。

入职的前几天，我一直都在汲取各种产品方面的方法论，各种社区，网站，论坛，文章，都快看疯了，然后再一次产品组内部会议的时候，老大专门做了一个关于他总结的方法论的PPT给我们分享，真的是受益匪浅，也在我后来的工作上避免了很多坑（虽然依旧踩坑，但少了很多）我后面也会慢慢的都分享出来，因为我想通过自己的理解去表述，而不希望直接引用他人的成果。

需求到底是什么？

其实做了产品以后，经常会有疑问，运营、商务提出来的需求千奇百怪，可是我们应该怎么总结这些需求？是提出来的就做？还是我们再去思考一下？有的时候按照他们所描述的做出来的东西他们未必真的会用到，因为他们也不知道自己到底想要什么。所以，作为产品的第一个能力就是追根问底，找寻这个需求的真正面目，还原最真实的场景，这样才能避免我们踩坑。

按照我老大的说法就是，问五个为什么，追寻它的本质，问到底。然后想一个方案去解决，但是一定要站在他的角度用他的思维去考虑这个问题的核心是什么，往往只有这样，你才能发现最本质的需求。另外就是多维度去思考，除了五个为什么，还有五个W一个H，也就是何时(when),何地(where),什么人(who),什么事(what),为什么(why)和怎么做(how)，通过这几点来发现最基本的需求场景，往往是比较接近于最真实的需求的。

作为产品我认为最需要具备的，第一是较为缜密的逻辑思维，因为产品是一个项目从诞生到成熟需要操心最多的人，因此一定要对整个项目有一个清晰的结构，第二是大局观，通过局部看到整体，又从整体来细分局部，并且实时进行一些调整，使之符合现在的市场需要，用户需求。因为我目前的这个项目是to B的，因此我们的整体就是市场，就是通过商务，运营来反馈的，这就引申出了第三点，对需求的把控，对伪需求的辨别，或者说是找到真正的需求。

产品是一条很长的路，需要学的东西也很多~所以，欢迎同行们或者前辈们指教，可以的话分享分享你们的一些方法，可以一起交流一波~