本篇文章是笔者结合所学知识和自身思考而成的文章，主要讲解笔者所理解的产品经理自成体系的思维模式，包括但不限于技术思维、用户思维、功能思维、商业思维。由于个人才疏学浅，写此一文一则是梳理日积月累的点滴思考，以成体系；二来希望能抛砖引玉，引起读者的指导和点评，优化自身内容。

我认为产品经理的产品思维是一种综合性思维模式。它包括了贴近工程师的技术思维、关注产品功能本身的功能思维、以用户为中心设计产品的用户思维和依托商业战略构建商业价值，做到产品驱动业务的商业思维。

一、技术思维

何为技术思维：

要想了解技术思维，我们需要先了解一个互联网工种——技术工程师。技术工程师是技术思维的典型代表。当一个需求或功能被提出时，技术工程师会从技术实现方式的角度进行考虑问题，设计出技术方案。对于他们而言，看到一个产品设计，会如同构思房子的内部结构一般去构建技术架构，逐层拆分功能的实现要点，并评估产品功能背后的技术价值和开发成本。所以技术思维是一种层层深入的路径推进思维，从技术角度审视产品本身。

为什么要懂技术思维：

（1）与技术工程师的沟通需要

了解产品经理这一岗位需求的人都知道很多时候产品经理是信息的传递者，在一个项目推进中起到信息中枢的作用。一个产品经理需要和技术团队、设计团队、测试团队和运营团队等成员进行沟通与合作；而不同工种的人好比是不同国家的人说着各自的母语。产品经理要想与不同职能部门的人打好交道，就需要掌握不同工种的语系。

产品经理与技术工程师在工作流上是上下游的合作关系，他们时常需要密切的沟通交流以保证双方能达到共识。试想，当讨论需求时，技术人员说“这个功能得调用其他功能模块的API接口“，而产品经理却一脸可爱的听不懂的话，后续的沟通很有可能变成了技术人员对产品经理的课堂教学时间。这无疑增加了沟通上时间成本，产品经理还不一定听得懂。（注：这里用通俗而不精确的语言解释一下API接口的概念：如果系统A和系统B是分开独立的，而当系统B需要从系统A中获取部分数据或者使用系统A的功能时，此时API接口如同一道由系统A打开面向系统B的大门。仅由系统A授权后，系统B无需知道具体的代码细节，就能索取数据或者使用功能。因此在业务中，服务器需要向数据库提取数据时，数据库需要提供一个接口；常见的电商系统中产品管理系统需要调用商品订单系统的订单数据时，也需要调用商品订单系统的接口。）

因此产品经理掌握技术语言，懂得在和技术工程师沟通中切换成技术语系交流能提高沟通效率，同时获得技术成员的信赖和认可，这将有助于项目的顺畅推进。

（2）明确产品设计时的技术边界

随着互联网技术的日益发展，互联网的产品形态和功能也在技术的更新迭代中变得多样化和丰富。例如重力传感器和加速度传感器技术的引入带来的微信运动、测步的功能，GPS传感器带来的定位功能，以及不断升级的手机拍照技术给予了我们堪比专业相机的拍照水平。这一切都源于互联网技术的发展。

与此同时，互联网现有的技术边界或者说现有技术可实现的功能范围也在限制着互联网产品的发展。纵使在完美无缺的产品设计也需要可实现的技术支持将它踏踏实实地呈现在用户的面前。因此产品经理懂得互联网现有的技术边界，了解当前技术可实现的功能范围，就能避免产品经理一味地沉醉于天马行空的想象中，而忽略了是否能够实现的尴尬境地。

技术思维需要做到哪些：

（1）在沟通中听懂技术工程师的常见技术名词

如前文所述，产品经理对技术人员的基础技术知识有一定的了解，明白日常沟通中出现的技术名词的含义，就能在与技术工程师的沟通中，避免过多地陷入不懂技术的尴尬，促进双方在探讨产品设计上达成一致的共识，保证双方信息的对等，提高沟通效率。

（2）将产品概念转化成技术名词

这里主要是说明产品经理如何让擅长技术思维的工程师更好地明白产品设计的概念和核心，以保证最终开发的产品功能是符合预期评审后的产品原型的。这里举一个小小的例子，我们时长会看到在一个活动文案中显示一串“目前已有XX人参与活动“的文字。对于产品经理来说，这个文案设计是一个统计活动参与量并显示的功能，表面上看就是显示一串文字而已；而对技术工程师而言这里是需要使用多个变量存储上述文字并对部分变量进行数据类型转换后进行数据拼接方可显示的功能。具体以Java语言举例便是，定义字符型变量a和c，并将文字中的”目前已有“和”人参与活动“两串文字分别赋值给a、c，然后定义整型变量b，将参与人数赋值给b后将整型变量b转化为字符型数据，最后借由字符串加运算String s=a+b+c进行数据拼接，连接起所有文字才可显示。如果产品经理能在一开始的设计中表明此处XX人的数据是动态变化，使用数据拼接。那么可大大降低工程师对产品设计的理解成本，提高他们的工作效率，也让工程师对产品经理另眼相看。

（3）思考需求和功能背后的技术边界和技术原理，预估技术成本

仅有天马星空的想象的产品最终只会是口中楼阁，在需求评审中沦为团队们的笑柄。需求和功能的背后是强有力的技术支持。产品经理需要明确产品是否可实现，不求能写代码编程，但对功能背后的技术原理有基础的认知是必要的，并与开发成员们协商沟通评估产品的技术成本。如果一个需求无法被满足或技术成本过高无法承担的情况下，就需要产品经理权衡需求，思考是否需要修改产品策略。

二、用户思维：

何为用户思维：

用户思维是指以用户为中心的产品设计思路。它在明确用户需求、权衡各需求中重要性和提升用户体验感上都能给予一定的指导方向。

如何让自己贴近用户思维的思考模式

（1）产品人本身得是产品的资深用户：

笔者一直秉持着一句话：没有调查就没有发言权。放在此处，便是说，产品人若不是自己产品的资深用户，就不可能对产品和它所在的行业有更好的认识，在设计中也会碰钉子。因为你无法换位思考站在用户的角度去感知用户的痛点和使用感受，从而在产品设计中很可能会陷入自我的主观认识中或者盲目的模仿竞品。

（2）不要为了百分之一的可能，去影响百分之99的用户

这句话大家或许都听到过，基本意思是说当一个问题是不确定的小概率事件时，对它做出的产品改变会影响大多数用户，这样的改变是不可取的。在此，笔者给予了一定的延伸思考。这句话的本质是对需求的权衡和取舍。对一个问题的出现，我们是否可以从以下角度逐步深入的思考呢？

a、问题发生的概率有多大？影响面有多大？

b、问题出现时，用户是否会在意而影响对产品的看法和使用？

c、若是解决该问题的话，新方案是否会对老用户造成影响？

d、如何衡量新方案的优化效果？采用什么数据指标验证？

以上层层思考的逻辑能帮助我们明确：是否要做、怎么做、做的怎样这三个问题。

三、功能思维：

何为功能思维：

功能思维是从软件角度出发，思考功能的完整性和实用性。一般在功能设计上需要做到横向分类是否全面合理和将各功能模块纵向垂直细分成子功能。例如我们日常使用的微信，在横向分类为“首页”、“通讯录”、“发现“、”我“，在纵向逐层细分。如下图所示

微信功能结构图

明确产品的核心功能只有一个：用户只会因为一个核心功能而使用我们的产品，而其他附属功能仅仅是围绕我们的核心功能作出的补充和完善。核心功能如同产品的主干，附属功能好比枝叶，仅有枝干而无主干是无法支撑起我们产品大树的。而产品为用户解决了什么核心问题往往决定着我们产品的核心功能。例如在微信初期，它所解决的核心问题就是沟通，那它的核心功能可以是语音、文字、亦或是视频。这里基于微信的原始版本的时代和网络环境，那时微信选择实时文字短信收发作为核心功能是最佳的选择。

四、商业思维：

笔者一直认为，商业思维不是一蹴而就的，它需要产品经理沉淀自身，有多年的业务经验作基础，才能拥有的。由于笔者的项目经验和业务经历有限，笔者无法对此给予非常中肯的描述。事实上，对商业思维这一块内容也是自己需要学习的内容之一。除此之外，笔者或多或少明白一些有关商业思维的准则，仅供参考。

为了价值而活：明确产品的盈利模式

事实上，不以赚钱为目的的生意都不是生意，而是耍流氓。因此，在一开始的产品设计前，我们需要明确我们产品的盈利模式，能给公司带来什么商业价值。一切情怀和理想不是不能有，事实上情怀和理想是给用户和产品人自己的，但都必须建立在产品的商业基础之下。毕竟，空谈情怀和理想，并不能给我们带来盈利和价值，更别说无法支持产品的发展。我们日常认为的谷歌这一互联网公司是注重情怀的，但是否看清其面向用户的搜索引擎，天生就有强势的盈利模式，在打磨产品，追求用户极致体验的同时，公司也收获了巨大的经济价值。

商业与业务闭环的构建：

产品经理在明确产品的盈利模式之后，需要考虑产品功能背后所承载的业务闭环和商业价值。因为单纯的功能并没有价值，产品经理需要思考如何在设计产品的同时以我们的产品业务为基础完善整个业务闭环并构建商业价值。事实上，这一过程是将商业模式具象化地表现在产品中。

最后：由于笔者对商业思维的磨练有待提高，以上也仅仅是自身思考的拙见，所以未能给予事实论据说明。如对上述观点有所指导和点评，在此先感谢一声。

谢谢您的阅读