成功的产品都是相似的，因为每个环节、每一步都要做对，而失败的产品各有各的不同，因为任何一环出问题都会垮掉。
迭代与规划：（发射火箭和开车出门）
在做产品，特别是互联网产品时，很难做到像发射火箭那样，在点火前收集到足够充分、完备的信息，准备好一切后再发布，也就说无法事先“规划”。我们面对的局面往往是信息很难收集、市场在快速变化，所以做产品更像是开车出门，有一个明确的目的地，然后走一步看一步，这就叫作“迭代”。
规划得一步步来，是以自我为中心、以公司为中心的，是生产驱动的。而迭代的一步步来，是需求驱动的，是对用户反馈的不断响应，需要根据市场信息的变化来一步步调整。
规划是战略布局，是定方向，做正确的事；迭代是战术实施，是定走法，正确地做事。二者各有短长。

产品经理视角的项目流程

产品经理视角的项目流程
（来自《人人都是产品经理2.0》）

► 立项环节：在这个环节，产品经理要组建团队、设法获取各种资源，以及确定项目计划。在正式开干之前，一般还会开个Kick Off会议，鼓舞一下士气。
► 需求环节：这个环节主要做的是功能细化，也可以叫需求开发。产品经理要写PRD产品需求文档和UC用例，并和设计师配合做Demo原型。在这个过程中，可能会经历多次评审会议，还要和技术人员一起确定功能细节。以写产品需求文档为例，产品经理一般都不会遗漏主干流程的描述，但是否能把分支流程、异常处理、边界条件都写完整就不一定了。比如，一个搜索结果为空或少结果时怎么处理，会员管理列表中如果一个会员都没有，是否应该全空着，微博用户关注人数达到上限时该怎么提示，等等，都是产品经理需要掌握的基本功。
► 开发环节：这一环节的主角是开发工程师，他们要做代码方案的设计和评审，然后完成编码和单元测试。与此同时，产品经理已经开始下一个迭代版本的项目前期准备。
（Unit testing是指对软件中的最小可测试单元进行检查和验证，一般由开发人员自己完成）
► 测试环节：开发推进的同时，测试工程师要编写TC测试用例，通过TC评审，并且在系统可用的第一时间做冒烟测试。此环节中，产品经理要组织功能评审，在第一时间把新产品展示给所有的项目干系人，以确保做出来的东西是大家想要的。
（冒烟测试smoke test，是对新电路板基本功能检查的形象类比。任何新电路板焊好后先要通电检查，如果板子不冒烟，则冒烟测试通过。软件研发领域借用这个词描述新功能是否可用的初步测试。）
► 发布环节：测试工作完成后，运维人员要组织发布评审，执行预发布、发布的动作，并且在发布完成后让产品经理到真实的线上环境去验证，以确保产品符合预期。

为了保证整个过程的顺利进行，产品经理还要把控三件事。
一是文档管理：每个环节的输入/输出文档是什么，用什么模板、工具编写，以及如何保证同步更新等。
二是流程管理：每个环节的各种评审会议，是否可以结合团队实际情况做出删减，突发需求和需求变更如何处理等。
三是敏捷方法：团队日常沟通采取什么方法，如何监控进度，以及如何改进配合模式等。

避免成为讨厌的人（避坑指南）

以下内容正话反说

开始实施之前

► 不说清需求价值。技术问“为什么要做”时支支吾吾，或者说这是老板（运营）要的，假装自己是个传话筒，或者说“我接的是二手需求，什么都不知道”，而不是去追溯这个需求的初衷。相反，面对老板时，则一定不要有理有据地顶撞，那会让大家喜欢上你。
► 不去想功能细节。技术问细节（当然，是涉及业务的细节，不是技术实现细节）时，装作自己之前完全没想过，需要现想：“那就这样做”、“可能那样做也可以”“要不你来定吧”……这时你能看到的是技术同学的白眼，听不到的是他们心里的三字经。【技术需要确定性的结果。】
► 帮技术评估工作量。特别是技术出身的产品经理，最容易这么干。他们的潜台词就是“希望加活”：“我评估过了，这些都能做掉的”、“不要偷懒，不要忽悠我，我都懂”。
► 逼着技术团队承诺。任何时候只知道公事公办，技术承诺了却做不到，自己就没责任了。很多事情不像接力跑的交棒，更像踢足球的传球，一开始没人知道下一步该干什么，如果对方基于此对你说：“大家在一条船上，应该同舟共济”时，你只要回：“我不管，我不管，我不管”就好了。
承诺与预测：瀑布模式下，开发任务明确，技术也成熟，可以提前计算好工作量。但在敏捷模式下，很多时候会做着做着发现坑，或做着做着需求不得已发生变化，所以产品经理应该和技术人员一起做“预测”，心里想着目标，一起面对变化。最核心的区别是：承诺是技术对产品的责任，预测是两边一起承担责任。

实施过程之中

► 做了一半改需求。经常在某个迭代周期内做“非受迫的需求变更”，这招太狠了，技术同学肯定很难忍受，俗话说“没有变更就没有伤害”。如果是因为产品经理没想清楚而导致无谓劳动，碰到性子烈的技术就要直接干架了，这时候要注意保证自己的人身安全。
► 开发过程中消失。你可以多安排点出差、多开开会，注意手机尽量关机，不要响应技术的问题，要不然，责任就回来了。让技术同学为了赶进度，按照他们自己的想法做下去，关键是要在验收的时候跳出来说“这不是我要的”，再次提醒注意人身安全。
► 过度关注实现细节。帮技术决定技术方案，技术出身的产品经理最爱干的事儿就是变着法儿地越俎代庖。一定要把技术从积极主动的小伙子，打击成一个个纯打工心态的“资源”（这个词听起来就有杀伤力）。

产品发布之后

► 发布后没有反馈。技术人员也需要从市场、用户那里获得反馈，从而对自己做的事情产生价值感和成就感。我们要做的就是，功能发布之后，好像石沉大海，不告诉大家任何结果，甚至庆功会都不叫他们，紧接着继续安排他们干活。
► 任务无节奏感。让技术人员忙一阵闲一阵，发布之后再开始研究接下来做什么。一会儿让技术人员有着天天通宵的高强度，给deadline，下死命令，做完之后突然不知道做什么：“你们也一起来讨论一下业务”或者“出去培训培训（做做团建）吧”。

全程适用

► 优柔寡断无决断。表现出这个品质很具杀伤力。比如，在事情讨论完毕后，大家说：“你定吧，你说往哪儿走我们就照办。”在所有人都等着你拍板的时候，你说：“啊……那个……方案各有利弊，我也不知道怎么办，你们有什么好想法……”
► 报喜不报忧。藏着、掖着一些坏信息，比如“老板在考虑干掉这个项目”这类信息，从不主动公开，但通过其他小道消息让大家知道，这样很容易就把互信完全打破，这时候他们一定很讨厌你。
► 不要把他们当人。这是必杀技——不关注人的成长，只关注事的结果，永远把合作伙伴当“资源”。