作为写了十多年代码的技术表示：产品思维比程序员们想象中重要得多！掌握了产品思维的程序员能力可以double！我把产品思维的养成要点，从我的认知上提炼了下，供大家参考。
理解产品思维前，首先需要了解产品经理是一群什么样的人；其次我们再来看产品思维的本质；再次看看程序员们的技术思维有什么特点；最后谈谈技术人员如何具备产品思维。
需求是混乱无序的，需求有来自管理层关于公司长期目标的、有来自合作伙伴的诉求、有来自销售和市场对新客户的功能代言、有来自运营对存量用户使用体验的代言、有来自品牌对活动运营的诉求，还有来自所谓“用户”由产品经理代言的需求，因为用户种类很多，且随着时间而变化，所以最后这个代言非常难。如果让这些需求直接砸到技术，那么技术是没办法设计、开发、按时交付产品的。产品经理需要把混乱的需求翻译成技术可以看得懂、可以执行的产品需求、可以迭代的版本！所以，如果一个产品经理不能够保护技术直面混乱的需求，那么这不是一个好产品经理！产品经理通常会很在意自己的“人品值”，每当他们没有保护好技术，使得技术在多个版本里返工，推倒原先的代码和功能实现，这就在消耗他们的人品。当技术对产品经理完全不信任时，这个产品也就该走人了。
如果在产品评审会，产品经理抛出了许多没有解决方案的问题，那么他不是一个优秀的产品经理。所有人都有无数的idea，每个人都可以很挑剔，提问题的人应当是产品经理以外的所有人！产品经理的核心职责是解决问题，给出问题的解决方案（当然，产品经理可以私下与专家讨论，汇聚想法，而不是在需求评审会里提问题）！
互联网行业与传统的IT行业最大的差别在于，前者提供的是服务，是持续交付的，而后者提供的是软件，是一次性交付的！因此，互联网产品非常需要运营，它与产品是共生的！而运营需要考虑行业蓝图，谁是敌人？谁是友军？公司的资源在哪？我处在供应链的哪个环节？谁是惹不起的？BAT哪家有红利可以使用？哪里投入产出比最高？产品现在是早期、增长期还是成熟期？是应该不计成本的投入给种子用户，还是该规模化拉大众用户进场了？这些离研发似乎有些远，但确是产品经理得懂的必知必会。
产品经理非常需要严谨的逻辑，因为他需要设计流程，而流程是不能容忍“例外”的！同时，他还需要与各种角色沟通，并能够从沟通中获取到自己需要的信息，同时准确、讲究方式方法的把信息传达给目标角色。
对互联网产品来说，每个人都是用户！但用户作为群体是没办法发声的，产品经理必须为用户群体发声！当然，这需要强大的能力，包括用户调研、前端埋点、数据分析等各种招数。
简单的聊完产品经理，我们再看看产品思维是什么。
首先要把自己放在产品的操盘手位置上去思考。例如下面的金牛瘦狗图，横坐标是市场占有率，市场占有率高（左边）当然最好！
纵轴表示需求增长率，上方表示需求增长很快，这表示我们必须花更多的资源才能满足用户。所以，左上角就是明星产品，它值得花大力气去研发，而下方的金牛则是可以考虑变现，潜力不足但市场占有率很高。对于右上角市场占有率低且需求增长很快，则明显是个“鸡肋”，这种问题产品应该尽快放弃掉。
能像以上这样思考问题，就有了行业视角、老板视角，这样的大局观是高级产品经理必须具备的。或者使用下面的SWOT态势分析法，从战略层面上定位自己的产品。
现在我们再来看很多问题就一目了然。比如，互联网的商业模式要么是to C从用户那里收费，这要求我们的用户体验必须是第一流的，就像腾讯！
要么是to B从服务的企业那里收费，这要求我们的技术能力必然远强于企业客户，所以我们要在技术能力上下大功夫，就像百度；
要么是在B to C商家向用户出售产品的过程中收取服务佣金，这要求我们的运营能力必须非常强，能够整合商家到平台上，吸引用户消费，就像阿里。
所以，你的产品的商业模式到底是什么？最大的成本花在哪里了？
本质上，互联网产品需要取悦用户，由用户的微笑价值进而才能产生商业价值。
这要求我们必须具备从用户体验出发的设计思维，就像下面这张图，从用户体验的5个层面上思考产品的设计：
界面好看不好看，从来不是决定一个产品成功或者失败的关键因素！所以，上面这张图越是下面的层次越是重要！
互联网行业最擅长快速迭代的交付产品，这是有原因的：
1、快速交付产品可以减少版本风险！时间跨度越长，交付的产品与我们的预期差距越大，版本风险越大！
2、互联网产品有许多都是从0到1的突破性产品，而不是从1到N！这样，在探索期内，降低试错成本非常重要，产品必须灵活的快速尝试简单、实现迅速的功能，由种子用户的运营中反馈到版本迭代中去，进而修正产品，这样最有效。
而快速迭代也不能乱来，就像下图中的MVP最小化可实行产品设计。当我们想造一辆汽车，不能第1个版本先迭代造出轮子，第2个版本选出车身，第3个版本集成，这可以是快速迭代，但它不是MVP。
以滑板车、自行车、摩托车、汽车的方式迭代，这才是MVP，才能给用户提供微笑价值！
产品经理需要有运营视角，因为需要从迭代中要数据，从数据中去迭代。在产品的不同发展周期，用户群体也是不同的，如下图所示。
产品早期愿意尝鲜的用户是创新者，他们是不走寻常路的，广告投放对他们无效。而对他们则应该增加投入成本，找到可以解决用户痛点的引爆点，从而使用户增长斜率从小于1到大于1！而且这些用户就像恋爱理论里的18岁红颜（“我要我要我就要”），“懒惰而贪婪”，是产品经理（“我给我给我全给”）最理想的用户，从他们身上可以最快速的试错。而这些用户最不吝于用口碑去宣传产品，只要产品能给他们惊喜！一定要珍惜这样的用户，千万不能让他们跑了！！
在增长期才应该在媒体上投放广告轰炸，给大众用户以“大家都在用XXX”的感觉，大众用户走的是群体思维，爱从众。
?
下面再来看看技术思维的不同之处。
技术人最讨厌的就是不确定性。如果产品经理在跟技术阐明需求时，表达出各种不确定性。特别是，即使某个需求点可能有变化，但变化的趋势也完全不确定时，技术就要抓狂了！
产品经理讲述概念、场景时最喜欢类比，因为讲故事这个能力产品经理很擅长！但是请记住，工程师不吃这套！比如产品经理为了说明需求，可以拿一个完全不同的故事来说事，因为这两件事有共同点，这样表述重点突出也更性感生动（在产品经理看来）。但工程师的思维很严谨，他的潜意识会优先判断这两件事有没有可类比性！通常，产品经理只是为了让故事服务于他的观点，而所有的“故事”都是不严谨的，所以产品经理一旦想拿“故事”与工程师沟通，首先就会遭遇“穷举法”的为难，找例外嘛，这是程序员非常擅长的事！当然，程序员的招还有很多，因为所有的设计模式准则都能套用在现实世界。所以，如果产品经理理论功底欠缺，或者拿与其他角色沟通的方式与程序员交流，就会陷入困境。
技术人员非常讲究逻辑、数据、方法，包括在很感性的人际交往中。而产品经理遭遇的局面往往错综复杂，在信息不足时非常需要产品经理基于经验和方法论的主观判断能力。这时，由于产品经理拿不出论据，在与技术沟通时就会非常吃力。
技术人员谈需求时下意识的就会讨论各种实现方案的成本与优劣！所以，技术人员很容易陷入在局部细节中，而忽视了总体目标与整体结构，缺乏计划性。
技术人员非常在意自己的代码是否优美，可扩展性好不好，像不像一件艺术品。通常又懒于关注他人，于是特别喜欢重构新接手的他人代码，当然自己的代码也超爱重构！完美主义极易导致设计过度，忽视了项目的成本和进度。
?
技术人员在具备了产品思维后，就可以直接对自己的产品负责，进而同时为产品设计、测试、运营赋能。而且可以从任务导向转为目标导向，大幅提升效能，优化产品的招数套路也会更多！下面我们来看看如何具备产品思维。
把任务导向调整为目标导向，不再仅仅去看产品经理PRD文档上的需求，而是去看产品的生命周期与发展，关注行业、公司、部门、团队的总体目标，这样就能理解产品思维。当然，屁股决定脑袋，因为职位与职责所以不用为决策（如果有的话）的后果负责（通常，互联网公司都不会让技术对失败的产品负责），所以技术尤其不应当固执（！！！），保持头脑的极度开放，从长远目标看任务。
这是互联网服务下必修的技能，网上各种文章，不再赘述。
程序员非常需要学点心理学知识并践行，比起机器来人性很复杂，无论是了解产品用户还是与同事协作，都需要食点人间烟火。而学习心理学上的很多系统性理论能够降低未知恐惧感，特别是近来非常流行的基因、神经科学与心理学的交叉理论知识。
不能因自己的喜好就抗拒使用新类型的互联网产品，好奇心是掌握产品思维的必要条件！
?
技术人员天天爱看的文章、视频都是关于数据库、分布式框架、消息系统、算法、神经网络、爬虫这样的纯技术知识，当然，如果你有非常紧迫的任务，可以立刻提升工作效率那另说。从长远看，沉下心学学与技术不那么相关的产品知识，其实对我们的未来发展更好！就像产品经常说的两点之间曲线最快（最速曲线，如下图），我们的职业生涯也是一样，sat报名下面这条红色的曲线和蓝色的直线，小球沿线下落时红线是最快的。
这其实要求我们多蓄点势能再出发，到达终点的时间会更短些！
本文其实是笔者最近看完后显慧的《产品的视角：从热门到门道》一书有感而作。笔者从资深后端架构师，跨度为创业公司的联合创始人，翻完这本薄薄的小书后，豁然发现这两年自己踩了无数的坑，于是写下本文给团队的研发小伙伴们看看，如何快速提升自己的产品思维，也希望能给广大的互联网从业者们以启发。最后附上我的读书笔记思维导图供大家快速查阅。特别欣赏这本书序言里的一句话：你所做的一切，都是为了明天的某个时刻做准备！所以，程序员们，学点与技术无关的知识吧！