前言
集成产品开发（Integrated Product Development, 简称IPD）是一套产品开发的模式、理念与方法。当然，世界上不只这一种产品开发模式，还有类似的，但总体来说，其知识体系都大同小异，学会一个以后，灵活运用。
- 产品开发是一项投资决策：需要严谨的阶段性评审。在开发各个节点评估是否要启动、暂停、终止、改方向。
- 基于市场开发：充分了解市场需求、竞争产品的情况下，进行产品定位。
- 跨部门、跨系统协同：利用一切可利用资源，并进行有效、及时地沟通。
- 异步开发模式，也称并行工程：通过严密的计划，把接口定义完善，把在时间上后续的开发任务提前，并行开发，缩短开发周期。
- 重用性：不管是硬件还是软件，一些可以重用的模块，进行公司技术积累，当然也可以包括工作总结、FAQ等。
- 结构化的流程：开发是一件不确定性的工作，需要在结构化和非结构化之间找到平衡，灵活运用管理模式。
投资决策的参考标准
通过上述的这些要素，对产品立项的指导还是具有一定的意义。毕竟，开发一款产品最终是为了创造利润，当然新产品也要符合公司的战略方向，例如小米公司这几年会投资一些电源插板、空气净化器等零碎的家具产品，那是小米在部署家庭物联网生态圈的战略中一分子。公司制定的产品战略方向，也还是根据市场决定的。
之前听过单副院长的讲座，开发一款产品，要研究竞争对手。竞争对手的产品，成熟、稳定、价格极低，软件、硬件、利润已经没有多少竞争空间，就不要再做（我以为如果是公司战略，还是需要开发的）。
| 市场 | 市场规模 | 总市场：百万、千万？ 单个用户：十万？百万？ |
| 成熟度 | 市场刚起步发展 （价格、功能很有利润余地） 发展已经成熟（价格、功能由部分利润余地） 发展末期，有垄断 （价格、功能没有利润余地） | |
| 带给客户的价值 | 分析客户需求（价格、功能、外观、性价比、易用性的需求程度） 收回成本时间 年化收益 | |
| 实施 | 开发资源 | 技术人员齐备 |
| 市场资源 | 市场推广人员齐备 | |
| 技术风险 | can or not can（是否技术壁垒、过度依赖） can & better | |
| 服务、支持 | 售前、售后、技术支持 | |
| 财务 | 成本 | 人力成本、物料成本 |
| 利润 | 毛利润、净利润 | |
| 风险 | 资金收回 |
忘记上述的知识
“ 乔纳森刚加入谷歌不久，就目睹了两位创始人对传统商业模式的厌恶。作为一名资深的产品管理高管，他对产品研发中所设的“过关制”("gate- based" approach）并不陌生。多数企业都在用这种方式：设立明晰的阶段和步骤，并安排公司自下而上的各级管理者进行层层评估。这种方法的初衷是节约资源， 将广泛散布的信息汇集到一小撮决策者那里。乔纳森本以为自己的使命就是将这种制度带入谷歌，他非常自信传播这一制度的使者非他莫属。
几个月之后，乔纳森给拉里提交了一份产品计划，将“过关制”研发方式展示得淋漓尽致。计划中包含了步骤、审核、优先次序，还有两年内推 出的产品种类及上市日期。这份计划是教科书思维模式的杰作，乔纳森应该赢得一阵热烈的掌声和校长在背上鼓励的一拍。可惜，现实并非如此，因为拉里讨厌这种 方式：“你见过哪个团队的表现能超越既定目标？”呃，没有。“你的团队研发过比计划中更出色的产品吗？”也没有。“如果是这样，计划还有什么意义？计划只 是在拖我们的后腿罢了。一定有比计划更有效的方式，去和工程师谈谈吧。”
听了拉里的话，乔纳森豁然意识到，原来他所说的“工程师”并非通常意义上所指的工程师。没错，拉里所说的工程师都是杰出的程序员和系统设计师，但除了技术方面的资深经验之外，很多人还具备敏锐的商业头脑，在创意上也是才思泉涌。
从大学校园出来的谢尔盖和拉里给了工程师非同寻常的自由和权力。传统的计划管理方式对这些工程师并不适用，这些条条框框虽然能够提供一定的指导，但同时也设下了羁绊。“为什么要束缚大家的手脚呢？”拉里告诉乔纳森，“这样做太蠢了。”-----from《How Google Works》
总结
听说一句话：大公司里，员工只要按照定好的流程做事情，就能把事情做的很好。所以一直比较推崇在公司里建立各种工作流程和制度。但是，开发产品是一件创造性的事情，对于IPD不可迷信，不可不信，摘取有用的，指导自己的工作。
尽信书则不如无书，人是最灵活、也最有创造力的。创造，不要让规则局限了思维和脚步。