产品包是产品开发团队对客户或下游环节交付的统称，是产品分层次理论在实践中的具体应用。
抛开内部向下游组织交付的内容，先看一下向客户的交付。拿软件来说，我们一般都能够说的八九不离十，软件安装文件、操作手册、维护手册，基本就差不多了。
通常的理解，产品开发团队的任务就算完成了。事情是不是这样的呢？我们通过一个例子来看一下。
面向客户的产品包
假设您是一家大型企业的IT部门的主管领导，负责ERP系统的选型，有两家供应商来给您做产品展示。
第一家供应商向您展示了丰富全面的产品功能，涉及企业管理的各种职能，各种统计分析功能，操作体验方便又快捷，界面看着也很舒服，最后表示您需要的功能都有，只要上了他们的产品，不用担心有覆盖不到的需求。
轮到第二家供应商，他们没有展示具体的产品界面，而是从企业一般的发展过程入手，结合同类型企业的通常情况，介绍企业在不同时期可能会面临的问题，表示他们提供的正是这样一套完整、可持续的解决方案，可以帮助您进行管理规划，和您一起解决您遇到的问题，为您进行个性化定制，而不仅仅卖给您一套软件。
此时，作为方案的决策者，抛开预算的因素，您觉得哪一家更值得信赖？毋庸置疑，大多数会选择第二家供应商。
我们对比一下两家供应商。第一家供应商在简单的推销产品，给客户的印象就是你就是来向我卖东西的。
第二家供应商告诉客户，我们了解处于各种阶段企业的管理需求，我们了解您所在行业的情况，我们会按照您的需求帮您制定适合的解决方案，并且我们的方案是可持续的，软件只是实现这一方案的工具，现有的系统数据可以帮您迁移过去。这样的供应商，给客户的印象是他能来帮我解决问题。
客户对这两种供应商的认知高下立判。这是为什么呢？第二家的产品比第一家好太多吗？
未必，任何决策者都不可能通过一次展示会就能够完成对产品的客观、实质性比较。那这种差距是如何产生的呢？
产品的5层次理论很好的诠释了其中的原因。产品概念的5层次分别为：核心产品、一般产品、期望产品、附加产品、潜在产品。
第一家向客户推销的只有一般产品。第二家就不同了：
首先，告诉你我了解企业生命周期的一般规律和管理诉求，我了解你的行业，我可以根据你的情况提出建议和方案来解决现在面临的问题。客户买ERP的核心动机是什么？不就是要解决企业的管理问题吗？切中要害，打中了客户需要的核心产品。
其次，既然我是来卖ERP的，当然有产品，虽然只是简单的展示，但我对管理和行业的理解，已足以让你信服。给客户的感觉是一般产品自然不会差。
然后，客户再想，我现在有ERP，只是效果不大好，但原来的数据我还是要的。没问题，我帮您迁过去。又满足了客户的期待，期望产品也不少。
接下来如果再打个折，送个售后啥的，客户下决心的理由就更充分。卖东西这个应该不会少吧，这是附加餐品。
最后，企业是发展的，我们的方案也是发展的，我们管您现在，还管您将来。这是潜在产品。
所以，表面上两家都是卖ERP的，但第二家赋予了产品更广泛的内涵，水平上的对比是显而易见的，但却不是体现在ERP软件本身，而在于一份向客户介绍产品解决方案的PPT。
竞争在实物产品之外，各位想想看，5层次理论各层次的产品，是否都是面向客户的交付？是否都应该是产品包的组成部分。解决方案是、ERP软件及说明书是、数据迁移服务是、报价和服务方案是、长尾服务的引导也是，这个演讲用的PPT也是。
因此，5层次产品是产品包的竞争，产品创意和设计的过程中，要从这5个层次综合考虑，升维思考，降维打击，面对这样的对手，单靠只覆盖一般产品层次的交付如何扛得住。
面向下游环节的产品包
下游环节，主要是企业内部的组织，比如采购、生产、交付、运维、市场、销售等。这一部分交付往往是被忽略的部分。
产品需要经过创意、设计、开发、验证、生产、市场、销售的整个链条才能够实现其商业效益，而大部分企业的开发团队，也就是项目经理、架构、开发、测试，最多再加上运维，还可能是多个项目共用。这样的团队配置，最多能够保证把开发阶段的事情做对，至于是否做了一件对的事情？生产、营销等环节是否能够获得成功，大部分是到产品快要上市那一刻才来考虑。在竞争如此激烈、时间就是效益的今天，这怎么能行？看看下面的情况吧：
生产的兄弟说，大哥，上市时间这么紧张，我得先搞生产环境啊，加班加点都不一定能行。
采购的兄弟说，你们研发时用的元器件已经块换代停产了，短期还凑合，未来两三年的采购不好保证啊。
质量的兄弟说，你们用的元器件之前公司没用过，没有经过公司质量测试，直接用在产品上不合规啊。
交付的兄弟说，人家都docker了，安装维护简单方便，交付分分钟搞定。我们还传统方式，一通安装配置，操作规程繁琐容易出错，交付产品的质量不容易稳定，交付成本还居高不下。
市场的兄弟说，我们的生产成本都超过市场上同类产品的定价了，我们的价格咋定啊！
……
这是产品开发团队以产品和开发为主导所经常遇到的情况，只考虑把产品做出来，往往对生产、交付、运维、营销下游环节考虑的不充分。
在集成产品开发（IPD）中，产品开发团队（PDT）是一个组合团队，包含来自市场、产品、开发、生产、交付等各环节的PDT代表。
在需求阶段，这些成员代表各自环节，提出本环节对产品的需求，每一方的需求都会形成向该环节交付的产品内容，这些内容的集合，就是产品开发团队向下游环节交付的产品包，这些需求就是产品包需求（Offering Requirements）。
我们也可以把面向某一环节的子产品包称为产品包，如市场需求包、生产需求包等等。
看个产品包需求的例子，有助于我们对产品包的理解：
市场需求 OR.MKT.****
成本需求 OR.DFC.****
质量需求 OR.QA.****
环境需求 OR.ENV.****
国际化需求 OR.DFI.****
可交付需求 OR.DEL.****
标准要求 OR.STD.****
……
其他需求 OR.ETC.****
用进度的思想武装自己，升维思考，降维打击
产品开发团队从交付产品，到交付产品包，是一个思想上的巨大进步，不仅考虑把事情做对的问题，更是从源头上考虑做的事情本身是对的、全面的、完整的和高度协同的。
诚然，因为企业组织结构、综合能力和资源的限制，无法全盘操练起来。但是，至少可以提供一种理念，使产品部门/产品线领导、产品经理及整个产品开发团队在需求阶段能够纳入更多的需求因素，减少后续环节可能遇到的麻烦，提高研发的综合时间效率、资源效率和收益水平。
产品概念系列文章请参考：
产品概念之1/4：前言 —— 有必要这么学术吗？
https://blog.csdn.net/zhanglinneu/article/details/85104000
产品概念之2/4：三层次理论 —— 生产者主导视角的产品概念
https://blog.csdn.net/zhanglinneu/article/details/85104567
产品概念之3/4：五层次理论 —— 消费者体验视角的产品概念
https://blog.csdn.net/zhanglinneu/article/details/85105389
产品概念之4/4：产品包 —— 升维思考，降维打击
https://blog.csdn.net/zhanglinneu/article/details/85106546