互联网产品经理进入传统企业后，冲击最大的可能是传统企业的研发现状：业务人员根据业务需要将需求写成Word文档丢给开发部门，然后开发人员根据需求就开始吭哧吭哧写代码，对于产品框架、页面层级、交互设计等内容，都是开发人员根据自己的理解和偏好一边写代码一边做出的决定。在这中间，如果需要个宣传图、Logo、图标、按钮等，就让一个被称为美工的人马上画一个。
由这样的研发现状形成的结果也让互联网产品经理心中为之一颤：明明一个一直存在的、很成熟、很明确的基础需求体系，其对应研发出的产品经过这么多年的更新迭代，现在依然混乱不堪……
在互联网公司，这样一个很成熟、很明确的需求体系，恐怕早就被研发的妥妥当当、明明白白，后来的产品经理都没有机会经历这个开天辟地的过程，只能做些缝缝补补工作的份儿了。
为何会出现这么大的差异呢？产品经理们会觉得不可思议，业务存在那么久了，行业规则基本也没有变过，为啥这个产品还是这个样子呢？深入之后才发现：原因在于传统企业中有需求文档、有技术方案、有需求评审、有技术评审、有测试文档、有测试评审，但却唯独没有产品方案、没有产品方案评审！
产品方案的缺失，造成了产品上的无底洞。改来改去，却总是改不到位，一会儿觉得这样好，一会儿又觉得那样也不错，没有一个标准。参考别的产品抄来抄去，却也总是抄了表面看不到背后的规则，常常抄了一半后才发现自己的和别人的存在着不同，抄不下去了。于是就会出现一直在优化、一直在重构、但依然混乱不堪的状态。
这在互联网公司简直难以想象，产品经理们不禁要问：难道领导不知道这个情况吗？直管领导当然知道，可是高层领导就不见得知道了！很难有传统企业的高层领导如同互联网公司的高管那样对产品有如此的重视。
在互联网公司，高层领导常常参加的会议是与产品有关的会议。光通过会议参与产品决策还不够，互联网公司的高管还经常过问产品相关的进展和方案。这还不够，他们还经常自己试用、把玩自家产品，并请朋友圈好友也参与试用，直接给产品提出各种意见。早期，腾讯的产品是被马化腾的邮件推着走的；现在，微信的每一个新功能都要经过张小龙同意；创业公司，CEO更是直接参与头脑风暴、需求讨论、产品方案评审等会议，并邀请投资人试用产品、向他们展示产品最新状况等，可见互联网公司对于产品方案的重视。重视的原因是什么？产品就是互联网公司的一切，而产品方案就是产品未来的样子。
那么再来看看传统企业里是什么样子呢？为何传统企业的高层领导很难像互联网公司的高管一样重视产品呢？因为业务模式不同。传统企业的生存也是基于向消费者、向客户提供产品，但是这个产品是业务方面的产品，并不是互联网产品。互联网产品，在传统企业的商业模式里只是一个渠道、一个载体。没有互联网产品，传统企业的生意照样可以运行下去。通过线下渠道、与其他线上平台合作等等，都可以保持公司的运转，实现业务的闭环。其实在互联网发达之前，甚至是移动互联网兴起之前，互联网渠道对于传统企业的作用一直都很小，甚至在早期处于可以被忽略的地位。如保险公司的营业点、电话销售、短信互动销售在业务推广过程中曾经占据着最主要的方式。只是在互联网浪潮发展到今天，互联网公司把各类互联网产品推到大众面前，几乎全民成为网民并养成了良好的互联网产品使用习惯以后，互联网这个渠道在传统企业的业务模式中成为再也不可被忽视的关键渠道，以致于招商银行提出“APP时代”、“推动APP取代卡片”等战略。
那么既然今天的互联网已经如此发达，传统企业的高层也意识到互联网的重要性，也一直都在大喊着数字化转型，那么已经又过去了好几年，为何还会出现产品方案的缺失呢？原因在于虽然对科技提高了重视、加大了投入，但是认识却不彻底，存在误区，表现在如下几个方面。
1、重视科技=重视技术、重视开发人员
传统企业一直有科技力量，甚至有的传统企业其科技队伍的规模还不小。不过大部分传统企业并不是以输出科技产品为经营业务，其建立的科技力量而是用在了对其业务经营的内部支撑上。当互联网浪潮来袭时，各传统企业也纷纷谋划转型，喊出要加大科技力量的投入。但很多企业所提出的加大科技投入却是对技术本身的投入、对开发人员人数的增加和开发人员在公司所有人员中占比的提升。重视科技，表现为了重视技术本身、重视开发人员。事实上，当互联网与传统企业融合时，重视科技，要重视整个研发流程上的各个角色，而不仅仅是开发人员。实际上，能够带来最大改变的是引入互联网完备的科技人才体系，特别是引入产品经理、设计师、运营等人才。其次，重视科技，要重视产品思维、科技引领业务思维的培养，将固有的技术思维进行转变。与互联网的融合是对传统企业生产经营方式的重塑、对业务场景的重构，重点是技术与业务结合的场景化应用，而绝不仅仅是技术和技术人员本身。这其中，业务对科技需求的解决方案，即产品方案，应是研发过程中首要关注的问题。
2、产品方案=产品设计
这是大部分传统企业都会产生的误区。有些传统企业有了科技产品的初步概念（在传统企业中，为了避免混淆，可以把产品分为业务本身的产品和科技产品，如保险公司，可分为保险产品和科技产品，如基金公司，可分为基金产品和科技产品），也引入了互联网专业的产品经理，但他们对于产品经理、产品方案的认识却非常片面。另产品经理烦恼的是，每次一提到产品、产品方案，他们所指的仅仅是产品设计。在他们的心智中，产品方案=产品设计。这个他们，不仅仅是周围的同事，也包含了各层级的领导。产品经理对于这样的现状很难改变，在这样的环境中，产品经理的工作就是产品原型，是画图、是展现、是可视，终是设计，唯独不会和需求、方案关联！产品经理俨然成为了一个设计师！可事实上，产品方案和产品设计完全不是一回事。产品方案是为了解决某个问题而提出的解决思路与落地可执行的具体解决方法。解决一个问题，可能有很多种方法，产品经理需要先把这些方法找出来，然后选择其中一个作为最终的产品方案。产品方案是产品经理的事，而产品设计那是设计师的事。有时一个产品方案，可能根本不需要设计师做什么，而有时一个产品方案却需要设计师做大量工作。
那么为什么传统企业的领导和同事们会认为产品方案=产品设计呢？原因有几点：一是互联网公司产品的用户体验留给他们深刻的印象，他们认为他们与互联网公司的差距主要体现在用户体验上，并且想要迫切的改变现状，将此作为眼前的重要目标；二是他们分不清产品经理和设计师的职责分工，认为产品经理就是做产品设计的；三是传统企业的领导和同事们对于自己的业务深耕多年、经验丰富，对于业务的产品落地方案比较自信，不太相信一个刚上手的外行产品经理能更了解业务、提出更好的想法和产品方案，认为产品经理只需要把产品设计好就行，其余的他们更有经验。关于最后一点，是有些道理的，产品经理刚进入一个新的行业，刚开始肯定跟小白一样，关于业务方面的考虑肯定不够成熟、不够全面。但是我们也要看到，作为小白也有没有形成定式思维、敢于打破常规、初生牛犊不怕虎等优势。小白提出的问题，有时也是行内人之前从未考虑过的一些问题，这些问题里也许就藏着一些创新和机遇。另外产品经理本身的专业也能帮助他们用同样的方法跨行业分析问题。
3、研发流程未随之改变
研发流程不随之改变，产品方案便难以存在。究其原因，在于如下几点：一是还是保持项目制，而不是产品制。研发部门依然按项目进行考核，自然人人关心的还是项目，没有人关心产品现在成了什么样子，更别提关心产品方案了。在项目制下，项目是业务需求和技术开发的载体和运作方式，而不是产品方案来引领研发工作的节奏。业务部门关心业务需求，认为围绕业务目标制定的业务需求搞定以后就万事大吉。技术部门关心技术方案，认为只要能满足业务需求就功德圆满。而在业务需求之下、技术方案之上的产品方案却被不假思索地忽略。产品变成了一个又一个项目的结果，而不是产品引导着一个又一个项目的进行。二是业务人员直接对接技术人员，产品人员夹在其中没有话语权。传统企业引入互联网产品经理后，常常是由于对这个岗位没有充分的认识而没有明确的进行岗位职责定义，这使得产品经理开展工作不便，未能充分地发挥其专业能力，造成人力资源的极大浪费。产品人员岗位职责不清晰，一方面容易与已有岗位产生冲突，很有可能使领导们会觉得产品经理反而增添了麻烦，另外一方面产品经理无法主导产品方面的工作，其价值也无法体现和获得认可。没有话语权，自然产品经理所输出的产品方案也难以成为关注的重点。
说了这么多，再回到一开始的那个例子，明明一个一直存在的、很成熟、很明确的基础需求体系，其产品现在依然混乱不堪也就不难理解了。
如何能让产品方案不再缺失，是传统企业研发工作中需要考虑的一个议题。这个议题，关系到一连串的相关事项，包含意识的转变、人才的引入、岗位职责的明确、研发流程的升级、考核指标的变化等。涉及到这么多核心的方面，却仅仅获得了科技产品一定程度的提升，还不能直接体现出所经营业务各项指标的提升，这或许是传统企业的科技产品一直无法显著改善的原因所在吧。可是不解决这些问题，每当提起时都还是会说科技产品不好用、支持不到位；不解决这些问题，传统企业的数字化转型将往何处去呢？
