因为个人职业规划选择，我未来打算从现在的Java开发岗位转到产品经理岗位上，所以这段时间我看了一些书还看了一些关于产品经理的视频。那么现在我想对我之前一段时间的学习做一个小小的总结。

        对于产品经理我将分成三个篇章进行阐述，分别是《需求篇》、 《项目研发篇》、 《运营篇》需求。

        首先第一部分是《需求篇》

        作为在IT行业混的人，一定会听到或者用到的一个词汇，需求！那么什么是需求呢？在这一篇章我来给大家讲述一下需求的基本概念。

        提到需求最基本的会冒出三个问题：

        第一个，什么是需求？

        第二个，需求的来源？

        第一个，需求的目的？

        我们一个个的来解决，首先，来解决第一个问题，什么是需求？

      在经济学中的定义是：用户愿意并且能够购买某个具体商品的欲望。需求分析是产品经理在工作中最基本的能力，也是需要话最多时间修炼的能力。

      举个例子，比如现在是中午，我肚子饿了，我需要吃饭，但是下楼买东西太麻烦了，太浪费时间了，所以我掏出手机，在外卖平台上顶了一份午餐，这个动作解决了我吃饭的需求，并且外卖平台上的价格比楼下实际的价格也贵不了几块钱，相当于我用金钱在买时间，这点钱我花的起。

        再举个资料，比如我对太空比较好奇，但是坐火箭需要花费3-4个亿，远远超出了我的能力，那么这个就不成立了。

        用户在使用某个产品的时候，一般分为三步走，第一步，期望，第二步，具体行为，第三步，核心需求。比如我现在想要找一份产品经理的工作，那么首先我的期望是替身求职的竞争力。具体的行为表现是，参加专业的产品经理培训，阅读产品经理的书籍，撰写产品相关的文档，核心表现为，想要找到产品经理这份工作，并且获得比较高的薪资待遇。

        说到需求，不得不提的两个理论，第一个是马斯洛需求理论，还有一个是Kano模型。

        先来说下马斯洛需求理论，初级阶段：生理需求，比如衣食住行之类的。安全需求，生命的安全，财产的安全，社会秩序到安全。中级阶段：社会需求，比如友情，爱情，归属感等等。尊重的需求，每个人都渴望被别人尊重。高级阶段：实现自我价值的需求，实现理想，改变社会等等。

        一般的来说最高级的需求比较少，大部分的产品都是为了实现初级目标衣食住行和中级目标感情和尊重去的。

        再来说下需求的类型，需求一般分为三个类型，基础型，期望型，兴奋型。比如一个手机，基础型的我要求手机可以打电话，发短信。期望型的我希望手机可以上网，打游戏。兴奋型的，手机的系统是IOS，非常的好用，用了之后感觉让人欲罢不能。

        当然，随着时代的推移，类型也会发生变化，比如最早期的手机是键盘类型的，在那个时候要是有个触屏式的手机，就属于兴奋型的需求了。然而现在呢？基本手机都是触屏的，这就变成了基本型的需求了。

        那么，在实际工作中，需求从哪里来的你知道么？

        一般来说，需求的来源大多数源于一下几个渠道：用户的需求，竞品分析的需求，老板的需求，政府部门的需求，产品的自身需求，同事的需求，产品经理头脑风暴的需求。

        第一个要介绍的是来源于用户的需求。在谈这个问题之前，大家都可以得到一个共识，就是产品是给用户去使用的，并不是给开发用，不是给产品经理用，更不是给老板用的，我们面向的对象是用户！这一点必须牢记，路不能走歪了，否则很有可能被市场和用户所抛弃。

        当用户在使用产品的时候，该产品是否能够真正的解决用户的核心痛点，使用是否方便，解决问题的程度是需要产品经理时时刻刻去关注的。产品经理需要长期的与客户建立一定的联系，以最快的速度了解用户，收集到用户的反馈，得到最真实可靠的情报，并且做出最快最正确的反馈。

        分析并挖掘用户真实的需求，这个能力尤为重要，比如福特汽车的创始人说过，当我去问用户你们需要什么的时候，用户回到我，需要一匹马。但是福特最好创造出来了一辆汽车，因为在这个需求的背后，用户真正想要表达的核心痛点是，马太慢了，他们需要能够更快速的达到目的地。

        用户提出来的需求和产品经理分析出来的需求很有可能存在着巨大差异，甚至是两件完全不同的事情。有些时候用户自己都不知道自己想要的什么，或者只有一个模糊的概念，这个时候产品经理就需要通过自己的专业知识进行分析，提炼，挖掘，得到用户真正想要的东西，这样用户才会买单。

        其次，判断用户是否说真话的能力也同样重要。当我们在了解用户需求的时候，有些情况下用户并不一定会把内心真实的想法直接告诉你，人都是带着面具的，都是有一层伪装的，这种时候，产品经理就需要撕开伪装，直接找寻到真相。比如有一家做MP3的公司，找了一批用户来公司做调研，在询问客户如果购买的话会选择什么颜色的时候，大多数用户说的是蓝色，黄色，白色等一些炫酷的颜色，几乎没有人选择黑色。厉害的点出现了，在调研快要结束，产品经理逐个将用户叫到了小会议室表达感谢之情，并且，在桌上摆出了一排MP3，让用户自行挑选一个带走，结果出乎所有人的意料，用户基本都选择了黑色的带走。

        为了给用户提供更好的产品，提供更好的服务，产品经理需要从用户的言行之中分析挖掘出用户真正的问题，并精准的定位到核心，由此来对产品进行调整优化完善。

        第二个比较特殊，是来源于老板的需求。既然说到了老板提需求，先说说有几种情况下老板才会提出来需求。

        第一种，最无厘头的拍脑瓜式的需求。比如，我看百度这个页面挺简单的么，来你去给我弄个百度。遇到这种情况，其实比较无奈，需要产品经理非常耐心的去向老板解释问题，并且表示这种类似的需求无法完成，千万别跟开发提，否则容易挨揍。如果老板长期都在提这样的需求，那么个人建议脚底抹油，跑路才是上策，跟着这种人，别说吃肉了，汤都轮不到你喝。

        第二种，合作对象提出来的需求，尤其是那种大单子，往往优先级要排到第一位，这种情况套用一句大家都懂的话就是风险和机遇并存。当你把这个需求好好的完成，让老板签下了大单子的话，你后面的路往往会走的比较顺，升职加薪这种事情往往也会优先考虑你，但是如果在这种时候掉链子了，那么估计就难了，要么你识相点自己离职，要么老板直接把你开了。

        做这种需求时，有一个最难的点，产品经理无法直接和用户见面，都是通过老板的转述获得产品的要求，语言的传递存在一定程度的变形，经常看综艺的小伙伴肯定看过类似于传声筒之类的小游戏，第一个和最后一个说的话很有可能天差地别。在这种时候就需要产品经理又足够丰富的经验去分析判断出客户的真实需求，并且完成它。

        还记得我刚刚开头的时候说的话么？特殊，老板的需求会比较特殊。因为老板都是有一个原则，结果导向。我不关心你的过程是怎么样的，我只关心结果，条条道路通罗马，只要能够得到最后的结果，怎么做无所谓。但是重点在于，产品经理会失去试错的机会！一般产品经理自己在做需求的时候，会存在试错，只是单纯的获得需求，在并没有太大把握的时候，先做个MVP出来，小规模的试试看，如果有机会，咱们再把这个项目的血肉都填上，一旦不行直接推到重新来过。这样的做法，从经济的角度来说是非常节约成本的，但是从时间的角度来说是比较浪费的。但是老板的需求特殊就特殊在这里，时间才是最重要的，当你做了三个MVP才成功的时候，竞争对手已经把单子签下来了，那么所有的努力都将白费。

        好消息是，一般都是高级产品经理或者产品总监才会遇到这种事情，一般的初级产品是不会碰到的。

        小结一下，老板的需求必须排在最前面，并且在适当的时候尽快给出反馈结果，便于老板下一步对策。

        第三种，来自同事的需求。同事可能是客服，可能是运营，可能是销售，也有可能是市场。跟同事配合做需求有比较多的技巧和方法，因为每个部门不太会无缘无故的来提需求，一般提的需求都是有一个基本的目的，这也关乎到每个部门的KPI完成情况，还有最最重要的每个人的奖金，稍有不慎，不利于同事关系，今天是他来找你办事，那么明天，你能确定你不去找他办事么？产品经理是一个接触非常广的职位，几乎要和公司的大多数岗位的人接触。

        这里还涉及到两个概念，需求池和需求的优先级，我们放在后面说。当同事过来提需求时，尤其是扎堆过来提，这样的需求即便你产品经理能够迅速的出PRD，开发和测试也没时间去完成需求啊，那么需求的排序就显得非常重要了。当有5-8个需求提过来的时候，产品经理要优先选择最重要的需求去完成，最重要的需求有一个非常明显的指标，需求的价值，比如一个需求价值30W，另一个需求价值50W，那么先做谁的需求呢？显而易见，当然特殊的需求不能用这个规则，比如老板的需求，必须放在第一位，再比如，政府提出来的需求，如果你不做，直接把你的产品封掉。比如必须实名制，必须提交身份证等信息，那么的迅速安排开发和测试，去和政府的人员进行对接完成API的调试。

        判断出需求的优先级还不算完事，还有一步，需要去安抚那些没安排上的同事，毕竟人家的奖金就指着这个需求了，你告诉人家暂时先不做，他能开心么？那么该怎么样做呢？

        方法一，比较适合新人产品经理，将产品部门，开发部门，测试部门的人力安排情况先和同事告知清楚，不是我不愿意接你的需求，是开发和测试人员不够啊，我是真的没办法在第一时间安排，但是等这个需求完成我立刻马上把你的需求给安排上，需要你稍微有点耐心。

        方法二，比较适合有经验的产品经理，在其他同事提需求之前，提前告知开发和测试的工作情况。比如，这个需要需要做3个星期，那么2个星期之后，你们可以把需求提上来，我准备分析撰写文档，然后安排开发测试，这样大家心里都有数，会极大程度的降低争吵和矛盾。

        方法三，不到万不得已别用。跟领导申请资源的调配，把一些暂时有空的开发同事和测试同事调到你们组帮忙。原则是不采用这种形式，因为会比较麻烦，临时调过来的同事，磨合方面有可能会比较不顺畅，并且人家是一个打短工的，一般不太会过于用心做事，不像是那种长期跟你一组的，你们的升职加薪是绑定在一起的。

        对于同事的需求，尽可能的要做到让大多数人满意，毕竟大家都是为了工作，而且帮忙是相互的，总有一天你会需要他的帮助！

        第四种，来自客户的需求。听说过二八准则么？20%的客户带来80%的效益。当客户过来提需求的时候，首先我们要知道，这个客户是不是我们的核心客户，如果是核心客户，那么即便是非常小的需求，我们也同样要花大力气去完成，要让客户尽可能的满意，绑定客户，让他一有需求就想起你，这样将来有大订单的时候，好运也会降临到你的头上。对于剩下利益不是很大的客户，表面上得做到让人感到舒服，别一下子就让人感觉你在敷衍他，毕竟是客户，他要是向你的领导投诉你，你也吃不消。

        重点是价格，除非老板有特殊的要求，否则赔本的买卖咱们可千万不能干。作为一个开发这种事情我听的太多。某某集团去招标，客户的要求是要做三个系统，分别是财务系统，OA系统，订单系统，并且要做接口将这三套系统连接起来，基本算下费用，三套系统，平均每套的价格在100W左右，在做接口把三套系统调通，成本起码得20-30W,在算上公司的盈利等等，这个需求没有500-600W基本是下不来。结果遇到个二傻子，300W左右的价格中标了，结果可想而知，由于开发测试人力不足，项目流产了，该人员也被老板直接开除，当然最亏的还是老板，员工开除了他工资还是拿了的，老板可是实实在在的赔了钱啊！

        最后是类型，toB和toC的业务类型是不一样的。toB是客户内部自己用，对于界面的设计和用户体验感之类的，不会有太高的要求，同事并发量也不会太高，一般10-20左右，但是toC的就不同了，对于设计，用户体验，并发，都会有比较高的要求，当然，价格也不是一个价格，如果在只能接受一个需求的情况下，选择一个性价比高的需求接会比较好。

        第五种，这里把自竞品分析和产品经理头脑风暴所得来的需求一起说。当然，头脑风暴同样不太适合初级产品，一般是中级产品和高级产品去完成的，竞品分析也同理，不过分析文档可能是由初级产品经理来完成，分析和决定的工作可能是由中高级产品经理来完成。

先说竞品分析，当咱们的竞争对手出了一个新的功能，并且在第一时间效果非常不错的时候，咱们的项目需要跟进么？这边要先打个问号！首先我们得分析这个效果好是短暂的还是持续的？

        举个最简单的例子，手机的双卡双待，山寨手机早在N年前就有了双卡双待的功能了，但是苹果手机呢？只有XS Max和XR两款有这个功能，那么请问苹果的实力难道不如山寨手机？答案显然是否定的，苹果一直以来走的是高端风格，虽然最近几年已经慢慢的变成了街机了，但是这依旧不影响人家手机的格调啊。苹果手机是选择了一个最合适的时间点2018年9月发行的，在后期也都没有在继续发行了。原因是什么？因为苹果的理念是：是产品至上、人才第一、追求完美、敢于残忍、嫁接艺术、不断学习、极简主义、守住秘密、保持团队、多奖少惩。双卡双待显然不太符合，所以苹果并未在这方面下功夫。

        其次，新的功能技术是否跟得上，还是说手机，这次说的是指纹解锁，我影响中，最早期的时候摩托罗拉就已经出现了指纹解锁的功能了，后面HTC等品牌的手机也加入了其中，但是苹果直到2013年5S的时候才发布了有指纹解锁的手机。苹果不如摩托罗拉？显然不可能成立。在最早期，指纹解锁这个功能是非常不完善的，10次解锁能够失败7-8次，把一个不成熟的技术直接放到客户面前显然不是个聪明的决定，然而苹果的手机，指纹解锁的成功率则非常高，为什么？人家把这门技术吃透了，研究明白了，再拿出来效果就非常不错。

        最后，这个点比较高深，适合资深的产品，新人产品别看，浪费时间。对于未来市场的预判。大多数的产品经理只能够看到市场的现在，并且为了跟上脚步就已经使出了吃奶的劲了，要想提前预测市场，提前布局，这点超出了绝大多数产品经理的能力。当然资深的产品可以凭借丰富的经验和预感对未来进行一些预测，不过，这是一项非常具有风险的举动，成功了别墅靠海，失败了… 所以需要MVP啊！

        刚刚在上面提到了两个概念，需求池和需求的优先级，现在我们单独拎出来说一下。

        首先，我为什么要创立需求池？需求时远远不断的过来的，一般情况下很少出现需求做完的情况。而且需求是需要管理，如果不管理，很容易出现需求遗漏现象。又或者，有些需求是N久之前提的，经历过N手了到了你手上，你完全不知道这个需求是个什么东西，如果只是一个简单的标题和简单的描述，你根本无法操作。需求池让需求有了追溯的源头，起码你可以根据它去寻找这是哪个部门提出来的需求，到你接手的时候也方便操作。

        需求池的定义：产品经理用来管理需求的工具名称。需求一般有这些属性，序号，模块，需求描述，需求来源，需求类别，优先级，版本号等等。

        我先给大家举个例子好了，比如一个渔民在池子里打鱼，把网一撒，然后把大的鱼捞起来，再让小的鱼从网的缝隙中漏掉。这就是渔民打鱼的过程，跟产品经理从需求池里面选择需求一样。

        当我们收集到这些需求之后，对于那些暂时不做的需求，我们归档到需求池中，等我们有时间了，再去安排开发和上线。当然，在需求进入需求池之前，我们需要辨别下需求的真伪性。比如最常见的三类，不存在的需求，不合理的需求，非本质的需求。不存在的，比如这是产品经理或者运营人员空想出来的，实际情况下没有人会这么操作的，毕竟你不能代表客户。不合理的，比如别人有，但是这个功能跟我们的产品不匹配，或者我们的资源时间等其他要素不允许，或者逻辑有BUG。非本质，还是举汽车那个例子，用户要的并不是一匹块的马，要的是比马更快的一个产品，比如汽车。

        跟打鱼一样，我们从需求池里挑选需求不是随便挑选的，是有规则的挑选，根据需求的优先级来。

        大家都应该听说过四象限法则吧！我们通过重要和紧急两个维度对需求进行划分。

        如何界定需求是否重要，主要有以下两个标准，第一点，商业价值，说白了，就是这个功能做出来到底值多少钱。第二点，用户使用量是否足够大。

        界定需求是否紧急，主要有以下三点，第一点，是否能够抢得市场先机，别人没有你有！第二，能够解决用户突发状况的，用户的迫切度非常高。第三，生产上出现了紧急的BUG。

        所以，得到的结论是，重要且紧急的事情，立刻马上做。重要不紧急的事情安排计划做，不重要但是紧急的事情看情况而定，不重要且不紧急的事情放一放。从一个初级产品经理的角度出发，需求篇的东西基本上都讲完了，希望对大家有帮助。

        终于来到了最重要的《项目研发篇》，这一篇章的内容相对来说会非常的多，也会比较复杂，需要多一点的耐心。

        提到需求，我们首先也说到的是需求的四要素，分别是人物(用户)，场景(环境)，目标(痛点)，任务(解决方案)。

        举个简单的例子，人物，公司小白领，场景，写字楼，痛点，午餐不知道吃什么，解决方案，网上订外卖，想吃什么点什么。

        当大体的一个方案已经制定了，那么开始细化，比如，这边的核心部分就是网上订餐。第一步，先搭建一个网上订餐的平台，分为用户版和商家版。第二步，邀请一部分商家来平台开店，并且给出非常丰厚的补贴条件。第三步，大量发放广告，邀请客户下载平台，并且大量发放优惠券，鼓励用户在平台上下单，以此来解决三餐问题。

        产品经理就是这样将用户的需求转化为产品的功能，并解决用户的痛点。

        当一个产品收集了足够多需求的时候，就需要产品经理对产品进行一系列的规划了。那么，什么是产品规划呢？

        产品规划是指产品规划人员通过调查、研究，在了解市场，了解客户，了解对手，了解机会与风险以及市场和技术发展态势的基础上，根据公司自身的情况和发展方向，制定出可以把握市场的机会，满足消费者的产品的远景目标以及实施该远景目标的战略、战术的过程。

        产品规划的意义主要在于，制定一个明确清晰的目标，更有利于资源协调，团队的向心力执行力，相互协作调配，当然，这点主要是老板的要求，老板需要牢牢的掌控他的企业，让企业以他的思路去进行发展。

        我们把产品规划具体拆分一下，可以分为产品的愿景，产品定位，产品的目标三个方面。

        什么是产品愿景呢？就是企业长期发展的终极目标，企业的蓝图，说的通俗易懂点，就是一块饼，一块大大的饼。比如，阿里巴巴的愿景，成为全球最大的电子商务服务提供商，使命：让天下没有难做的生意。比如，头条的愿景：做全球创造与交流平台，使命：连接人与信息，促进创作也交流。

        什么是产品定位？

        产品定位是指确定某产品在消费者或者用户心中的形象和地位，即通过塑造产品或企业的鲜明个性或特色，梳理产品在市场上的形象，从而使市场上的目标用户了解和认识企业的产品。

        比如头条有句非常有名的话，信息创造价值。从这句话中我们可以得出，头条是一家为客户提供信息的公司。

        产品的定位是代表产品是什么的一条基准线，需要第一时间发现和提炼定位可做调整，变化以及扩充，但是主基调不变。比如，KEEP是一个做健身的app，那么他所有的功能都是围绕着线上做运动，当然，也可以线下做健身，三五好友大家一起健身，一起鼓励，相互督促，但是如果有一天KEEP去做线上卖货，那么这个产品就出问题了。

        产品和生命一样，都是存在一个周期的。

        第一个周期，开发期，在开发期，公司会进行大量的用户调研和数据分析，寻找市场上的痛点，并且针对这一痛点，公司提供解决方案，然后再提供最小可运行的产品，也就是我们俗称的MVP。接着我们需要找到种子用户或者天使用户，将我们的产品提供给他们，然后搜集反馈意见并迅速做出调整。

        第二个周期，成长期，如果开发期是一个产品从0到1，那么成长周期就是从1到10，10到100，在这个期间会面临更多的问题。

        问题一，用户！相对于天使用户来说，其他的普通用户并不是这么容易找到的，即便找到了，要转化他们，要让普通用户变成我们的忠实用户，这是一件非常困难的事情！

        问题二，产品硬件！作为一个开发者，在这方面最有发言权了，在同一时间内，做100件事情和做1万件事情完全是两个概念，随着用户的升级，我们的代码和硬件也必须得升级，最头疼的是，如果遇到之前的技术债务，要在短时间内解决，还要再提升产品的使用量级，这不是一件容易！

        问题三，管理！之前是一个小型的团队，十几个人或者几十一个人，当团队扩张了，做大了，会发展成几百个人，甚至几千几万人，那到那个时候，很多事情的难度会呈指数级上升。公司的流程变复杂了，人员结构变臃肿了，无休止的会，无休止的资源调配和纷争，都将成为你头疼的问题。

        第三个周期，稳定期！当产品已经上线很长一段时间了，用户也达到了一定的规模，团队也日渐稳定了，还保持着非常高的效率，新的问题也随之而来。人有个特性，就是喜新厌旧，昨天你是怎么样把用户从别人手中抢走的，那么今天，你同样面临的这个问题。新的公司会不断的出现，同样的问题市场上会有新的更优质的解决方案，这些新的公司会不断的来抢夺你手中的用户，怎么样留住之前的用户，怎么样让用户保持新鲜感，让公司保持活力和创新，这是个巨大的难题。

        其次，更好的运营用户，当你辛辛苦苦培养出了一大批用户，慢慢的准备变现的时候，又是个难题。就拿视频网站来说好了，本来视频网站是免费向大众提供视频的，最多我们看看广告么！现在随着广告的越来越多，广告的时间也越来越久，甚至连VIP都不再保险了，还有VIP专属广告！那么用户的忍耐值也逐渐趋于0，这种时候要继续留下客户，得费一番功夫的。

        第四个周期，衰退期！产品会成长，那么也会衰退，旧的产品衰退，新的产品上位，这是亘古不变的道理！其实产品人都不太愿意讨论这个，但是如果真的到了那个时候，市场上出现了一个可怕的竞争对手，用户大面积流失，公司内部也逐渐混乱，账面也越来越不好看了，投资人之间矛盾重重，那么基本可以宣布这家公司死刑了。

        如果真到了那种时候，希望公司能够对得起忠实的用户，为那些忠诚的，在最后时候依旧和公司站在一起的用户做好善后工作，该退款的退款，不要向某个共享单车一样，留下一个巨大坑让社会来替你擦屁股。要知道，这部分忠实的用户，很有可能是你下一个产品的种子用户，请善待他们。

        说了这么多的产品规划，那么介绍一下产品规划的主线吧！

        第一步，我们进行市场分析，竞品分析，产品数据分析，提炼出分析的依据，为后面的的需求做一个支撑。

        第二步，我们结合公司所拥有的能力，包括资金，人力，影响力等等，得出一个可行性的解决方案。

        第三步，按照需求先做出MVP然后根据市场反馈进行调整，版本迭代。

        作为一个产品经理，尤其是初级的产品经理，我们应该多关注行业动态，多看下产品的发展历程，多向那些能力强的产品问为什么，以一个主人翁的意识去思考，去工作。

        每一个产品都是产品人精细打磨，精心设计出来的产物，那么到底什么是产品设计呢？

        产品设计是指基于产略需要和用户需求，结合着自身产品定位，通过具体的设计，在互联网的产品迭代周期表达出来的过程。

        那么在产品的设计中，有哪些要素呢？

        下面我们来介绍下，产品设计中的五要素：

        首先是战略层，在做一个产品的时候，我们首先要定一个产品的目标，找到客户的需求和痛点，并且想办法解决它。比如最典型的饿了么和美团，这类外卖产品的出现，就是为了解决的客户吃饭便捷的问题。

        第二是范围层，主要是包括该产品有哪些功能，将核心需求进行一个整合。需要明确产的具体应该给用户提供哪些内容以及功能，这样方便将来把需求转变成需求文档。

        第三是结构层，在结构层中主要考虑两个问题，信息架构和交互设计。信息架构整个产品如何将自身的产品、内容、服务呈现给用户。而交互设计是指，用户在使用产品过程中和产品发生的信息传递、交流、反馈。比如，微信的架构就是：微信，通讯录，发现，我四大模块。在微信模块中又聊天记录，微信公众号，添加好友，添加公众号。通讯录中是所有添加的好友。发现中是朋友圈，视频号，扫一扫，摇一摇之类的。我的是个人的基本信息，还有一些设置。

        第四是框架层，框架就是具体到了UI设计了，比如产品的界面该怎么设计，导航条怎么设计，信息展示怎么设计。

        第五是表现层，表现层是充分的利用用户的感知，通过配色，排版，风格等将产品完完整整的呈现给用户，也是用户实实在在能够感受到的。

        以上是一个产品从0到1的一个过程，如果我们去分析别人家的产品，那么我们就需要倒着来，从外表开始逐步逐步推进到战略层。

        一个产品的制作，从来都离不开项目组全体人员的努力，那么什么项目管理？什么是项目的流程呢？

        项目管理是项目的管理者，在优先的资源约束下，运用系统的观点、方法和理论，对项目设计的全部工作进行有效的管理。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。

        接下来我们说一下项目的重中之重，项目研发的流程。作为一个从事多年开发的开发人员，对于项目组的事情可以说是最清楚的了。

        这就是项目研发的主要流程图：主要分为需求阶段，开发阶段，发布阶段三大块。而这是一个需求从0到1的过程。

        需求阶段：先是获取需求，获取需求的来源有很多，比如客户提出的需求，比如老板提出的需求，运营提出的需求，公司其他部门提出的需求。然后产品经理需要去设计需求，再由小组内的产品经理对这个需求进行讨论、内审。如果内审没有通过，那么会被打回去重新设计需求。如果内审通过了，那么会产品经理会叫上开发，测试，领导等相关人员开一个需求评审会。需求评审会对于一个项目组来说是至关重要的，这关系到一个项目是能够进入到下一个阶段还是被打回去重做，同样来到人也最多。如果在需求评审会中需求通过了，那么接下来需求会到UI人员手里进行设计和开发人员手里进行开发。

        开发阶段：这个阶段是所有阶段中最重要的阶段，甚至可以说，是整个项目中最重要最花时间的阶段。

        开发经理拿到需求后，会对需求进行一个初步的评估，然后根据每个开发人员的能力，时间分配需求，一般新人开发主要做增删改查之类的相对简单的需求，中级开发会接一些修改业务逻辑，新增流程等需求，高级开发改动项目核心的代码。

        当一个开发人员拿到需求后，如果是一家规范的公司，不会直接让他去开发，而且先做需求分析，出一个需求分析的文档，对于产品经理PRD文档中的需求和各个功能点进行拆分，统筹规划到底该如何进行开发，最后再对该需求的开发时间做出一个大致的评估。

        在需求分析完成后，开发人员再把需求分析文档提交给开发经理查看，当开发内部讨论通过后，开发人员才可以动手开发，如果需求分析被打回，那么该开发人员需要重新整理思路编写需求文档。

        当需求文档确定后，开发经理会给产品室或者产品部门一个反馈，然后再有产品部门向上进行反馈。根据以往的经验，反馈的时候别太老实，留个余地，比如开发人员自己评估，该需求开发时间为1个星期，那么开发经理往上汇报的时间往往为6-7天，产品经理则会继续增加1-2天再向上汇报，因为一个需求如果提前完成，那么没什么问题，如果延后了，领导要是追责下来，后果都懂的。

        开发评估完后就轮到测试了，测试人员在拿到产品经理的PRD文档后，会对文档里提到的需求进行拆解，对每个功能点进行分析，然后编写成一条一条的测试案例。测试案例要尽可能的全面，要包含需求文档中所提及的每个功能点，哪怕只是页面上一个很小的改动，在测试案例中也需要有体现。

        其次，测试案例还需要对之前原有的功能进行验证。比如和该需求有交集的流程有三个，分别是ABC流程，而每个流程都有10中可能性，本次需求只需要对B流程进行修改，那么B流程中的10种可能性都需要进行测试。而对于AC两个流程，每个流程中只需要测试2-3种可能即可，不需要全覆盖测试。

        在测试完成了测试案例之后，还需要再开个测试案例评审会。开发，测试，产品都需要到场，并对测试编写的测试案例进行评估，主要讨论有没有遗漏的点。如果有遗漏的点，那么需要马上做记录，等会议结束立刻将测试案例补充完成，且立刻将最新版的测试案例发送的群内，保证每个小组成员都能够第一时间得到最新版的文档。

        经验之谈！在测试评审会中，还有一种特殊的情况，当开发人员在开发的过程中修改过公共类的时候，一定要把涉及到该公共类的所有模块都说一下。比如该需求通过PRD文档是所看到涉及到的流程是ABC，而开发人员为了节约开发成本，修改了公共类，这个公共类还涉及到了H I J三个流程，但是从PRD文档中是看不出来这点的。所以，当开发人员在修改公共类的时候，一定要做个记录，将涉及到的其他可能有改动的流程都统计下来，在测试评审会上告诉测试。当测试人员接受到这个信息的时候，也需要立刻做出反馈，更新测试案例，并及时发布群里面。

        当开发人员将需求开发完毕后，需要产品经理进行验收，如果产品经理通过验收，那么可以提交到测试人员这边，由测试人员进行测试，如果产品经理这关都没有过，那么就会被打回去重新开发。

        测试人员可以说是整个产品的最后一关守门人，就好像是一辆汽车的刹车一样，如果刹车出了问题，那么这俩汽车大概率是不敢开了，就如同最近非常火的特斯拉事件一样。

        如果是一家正常的公司，测试一般分为三个阶段，分别是第一轮测试，第二轮测试和回归测试。

        测试的顺序是先测试主线功能，再测试支线功能，比如这个流程主要的功能是保存，那么要先确保输入的字段全部都保存进数据库中，并且字段的输入长度或输入类型提示要到位。比如一个备注的字段，只能输入100个中文字符，那么当输入底101个字的时候就无法显示并提醒客户。再比如，该输入框内只能输入数字的时候，那当用户输入英文字母就不能显示，这点同样需要提示给客户。

        特殊轮次，回归测试！

        当第一轮第二轮测试都完成之后，开发经理会提交申请进入到准生产环境(回归)进行测试，领导同意后，打版人员将代码打到回归环境上，然后通知测试人员。测试人员需要将之前第一轮第二轮的中的测试案例到准生产环境中再测试一遍，在这轮里面一般是不太会发送其他情况的。如果有情况，一般来说就是效率的问题，比如做个搜索，测试环境可能只有几千几万条数据，但是准生产环境可能有几十万甚至上百万条数据。如果sql效率低，超出了项目设置的响应时间，那么系统会有超时提醒。

        当回归测试都已经完成之后，大概率这个需求是没什么问题了，可以发布到生产环境中。当然测试完成之后同样还是会出现异常情况的，比如测试完成之后还有BUG存在，要么是暂时修改不了的BUG，要么是时间不够的BUG，那么这个时候就需要重新分析问题了。

        BUG一般分为大，中，小三种类型的BUG。如果如果本次测试完成后，只剩下小BUG，并且这些问题是可以通过调整去解决的，那么这些问题将由产品经理跟进，在之后的时间内逐个解决，上线还是不受影响的。

        如果是中等的BUG，那么就需要产品经理和开发人员共同讨论了，必要时拉上与之相关的领导开会讨论，权衡利弊，最终决定该版本是否按时上线还是暂停上线。一般情况下，如果不会出现重大问题，在客服和运维能够解决的情况下，大多数时候都是可以按时上线的，不过需要发送邮件通知大领导，并抄送相关人员知晓。

        如果是大型的BUG，会出现严重的问题，那么不用说，基本上是不会上线了。比如这个功能是转账的功能，但是有一定几率会出现扣费成功但是转账失败的情况，即便这种概率很低，但是这种情况是绝对不允许出现的。

        如果最后需求确定不能发布，同样需通知到各个领导，并且说明具体原因，并且给出对应的计划，什么时候能够修改好BUG，下个版本还是下下个版本再上线。当然最好是不出现这种情况，一旦出现这种情况，往往会伴随着一些惩罚，比如扣除工资，绩效等情况，严重的还会被开除处理。

        发布阶段：当开发和测试都完成之后，并且也开过会确定该需求能正常上线了。那么还有以下工作需要完成。

产品经理需要提前更新好用户手册，并且就新的功能以及可能发生的情况对客服进行培训，以此来保证客服能够顺利的开展接下来的工作，并且还需要配合验证渠道包。

        运营方面需要为发布渠道做准备，打包上传图片已经相关素材，之前准备好的推广计划也可以展开了。

        开发人员需要打渠道包，并发送给相关的产品人员和运营人员。

        测试人员需要在最后时刻验证下渠道包是否能够正常运作。

        当所有工作都完成之后，选定合适的发布时间进行发布。发布的时间除了修复紧急BUG之外一般选择的是周二到周四，不会选择周末，周一或者周五。因为周末大家一般是出去玩的，比较少去玩手机，或者要玩就希望是一家更新好了的，如果周末我满怀期待的打开手机，第一时间你告诉我的是更新，而不是呈现内容，那么客户往往会比较失望。其次，周一一般是所有时间中最忙的一天，不太有人愿意在更新软件上浪费时间。周五更新如果出问题怎么办？叫团队的小伙伴周末过来加班么？加班费也是个问题！所以，发布的时间大概率是周二到周四之间。具体发布的时间段一般是选择用户最少的时候更新，这样对整体的影响会最小，比如晚上11点以后或者凌晨2-3点，再极端一点的，凌晨4-5点都有。

        发布完成后，需要发送上线邮件，主要内容包括上线的版本，日期，上线的功能，感谢组员和小伙伴们的付出，并告知后期的跟进计划，发送大领导，并且抄送相关的部门经理。发邮件也是一门技术活，首先要告知领导发布的相关信息，其次要带上所有付出的小伙伴，毕竟大家付出了这么多，都想在领导面前露个脸，这两点尤其重要。

        当项目上线一周或一个月后，有些公司会开项目复盘会，统计下线上数据的变化，版本的覆盖率，收集用户的反馈，并且对整个项目做一个回顾，总结优点，改进缺点。开完会后，需要把结果总结向领导汇报，毕竟折腾了这么久了，员工往往会比较关注过程，关注我付出多少，但是领导不一样，他关心的是我花了多少钱，得到了什么样的效果，领导也需要安全感。

        如果该项目上线，数据不错，那当然最好，年底加薪升职也有底气了，如果数据不怎么好，也不要气馁，团队需要相互鼓励，相互帮助，一起走出困境，走向美好。

        一个版本的结束是另一个版本的开始！项目是需要有多个版本迭代去推进的，当我们完成一个版本之后，新的版本也随之而来，没有人可以一次性直接把一个项目做到完美。比如，上个版本的BUG或者优化，需要在新的版本中体现，上个版本上线后，客户又提出了一些新的问题或新的需求，也需要迭代到新的版本中去，再比如，老板，客户，公司其他部门的同事提出的另外的需求，也是一个新的版本迭代。

        项目迭代的好处有很多：

        1. 节约成本，每次做一个部分，然后交付给客户，如果一次性做很多，那可能要很久才能交付，并且也很容易失去客户。

        2. 把握方向，除了向乔老爷子这种神级产品经理可以提前预知，绝大多数的产品经理只能做到跟随大流，市场是怎么样的情况，我们就跟随着市场做，一个版本做一部分更有以利于方向的把控。

        3 .资源的合理分配，开发人员是有限的，测试人员是有限的，运营的资金更加是有限的，公司需要把有限的资源最大化的利用，所以每次只做最关键的部分，把力量集中到最需要解决问题的地方。

        说了那么多版本迭代，那么我们先来看一张图吧。

简单用文字来表示一下：

需求1预审–> 需求1评审–> 需求1UI  –>需求1开发–> 需求1测试–> 需求1回归

                                        需求2预审–> 需求2评审–> 需求2UI –>

        这就是版本迭代，当一个需求进入尾声之后，另一个新的需求马上接上了，将团队中每个成员的利用率发挥到最大程度，这就是版本迭代的目的。

        作为基础的产品经理，只要把需求设计出来即可，但是作为一个优秀的产品经理，还需要考虑一个问题，交互！

        先看一副漫画，漫画是作者是胡痴儿：

        这幅漫画看上去有点凌乱，但是稍微仔细一看，其实内容还是非常明确的。我们生活在一个信息爆炸的社会，每天都会有无数的信息等待着你的处理，如果一天天去看，太麻烦，而且效率非常低。这个时候，有一个工具替你去筛选信息，通过信息架构层和界面设计层，把对你有用有价值的信息呈现到你面前，那么这样是不是比无规则无目的的去阅读信息要高效的多呢？

        那么什么是交互设计呢？

        交互设计协会（IxDA）的定义如下：

        “交互设计定义了交互系统的结构和行为，交互设计师致力于在人们和他们使用的产品和服务之间建立有意义的关系，从计算机到移动设备再到应用等。交互设计的实践范围与世界的发展同步。”

        从第一个屏幕被设计的那天起，交互设计就诞生了， 从按钮、链接到表单字段都是交互设计的一部分。 在过去的几十年中，出版了许多书籍从各方面来解释交互设计，并探索它与体验设计交织重叠的方式。

        是不是感觉没听明白？说人话，交互设计就是处理在现实生活中，人与外界之间的操作连锁反应，比如现在的电子产品，手机，电脑，VR眼镜等，都运用到了交互设计。

        那么我们是如何进行交互设计的呢？

        1. 参考同类产品，找出同类产品的优缺点。

        2. 把自己的产品和同类产品做对比，分析出二者的差异性。

        3. 整理完毕后，出一版初稿。

        4. 叫上相关的领导和设计师，开个会，大家一起讨论。

        5. 让一些不了解该产品的人过来体验下，然后根据体验情况记录问题。

        6. 根据记录及时修改问题。

        7. 重复以上步骤。

        8. 完成。

        就交互设计这点，没办法，只能一点一点去磨，切记，不要用自己的行为习惯去替代客户，你的想法是你的，客户的想法是客户的，一定要进行验证。举个例子，就好比儿童产品，你一看会觉得这些设计真的好幼稚啊，要我的话，肯定不会买，但是对于儿童来说，这些设计风格就是好的，他们就是喜欢。

        在交互设计当中我们如何判断好坏呢？

        1. 看是否简洁，突出重点。

        2. 看用户是否能快速做到自己想要做的事情。

        3. 产品是否好用，易用。

        4. 对于一个新手，上手速度是否够快。

        交互设计的国际标准将交互设计分解为五个原则：

        易学性：新用户能多容易学会浏览界面？

        可理解性：用户如何理解他们所看到的？

        可操作性：用户在界面中有多少控制权？

        吸引力：界面的视觉吸引力如何？

        可用性合规性：界面是否遵循标准？

        交互设计有开始，就有结束，任何一个好的交互设计都是有闭环的。一般只设计一种场景，只为了一种功能，只为了完成一件事情。比如上传文件，设定闹钟，修改密码等等。

        交互设计的闭环体验主要由4方面构成：

        触发控件：交互闭环的起始点

        设计规则：交互闭环所遵循的交互方式

        信息反馈：用户与产品的互动过程

        关闭（循环）模式：交互闭环过程的结束（循环）模式

        触发控件是交互的最初步骤，这个控件必须要让客户在使用的情景下能够认得出这是可交互的控件，比如，这个按钮是可以点的，或者不可以点，这里有个条是可以拖动的，或者不能拖动。并且在触发控件的时候，触发的动作是相同，便于用户多次使用。触发完成后，要有数据能够展示出来，比如声音控制条，现在的声音数值是50，向右拖动后变成了70，向左拖动后变成了40。

        PC端和移动端也不一样，PC端主要是鼠标操作，鼠标有单击，双击，悬停等动作，不可点击一般设置为灰色。移动端一般是手指点击，有焦点状态，按下状态，选中取消状态，不可点击状态。

        在交互过程中设计信息反馈目的是帮助用户理解交互的规则。 如果用户按下一个按钮，至少会有两件事发生：按钮被按下了以及按钮被按下后导致什么结果。

        比如转账，当我们输入转账的对象和转出的金额，转出的银行卡后，点击转账按钮，银行APP会提示转账成功，不要重复转账，到账时间以对方行为准等字样。

        当一个交互完毕时，需要告知用户该流程已经结束了。比如在电商平台下单，当货物已经送到后，客户觉得货物没问题会点击签收，并把钱打给商家，那么这个交易就算是完成了。

        大一点的公司一般都有专业的交互设计师去画原型图，小的公司或许没有专业的交互设计师，但是不管有没有，作为产品经理，我们都必须懂交互设计，同样也必须得会画原型图。

        画原型图的工具有很多，除非公司明确规定了，一般来说是不限工具的，Axure，墨刀，sketch，PS都行，但是，手绘除外，这是个底线问题，我们可以自己先画个手绘图看个大致的样子，然后再出原型图给同事看，千万不能直接出个手绘图，这样太不专业了。

        其次，在换原型图的时候，我们要把同一功能、同一逻辑的交互界面放在一个大的页面中，这样方便整体观看。每一层逻辑都需要有简单的文字描述，不需要大段的文字。每一页面都需要命名，命名规则一般是功能或者某某页面。

        最后，画流程图的目的，主要是为了拆解需求，功能分类，明确层次。通过原型图，我们可以将需求的每个部分都拆解开来，逐个分析，逐个开发，能够让团队中的每个小伙伴都清晰的了解到产品经理的想法和思路，也便于出来问题后进行修改。

        当一个项目完成了之后，对于开发人员而言，这个项目基本就结束了，但是对于项目本身而言，它才刚刚开始。下面进入最后的篇章，《运营篇》

        有一句话相信大家应该都听到过吧，产品负责生孩子，运营负责养样子。光是产品生的好没用，后续还得养的好，才能发挥产品最大的价值，才能不辜负前中期产品团队所有小伙伴的辛勤劳动。

        作为一个技术出生的，相信很多小伙伴在一开始跟我有相同的想法，运营么，干啥啥不行，BB第一名，上来就说，给我做个图，我要参加一个活动；给我开发一个新功能，我干嘛干嘛的，说话还拽的跟个250似的。打心眼里，技术人员是看不上运营的。

        有很长一段时间我都是这个想法，直到后面我看到了一位经济学的老师给我讲述了一个例子，这才改变了我之前的看法，我才明白之前的我，太浅薄了。

        只要是研究过营销的人，肯定都知道营销界的巅峰之作，钻石！

        一提到钻石，大家会想到什么？一句最著名的slogan，钻石恒久远，一颗永流传。

        首先，钻石本身毫无价值，就是一块碳，它的价值全部都是营销赋予的。其次，钻石的产量非常巨大，40年前，钻石总量就有5亿克拉，而当时的年产量从来没超过1000W克拉，据说以现在钻石的总量，如果平均分一下的话，每人都能够分到20克拉，那么为什么钻石还能卖这么高的价格呢？

        第一步，制造稀缺。钻石商人限量供应钻石，每次只卖几克拉，其他货在仓库里屯着，当然只有这一步是远远不够的。

        第二步，绑定意义，钻戒 = 爱情！

        结婚要送礼有很多可以送啊，珍珠，翡翠，玛瑙，黄金，稀有金属等等，但是只有钻石才等于爱情！只有钻石才最纯净，最永恒，最符合爱情！它极度精准的切入到了一个细分的刚需，并且将两者牢牢的绑定在一起！

        那么问题来了，你为什么会相信钻石商人的话呢？你又是从什么时候开始相信这句话的呢？从一开始，钻石商就在不停的给你灌输这个概念：钻石 = 爱情！

        几乎所有的商场，报刊，杂志上，只要提到钻石就会提到爱情。所有的婚礼都会用的钻石。尤其是大明星求婚，送他妻子的钻戒一定会告诉你克拉数。A明星9克拉，B明星10克拉，C明星12克拉，收到大钻戒后，女明星往往都感动的落泪了！它不仅让你相信钻石等于爱情，还让你相信钻石的大小等于爱情的分量！

        说到这里，肯定有人说，就你聪明？其他的都是白痴么？就没人看透这个营销策略么？当然有啊，肯定有男生看透了啊，买钻戒就是交智商税，就是白痴行为！但是这个时候新娘只需要一句话，那么你愿意为我当一次白痴么？那么，你会怎么说？

        看透了就能逃脱么？不能！因为这由不得你啊！

        你以为这就结束了？当然没有，还有第三步，切断渠道。比如，我买了个宝石，项链，耳环，手镯，包包，都可以通过折价的方式去二手市场是脱手，但是钻石不行，因为钻石一旦开辟了二手市场，钻石的价格一定会崩盘。试想一下，以后我们结婚大家都租一个钻戒，哪怕一天花1000块钱，会导致什么结果？后面的钻石几乎都卖不出去了。所以，钻石商人会想办法让你把钻石一直捏在手里，永远都不要出手，因为这样，他才能够源源不断的赚新婚夫妻的钱。

        那么，我再把刚刚的那句slogan重新说一下，钻石恒久远，一颗永流传。

        永流传，这三个字很厉害，钻石你要紧紧的捏在手里，这样你们的爱情和婚姻才能永恒。永远永远别想着去卖！才是你们最美好的爱情，单单只属于你们两个人的！

        试想一下，求婚，你用别人用过的钻戒，你好意思么？再试想一下，为了钱，你把独独属于你们两个人的爱情给卖了，你好意思么？卖钻戒 = 离婚，这才是核心！没买钻戒的，去商店买新的钻戒，买了钻戒的，紧紧捏手里，不许去二手市场上卖！

        总结一下，第一步，限量。第二步，绑定爱情。第三步，切断流通渠道。最后把这个事情对所有人重复1000遍，如果不够再重复10000遍，让所有的人都知道这件事，认可这件事，并愿意为此买单。

        知道，认可，买单！三部曲，买单是最终的目标！

        例子讲完了，那么现在大家应该知道运营的重要性了吧！

        那么再来说说运营一般都是干些什么事情的。从大的角度来说，运营的工作分为两块，一块是内容建设，一块是用户维护。

        说的再细一点，数据统计分析，收集客户的意见，集市反馈给产品经理和技术人员，进行用户调研，挖掘用户需求，分析竞品分析行业，及时调整运营策略，等等。

        那么运营的工作逻辑是什么？

        第一，是场景，客户在什么样的情况下才会使用我这款产品，比如我是个定外卖的产品，那么产品的使用的高峰期一般出现在三餐的时候，尤其是中餐和晚餐，当然偶尔也会有人点个下午茶什么的。要了解客户使用的核心需求，有哪些人需要，什么时候需要。

        第二，解决途径。还是用外卖来举例，先搭建一个平台吸引商家来平台上开设店铺，吸引用户来我平台下单购买食物，然后再招聘外卖骑手去送餐。

        第三，增加成交的概率。依旧用外卖举例子，比如我楼下有一家面店，今天中午我打算去吃个面，如果我直接跑下去吃，我需要付出的是买面的钱15，等待的时间20分钟，楼梯跑上跑下一共两次20分钟，经济成本+时间成本大约是这些。但是如果我去某外卖平台上下单呢？我可以提前下单啊，这样等待的时间可以省略，跑楼梯两趟的时间也可以省略尤其是中餐期间，电梯太忙了，我根本就挤不上。那么剩下的就价格的问题了，假设去店里是15块钱，在外卖平台上是30块钱，那么我大概率还是会去楼下，如果外卖平台上是20，外送费是2块钱，然后平台再送我一个满20-5的优惠券呢？那么我大概率会在平台上下单了吧~

        第四，留存。当客户进入到我们的平台，成为我们的用户之后，他能够停留多久呢？一个月？半年？还是一年？从运营的角度来说，当然是希望他永远留下来啊。这里运营的惯用手段是会员，特价，猜你喜欢等等。

        会员，这个很好理解，这次我用视频网站举例子，我要看个电视剧，不开会员，80-90秒的广告，开个会员无需等待，并且由于我在这个视频网站开了会员，一般来说不太会去其他视频网站看了。用会员的方式去绑定用户。

        特价，这个比较通用的是电商平台，网上大多数的价格是100元，但是你来我这边80块钱就可以购买，多出来的20块钱，我们平台自己补贴，你网购不就是图个方便+便宜么？并且一旦我们平台有了优惠信息，我第一时间发短信通知你，如果你刚刚好要购买，是不是就能够直接来我这边下单了呢？

        猜你喜欢，这个是属于技术类的范畴。比如你在某个电商平台搜索了电脑后，过一个小时打开，首页给你推荐的，80%都会是电脑的信息或者电脑的配件，用大数据的算法推测出当前情况下你想要买的产品，并且以最快的方式展示在你面前，仿佛再说，这就是你想要的，赶紧下手吧，别再犹豫了 ~

        第五，裂变。一个产品有100个用户，够么？不够，1000个呢？不够，10000个呢？依旧不够？那么要多少个才够？答案是，多少个都不够。产品要想拉新一般的手段是去某个渠道砸钱，但是砸钱的成本太高了，而且转化率还不一定高，那么还有其他方法么？

        来来来，兄弟，帮我砍一刀！最成功的裂变案例，也是最恶心的裂变案例PDD！产品本身不去拉新，他让使用产品的用户去帮他拉新。一个陌生人跟你说什么什么好用，你信么？大概率不信吧！如果是你朋友呢？最起码你会听一下，会知道这个产品，对吧，这样效果就会比直接去渠道砸钱要好很多。

        裂变的核心是用户的认同和利益的驱动，只要同时做好这两个点，用户自然而然的会帮我们去拉新。

        第六，客单价。这个有点难，一家企业要想发展必须要盈利，一个客户使用你的产品一部分是因为你的产品好用，一部分是因为在这个档位的服务内，你们公司是最便宜的，一边客户想要省更多的钱，一边公司想要赚更多的钱，这两者乍一看是矛盾的，但是依旧有解决方法。

        最早期的时候商家一般是使用折扣券的，比如，全场8折之类的，但是后面发现并没有太好的效果，直到一个角满减劵的出现。比如你买了85块钱的东西，但是商场告诉你，满100-10块，所以，你再买15块钱的商品，就能够获得-10块的优惠了，等于后面花5块钱买15块钱的商品，你心动了么？大多数人都会吧，这样的好处有很多，提升了客单价，增加了商品的流动性，还会把一些本来卖不动的商品都处理掉，消费者也很开心，一举多得。

        第二件半价，从数学的角度上来说，第二件半价等于7.5折，但是区别在于7.5折商家只卖出了一件商品，第二件半价，商家卖出了两件商品 ~

        差异化产品，比如就拿宝马来举例子好了：

        3系

        5系

        7系

        由这种差异化所带来的的优越感和满足感可不是这点钱就能够满足的了！

        第七，用户体验感。这个在上面产品篇章中讲到了，一个是产品的基础功能，一个是产品的期望功能，一个是产品的惊喜功能，给客户带来的惊喜多，用户体验感就好，用户使用越方便，用户体验感就好。参考IOS系统。

        第八，激励规则。比如年底了，我在某个平台有1000积分，我可以兑换1000积分的产品，我同事有10000积分，他能够兑换10000积分的产品，他兑换的就比我兑换的要更多，要更好。那么在潜意识里，就形成了一种竞争，如果我嫉妒了，那么久促成了我在下一年里，会更多的在该平台上消费。以此来兑换更多的积分。

        其实，作为一个技术人员的我，到现在为止只有在做设计的时候才接触过一些运营人员，其他时候并没有太多的接触运营，对于运营中都很多门道也不是很懂，对于运营我就说这么多，如果上面我有说的不对的，希望大家指正。

        说到这里，我个人的这片产品经理入门的文章差不多也要接近尾声了。从入IT行业开始到现在，我已经有快10年了，在最后我想分享一些我的项目经验给大家。

        第一条，一个项目不是个人的功劳，是团队大家的功劳，如果这个版本效果好有功，领导奖励的时候，有人或者有小部分人每次都跳出来抢功。但是如果这个版本效果不好有过，有些人就甩的干干净净，尤其是团队中的领导，那么这个团队100%会崩溃！100%无一例外！

        第二条，方案是人出的，只要是人想出来的，就会有漏洞，就会有缺陷，尤其是一个方案是团队中大部分人都看过的，当这个方案出了问题，那么团队中的大部分人都有责任，千万别随便找个人背锅。在我所经历的开发生涯中，很多时候这种锅就是开发来背，这是不对的！代码出错100%是开发的锅，如果是思路上有缺陷，或者某个业务场景没考虑到，这种事情全部让开发来背锅是不公平的，也是不合理的。

        第三条，沟通，不管是产品和开发沟通，还是开发和测试沟通，还是领导和下属沟通，最好的沟通是大家都在一个信息对称的情况下进行，双方都有思考的空间和时间，切记相互甩锅，有困难提出来，如果在会议上无法解决，可以先记录下来，过两天再开会讨论。

        最后的最后，我想用《启示录》上的一句话结尾，产品团队不要像雇佣兵那样，要想传教士，每个人都投入到项目中去，每个人都是项目的主人。