关键角色及其职责
- 产品经理：评估产品机会；定义要开发的产品。
- 用户体验设计师：深入理解目标用户，设计有价值的、可用的功能，以及用户导航和产品使用流程。
- 项目管理人员：制定计划和跟踪进度。可能由项目经理担任，也可能有开发经理或产品经理担任。
- 开发团队：IT团队通常指为内部员工提供技术支持的团队，而开发团队指为外部客户开发和维护产品的团队。
- 运维团队：一般分为基础运维和产品运维两个团队，基础运维负责基础设施(包括机架、网络、硬件)和操作系统的安装，为整体公司的所有产品提供基础设施的运维服务。而产品运维负责线上产品的问题处理、代码的布署和跟开发的接口等。
营销团队：负责对外发布信息、宣传产品，为拓展市场销售渠道、组织重点营销活动（如在线营销）、促进产品销售提供支持。
产品管理与项目管理
- 互联网服务类产品对网站代码的局部修改更加频繁，发布周期明显缩短，大部分项目开发周期长于发布周期。为了适应这种变化，很快出现了并行开发和火车模型发布模式。
- 随着互联网产品的发展，产品发布流程变得越来越复杂，项目管理职能慢慢从产品管理职能中分离出来。
- 产品管理的职责是探索（定义）有价值的、可用的、可行的产品；而项目管理则关注如何执行计划以按期交付产品。
产品管理与产品设计
- 好产品必须提供舒适的用户体验，舒适的用户体验是产品管理和用户体验设计共同作用的结果。
- 产品设计的目标是确保产品同时具有可用性（用户如何使用产品）和价值性（用户对产品的渴求程度）。
- 视觉设计可以外包，交互设计不宜外包。
产品管理与软件开发
- 产品经理负责定义产品方案；开发团队负责评估产品构思是否可行，以及产品的开发与实现。
- 一旦产品进入开发阶段，要尽可能避免修改产品的需求和设计。
- 外包不是为了节约成本，而是为了实现合理的人员配置，为团队寻找合适的人选。
- 软件开发时需要预留一定的技术能力，即余量。余量意味着避免触及技术能力的上限，为用户数量的增长预留空间，为事务增长预留空间，为新增功能预留空间，保证产品的技术构架能够满足团队的需求。
评估产品机会
- 产品要解决什么问题？（产品价值）
- 为谁解决这个问题？（目标市场）
- 成功的机会有多大？（市场规模）
- 怎样判断产品成功与否？（度量指标或收益指标）
- 有哪些同类产品？（竞争格局）
- 为什么我们最适合做这个产品？（竞争优势）
- 时机合适吗？（市场时机）
- 如何把产品推向市场？（营销组合策略）
- 成功的必要条件是什么？（解决方案满足条件）
- 根据以上问题，给出评估结论（继续或放弃）
评估产品机会的目的在于：淘汰馊主意，避免浪费时间和金钱；挑选合适的产品机会，团结团队，理解产品，整合资源。
机会评估只讨论待解决的问题，不应涉及具体解决方案。
产品探索
- 软件项目可以划分为两个阶段：弄清楚要开发什么产品（定义正确的产品）；开发该产品（正确地开发产品）。第一阶段探索产品，第二阶段强调执行。
- 在探索产品的阶段，产品经理负责分析各种创意，广泛收集用户需求，了解如何运用新技术，拿出产品原型并加以测试，从全局视角思考产品方向，兼顾短期需求和长期规划。总而言之，就是探索出兼具功能性与设计性的产品。
- 一旦完成产品定义，进入开发阶段，产品团队就要切换工作重心到执行上——开发、测试、发布。
- 采用流水线方式并行开发产品，一旦1.0版产品进入项目执行阶段，就开始定义2.0版产品。一旦前一个版本进入开发阶段，就把创作热情投入下一个版本。
产品原则
- 产品原则是对团队信仰和价值观的总结，用来指导产品团队作出正确的决策和取舍。
- 产品原则不是产品功能清单，不依赖于任何单独的产品，它是整个产品线的战略指南，是公司的价值宣言。好的产品原则甚至可以激发设计产品的灵感。
特约用户
- 产品经理要深入了解目标用户，明确产品需要解决的问题，定义出满足用户需求的产品，因此产品经理必须和用户紧密合作，这样，开发的产品才可能满足更广泛的用户需求。
- 特约用户：在项目的开始阶段物色至少六位积极、活跃、乐于分享的目标用户，要求是他们在产品的目标用户中具有一定的影响力。
- 好处：①聚拢一批积极地用户，他们可以为定义产品和发布产品提供建议和协助。②提供调研便利，便与产品经理去特约用户的工作场所调研。③可以定期组织特约用户进行小组讨论。④特约用户第一时间使用、测试产品，迅速反馈意见。⑤如果特约用户满意产品的表现，会乐意公开推荐产品。
产品说明文档
- 产品经理的核心责任是确保向开发团队交付具有潜力的产品说明文档，理想的产品说明文档应该满则以下五点要求：①完整的描述用户体验——不只是用户需求，还包括交互设计和视觉设计②准确地描述软件的行为③以某种直观的方式把产品信息和产品行为告诉所有人④可修改⑤有一个主体来代表产品，避免混淆不清，版本错乱
- 高保真原型可以满足以上所有需求，它体现了产品的功能需求、信息架构、用户体验、交互设计、视觉设计。除此之外，高保真原型最突出的优势是可以用于测试。
基本产品
- 基本产品：只满足基本要求（价值、可用性、可行性）的产品。一旦基本产品定义完成，他就是一个不可分割的整体，去掉任何元素，都不可能获得预期的效果。
- 基本产品设计：①产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。②邀请以为开发人员参与设计原型，帮助产品经理和设计师估算各种功能的直接成本和间接成本，指出设计上的无趣，并分析、评估尚不确定是否可行的功能。③请真实用户验证产品原型。
由于开发的是基本产品，一旦进入软件开发环节，产品经理就不能再随意修改设计。
产品验证
产品验证是指在正式开发、部署产品前，验证产品说明文档描述的产品是否符合预期要求。
- 可行性测试：现有技术条件下能否开发，以及开发的难度评估。
- 可用性测试：交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都能明白如何使用。
- 价值测试：测试用时是否觉得产品有用，是否愿意购买。
平滑部署
- 不是所有用户都喜欢新版本的产品：①事前没有通知用户②用户没时间学习、适应新版本③新版本无法正常运行④新旧版本不兼容⑤添加的功能缺乏必要性
- 通常情况下，用户不喜欢变化，虽然用户也希望产品更完善、功能更丰富，但前提是不改变已有的使用习惯，大多数人不愿意花时间学习、适应新的使用方式。
- 为将新版本更新带来的负面影响降到最低，可以采用一下几种措施：①通过公告、邮件、在线教程等方式提前通知用户②加倍做好测试工作，解除隐患③采用并行部署或增量部署的方法
- 并行部署：发布另个并行版本，邀请有兴趣、有时间的用户试用新版本。如果新版本运行正常，大部分用户习惯新版本后，再将新版本设为默认版本。同时将旧版本保留一段时间，公示旧版本的提供支持的最后期限，以便没来得及更新的用户在这段时间内能照常使用产品。
- 区域性逐步部署：首先在某个区域内部署新版本，然后逐步扩大范围。
- 增量部署：将更新项分隔成几个较小的部分逐步发布。
敏捷方法
敏捷方法是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
瀑布式开发
特点
- 采用阶段式开发：软件开发过程事先分成固定的几个阶段——撰写书面的需求说明文档、设计高层软件架构、设计低层细节、编写代码、测试、部署
- 采用阶段式评审：每个阶段结束后，对该阶段提交的成果进行评审，评审通过后才进入下一阶段。
流程
- 首先由市场人员收集市场需求，提交给开发人员；
- 接着由开发人员制定开发计划，设计软件架构，进一步完善设计细节；
- 然后进入开发测试阶段，完工后邀请用户测试产品，最后部署。
优点
- 可预测性
- 每个阶段结束时都会提交书面材料
弊端
- 产品验证严重滞后：产品经理不需等到软件开发的尾声，才能看到可以运行的软件。
- 变更计划代价不菲：任何对前期决策的修改都会打乱开发流程，大量工作需要从头来过，不仅浪费资金，而且耗费精力。
- 无法适应快速变化的市场：瀑布式开发方法严重依赖文档和流程，在这方面开销很大。
瀑布是开放方法过于理想化，以为人们能预见所有问题，全面把握需求。实践证明除非是规模很小的项目，否则瀑布式开发方法很难顺利执行。
提防有特殊要求的产品
- 产品需求不能用户说了算：①在看到具体的产品之前，用户很难知道自己需要什么②用户不知道什么样的产品是可行的（在目前的技术条件下可以实现）③用户之间缺少沟通，需求很难统一④客户在描述需求时，习惯提出自己的解决方案，但不一定抓住了需求的本质。产品经理应该与客户一起梳理需求，发现问题的本质，提供更合理的解决方案。
- 公司应该根据企业文化树立自己的产品原则，关键时刻根据产品原则决定是否接受客户提出的特殊要求。