产品经理需要了解的产品基础逻辑！

狭义上逻辑是指每个人的思维方式，这是个体内在属性。广义上逻辑是指规律，包括思维方式规律和客观事物规律。这种思维的规律和规则，是对思维过程的抽象和建模的结果。

从逻辑的归属来看，没有明确的销售逻辑、运营逻辑、产品逻辑、程序员逻辑之分。而对于产品经理这个职位，更不要给自己设定一个清晰的边界，只要是对自己的思维方式有锻炼，对自己的产品工作有帮助的，都可以并且都应该去涉猎。比如公司销售的面向不同用户层层递进的营销话术、部门运营的针对不同时令有的放矢的运营策略、程序员并行处理多个线上问题的分堆归类原则。

不论是不是自己负责的系统或本职工作，都可以尝试去了解和学习，很多东西都具有可借鉴性，并且可以应用到自己负责的模块或功能上。

从产品逻辑角度来说，可以分成四类：基础产品逻辑、业务逻辑、系统逻辑、思维逻辑。四类逻辑是递进关系，分别拆分。

一、基础产品逻辑

也就是掌握常见应用的基础逻辑，这是成为产品经理的基本要求。比如前后端的数据交互方式、不同页面的跳转规则、多个用户角色的判断条件。

二、业务逻辑

有了产品经理的基本素养，接下来就要深入业务、理解业务。知道他们要做什么，要做的东西对自己负责的系统有哪些影响。当你被拉去一个新业务沟通会的时候，不要高估业务方的智商，也不要指望业务方能把自己的业务场景描述清楚，并且帮你明确要开展的新玩法对你的系统有哪些影响。要试着从产品的角度去理解这些新业务发生的场景、与现有业务的区别，从他们近似大白话的描述中捕捉到自己关注的信息，从而确定对自己负责内容的影响范围。

三、系统逻辑

1）自己的逻辑。产品经理作为一个系统的负责人，首先要知道自己的系统有哪些功能，功能的实现方式，出现过哪些问题，可以用什么方式解决问题且开发量最小。

2）别人的逻辑。其次还要了解自己负责的模块与上游哪些主要系统有交互、交互的核心字段是什么、交互方式有哪些。既然选择了产品经理这个行业，就要不断扩展自己的知识边界，技多不压身并非一句空话。

一个产品既对自己的系统实现轻车熟路，又对自己的上下游系统的核心业务了如指掌，出现了问题他能通过功能细节和以往经验定位问题的大概原因，试问，谁不愿与这样的产品共事呢？

3）细节逻辑。产品经理拼的是什么？对业务的理解？有BD和采销呢，然后还有运营支持呢；对方案的落地？有前端和后端研发呢，然后还有测试呢。除了PRD，产品经理没有明确的工作内容，也正是由于这一点，它才是最复杂的工种。运营要了解，技术也要懂一点。最主要的是对自己负责功能和模块的理解要深入，一定不是像业务方那种的泛泛而谈，或是领导那种大而空的规划，产品经理的能力体现在可以落地到具体问题、具体细节的功能点。能够描述清楚问题的现状、成因、影响范围以及解决方案。能指点江山的人不一定能脚踏实地步步为营，但能深究细节的人一定能立足现实勾勒未来。

4）框架逻辑。框架不是一张放之四海皆准的流程图，也不是一篇有普适效力的需求文档，它一定是面向特定方向，基于已有工作积累、项目经验所总结出来的，一套可复用可落地的方法论。

四、思维逻辑

这是最重要也是最难锻炼的，因为思维逻辑除了受日常工作方式影响，还会受生活方式、个人习惯等诸多因素影响。思维逻辑主要的几块：

1）严谨性。出现一个新需求，能够兼顾到各类用户、各类场景。比如做结算，当出现一类新业务需要向商家进行计费和结算时，除了正向订单货款，还要考虑退货退款的逆向场景。要新增一个数据字段，除了增量数据可由程序自动赋值，还要兼顾历史数据如何清洗；

2）完整性。做项目写需求，不单单是把自己负责的内容搞明白，让别人一眼就能看懂自己要做什么。更重要的是要通过自己负责的东西把能把整个项目或需求像多米诺骨牌一样串起来，告诉别人要做什么、怎么做、做完之后有什么收益。让别人既能了解细节，也能看到全貌。

就像之前京东一个部门，既有负责商家、商品、订单、售后各个条线的垂直产品经理，还有一个负责综合类项目，梳理整体流程的综合产品经理，相对于前者，后者则需要更专业的知识储备和逻辑思维，才能把一个综合类项目串起来，不至于遗漏其中的某一个环节。要知道，在京东这种体量和架构的公司，一个综合类项目可能涉及到前台、中台、后台三大模块、大大小小十几个甚至几十个系统。

3）敏锐性。就像前面说的，一个新业务的开展，BD可能给你讲一两个小时这个玩法有多新颖，能拉新多少用户，增长多少GMV，但是不会给你清晰的指出到底对你的系统有什么影响，而是要你自己留意对方的长篇描述，对比现有的系统交互，过滤出有效内容，捕捉到原流程和新流程的异同点，从而确定影响面和改造点。

怎么提升产品逻辑

1）注重细节

如果把一个产品新人和运营老人放到一起，讲真，产品新人对系统的了解不一定比运营老人多，因为运营老人使用的频率和次数比产品新人多，发现和了解的问题也比产品新人深入。产品经理新搭系统的经验和处理问题的能力，完全是一个项目一个需求一个问题堆砌出来的，没有什么过来人经验你能够完全复用。而作为产品，特别是B端产品，一定要对细节有所把控，因为你的一个小的纰漏，导致的问题是不可估量的。

2）了解技术

这个我曾不止一遍的说，是因为从我的个人经验来看，主要原因有二：

1）了解基本的技术实现能够很好地减少你和研发之间的沟通障碍，让你们能够很轻松的对话。而且也能让你了解自己负责系统的底层能力有哪些，对于业务需求能够支持到什么程度。一个项目要上线，看的不仅仅是收益，如果评审的时候研发和你谈可行性，而你却一直强调转化率能提升多少，这样的沟通对于研发也是痛苦的；

2）有了一些技术底子，能够让你对自己的工作更加自信。试想，如果出现一个线上问题，你自己能够通过SQL找到对应的库、表、字段，并且告诉研发现在的问题的成因和解决方案。如果现在的你已经能做到，祝贺你，再优秀的道路上越走越远。

3）定期沉淀

好记性不如烂笔头。有没有这种体会：本来一周挺忙的，结果周五写周报的时候却想不起这一周都干了什么。原因就是没有及时记录自己日常工作的重点内容。放眼到自己负责的系统，也是一样的道理。对于自己遇到的线上问题、特殊场景要有所记录和说明，一遍后面进行复盘的时候能够大概知道自己当时想说明的是什么，为什么会联想到这个问题。

4）不设边界

好的产品经理，是没有边界的，不会把自己局限在某一个小的领域。大家的日常工作中都遇到过类似的人，找他处理问题，他只甩你一句：这是上（下）游的，我不了解，也没法处理。这些人能力不一定差，因为他们能准确定位到问题的成因和系统来源，所以他们在自己领域的知识深度应该是有的。但是这类人不是优秀的，优秀的人知识体系是三维结构：既有垂直领域的深度、也有平行领域的广度，再者就是海纳百川、兼容并包的高度。

5）心怀敬畏

每一个领域都有优秀的人存在，你不知道，不代表没有。有的人故步自封，可能不是他觉得自己有多优秀，而是没有见到过比他更优秀的人。对某一领域有所了解，这是对从业人员的基本要求，不论是销售、运营、产品还是程序员。但是如果能在自己的领域做到极致，也一定符合28分布。看过射雕英雄传的同学应该记得，欧阳锋说过：孤陋寡闻的可以原谅，没有自知之明的就不能原谅。

本文内容来源于：cnwebe，不代表运营狗网站观点，如有版权问题，请联系站长删除。