基于市场的创新是IPD的核心思想之一，集中体现为客户需求驱动产品开发。具体实现方式是划分出一个个产品包（Offering），并根据客户需求（包括外部客户和内部客户）定义产品包需求（OR，Offering Requirements），再将产品包需求转化为设计需求（DR，Design Requirements），然而通过产品开发实现需求。那么，产品包需求（OR）与设计需求（DR）有何区别呢？下表列出了两者的定义和主要不同：
产品包需求的例子：
扬声器需要110dB低频声音输出
提供简易方便的查看和打印分公司经营数据的功能
减轻臂架自重，载荷能力提高20%
每站平均升级时间30分钟
设计需求的例子：
将广播的输出在20～50HZ的范围内放大到115W
在查询功能模块中，设置查看分公司经营数据的功能，可以选择按分公司名称、区域、月份、年份查询，查询结果按表格和图形方式显示，并能即时打印
臂架采用三角型支撑结构，支撑臂从圆形改为工字型，采用高韧性轻型钢
每次可以同时升级10个机站，加载准备时间60分钟完成，同步升级20分钟内完成，40分钟完成测试确认
汉捷咨询发现很多企业在产品开发过程中往往把产品包需求和设计需求混为一谈，获得客户需求（通常客户需求还不充分，也不明确）后就一古脑编制产品需求说明书和规格书，然后匆匆忙忙进入开发阶段。这是一种典型的欲速则不达的开发方式，往往造成以下突出的问题：
没有理解真正的需求。缺乏从客户角度对需求进行研究和分析，没有了解客户真正的需求，尤其是潜在的需求。很多新产品推向市场后虽然也能使用，但无法让客户满意甚至惊喜，就与此问题直接相关。如过去每款新手机都有短信功能，都能使用，但直到iPhone推出对话式短信格式才使消费者有了很好的用户体验。
需求出现偏差。由于前面的客户需求不充分、不清晰，开发人员在进度的压力下，从开发者的角度去定义需求，与实际的客户需求相距甚远。如汉捷与某公司交流时了解到他们刚推出一款高端灶具，设计师增加了一个罩，认为灶具不用时可以用罩防灰尘，利于清理，殊不知罩本身的清洗更为麻烦。再如某应用软件系统开发了一个对工厂发货数据进行多维度分析的模块，系统在使用过程中该模块从来没有用过，因为工作人员只需要了解每月、每类产品的发货统计信息并进行缺货、及时率、趋势等简要分析就可以了。
需求不全面。开发团队关注从技术实现的角度定义需求，主要考虑的是功能及性能需求，而可制造性、可服务性、可测试性、可靠性、可安装性等方面的需求缺乏考虑，导致需求定义不全面。
产品创新性不足。在定义和实现需求的分析过程中，缺乏探索不同或更好的产品概念及技术方案，往往只是沿用过去的设计方案，失去了提升产品创新性和竞争力的机会。如手机要带物理键盘，这是开发人员习以为常的做法，消费者也使用习惯了。而苹果开发iPhone时基于客户需求探索新的技术实现方式，首次采用了通过触摸屏的软键盘方案。
导致返工。开发团队不仅致力于快速形成产品需求说明书，而且希望尽快明确硬件、软件、结构等各部分的需求，于是相关专业领域的人员按照自己的理解定义各子系统及模块的需求。且不说整个产品/系统的需求是否存在问题，各自为战的方式导致彼此理解不一致，各部分的衔接和接口考虑很不充分，代价就是后面频繁的返工和修改。
可见，在开发流程中，产品包需求定义和设计需求开发要相分离，当然两者又是紧密联系的，而其转化过程就显得极为重要，其中涉及到产品概念开发、技术方案选择、操作方式分析、需求映射分析、设计需求合理化等方面的具体操作。 在产品开发流程的概念阶段，首先需要从客户的角度明确、完整地定义产品包需求，接下来的关键转化为设计需求。设计需求既然是技术上如何实现的需求，那么需要先确定技术实现的方法，因为不同的技术实现方式就会有不同的设计需求，如手机输入的需求如果用物理键盘实现，则需要明确按键、信号获取等方面的设计需求，如果用触摸键盘实现，则需要触摸屏、软件处理等方面的设计需求。所以，同步要进行产品概念和技术方案的开发，这也是产品开发的一项关键活动，一般要探索多个产品概念及技术方案，然后从中选择最佳且可行的方案。根据产品概念和技术方案，即可以确定产品包内部的及与外部相关的操作方式，然后将产品包需求分解为设计需求。对于每一个产品包需求，根据下面内容对操作方式进行概括。因为分解过程比较复杂，可以借助表格，将相关内容都写入表格中（见后面附表）。
操作环境及顾客/用户眼中的操作
顾客/用户期望的操作
操作限制，在成本、尺寸、重量、电源、冷却、环境、制造、服务等方面的操作限制。
限制范围内的实际操作
在以下方面所带来的结果影响：成本、质量、上市时间、顾客满意度、兼容性等等
客户/用户对操作表示出来的任何吃惊（包括正面的和负面的）
对操作方式进行概括的一个例子：产品包需求是在中国偏远地区进行紧急呼叫。用户希望中国偏远地区进行紧急呼叫而又不掉线。对操作方式进行概括的过程如下（操作概要）：a) 操作环境或上下文，从顾客/用户角度考虑操作。举例：呼叫人可能在偏远山区快速移动，可能在大客车上，车上还有很多人也在打电话；电池可能不足，等等。b) 顾客/用户对操作的期望。将期望划分为强制性的、具有竞争力的或者最好的。比如：
强制性的：呼叫人呼叫，在振铃五次内接通
具有竞争力的： 在振铃三次内接通
最好的： 一次振铃便接通
c) 操作在以下方面受到的限制：成本、体积、重量、功率、冷却、环境、制造、服务等。比如：呼叫人不愿为被提供紧急呼叫的便利而另外付费，也不愿为支持紧急呼叫功能的手机而额外付费，并且希望电池使用时间越长越好。因此，也许必须使基站具有支持紧急呼叫的额外功能。内部限制是，原有基站已经占用所有可用功率，因此在基站上补充新功能要求进行重新设计。d) 在实际系统操作时尽量考虑这些限制因素。要注意考虑对成本、质量、上市时间、客户满意度、兼容性等方面的影响。例如：必须对基站重新进行设计来支持增加的功能，这样一来便会增加成本，要求运营商们（顾客）对现有基站进行升级会增加成本负担，而他们必须将这些负担转移到呼叫人那里。e) 顾客/用户对操作的任何吃惊反应（正面以及负面的）都要重视。例如：如果需要为此项服务而额外付费（因为运营商产生了追加成本）的话，呼叫人会很不愉快。如果呼叫人在边远地区能够很稳定地进行紧急呼叫的话，他们便会很高兴。而运营商对于必须升级他们的基站则会很不愉快。在完成对操作方式的概括后，在附表的帮助下，依据操作方式把产品包需求分解为设计需求，并在下面图表的帮助下并详细列出每个设计需求可接受的参数范围。应当将产品包需求分解为不同种类的设计需求，包括如下各部分：
功能
环境
性能
强健性（鲁棒性）
可靠性
可维护性
可用性
安全性
重量
电源
尺寸大小
灵活性
其它
为了实现可追溯性，已经在分解层得到表述的分解描述的设计需求应当与特定的产品包需求建立明确的联系。分解得到的设计需求还需要进行合理化处理，包括对设计需求进行分类、合并、冲突权衡、整合、删除、修正等，以形成高质量的设计需求，为后续的产品开发工作提供坚实的依据。附表：产品包需求到设计需求的映射
