前言
近两个月前换到了一个面向内部业务的小组，和之前面对商家端的业务感觉还是不太一样。我思考了下这种不一样的感觉的根源，应该是参与产品的程度导致的。越复杂的系统，参与的人越多，每个人对于整个体统的感知度越低，带来的结果就是每个人都只是系统中的一颗螺丝钉。而在一个小型的系统中，每个人都能够对整个系统有更全面的了解，从而能够参与到产品方案的制定和决策，在有些时候甚至能够影响产品的形态，这在大型的系统中通常不会发生。相较而言，前者对于产品方面的参与非常少，只需要关注实现部分，而后者既要关注产品也要关注实现，这就引发了我对于产品和技术的思考。
正文
在每个人都能够很好的完成技术需求的前提下，经常听到领导强调，要有产品思维。那么，什么是产品思维呢？以及为什么需要有产品思维呢？对于这个问题，思考到以下几点。
其一，产品思维即用户思维。之前也经常思考这个问题，对这个问题的理解是产品思维即站在用户的角度思考问题，从而产生实际的价值。这种思维是区别于技术思维的，技术思维习惯从技术层面去分析思考问题，对于用户是否有很大的价值并不十分关心。
其二，产品思维要求有领导力。前几天看到阿里玉伯前辈的文章，对产品思维有了一种新的理解。在他的早课的一系列的文章中可以看到他对于各种产品的思考。在他的文章 团队的文化根源 中，他提到他们团队的文化根源中的一点即为“产品梦”，这里的产品梦我理解为创造力以及实现创造思维的执行力。这种创造力和执行力让我想起了另外一个名次：领导力。维基百科中领导力的解释为：领导也称为领导力，是个人或是组织带领其他个人、团队或是整个组织的能力，是社会学中的一个研究领域，也是实务技能。这个词很早就经常出现在各行各业的招聘要求中，现在在我看来，它和产品思维其实相互重叠交错。
其三，产品思维有助于构建可持续交互的代码结构。呈现在用户面前的产品实际上是多方思维的集合：产品提出产品逻辑，后端控制数据关联，前端实现页面交互。在这个过程中，一个合格的产品应该对整个产品的短中长期都有一个比较清晰的规划。在这个前提下，产品功能的增删改都变得有迹可循，而此时如果技术拥有产品思维的话，会有预见性的设计自己的代码结构，为之后的变化留下充分的可能性。所以，在技术实力差不多的情况下，产品思维对于提高代码效率有着非常重要的作用。
产品的实质在于能够为用户提供价值，技术只是实现价值的工具。除非技术本身就是提供给用户的价值（比如教学），那么就永远需要更关注的是产品而非技术。但是作为一个技术人员，技术不能成为实现工具过程中的短板。这也很好理解，比如需要实现一个大表单的修改及提交，从产品的层面来说，只要能提供顺畅的填写体验，不管是通过原生的 js、早期的 jQuery 还是目前流行的 React/Vue，都无关紧要。但是如果只会 React，而且交互非常卡顿，那么这时候技术就会比产品更重要了，因为这时候技术成为了短板。在差不多技术水平的前提下，更拥有产品思维的人，会拥有更大的价值。评估这种产品能力对技术管理者而言就显得十分重要了，特别是对于大型团队的技术管理者而言。
关于产品经理，多说两句。产品经理作为一个产品背后逻辑的源头，会对产品最终的形态产生非常大的影响，所有一个好的产品经理非常重要。熟悉竞品、了解用户是产品经理的基本功，抽象归纳功能则是产品经理的核心能力。基本功只需要靠脚踏实地的使用、思考竞品，访问用户、了解场景即可，而核心能力则需要在基本功的基础上进行更加深入的思考和取舍，这是非常难的。然而据我观察，很多产品的基本功都不够，更别提抽象归纳组合能力了。这就导致项目没有明确清晰的规划，需求三番五次的修改，一句话总结就是：将帅无能，累死三军。希望每个程序员都能遇到一个合格的产品，也希望每一个产品都能成长为优秀的产品。
纵观互联网大佬发家史，非常多的创始人都是技术出身，然后才慢慢转型到产品和管理。可以说在创业的过程中，技术不是他们的短板，而是他们创业前期坚实的基础。于我而言，夯实基础，开阔技术视野仍然是目前的重点。与此同时，多发现、多思考，培养产品思维，希望有一天也能做出自己的产品，即使能让很少一部分人得到收获，也就够了。
