基于常见的业务形态和相关的合作团队，在这里给大家讲一下典型的互联网产品经理是怎么进行日常工作的，让我们带入一个真实的场景来帮助大家更好地理解。
假设你现在是一个创业电商公司的产品经理，早上到了公司之后发现最近没有什么太多有价值事情（需求）可做，于是你打开了自己家的电商APP，和成熟的电商APP，例如淘宝进行对比，也就是进行竞品分析的工作。在分析后你发现自己公司的电商购物APP和淘宝比少了许多非常重要的功能，所以你一一罗列然后打算补全。在所有的缺失的重要功能中，你发现自己公司的电商App竟然没有购物车这个功能。所以你分析了当前的自己公司的目标用户和产品定位之后，决定为自己公司的购物App增加一个购物车。
以上就是一次需求定义的过程，需求定义也就是发现、寻找市场机会并且总结成需求。这是产品经理开始工作的第一步，但同时也是最难，最重要，需要持续的挖掘和迭代的一个步骤。
好了，当你决定了要先做购物车这个功能之后，你开始完善你的调研和分析结果，拿着你结论、数据和逻辑去找了老板寻求他的认可和支持。在经历多次沟通，回答了老板无数个疑问之后，终于得到老板的同意和资源的授权。然后你开始拉着运营，设计、开发、测试，也许还有商务、法务等部门一起开会，再又一次回答了大家无数个疑问，终于和大家一起达成共识：明天开始每个团队都投入部分人力，为APP开发一个购物车功能。
以上就是一次简单的，和各方对齐需求的过程。对齐需求的直接诉求与结果是能争取到不同的团队的对于这个需求的资源投入。在对齐的过程中一般不会光凭嘴说，通常会有一个文档或者PPT去展示自己调研得到的信息与数据。在这个阶段产出的文档，也就是大家常说的BRD（商业需求文档Business Requirements Document）或者MRD（市场需求文档Market Requirement Document）。
光有BRD是不是足够呢？肯定是不够的，因为BRD只是解释清楚了“你需要做什么”和“为什么要这么做”。但决定了做什么之后，这个事情具体怎么做呢？于是你作为产品经理，拉着UI设计样式和交互，拉着技术对初步的可行方案，同时自己撰写需求细节，产出了PRD（产品需求文档Product Requirements Document），并且拉着所有和需求有关的合作方进行了需求评审。
评审中可能会有无数的疑问和质疑，在你经历了无数次的答疑，回答了合作伙伴的各种问题之后，你可能得到了技术同学给的排期：30天之后功能就能开发完成。
还记得上面的产品定义中“推动关键结果发生”吗？于是你作为产品经理还需要在未来的30天承担起项目经理的关键角色，不断跟进技术同学的开发节奏，解决开发过程中提出的技术疑问，不断调整自己的需求，终于保证了这个购物车在30天之后顺利上线，这就是一次产品需求的过程了。
好了，项目上线了，你觉得就到这里结束了吗？还远远没有呢。实际的业务中，等功能上线了你还需要验证上线的数据和用户的反馈，根据这些去不断调整的自己的产品。
在这个简单的情景模拟之后，你是不是对于产品经理基本的工作模式有了一些了解，甚至还觉得这还也挺简单的，我也能直接成为一个合格的产品经理了。
那么接下来，我继续用一些这个项目中实际可能遇到得困难，采用问题+回答的方式，讲讲这个简单流程里面需要的注意事项和可能遇到的问题。在看回答之前，你可以先自己想一想答案。
问题1：当你和老板沟通需要做购物车这个功能时，老板可能的质疑有哪些？可能的质疑包含：
为什么你要做这个功能，为什么淘宝有这个功能但同样作为购物APP的拼多多没有——这里问题的潜台词是你有没有经历过充分的市场分析和调研，是不是真的了解和理解当前电商的App应该怎么去做。
做这个功能有什么收益，产生收益的原因是什么，这些收益和当前公司的核心目标是不是一致，收益能不能量化出来——想了解你提出购物车这个功能，是真的把收益想清楚和计算清楚了，还是只是拍脑袋觉得这个功能重要。
为什么你现在做这个功能，为什么之前不做或者不在以后某个时间做——这里主要是想问为什么现在是合适的时机。因为每个阶段投入的资源都是有限的，为什么现在要做购物车这个事情。
不做有什么坏处，做购物车功能需要多少资源耗费多少时间，这个资源为什么不用来做其他的功能——想知道你的ROI意识，面对的机会成本和机会收益是不是有过合理的评估，以及当前投入资源进行购物车功能的开发是不是产出最大的投入。
老板层面具体的问题可能千差万别，但基本都会聚焦在“为什么做”和“为什么现在做”这两个核心问题。购车还是一个看似简单，不用太多介绍大家就已经很熟悉的功能。如果是一个大家都还很不熟悉的功能，老板的疑问则会更多，那么前期的市场调研，说服老板的立项文档就更加重要了。
等你终于经历了无数的论证、调研和收益计算，并且成功的说服了老板支持你做这个项目之后，就可以到下一环节了。但可千万别以为老板拍板同意就万事大吉了。
问题2：当你和运营、设计、技术等合作方沟通需要做购物车这个功能时，他们可能的疑问有哪些？
为什么现在要增加购物车这个功能，用户凭什么会用这个功能，这个事情和其他正在做的事情优先级是什么关系，如果我支持了购物车这个项目，其他项目能不能暂停。
你想要的购物车功能是什么样式的，什么颜色的，为什么淘宝是黄色的，京东是红色的，那我们APP主色调是蓝色的，我们购物车按钮可不可以也是蓝色的？（京东与淘宝的购物车按钮是红色/黄色实际上涉及到严格的用研测试，一般来说用户对于黄色和红色等刺激性颜色更为敏感，使用这样的颜色可以刺激用户下单）。
IOS和安卓用户看到的样式一样吗？web页面和客户端页面用户看到的样式一样吗？未登录用户点击购物车按钮怎么办。
购物里的商品信息保存多久，购物车有多件商品一起支付怎么处理，如果支付成功是否需要清除购物车，发生支付不成功或者退换货购物车里的商品怎么办。
购物车里的商品信息价格变化了怎么办，商品下架了怎么办。
添加购物车成功后怎么提示给用户，有哪些情况会导致添加购物车不成功，不成功怎么办，添加商品重复了怎么办。
……
可能你看到这里已经有点头晕了，里面很多的问题可能根本不在你最开始提出需求的考虑范围里面。你以为只是在App上加个购物车的功能就好，但实际需要考虑的问题远多于这些。比如购物车功能就会和商品状态的流转，订单状态的流转，购物支付等环节强相关。这些逻辑如果没有一定的业务经验和强大的逻辑思考能力会很难应对。
我们假设你作为一个资深的产品经理，对于每个环节都很了解，很好地对这些问题进行回答，然后大家已经热火朝天开始干活了。但请仍然别高兴太早，后面在功能开发的过程中，可能还有非常多的问题等着你作为产品经理来解决。
问题3：当研发团队告诉你已经开始做了，大概需要30天上线后，产品经理还会遇到什么挑战呢？
如果老板对于上线时间不满意，要求压缩到20天内完成，你要怎么办。
如果研发团队需要你砍掉一些其他的需求，甚至是其他产品经理负责的需求来保证上线时间，你要怎么办。
开发过程中出现一些意外，例如人员请假或者其他需求插入导致上线延期，你要怎么办。
沟通中发现偏差，导致一些关键需求没有被实现或者被实现错误了，比如你说购物车是红色（大红）的，但研发实现成了红色（粉红），你该怎么办。
开发中老板突然提出新的想法，例如要在购物车上加一个酷炫的提示文案，或者大改一个功能影响了上线的时间线，你又要怎么办呢。
……
实践中产生的突发情况远远不止这些，每一个问题如果不能有很好的解答，都可能造成项目的失败。可能你会有困惑，毕竟这些问题和情况已经不是产品设计的范畴了，产品经理连研发休假对于项目的影响也要考虑到吗？当然！因为产品经理如果要对最终的产品负责，就必须承担起项目经理的角色来。否则产品设计的再好，但不能保质保量的交付，也起不到最终好的结果。一个负责任的产品经理在重要又复杂的项目里更多的时间其实就是花在项目管理和沟通协调上。
现在让我们跳过这些问题，假设你都能非常好的解决，在大家约定的期限内购物车终于上线了，那是不是就算项目结束然后完事大吉了？请记住不是！初级的产品经理常见的一个错误就是把项目上线当做终点。
在项目刚开始的时候，面对各方的疑问，你作为产品经理可是给大家计算过收益和效果的，那上线后是不是达到了这个收益和效果呢？就需要进行评估和复盘了。这样的好处至少有两个。
对项目来说：复盘和分析都是项目持续进行改进的基础。只有认真分析了现状，了解当前的数据，通过现状和数据总结出项目符合预期或者不符合预期的原因，才能不断进行迭代，让产品功能发挥更大的价值。
对产品经理来说：复盘和分析是自己成长的一个重要途径，通过实践中的复盘和反思总结自己做的好和不好的地方来帮助自己的成长；而且和合作方一起复盘也是一个与合作方建立信任很好的方式。一个产品经理如果能不断的复盘自己做过的事情，拉着合作同学一起实事求是的复盘，真诚的总结之前不足，勇于承认之前决策失误，总结大家做的好的地方并且提出表扬和鼓励，将会非常迅速的收获大家的信任，建立起你在团队影响力。
讲述了购物车这个案例之后，再来总结一下，产品经理日常的工作就是：发现和定义需求->描述清楚需求的价值->描述清楚需求怎么做->提出需求并获取资源进行实现需求->进行项目管理保证上线->观测数据进行复盘和迭代->达成关键的结果。
本文作者：照叔聊广告
产品经理干货分享：产品人 - 产品经理交流社区 - www.chanpinren.com