产品逻辑，指的是一个产品对所支撑的业务过程的抽象，是一个产品从数据维度对功能模块的分割。各模块接收的外部数据，维护的内部数据，比如订单模块内部维护的：订单ID、订单状态、交易双方ID即用户的索引值、订单时间、金额和该模块提供能的服务能力，该模块可提供各内部数据的查询服务、由外部触发的更新订单状态的服务，将上述的服务能力，以模块之间的调用关系结合起来，形成了一个产品支撑的各种功能的实现过程。
你的产品逻辑是什么
最近突然有种茅塞顿开的感觉，我觉得应该进入产品的第三个阶段了。
从整体上来考虑产品的逻辑是什么？
分为以下几个方面：
1、产品逻辑是什么？
2、你的盈利模式是什么？怎么验证？
3、你积累用户的方式是什么？
4、你的优势是什么？
5、做这件事情的成本是什么？
6、你下一年的预算是什么，能达到什么样的结果？
想清楚这些问题，再来做规划，再来拿投资。不挣钱的公司都是耍流氓。
另外，谈投资的一些手段。
其实去谈投资，最重要的是能够把产品逻辑和商业模式给讲通，如果能验证商业模式就更好了。
如果是创业，产品逻辑和商业模式是首先需要弄清楚的，其次是搞清楚要做成这件事情需要什么样的人。
后面重点多看看其他产品的逻辑是什么，怎么积累用户，怎么盈利，如何一步步实现自己的目标。
FABE产品讲解逻辑
韩梅梅最近见了不少客户，但是一个月快过去了，就是没有单子签回来，她的经理都替她着急。
问她：韩梅梅，你最近出去见了不少客户，但是没有单子签回来，你遇到了什么困难？看看我能帮你做点什么。韩梅梅沮丧的说：是产品的功能，我都跟客户讲了，可是客户听完之后，总是跟我说：好的，我回去研究，然后再答复你。然后就没有然后了。
好，如果你是韩梅梅的主管，你应该怎么帮助她呢？你是花两个小时训练韩梅梅的产品讲解能力，还是教会她如何强势的对客户进行逼单？！我建议你，可以换一种方法，讲解产品逻辑的FABE沟通法则。FABE沟通法则是由美国奥克拉赫大学企业管理博士郭坤墨先生，总结出来的一套非常典型的利益推销法，它是通过4个关键的环节巧妙的处理好客户关系的问题，然后顺利的销售产品。
先给你讲个故事，一只猴子非常饿了，想找香蕉吃。这时推销员给它拿来一摞钱，对猴子说：猴妈妈，这是一大笔钱，足足有1万块。猴妈妈没有任何反应。销售员接着说：猴妈妈，这可是一摞钱，可以买很多香蕉。猴妈妈还是没有反应。销售员继续说：猴妈妈，请看，我这有一摞钱，能买很多香蕉，你可以用这些钱买到最好吃的香蕉，然后还可以带着孩子们大吃一顿。猴妈妈有点心动了，但是还是将信将疑。销售员继续说：猴妈妈，请看，我这有一摞钱，能买很多的香蕉，你可以用这些钱买到最好吃的香蕉，然后还可以带着你的孩子们大吃一顿，你的邻居老王刚刚就用钱买了很多好吃的香蕉，现在正在和他的孩子们享用香喷喷的香蕉。猴妈妈立刻扑上去，把钱带走了。
好了，故事说完了，销售人员给猴妈妈推销的方法就是FABE法。那FABE到底代表什么意思？
F：就是功能，指的是产品的特质、特性等方面的功能，产品的名称、产地、材料、工艺定位、特性等等，作为销售人员需要深挖自己所销售产品的内在属性。
A：就是优势，找出这个产品独特的地方，比如它更高档、更温、更温馨、更保险、更安全。
B：就是好处，这个产品能给消费者带来什么好处？
E：就是证据，通过现场的演示、相关证明的文件或者品牌效应等等来印证，你刚才说的一系列的介绍，而这些证据是需要有足够的客观性、权威性和可靠性的。
好了，用一句话总结，FABE就是在找出产品独有的或者顾客最感兴趣的特征之后，分析这些特征所产生的优点，而这些优点能够带给顾客的利益，最后提交证据证明利益是可以实现的。
按照经典的格式，我们可以把FABE连成一句有吸引力的句子：这是什么特点？它可以实现什么功能？对您来说有什么好处？您看这些就是证据和证明。
例如：
F：这款“未来计划”是专为6岁-23岁的小孩专属设计的医疗保险，涵盖了意外、疾病、门诊、住院医疗。在经济条件还不能为小孩配套一系列百万医疗、重疾等情况下，“未来计划”是首选！
A：意外报销是3千/次，全年不限制次数；任何状况下的住院，自费部分的医疗报销更有一年高达7万的额度。最关键的是，一年只需要100元。
B：例如猫抓狗咬、跌跌撞撞等意外受伤，可以报销；感冒、发烧、肺炎等需要住院的，也可以报销；父母双方每人同时也有一年3万的意外身价保额。
E：之前我女儿在一年内得了3次手口足病，住院了3次，这3次住院的医疗自费部分，我就是用“未来计划”来报销的。而且，“未来计划”的理赔案例也不少（列举理赔案例图片）。
如果想分析一个产品，那么分析的逻辑框架大概是应该是什么样的？
项目中有时候的确会有完整的描述功能的脑图。他是保证项目的实现没有遗漏，对反向分析产品的帮助不大。
UML在设计阶段，也被越来越多的人放弃（用例还用的多一些）。
反向分析产品，线框图，UI设计，画面之间的迁移等也是可以忽略的。
那么第一个需要的文档应该是交互图。
1 交互图在熟练使用和理解产品的情况下。。。
列出整个产品逻辑上的主要元素，他们应该是名词。
然后连接起元素之间的关系，他们应该是动词或者介词。
交互图能表现出产品的要素和他们之间的关系。即 UI 背后产品的骨骼。
2 UI和交互的特点但是，在用户体验越来越重要的今天，清晰和完整的搞清产品逻辑不是唯一。
结合这些元素和关系，还可以分析出这个产品在UI和交互上的亮点。
大一些的，
比如新的 JS 框架可以方便的隐藏内容，所以某个元素的列表和明细页面，可以被二合一。（是的，知乎的主页就使用了这种设计 － “显示全部”，而 minigroup 有些更酷的隐藏设计。很多新技术会影响到产品的结构和功能）小一些的，
比如一个意思复杂但是传达到位的图标。
或者，推送页面状态的技术特色。（是的，在知乎，在 A 浏览器窗口清空知乎的未读通知，状态可以被推送到 B 浏览器窗口）
3 产品交互图之后，可以反推出产品的 PRD 。
甚至，具体的功能背后的算法和逻辑？（比如豆瓣推荐算法的最初思路，大概是从和你气味相投的圈子里面，推荐你没有看过的东西）
但是，这也并不足够。你还应该可以竖向追溯产品进化的历史，横向比较产品的竞争对手。
4 用研但是，这也并不足够。你还应该可以从产品的形态，推测出其背后的用研数据。
比如Twitter 在新版本中把 List 功能隐藏的很深，那也许说明用的人并不多。
甚至，你还能比他们当时的用研知道的更多些，因为你在回溯历史。比如：微信 2011 年 5 月用户量的爆发，和 微信 2.0 增加的新功能之间的关系。
5 战略搞清楚这些之后，你就能比别人更靠谱的揣测一个产品的战略目标了。
如何画好一个产品的逻辑图？
逻辑要弄清楚！为什么我这么强调逻辑，因为如果你的逻辑跑不通，最后出来的东西会陷入死循环，这对于使用产品的用户来说是致命的！你的每个功能的逻辑要跑得通，三个字跑得通看似简单，实际你需要花一定量的时间去跑逻辑，当然了，并不是说你花的时间越多越好，如果逻辑比较复杂，花的时间越多越可能把自己搞晕。有精力的朋友可以去梳理以下淘宝的订单逻辑流程图。跳出订单页面的可以不用理会哈。聪明的产品一看这个图就明白如何画，而且还会在我这个基础上更加完善更加美观。
用户体验即营销,如何在运营中快速改善产品体验
产品用户体验
一、产品第一印象
需求分为刚需和弹性需求。而需求从频次上又分为高频需求和低频需求。在做产品需求层面上，一定会选择刚需且又是高频需求。哪怕一个产品市场中已经有很强大的竞争对手时，我们还是选择这样的产品需求去做。首先，这样的产品容易获得用户关注，用户就会在产生需求的时候第一个就会想到你。其次，高频需求的产品可以快速验证我们的MVP产品。快速验证的产品就是马上进行试错，那么我们后面的试错成本就会小很多。不然我们会犯很多的错误。需求产生的时候，用户想要第一时间想到你的产品的话。就必须做好用户看到你的产品第一印象。而这个印象可以建立在用户体验上的。
二、即需求即产品
为什么张小龙想让微信用完即走?原因很简单，因为工具产品的微信要做一个工具的使命。而不是大量霸占用户的时间，最后让用户产生厌烦的感觉。最好的工具产品一定在需求产生时，想到你的产品。然后用户在需要产品时候，能够愉快的使用你的产品。特别是文案的体验十分重要。每一个人性化的文案会让用户产生留下来继续使用产品的理由。用完即走是一种舒适刚好的用户体验。它不会霸占用户时间，更多的时间应该是会让用户在付费产品上产生出用户价值。
三、用户实用场景
什么是场景?用户场景就是用户在生活中一个环节，比如在上下班的时候，很多人直接拿出地图来进行路况查询;当遇到老外的时候，很自然的拿出翻译软件等。用户的刚需表现在特请场景下的使用便利性。如果违背了用户最最核心的场景需求，只会让产品体验更差，比如看到一些上门火锅的产品，不符合火锅背后的文化，火锅建立的是人与人之间近距离的接触，主要体现在朋友之间的聚会，火锅的简单生活、氛围更适合谈心聊天，上门送火锅则少了一种氛围。
四、产品的思维逻辑
产品逻辑就是用户的正常合理的习惯，产品往往起到的作用是让用户的行为更简化、更合理，抽象的人是主要建立在操作流程、视觉流程及内容流程;操作流程是当用户进入产品后手指行为的互动，视觉流程是直接关系到内容的扫描速度，内容流程则主要体现在理解功能的复杂度、产品的整体价值，所有的逻辑要符合目标用户习惯，否则只能形成习惯强加，用户的第一印象是产品复杂、难以理解。
五、产品功能互动
产品的实质性主要体现在产品的操作互动性上，生活中我们可以用手触摸产品，让人感觉到真实，这个从用户心理上是“满足的、真实的、友好的”，但是电脑尤其手机端的操作，平面点击让用户无法感受到这种友好性，只能建立在视觉的互动上，每一次的点击都能让用户感受到交互了，点击有了快速的响应，以增加操作的真实性，这种功能互动间接的会引导对于产品简单化的培养和引导。
产品设计应该遵循怎样的逻辑
①概念化”阶段进入到“图纸化”
我们之前在市场需求文档（MRD）中阐述到的功能，都是表达的一个意向，不考虑实现方法和细节。而PRD则是将概念图纸化，需要阐述详细的细节和实现模型。产品人员可以通过撰写PRD，梳理清楚方案实现过程中的各种问题和影响。
②向项目成员传达需求的意义和明细
PRD的主要面向对象是项目经理、开发、设计和测试。如何向这些不同的角色表达清楚需求明细，就需要一份规范的PRD文档来描述。项目经理通过文档可以迅速了解任务的规模和相关接口，而开发设计人员通过文档可以了解页面元素和用例规则，测试人员可以提前根据文档撰写测试用例。PRD文档在形式上是项目启动的必要元素之一。
③ 管理归档需求
大都数的新需求都需要迭代几个版本后才能走向成熟稳定的阶段，如果没有PRD文档，在大型项目中，需求的迭代变更将变的无据可循。PRD的文档修订编号和命名也是项目规范化管理的主要方法之一。
PRD的表现形式
一般企业内部的PRD文档选择wiki系统或word文档。wiki在协同和保密方面会有优势，而且能够记录修改文档的每一次变更。而word在阅读修改方面比较有优势，一般使用Word加SVN的方式来管理更新文档。这个可根据每个企业的管理规范来选择那种方法更合适。
PRD的主要构成
一份基础的PRD文档主要由三部分组成
①引言
引言部分主要包括：需求背景、需求目的、需求概要、涉及范围、全局规则和名词说明，交互原型地址等。引言部分的写作目的是让阅读者快速理解需求背景和概要。如果是公司内部文档，引言部分可以从简写作。
②业务建模
建模的目的是为了帮助阅读对象更好的理解需要开发的需求，常用的模型种类包括：用例图、实体图、状态图、流程图等。常用的建模语言如UML。UML具体的建模方法请戳这里。
③ 业务模块
业务模块包含具体页面的元素、用例规则，以及相关的原型，流程图。业务模块的描述是整个文档最核心的部分，下面博主用案例来描述一下业务模块的编写方法。
