企业发展的驱动力可以有哪些？

企业的驱动力有4种：产品驱动、营销驱动、运营驱动、资本驱动

一，企业要成功。也是四个方面都要有，区别在于顺序，和价值观。资本驱动型企业以资本为第一驱动顺序的，忽略了产品驱动和运营驱动，你会发现这个企业死的很快。比如OFO，不注意产品，运营不注意股权结构，结果一味靠资本驱动，最终破产。以资本为第一驱动的企业，典型的还有瑞幸咖啡。每天亏损400万，两年开数千家店，每天亏钱。为的就是追求市场占有率，让数据好看。但是你会发现，亏损过了，投资人的钱不是无穷尽的，早晚要回报的。那这个时候，企业就不好过，所以就走向资本市场，用股民的钱，用股民的资本，去玩自己的野心。瑞幸产品我体验过，咖啡也很好喝，但是他发展的快速，完全不是产品驱动的，而是资本驱动的。

二，产品驱动型企业以产品为第一驱动的企业，有知识付费类樊登读书，通过讲书的质量，产品的差异化，迅速抢占了市场，后期再通过运营，加盟，代理，通过营销驱动，资本驱动，做的很不错。而那些不注重产品驱动的知识付费平台，或者知识付费课程，项目几乎处于倒闭状态。想想，你现在还去荔枝微课、千聊、喜马拉雅、得到上去学习吗？你囤的那些专栏，都学习完了吗？典型的产品驱动型企业，有小米，华为，营销驱动型企业以营销为第一驱动的企业，有很多是互联网IP做的合伙人项目（动则收几万的创客费用，联创费用，实际上你就是一个sale），你之所以推荐这样的项目，就是因为为了利益。开一单，就等于人家努力一个月的工资，诱惑太大了。还有一般就是微商的项目，当然也有好的微商项目。微商产品利润最高可以到达70%，十足的营销驱动，利益驱动。

三，由于大部分成本都消耗在营销成本方面了，因此产品活得不久，大部分产品生命只有几年，最近一位业界专家表明，目前没有听过哪款微商产品活过超过7年的。如果一个产品、项目的利润有70%以上，那一定是产品或者服务质量灌水，甚至毫不在乎的产品或者项目的服务品质。由于不注意产品驱动，或者把产品驱动抛在脑后，最终你成为了别人的收割机，而被收割的对象，是你苦心经营多年的友谊，人脉资源。

四，运营驱动型企业以运营为第一驱动的企业，在股权设计上，在搭班子，建立团队方面非常优秀，但是这样的企业如果把产品驱动排后，忽略产品驱动，一味的做运营，喊口号，开常委会，带势气，虚激励，而产品本身没有硬核竞争力，没有差异化的亮点优势，那么无外乎出现一种现象：一将无能，累死三军。跟着的人也会苦不堪言，赚不到钱。因为这样的产品，不受市场欢迎，不能解决消费者的问题，即便是做了再多的员工激励，消费者也会啪啪打你的脸，让你意识到要好好做产品。

五，做好企业，首先是产品满足市场需求，有竞争力。所以，做好企业，必须是产品驱动为首。任何不是产品驱动为首的企业，都是寿命短的企业。我们看看，老干妈，王守义十三香，同仁堂，云南白药，全聚德烤鸭，也许这些企业做的不大，但是他们是实打实的产品驱动为首。就可以做到百年企业。营销驱动可以企业赚到钱，运营驱动可以让企业做的大，资本驱动让企业做的快，只有产品驱动可以让企业做得久。

判断行业的未来空间的一个基本要素：分析行业是需求驱动是供给驱动

关于这个的判断，也看了很多大佬们的分析，但是仍然不是很明确，因为不同时间点行业的增长是驱动力是不一样的，而且对于行业和公司的分析角度是不一样的。

以互联网公司为例，互联网公司与传统行业的关系有三种：替代（媒体，社交软件）、改造（线上购物去掉了经销商）、创造（uber，共享单车）

在行业的发展前期，一般都是需求驱动，因为这个时间点上大部分人对于产品的接受度比较低，所以行业的增长是更多的用户接受了新行业的服务带动了整体的增长。随着行业的不断成熟，渗透率增高，行业的发展依靠供给上的变化驱动。举一个具体的例子：外卖市场分为三种，校园市场，白领市场，居民市场。其中校园市场是商家和用户都集中，点到点的配送。白领市场是两端都分散，居民端是用户集中，商户分散。切入市场先从校园市场做起，因为点到点的配送最容易，而且商家已经有配送能力了。校园市场时是需求驱动，因为商家有送外卖的能力，学生有吃外卖的需求，但是这个市场并不大，核心原因是学生对于价格高度敏感，所以愿意支付额外外卖费用的并不多，而且叫外卖的用户已有固定的习惯（传单，电话名片），所以要把这些用户转移到线上，通过发优惠券的方式，来激活这个市场。但是这个市场和饿了么打了很久，到2016年底没有分出胜负。于是开始朝着白领市场进军，但是白领市场的能力要求是不一样的，首先供给端白领市场愿意送外卖的商户比较少，其次需求端白领在意的是配送速度（中午吃饭时间有限），与商家质量（优质商家）。而这个市场现有的供给，有配送能力的商户（黄沙拉麻）是不能满足这些用户需求，而那些优质的商家由于生意忙不过来又不愿意送外卖，所以只有自己建立配送能力才能将这些商户迁移到线上。

其实想想淘宝也是这样的例子，早期的淘宝主要是一些非常便宜的商品，加上通过优惠吸引用户，主要也是需求驱动。到了发展的后期品牌店开始加入进来，服务了大众用户。

再举一个例子，初始阶段是供给驱动的，例如iphone，前期是通过供给来驱动，在没有这样的手机前，用户并不知道有这样的产品，iphone的出现定义了智能机。小米也是类似的，用户有性价比高的智能手机需求，但是没有这样供给。小米的出现促进了手机行业的发展。供给驱动的阶段有明显的特征，就是供不应求，用户往往需要通过加价才能买到，早期的iphone与小米手机，甚至2000年左右的电脑，2004年左右的汽车市场均是如此。

但是看这些例子，好像非常明确。但是具体到自己所在行业的时候，常常难以看清楚。因为前者就像是看历史，结局已经知道了。但是当到自己的时候，就是看直播，你也不知道行业现状是怎么样。

公司的运行方式有两种：“产品驱动”和“技术驱动”。

国内甚至国际上绝大部分的公司都是“产品驱动”型，它的运作方式是这样的：公司高层负责“战略布局”，只提出需求“我要个什么东西，能实现什么功能”，然后给出一个时间点，要抢在什么什么时间点上线这个项目。如果有现成的团队，那么由这个团队去完成，如果没有，那么招人或内部调整组织起来这么个队伍。队伍里会有产品经理和项目经理，产品经理负责设计工作的把控和对产品的收益负责，也就是说，由他来对这个产品的经济效益扛KPI。项目经理负责开发团队的日常进度管理，协调资源分配开发任务什么的。产品经理和项目经理虽然同称为“经理”，但事实上，产品经理是公司高层和开发团队的扭带，公司高层并不会关心开发工作的细节，他们只会跟产品经理衔接，对于开发团队来说，产品经理是公司高层的代表，是项目需求方，而且他对产品的经济效益扛KPI，所以产品经理其实权力非常大！

但产品经理通常都没有技术背景，他们不懂技术，也不懂工程师文化，不知道工程师对什么在意，他的思想集中在“商业”和“产品设计”上。项目经理的职责是对项目的进度进行把控，他其实是很需要“软件工程”方面的知识的，如果项目经理靠谱的话，事情也好办，但往往项目经理大多数对“软件工程”其实并不太了解，项目经理往往是“技而优则仕”提拔起来的，也许“开发”能力过得了关，但“开发”和“管理”是两码事，“软件工程”之所以能独立成为一个方向，正是因为其重要程度已经达到了一个不可忽视的地步——上世纪六、七十年代的软件危机，就是因为缺少“软件工程”方面知识的指导而暴发的。

项目经理对“软件工程”的知识欠缺导致的问题就是：公司高层习惯了指定一个粗略的项目需求和一个时间点，而产品经理接受这个任务，一方面对项目需求进行进一步的详细设计并定时向高层反馈项目进展，另一方面对开发团队提出详细的产品需求。开发团队接受开发需求，在项目经理的带领上进行实际的项目开发。这里有两个问题需要重点关注：“时间点”和“产品需求的详细度”。“时间点”是由公司高层决定的，他们习惯了这样的方式，而“产品需求的详细度”是由产品经理控制的。我们知道软件开发的几个步骤应该是“提出需求-->概要设计-->详细设计-->编码-->测试-->发布”，理论上在工程师“编码”之前，产品人员应该把“详细设计”的工作做完，“项目需求的详细度”应该非常高，项目进入编码阶段，需求就不应该再改动了。但稍有经验的工程师都知识，产品人员不会也不可能会在项目进入编码阶段前完成详细的设计，他们总是会不停地进行修改。理想情况下，项目经理应该会很懂“软件工程”，为了保证项目进度，他们会对开发团队做出一些保护，阻止产品人员在项目开发过程中修改需求，就算无法完全阻止，至少会做一些措施，提高产品人员修改需求的门槛——比如说，修改可以，但时间点要重新预估。也就是说，“时间点”确定的前提下，“需求的修改”就不能那么随意，必须有一套合理的游戏规则平衡“高层管理”、“产品经理”、“项目经理”、“开发团队”各种角色的责任和权利。但实际情况是，产品经理权利过大，项目经理往往无法保护开发团队，更有些甚至不懂去保护开发团队，只会“拿鞭子抽”，成了一个监工的角色。开发团队于是成了埋头干活，却几乎完全没有话语权的编码机器人。时间点确定了，需求不停地改，监工不停地催，代码在一次次修改中越变越腐坏，只好不停地加班，期望通过延长工作时间这种原始的办法来按时完成开发任务。结果就如大家所熟悉的那样：开发人员抱怨产品人员需求老在变，代码越变越糟糕满是bug，产品人员抱怨开发团队不能按时交付高质量没bug的产品，开发团队加班严重，人员流失严重，项目组成员不停地更替，交接工作不可能完美，新人且对历史遗留代码头疼不已，项目开发前快后慢，维护成本越来越大直到某一天，某人实在受不了了，大喊一声“重构吧”。。。

上面提到的画面大家一定很熟悉吧，没错，这是“产品导向”的公司的基本行态。产品经理权利过大，产品的原型完全是由产品人员和公司高层决定的，开发团队完全是棋子，编码机器人，开发压力大，加班严重，生产的代码质量差，很难在预计时间点交付高质量产品。所谓“兵熊熊一个，将熊熊一窝”，在这种体制下，整个产品线完全围绕产品经理转，再牛B的工程师也扛不住不靠谱的产品经理，产品经理是如此之重要，以至于一个不靠谱的产品经理很可能会毁了一整支团队。“产品驱动”的体制大体上分产生两类问题：1）产品创意来自非技术人员 2）软件开发管理混乱。 对于第2点，通过推行好的软件开发方法（比如scrum）可以解决，当然，推行起来会有它的困难，但这不是这篇博客想要探讨的，后面有时间会再另写一博文探讨。对于第1点，完全无解，“产品驱动”的机制先天就无法解决这个问题。“创意”应该来自两个层面，一个是脱离技术的纯应用层面的创意，这是产品人员的长处，他们的灵感主要来自于用户需求，发掘用户所需，提供用户所想但IT圈里还没有做的产品，比如团购、sns都是另一个层面应该来自技术层面的创意，比如说技术上出现了什么新的技术，这种技术如何合理应用，发挥一些创意，可以用它来做成什么的产品，它的灵感来自于各种技术api的创意用法，比如gmail的ajax，比如google地图，这些都不可能由非技术人员去创意出来，他们压根就不知道这能否实现，对这种类型的“创意”他们并不敏感。虽然任何产品最终最会落实到具体的技术实现上，但非技术人员对技术层面不了解，这是他们的短板，哪怕他们再也创造力，技术上的创意他们无能为力。

“技术驱动”型的运作模式非常罕见，google应该算是。如果在产品驱动型的公司，工程师们想到什么创意其实很难去实施，很难去启动一个项目——大多数公司面对工程师的创意会去问“有其他公司在应用这个技术吗？”，如果没有，那么很难得到高层的支持去做。所以你可以看到国内大多数公司只会去抄一个国外的创意项目，迅速将其山寨化，拼的是山寨的速度，而不是创意。在技术驱动型的公司里，可以很好地发挥工程师们的创意，启动一个项目的并不是公司高层，而是工程师自己，工程师自己有什么创意就可以动手去跑这个项目，项目没有一个明确的上线的时间点，甚至不一定被要求要上线。项目开发到相对完善的程度了，可以请产品经理参与进来，如果产品经理对这个项目感兴趣，可以从产品设计角度提出修改意见，并帮助工程师将项目运作起来向外发布。产品经理的角色权力不会过大，他们在他们擅长的领域“产品设计”领域里可以发挥所长，但不会对“项目开发过程”有权力——他们并不在行这个，这方面他们没权力反而更好，对技术层面负责的完全是工程师。产品经理的KPI考核会有别的机制，并不像“产品驱动”型那样，背负过重的压力，导致有过大的权力，导致在他们不擅长的“管理”领域不得不过分关心。在“技术驱动”型的公司里，工程师有着非常高的权力，有着自由得多的时间，做着自己感兴趣的事，他们的KPI考核机制也和“产品驱动型”公司完全不同。为什么google是工程师梦想的天堂？不是没有原因的。

“技术驱动”型的公司竟然这么好，那么为什么这么多的公司都不用这种模式？因为他的成本很高，产品的原型完全是工程师去做的，也许他最终只能成为一个“技术成功”的项目，而无法带来“商业价值”，因为这不是工程师们的兴趣和长处所在。也就是说，也许100个项目里，最后有一个项目获得了商业上的成功，其他99个也许挣不到钱，甚至有可能夭折。而且技术驱动的公司，对工程师的要求很高，不会让一些能力很弱的工程师来公司混日子，公司相对很自由但相应的，进入门槛会很高——google和facebook的招聘条件大家都有所耳闻吧？门槛高意味着开出的薪水也会很高，而这些工程师开发的项目还有可能并不挣钱！“技术驱动”型的公司，必须有玩得起的资本，并不是什么公司都玩得起和有那个胆量去玩的。

---