以下这几种情况你有躺枪么？
产品逻辑总是梳理不清楚，很有边界情况没有考虑到，比如联网状态、登录态、弱网情况等；
只考虑到正向流程，返回操作和异常操作没有考虑到，比如退出是否二次确认，未保存返回时是否保存当前内容等；
自己觉得产品逻辑已经梳理清楚了，但是业务逻辑是有出入的；
多个产品中没有公共模块，导致相同业务的相同功能在不同的产品中逻辑不一样
……
在写这篇文章的时候，80%的产品经理都中枪了。John之前说过逻辑三段论：聚类、递归和因果。
感觉是非常难以理解的，需要经过大量的项目才能做这样的梳理。那么在项目的过程中，项目组不同的角色他们也会有自己的逻辑方式：
业务逻辑：需要业务伙伴解释清楚：这个业务想为哪些用户提供什么样的解决方案，目的是什么？——业务评审会
产品逻辑：需要产品经理在这个场景中能满足业务的哪些需求，通过原型交互方式、不同页面的跳转规则、角色判断等来对项目组其他同事梳理清楚。——产品评审会
视觉逻辑：需要依托于产品经理做这样的原型背景下，UI应该用怎样的视觉来让对应用户沉浸在该场景中。——设计评审会
交互逻辑：UE协同产品经理表达怎样的交互让用户感觉更加的友好，增强用户的操作感——交互评审会（和产品评审会一起）
开发逻辑：有些逻辑可能用技术语言描述更清楚一点，以及对技术有特殊的要求。前后端接口、数据对接等。——接口评审会
作为产品经理（万金油角色）也需要去梳理了解角色逻辑，方便更好的沟通交流，今天就重点聊聊产品逻辑。其实产品逻辑可以分为四大类：基础产品逻辑、业务逻辑、系统逻辑和思维逻辑。那么本文通过四个方面来聊下：
- 一、业务逻辑篇
- 二、基础产品逻辑篇
- 三、系统逻辑篇
- 四、思维逻辑篇
一、业务逻辑篇
业务是产品的根本，当产品经理和业务去沟通需求时，业务方只能知道自己想要什么，那么产品经理需要和需求去明确几个点：
- 需要做什么业务？
- 做这个业务的目的是什么？
- 这个业务的用户群是什么？
- 是需要解决这个用户群的什么问题？
其实总结起来需要沟通的就是一句话：这个业务是在什么场景下解决哪些用户的什么问题，目的是什么？这儿John举一个案例来说明下：
业务方想要做优惠券，主要目的是为了帮助商家促销和增加用户复购率。那么产品经理需要从这几个方向去思考下：
1.优惠券主要是为商家促销和用户复购——那么类型就可以按照商家商品的属性（全部商品、指定商品和指定商品分类）以及会员的分类（基于本身平台的会员体系分类）
2.是否把优惠券作为了一个单独的入口？主要是为了彰显优惠券的重要性，同时也方便合理的召回用户（利于消息的PUSH）
3.优惠券是否需要分类——针对于平台券和商家券，利于按照用户的属性（会员等级、消费额）等给用户不用的券
4.购买后是否也会派发对应的优惠券——方便更好的召回用户复购
5.是否是长期行为——长期行为需要梳理整个优惠券体系
以上5个业务方面的内容梳理清楚后，那么业务需求池以及对应的功能需求字段可以整理出来了。以下是John针对这五个需求场景和优惠券显示常用字段整理：
业务逻辑的梳理一定是需要和业务方保持沟通，不要高估业务方梳理的能力，也不要指望业务方能把自己的业务场景描述清楚，并且帮你明确要开展的新玩法对你的系统有哪些影响。要试着从产品的角度去理解这些新业务发生的场景、与现有业务的区别，从他们近似大白话的描述中捕捉到自己关注的信息，从而确定对自己负责内容的影响范围。
二、基础产品逻辑篇
也就是需要掌握产品的基础逻辑，这又是产品经理的基本要求，比如前后端的数据交互方式，不同页面之间的跳转规则以及多个角色的判断条件。可以用产品自查表去梳理清楚。
三、系统逻辑篇
产品经理对系统逻辑的梳理一定不是制作一个精美的PPT来说明自己想要去做什么。而是要去根据自己的产品从主体到细节的思考产品过程。所以可以从下面三个三个方向去考虑：
1.产品架构逻辑
你的产品处所行业的位置是什么阶段？竞争对手现在有多大的成绩？你的产品的商业模式是什么？应该怎么走？John在公众号写过产品架构的文，但是锻炼这种思维绝不是只是去了解下自己的产品。而是首先去通过行业去分析你的产品目前所处的位置，根据产品生命周期制定可行性的产品路线图。通过业务去整合模块去梳理。比如在电商产品中：
商业模式的思考：商业模式对于电商来说，有简单的搭建平台和自营方式。这样的方式，就是对于前端产品的架构设计提出了要求。我们使用不同的方式进行产品架构。在商业模式思考上，要把核心业务赢利点的流程设计清晰。
为运营者去思考：在运营模式思考上，要对公司后台管理人员进行有效了解和知晓未来产品推广的方向。在通过大运营的模式下，去提高产品设计结构完美性。
为使用者去思考：对于后台使用者来说，会有不同管理权限和对应的不同职责。在设计后台时，尤其要考虑使用人员的所在公司等级关系情况。针对性的进行设计。
为用户去思考：除了用户初次登录使用之外，几乎绝大部分的情况都是登录情况下进行操作。我们要尽量监控和维护用户所产生的数据。对于数据来说，我们在产品结构中是称为很底层的东西。在这个底层的数据中，我们需要通过数据挖掘去发现业务和进行业务营收的重任。
所以建议操作的步骤为：竞品分析→产品业务框架→商业模式→用户体系→产品规划→运营规划。只有这样才能清楚每一步需要做什么以及如何去执行。
2.产品细节逻辑
聊这个我就想怼人了哈。有些产品经理恨不得每天去讨论产品每个像素、每个颜色、每个按钮的设计。恨不得在原型里面埋上上百个交互细节，以体现自己产品设计细节的精妙之处。不过遗憾的是，产品的成败似乎与这些无关。而产品细节更多的体现在【需求本身的细节】和【功能逻辑的细节】这两个方面：
需求本身的细节：在人人都是产品经理的理念下，谁都会提需求。老板会提，开发会提，甚至用户都会提，在福特汽车时代，用户也会提出需要一匹跑得快的马。但是只有成熟的产品经理才能真正能准确判断需求价值，具备筛选需求能力。
产品经理永远是决定做对的事情的人，而所谓对的事情，其实就是选择最合理最符合当前产品背景的需求。面对让人心动的创意，产品经理如何判断出需求是否有价值？需求的场景是否靠谱？在多个重要需求中，如何权衡、取舍、妥协？光是这些决定，就需要产品经理全身心投入进去。
功能逻辑的细节：举个简单的例子：某电商平台需要开发一个退款的功能。在需求上，退款绝对是常规需求。那么问题来了，如果要实现退款这个需求？一定要关注的细节有：
- 用户支付过程中用了优惠券是否要退？
- 一个订单多个商品如何只退一个？
- 由谁来确定用户的退款申请？
- 退款是原路返回还是到用户的平台账号中？
- 退款时限多长？
- 是否所有产品都支持退款？
在面对一个正常需求时，产品经理需要把所有会涉及到的问题想透，想全，这个是非常考验产品经理经验和能力的地方。产品经理应该是全公司最了解自己产品每个功能细节的人，他要帮助技术了解每个需求的场景，帮助运营把需求转化为技术方案。
3.系统对接逻辑
其次还要了解自己负责的模块与上游哪些主要系统有交互、交互的核心字段是什么、交互方式有哪些。既然选择了产品经理这个行业，就要不断扩展自己的知识边界，技多不压身并非一句空话。
一个产品既对自己的系统实现轻车熟路，又对自己的上下游系统的核心业务了如指掌，出现了问题他能通过功能细节和以往经验定位问题的大概原因，试问，谁不愿与这样的产品共事呢？
产品架构逻辑、产品细节逻辑和系统对接逻辑是系统逻辑的三大基础。产品经理针对这三个方面需要去思考其中的场景。在针对于系统层面分析选择就你那个得心应手了。
四、思维逻辑篇
思维逻辑本身就是一个很虚的东西，因为干扰的因素众多，包含：日常工作的方式思考、产品经理个人的习惯等。那么主要通过三个方面：产品严谨性、产品完整性和产品敏锐性。
1.产品严谨性
产品需求需要能够兼顾到各类用户、各类场景。电商中结算体系，当出现新业务需要向商家进行计费和结算时，除了正向订单货款，还要考虑退货退款的逆向场景。要新增一个数据字段，除了增量数据可由程序自动赋值，还要兼顾历史数据如何清洗。
2.产品完整性
需要去思考各系统之间的串联，保持高效连接。比如O2O电商产品中， 既有负责商家、商品、订单、售后各个条线的垂直产品经理，还有一个负责综合类项目，梳理整体流程的综合产品经理，相对于前者，后者则需要更专业的知识储备和逻辑思维，才能把一个综合类项目串起来，不至于遗漏其中的某一个环节。产品经理也不要一叶蔽目，只关注自己所做的内容，而是要去思考全局性。
3.产品敏锐性
John保持产品敏锐性的方式就是去拆解产品，拆解App Store前50位产品能有效的帮助我们了解产品最新的微创新和行业动态信息。
思维逻辑本身是很虚的，作为产品经理一定要落地去融入这种思维。包括在面试的时候不要很抽象的解释什么是严谨性？而是通过案例去诠释你的想法。
以上四种逻辑是John在做产品之后一直秉承的，并不是说这四种逻辑就是产品经理思考的全部，但是在日常工作中产品经理工作流就是去思考产品从开始到结束的最好保障。
本文内容来源于：公众号：产品狗聚集地，不代表运营狗网站观点，如有版权问题，请联系站长删除。
微信扫一扫 
支付宝扫一扫 
