先对小团队作个定义：产品+研发+UED少于10个人，就算是典型的小团队。
10-20人也算是小团队。
100人以上算是大团队。
只计算产品研发的人数，是因为运营部门通常和产品部门同步增长，当运营人员增多，需求增多，产品研发人员也会增多。而产品研发的效率是互联网公司的发动机。
“如果不是微信/微博这些巨型APP，高德地图/滴滴打车这些重后端的APP；O2O这些重运营的APP，其余的大多数APP都可以由小团队来完成。”
如果我们通过项目复盘，仔细厘一下研发浪费发生在哪里，你就会发现：
首先是方向上的浪费。比如没划清楚主干道在哪里，对不重要的分支进行投入；或者没划清楚产品边界在哪里，对注定失败的拓展进行投入。美其名曰“试错”。试错这件事情大家都会做，但对成功率的预判，对预设目标与投入资源的分寸，人和人的差距可以大到几十倍，产生的研发浪费可以大到三五倍。
其次是低价值需求的浪费。低价值需求分三种，一是错误预判了用户需求，自以为聪明地研发主流用户并不在意的功能；二是在试错过程中，没做到小步快走，在反响不确定的时候把功能做得过重；三是抠细节体验抠出血，喝了“细节决定成败”这碗毒鸡汤。
所有的低价值需求都不影响成败，却造成大量的研发浪费。彻底消灭低价值需求是不可能的，只能控制它的比例。在一年的研发周期里，大多数产品的低价值需求在50%以上，也就是浪费了一半以上的时间。但以我的经验来看，控制比例在20%-30%是有可能做到的。
再次是产品经理level高低带来的浪费。好的产品经理，一是预判产品发展路线，提前推测出来产品可能的几条发展路线，提前做好规划，减少推翻重来的迭代次数。二是凡事都会考虑到研发成本，能复用的尽可能复用，能精简的尽可能精简。三是排期灵活，对优先级厘得特别清楚，很多低价值需求在降低优先级之后，拖着拖着自己就消失了。
最后，以上三点浪费如果能得到良好控制，程序员减少几倍，沟通成本随之减少几倍，带动研发效率翻倍上升，就可以实现我说的，大多数APP由小团队来完成。
敲黑板，划重点：“小团队的精髓并不是牛逼的程序员，而是对需求的冷静把控。”具备这个能力的人很少，所以产品经理越多项目越乱，PM扎堆的地方就跟养蛊一样。我曾经夸口说，只要由我带队，就能长期维持小团队，也是这个道理。
但我这个夸口经常被人喷，说你做产品不成功，没有说服力。
是这样的，无论产品成不成功，以上对成本浪费的分析都是成立的。最大的区别在于，产品发展起来以后，出于抗风险的考虑，每个位置都要有备份机制，团队数量×2，效率随之下降。像蝉小队那样长期3RD是不可能的——但6RD2PM2UI，还是典型的小团队配置。
产品发展起来，几千万融资到位以后，真正杀死小团队的不是业务成长，而是亢奋带来的需求膨胀。原本抠需求是因为穷，没钱请不起人，只能厉行节俭，现在“钱能解决的问题都不是问题”，为什么要斤斤计较呢？无论是创始人膨胀，还是投资人膨胀，都会急着证明“我们有更大的增长空间”，增长达不到(过高)预期，就会加功能甚至加业务线，让资本支持自己去多试错。在工作量增大的同时，核心产品现在也有身份有架子了，不愿意长期在一线干活，要去做“更重要的事情”，哪怕心知肚明一个好PM是何等稀缺。
一系列连锁反应让曾经的精益创业变得笨重，但并非人人如此。
按照科技媒体的报道，Instagram被Facebook10亿刀收购的时候，仅13人。
WhatsApp被Facebook50亿刀收购的时候，仅50人。
美国现象级应用Musical.ly做到千万日活的时候，据说整个上海团队(目前)不足100人。
我自己身体力行小团队战术，四年来维持一支6人的产品研发团队，总体输出可以与低效率的20人团队相比。由于对运营需求的控制良好，这6个人足够为超过30人的运营团队提供支持。以上的明星案例+亲身实践，证明了小团队的长期可行性。
如果你能自始自终地“抠需求”，不会因为傲慢而膨胀。
所以，我夸口能长期维持小团队，相当于下定决心在一线做产品，死都不会脱离产品经理岗位。同时也会选择产品驱动的项目，产品本身就是核心竞争力。只要我对产品话事，就能将上述浪费降低到最小单位，也将产品经理降低到最少人数，从源头上抓稳需求，奠定小团队的基础。至于产品成不成功，那就是产品玄学的领域了。
