产品从0到1的阶段非常重要，尤其随着用户调研+MVP上线后带来反馈逐步增多，常规产品经理很容易失焦，进入到“竞品有，我没有，因此我要有”的癫狂状态这样的状况大概持续3-6个月就会发现，无论自己再怎么疯狂加功能，对最终的漏斗转化率效果都不大，就要花时间关注增长的问题了 和增长相关的模型和理论有很多，有AARRR，有RACE，但本质都是回归到强化“网络效应”。因此在探索了漏斗转化率的基础和边界后，很多常规产品经理就会被分去做偏运营类的工作，也就是我们耳熟能详地“搞活动"。这也是为什么做了三年之后的产品难免会觉得自己的角色开始模糊，仿佛跟运营、市场都有点关系 总结一下：分析用户路径 -> 提出产品假设-> 优化链路 / 包装玩法 ->看对漏斗和大盘的收益 -> 评估是否达到全量标准（定性/定量），这大概就是大部分常规产品经理的日常。

什么是交易平台？交易平台是指连接某类业务的供应方和需求方，并促成双方进行交易的产品。交易平台是一个连接器，也是一个交易场所。供应方（下文简称“卖方”）通过交易平台，出让原本属于自己的商品，或为对方提供某种服务（下文统称为“商品”）；需求方（下文简称“买方”）到交易平台上，找到合适的商品并购买。张三有台闲置的平板，想换取现金，于是他把闲置平板放到了闲鱼。李四想用较低的价格购买一台二手平板，在闲鱼上购买了这台平板。闲鱼就是一个二手物品交易平台。交易双方的痛点2.1信息不对称所谓信息不对称，是指在市场交易中，双方对有关信息的了解程度有差异。买方不知道哪里可以买到自己想要的商品，也很难准确了解不同商品的质量及价格。卖方清楚自己商品的质量，但他无法充分掌握买方的需求、买方的购买意愿、竞争对手的情况。信息不对称可能直接导致交易双方错失交易机会，交易无法达成。没有闲鱼这类二手交易平台的年代，闲置物品很难转卖出去。卖方不知道哪里可以转卖闲置物品，也不知道如何定价会比较合理。买方不知道哪里可以买到价格实惠且质量靠谱的闲置物品。最终，卖方可能会选择送人，或低价贱卖。买方可能要花更高的价格购买全新商品。2.2交易成本高交易过程中，交易双方都会遇到阻力。找不到合适的商品、对比多个商品麻烦、难以有效验证商品质量、价格协商麻烦、付款过程繁琐、运输成本高、售后成本高···为了达成一笔交易，交易双方必须克服交易阻力，为此付出的全部时间和货币成本，就是交易成本。在闲鱼平台，一台二手平板的交易，双方有如下行为：买方在闲鱼上搜索闲置平板、对多个卖方提供的平板进行对比、同卖方讨价还价、选择其中一台平板、填写收货信息、完成订单支付；卖方在闲鱼平台查询同款闲置平板的市场价格、发布闲置平板的图文信息、回复买方的咨询、给买方邮寄。在这个过程中，双方付出的全部时间，就是交易成本。而最后的成交价1000元，是李四为了平板支付的购买成本。交易成本的存在，会降低卖方在市场中的竞争力，提高买方需要付出的整体成本，导致难以达成。

7、变更的流程7.1 收集对于变更的需求，需求变更方需要通过一定的流程提交给产品经理，不论是邮件还是流程协作工具confluence这种，亦或是自己做的企业效能工具，通过系统的好处就是做到有迹可循，责任到人，事后也方便对需求变更进行统计，以分析变化的原因，降低变化。7.2 评估将变更的需求提交给变更控制委员会评审，变更委员会可根据上面的拒绝OR接受需求变更原则进行评估，这个评估的过程就是需求分析的过程，也是头脑风暴的过程。需求变更委员会最好由项目所涉及的多方人员共同组成，应该包括产品经理、项目经理、用户方和开发决策负责人等。7.3 变更需求如果确认变更，那就走变更的流程，变更的需求再开一次评审会，给项目团队的成员详细讲解一下。 7.4 修改评审过后的需求，产品经理要修改对应的文档，开发计划的排期也需要重新排。7.5 归档妥善保存变更的相关文档，无论是以后自行查阅还是给到接盘者，让接盘者接手，都很有意义。 对于变更的需求，产品经理对上要反馈现状、明确目标、提出解决方案，对下要组织变更评估，明确目标，体现团队工作成绩。

4、需求变更的影响需求变更首先要评估一下需求影响的范围，然后评估一下对现有进度的影响，对项目交付质量的影响，是否需要增加成本（比如人力资源成本、服务器成本等），以及需求变更带来的潜在风险点。 5、预防需求变更与其发生问题想办法，不如在问题发生之前去预防。所以在考虑需求变更之前，我们先想想如何预防需求变更，产品经理提的需求，设计师设计的ui设计稿一定要经过团队内部的充分评审，让大家充分发表意见，做到需求理解一致，并最后邮件确认，也许你一个人无法发现问题，但是大家一起头脑风暴，就容易发现问题。针对技术实现方案，技术团队的同事也要充分沟通，反复研讨，务必把一切能想到的问题提前想到。对于外部的需求一定要充分沟通，能不变就不。同时保持对业务环境的敏感，知道业务同事的习性，提前做好应对措施。针对业务同时可能变更的需求，提早分析，做好预案。 6、接受OR 拒绝需求变更？针对变更的需求，我们是接受还是拒绝呢？在说拒绝还是接受之前，我们先说一下PM的态度问题，针对变更的需求，PM一定要保持积极的态度，不能消极对抗对于变更的需求一概拒绝，在高度重视的同时，要有全局意识，要能看到变化给每个模块带来的影响，以及给整个全局带来的影响。那我们判断是否接受变更可遵循以下三个原则：1、变更对项目是否有利，如果无利，我们肯定拒绝。2、如果变更对项目有利，那我们要接着看，变更需要投入的成本和变更带来的利益，也就是看投入产出比（ROI）如何，然后根据投入产出比判断是否值得更改。3、如果值得更改，那接着看是否紧急，如果变更带来的收益不是我们目前急需的，也可以往后放。只要那些重要且紧急的变更需求，我们才考虑插入。

2、需求变更来源需求的变更来源分为两个部分，一个是内部来源，一个是外部来源。2.1 内部来源内部来源又分为两个部分，一个是产品经理变更需求，一个是技术的小伙伴变更需求。产品经理自己变更需求，主要原因分为以下这些：1、需求没有考虑清楚，逻辑有遗漏2、产品设计变更3、临时插入需求，比如交互要调整、要加字段等。 技术小伙伴变更需求，主要原因分为以下这些：1、技术方案变更2、人员的变更 说完内部来源，我们再来看看需求变更的外部来源有哪些：2.2 外部来源外部来源有用户、公司的同事、领导、以及市场政策等1、用户。比如产品的目标用户的需求变了2、公司的运营、市场、业务等部门变更需求。3、公司的高层（分为本公司的领导、外部门的领导、以及公司的大boss，这里顺便说一下，职场一定要和领导接近，那些决定你能升官的领导才是你真的领导）。4、市场政策变化（比如政府政策的调整、潮流趋势、以及突发的黑天鹅事件）。3、需求变更的目的 所有的变更目的最终一定是能够更好的实现目标，不是追责，也不是扯皮。产品经理变更需求是为了贴近产品设计；开发变更需求是为了技术方案更加合理化，便于实现；用户变更需求是为了贴近自身需求；公司高层以最小的代价实现目标；市场人员变更需求是为了适应市场变化；政策变化是为了产品更加合法化。

面试题：作为产品经理如何应对需求变更？产品经理在项目中经常会遇到需求变更的情况，哪怕你计划做的再详细，也免不了受到一些需求变更的困扰，变化不可怕，（毕竟这个世界本身就变化的很快），关键是要建立起来应对变化的机制，在发生变化的时候，按照预先制定的机制来管理变更。通常对发生的变更需要识别是否在既定的项目范围以内，如果在项目范围之内，就需要评估变更造成的影响，以及应对措施，及时通知受到影响的各方，如果在项目范围外，就需要商务人员主动和外部沟通，看是否需要增加费用和时间，还是放弃变更。1、需求变更原因1.1 需求定义不明确如果产品经理自己对需求都没了解清楚，就让技术同事进行开发，最后开发出来的东西只能是回炉重造，1.2 需求理解有歧义一般在项目评审的时候，需要让技术的小伙伴主动的说一下他们理解的需求，这种做到彼此信息的理解没有偏差。1.3 业务需求变更产品经理要不断给业务灌输一个意识，一定要明确需求，不能反复变更，如果逼不得已变更，外包的话，就要向业务方要时间要钱，自己公司内部的业务方需求，就需要给团队要时间，让业务方知道，经常变更需求该来的弊端，以此掣肘业务方的需求变更。1.4 项目周期过长这也是为什么推荐敏捷开发的原因之一，项目周期过长，容易发生变化，比如技术人员变动，导致的人力短缺，市场环境发生变化，导致业务需求发生变化。

OKR和KPI之间的区别1、OKR包含了KPIOKR联系了目标与现实。他帮助你打破现状，带你进入全新未知的领域。如果你有一个远大的梦想——一个鼓舞人心的终极目标——为了你的公司，你需要制定OKR。另一方面，KPI为你做的工作提供了一个可考量的指标，它度量已经存在的工作或活动。通常，改进的KPI是创建OKR的起点，它将成为目标的关键结果。因此，OKR包含了KPI。2、KPI强调结果，OKR强调方向KPI强调结果，但如果过于看重KPI，有可能造成反效果，比如上面举的例子，如果限定客服必须在指定时间内解答完用户问题，那客服有可能在快到达的时间节点，主动挂断电话，反而造成用户体验不好，这就是唯KPI论的后果。OKR更强调方向，虽然也有KR作为考核标准，但更强调你关键结果是否为目标服务，通过okr我们可以发现，客服的例子中KPI并没有达到优化用户体验的目标。OKR与KPI如何配合使用由于其互补的范围，OKR和KPI是一个很好的搭档。下面我以一个例子来说明一下：假设您想衡量客服团队工作业绩。您可以创建一个KPI，比如客服的平均回复时间。你可以把平均回复时间是30分钟或者更少作为监控指标。只要是30分钟以内就算达标。如果当前的平均回复时间是48分钟，那你就需要制定一个目标来提升用户体验。但你怎么知道他们是否改进了?如果平均回复时间从48分钟降到30分钟就算改进了。这就是关键结果。你会做些什么来实现这一目标?你可以雇一个客服经理，让他来管理客服团队，简化冗长的服务流程。

如何制定OKR设定目标目标不要太多，建议1-3个，目标越聚焦，实现起来越有方向。同时目标制定要遵循以下原则：明确性：目标必须是明确的，不能是模棱两可或含糊不清的，比如“优化客户服务意识”就不是一个明确的目标，要能够量化。鼓舞人心的：这种目标可以激励你和你的团队激情投入。可实现：虽然目标应该是远大的，但它必须是可以实现的。一个可以实现的目标是一个巨大的动力，但是那些无法实现的目标会产生相反的效果。推动企业实现其战略：团队中的每个人都应该能够解释他们正在工作的okr（或okrs）是如何在帮助企业实现其总体战略方面发挥作用的。可控：即使你或你的团队正在为更高的战略目标而努力，OKR仍然必须专注于团队可控范围内的事情。时限性：没有时间限制，目标的制定就失去了意义，在OKR实施中，时限性体现在周期的设定上。设定关键结果：关键成果（kr）用于衡量实现目标的进展情况。它们是定量的，通常以百分比表示。您设定的关键结果应该遵循以下原则：高远：如果你设定了一个目标，将销售额提高5%，而且你觉得这是可以轻松实现的，那么你就要为自己设定一个10%的目标。每个季度，你可以检查你的kr，看看你做得怎么样，同时挑战自己达到目标。通过设定一个高远目标，你的实际销售额会比原来的目标高出2%。如果每次你的目标都轻松完成，说明你目标设定的还不够。可衡量：kr需要具体和可测量。雅虎首席执行官玛丽莎•梅耶尔指出：“除非有数字，否则这不是关键结果。”可查看进展：关键结果需要能够在整个季度得到衡量。看到进步是一个巨大的动力，激励着团队去达到他们的目的。如果你在季度末才能看到结果，你就会失去一个激励团队的手段。推动正确的行为：也许你制定的KR是好意，但是却产生了反结果。我看过这样的一个例子：有家公司给客服人员制定的KR是在六分钟内处理好客户问题，当电话时长接近6分钟时，客服人员会主动挂断电话，这样就可以重新开始计时了。在设定kr时，花点时间为团队考虑如何避免负面影响，并在存在风险的情况下，确保有减少风险的辅助krs。在上面的例子中，他们在呼叫处理时效考核的同时增加一个客户满意度考核——如果团队成员知道这会对目标相关的其他krs产生相反的影响，那么他们就不会那么肆无忌惮了。

什么是OKR？O是Objectives，KR是Key Results，OKR就是Objectives and Key Results，即目标与关键结果法。是一套明确和跟踪目标及其完成情况的管理工具和方法，被谷歌成功使用，现在逐渐也被很多国内的公司采用。O（Objectives）：目标，它问我们想做什么？K（Key Results）：关键结果。那些关键结果证明你实现了目标，通过关键结果来衡量我们实现目标的情况。目标是定性陈述，关键结果（kr）是定量的。设计KR最具挑战的部分是如何把目标中定性的部分翻译为定量的数字化的表示。一个来自于今日头条的OKR示例：O：今日头条粉丝数量超过10万人。KR1：每日原创文章规划100个指定选题；KR2：头条问答高质量完成所有邀请回答；KR3：每周完成5个小视频及其他头条视频的制作，多渠道传播；OKR的来源OKR是由几种不同的目标设定方法演变而来的目标管理（mbo）是彼得德鲁克开发的一个系统。mbo是通过制定管理层和员工双方一致同意的目标来提高公司的效率。德鲁克认为，确保员工在制定目标方面的发言权，可以促使员工更好的工作。因为毕竟目标是员工自己参与制定和认可的。1981年，George T. Doran提出了smart模型，通过smart模型来设定目标，这一简洁的模型迅速的得到了广泛的采用，这种注重成果的方法就是关键成果（KR）的来源。

原型画到什么阶段？01.想法阶段：在产品需求的初始阶段，功能概念都比较模糊，大部分想法都停留在脑海和口述上（工作中典型的场景，如团队风暴、需求讨论、会议评审）。需要我们不停地理清概念想法，验证需求的合理性、目标是否正确。所以这个阶段的强调是：产品雏形 - 将我们的想法、概念需求可视化出来，并加以讨论验证。因此，最合适的方式就是用‘草图’表达，快速产出快速修改，能即时看见产品的雏形。常用‘草图’勾勒产品雏形，除了可以表达想法、探索方向外，好处还在于：a. 能提升你快速思考、验证假设、优化设计流程的能力。b. 能展示你思考问题的过程（设计思维），体现专业能力。02.修改阶段： 这阶段的产品目标和方向较为清晰，接下来需要优化原有的概念想法，为产品创建一个信息架构、梳理功能逻辑等工作，方便在需求评审会、团队讨论中推动产品功能的进展。 该阶段强调：理清目标 - 根据用户诉求、业务目标、运营需要等不同目标点，逐步梳理出原型上需要展示哪些功能内容（界面布局、信息取舍）。所以对产品经理/交互设计师来说，只需产出一个大体上看得明白、能理清产品功能的‘中保真原型’即可。方便即时修改，向产品定型/高保真原型过渡。03.确定阶段：到了这个阶段，产品需求的功能布局、信息设计已全部确定，这时一份全面、严谨的‘高保真原型’就尤为重要。一方面可以为视觉同事的UI输出、开发的落地实现等提供依据。另一方面在各种工作场景中，高保真原型都能发挥很大的作用，如交互评审、领导过稿、A/Btest、demo演示等等。这一阶段强调：细节核对 - 因为关系着UI输出、界面实现等工作，所以需要注意各种交互细节，以防出现设计、流程上的漏洞。

受众永远是第一位的针对于产品本身来说，首先考虑的是用户的利益。（当然是在用户合法得到的基础上）但是产品经理在工作过程中，这儿的用户就变成了受众，受众可以是你的用户、同事、老板。因为产品经理会接收到来自各方的需求，但是和各方的沟通不能用同一种沟通方式：面对你的用户：你应该以保障他们利益优先，教他们一步步如何操作，给他们参与感和获得感；面对你的同事：先聆听并问清楚后，再梳理出自己的建议，因为找你沟通肯定是和你有关系的；面对你的老板：拿出有效的数据来佐证自己的方案和框架，不必过多的强调细节，当然到达的结果一定要可行并且有条理。这次结果产出的受众是谁？TA最重要紧急的是什么？我拟定的方案能否满足TA？我的方案的可行性有多大？执行难度大不大？通过这四步面对不同的受众应该拿出不同的方案。面对用户展示的是产品经理的细节梳理能力；面对同事展示的是产品经理的产品梳理能力；面对老板展示的是产品经理的产品规划能力。团队协作才能高效工作无论能力多强的人，也是需要团队协作的，因为有更重要的事情在等你。何况你能力并没有这么强！专业的事情一定要交给专业的人去做。和专业的人配合时，你一定要明白：你能比UI设计师更懂设计规范和设计趋势么？你能比技术更清楚如何实现这个功能么？你能比运营更明白运营策略么？如果不能，你只是提出意见方，可以和他们沟通并说出你的建议和理由。我一般是这么梳理的：这个模块，可能需要涉及到和哪些人协同？（心里可以圈定人选，然后找到对应协同职能的负责人，和他们说清楚模块规划，接着就是要人了）需要准备哪些资料给到协同人？（把对应的资料梳理，用落地的方案整理出来）接下来就是做实时的对接。（敲定时间节点并以会议的形式沟通）当你成为某个项目负责人后，你就知道团队协作有多重要。但是前期是要用项目成员的语言去沟通，有效的建议很重要，通过权力干预往往会适得其反。（现在你是我老大，也许下一次我就翻身做主人了。）

产出一定有结果和目标在梳理产品的过程中，这版本迭代需要在什么时间达到怎样的目标？如果是业务侧活动类型（短期）的需求，需要同步业务侧制定运营计划（计划一定要伴随方案和目标），根据运营计划做产品迭代（用一次性解决方案还是做成可配置的常规解决方案？）；如果是产品规划（长期）需求，提前想好这个模块的迭代计划（通过产品路线图展示出来），和其他模块是否有衔接点？以及如何协同？如果不能达到目标，解决方案是怎么样？未尝胜先思败。想好后路很重要，版本的每次迭代都有三个deadline：需求澄清最后期限，产品评审最后期限和产品上线最后期限。业务侧提出活动类型需求，产品经理要和业务方沟通清楚没有达到目标的补救方案是什么？（PS：如果没有，让业务方梳理清楚了再沟通）；如果是产品规划需求，尤其是在需求澄清最后限期没有思考清楚，那就给版本做减法，快速评审（评审如果都搞不定，那……）并跟进项目直至上线。方向永远比执行重要在版本沟通会上，把涉及到这版本的功能清单梳理清楚，同时也要把和模块有协同的模块梳理清楚。梳理清楚等待版本确认会上沟通……比如在电商产品做积分商城时，除了把获取积分和消耗积分的点列出来，还要考虑积分的期限和积分后续是否可以抵扣现金（防止通货膨胀），其中消耗积分有没有兑换中心？兑换的流程是怎么样的？可不可以退货？等等。如果没有想到对应的解决方案，咱去看看竞品，试着去拆一拆，他们是怎么做的？分成了几个版本？把竞品的功能清单和流程梳理出来。一起讨论讨论是否能被我们借鉴。在准备方案的过程中，一定要反问几个问题：还有没有其他更好的方案？（最好的办法是找运营模拟下用户流程）这个方案还需要补充什么？（试着把业务路径和用户路径梳理出来）在这个方案中，每个环节有几条出口？我该怎么引导用户一步步走下去？（大致的功能流程图梳理清晰）让业务方的小伙伴模拟后，提出他们的问题。

分析业务优先级品开发的时间规划、资源规划依赖业务优先级的确认，因此我们在产品规划时对系统的业务优先级进行优先排序，即分析系统产品用例的优先级。那么该采用什么样的方法去分析呢？应该综合考量以下因素：战略规划方向分析业务是否贴合企业当前的战略规划方向。市场情况即考虑市场的竞争情况、市场规模，分析业务对于产品的竞争力、用户群等方面的影响。业务目标分析业务的完成与否、完成质量对业务目标完成的影响。业务带来的价值分析业务能给企业、用户带来多大的价值。对于产品的初始阶段，要注意开发的业务要形成业务闭环，能优先实现最小闭环的业务优先级高投入产出比对接业务的带来的成本和其开发成本进行比较业务的优先级受到多因素的综合影响，因此要衡量好每个因素的权重。划分项目里程碑里程碑一般是项目中完成阶段性工作的标志，标志着上一个阶段结束、下一个阶段开始，将一个过程性的任务用一个结论性的标志来描述，明确任务的起止点，一系列的起止点就构成了引导整个项目进展的里程碑[10]。划分项目里程碑就是对完成业务目标的时间进行规划。划分项目里程碑包括两个部分一个是目标分解、另一个是完成时间。目标分解应该按照业务实际进行，常见的目标分解有按照业务功能、按照任务进行的步骤、按照业务价值的量化指标等。对于产品规划而言项目里程碑的完成时间不需要很精确，一般按照季度、月度进行划分。业务的优先级影响里程碑完成的阶段任务内容，每一阶段的规划要优先实现高优先级的业务。产品规划是系统开发工作的指导方针，通过业务目标梳理、业务范围明确、业务流程确认、业务优先级分析、项目里程碑的划分，项目参与人就清晰地知道产品在一段时间内的项目目标、发展规划、任务内容、资源安排。

量化目标需遵循SMART原则，同时也要考虑产品的生命周期。在引入期，产品自身的功能不完善、客户规模小，业务目标的制定应侧重于客户群体、解决方案、价值产生、客户触达。在产品的成长期业务目标的制定应侧重于客户维护、盈利模式。在产品的成熟期、衰退期业务目标的制定应侧重于客户维护、解决方案、价值产生。SMART原则Specific : 具体的Measurable：量化的Attainable: 可达到的Realistic：有关联的Time-based：有时限的产品生命周期引入期成长期成熟期衰退期明确干系人&业务范围干系人是影响项目成败、与项目利益相关的人员。常见的项目干系人有公司高层、项目团队成员、产品使用者。明确好项目干系人，满足不同干系人对项目的期望和需求是产品获得成功的关键要素.要构建的产品必须能改进拥有者的实际业务，其能够应用到拥有者的业务领域，并完成部分（有时是全部）的工作。因此业务范围的梳理不是基于系统的功能实现，而是从用户实际使用的业务出发，归纳其业务组成，明确业务系统化的界限在哪里，要对哪些业务进行系统化。业务范围的明确有两方面一个是对产品用户进行抽象，挖掘其共性，明确产品的业务对象，另外一个是分析实际业务的工作流程，分析业务事件，明确系统边界，梳理出系统支持用户实际的业务有哪些。得到正确的产品范围是得到正确的需求的关键。业务范围可以从不同的业务领域细化到业务用例，然后分析业务用例中哪些部分由系统进行实现，这些部分称为产品用例。