如何打造一个正规的、专业的产品设计和研发的团队？这其实是一个循序渐进的过程。而公司规模上从三五成群到二三十人的产品开发团队，公司大小的差异很大程度上影响到产品的优质。下面我们就以不同的公司规模来分析在产品研发上面的区别。

1.工作内容不同

当选择工作时，其实很多人都经常会纠结到底是去大公司还是小公司，所以在这里先谈谈分别在不同大小的公司，或者说在不同量级的产品团队中，自己所负责工作的差异。

1.1 大公司做产品

在成熟型公司，自己只能负责一小部分的项目，因为系统已经基本搭建完成，业务模式也很稳定了，所以自己更多地只能对单点的功能进行持续优化。而在初创型公司，由于业务还在快速发展，很多系统也待搭建，尤其是需要把很多公司内部的线下流程转变为线上系统，这就需要产品设计和开发团队做大量的工作了。

所以在小公司，自己能够独立负责许多完整的项目，比如整个网站和小程序开发项目、CRM的客户管理模块以及一些线下流程的线上化等等。同时更能够看到业务流程的全局，视野瞬间开阔了许多，对自己的整体提升非常大。

不过从另一方面说，凡事皆有利弊，在大公司做产品有3个优势：

一是聚焦，可以对某一个细分模块研究得很精深。毕竟业务发展稳定后，需要从原来的粗放式发展转变为精细化管理。要知道，现在产品经理已经分工很细了，在各个细分模块有专门的信息流产品经理、智能推荐产品经理、商业产品经理、社区产品经理等等。

二是规范，在大公司的产品团队中，产品方法论已经体系化了，所以新人可以接受已被验证过的且有体系的产品能力训练。同时，产品团队的分工、不同部门的分工都比较明确，在配合时也会减少很多的摩擦。

三是资源，大公司不仅有更大的平台和更多的用户，而且有成熟的工具帮助产品经理完成工作。比如AB测试系统、数据分析平台等，AB测试和数据埋点对于产品的迭代至关重要，也需要花大量的时间精力去做这些工作。

1.2 初创型公司做产品

但在初创型公司，虽然可以独立负责更大的项目，但是因为能力的短板，难免只会关注核心流程，很多分支功能做得很简陋和粗糙了。比如社区体系、会员体系、积分体系、广告系统、智能推荐系统等等，难以在单点上聚焦。

就像同时懂前端和后端的全栈工程师极少，能同时做好toB和toC的产品经理更是凤毛麟角。

而且在初创公司，最关键的是依靠产品负责人自己的业务经验，快速把业务上线、快速进入市场、快速解决问题，这些才更符合当前公司的需要。所以如果你要在上线前做AB测试、数据埋点，上线后再做数据分析，前后持续数周甚至数月，显然是不现实的，不符合创业公司的发展节奏，时机稍纵即逝，市场是不会等你的，可能短短几个月市场环境就已经变了。

2. 组织架构不同

2.1 高阶产品

说完在大公司和小公司的工作内容后，还有一个显著不同就是产品团队的组织架构与协作方式，这也直接关系到产品经理们的日常工作。小产品团队只有几个人，结构很扁平；但大产品团队的组织架构要复杂很多了。以产品负责人为例，一个高阶产品经理，其核心能力，一方面是业务能力，另一面则是管理能力。

其中，管理能力的体现就是怎样管理好一个数十人的产品团队。为什么高阶产品经理能力是管理一个几十人的产品团队，而不是数个人或者数百人呢？也就是说，为什么是“几十”这个量级呢？因为几个人的产品团队，一般是初创型公司，而几个人之间的沟通一般是比较顺畅的，非常容易沟通并达成一致的目标。那么在这个量级上的产品团队管理工作并不复杂。

而几十人的产品团队，经常出现在成熟的中等规模公司或者是巨头公司的某个事业群，这个量级是经常会遇到的，而且要比管理几个人的产品团队复杂得多，需要诸多的手段进行管理了，包括明确的制度和不明确的人治。

对于巨头公司呢，虽然产品团队可能达到数百人甚至上千人的量级，但通常会划分为数个事业群和数个业务线，那么每个事业群或者业务部门下的产品团队规模也就是几十人级别了。当然，存在横跨多个事业群的项目，但这是张小龙这样级别的产品经理要考虑的问题了，更确切地说，他们已经不是产品经理，只是在使用产品思维来解决问题，所以数百人产品经理团队的管理问题暂且不谈。

由此可见，管理几个人、几十人以及几百人的产品团队，是截然不同的。而产品经理，管理一个几十人的产品团队，是大部分普通产品经理进阶为产品负责人时必然会遇到的情况，也是必须要学会的能力。

2.2 网状架构

在大公司中，产品团队人数较多，每个人的能力点既有重合，也是各有侧重的，所以常见的组织架构是划分成不同的小组，进行小规模作战。

先是需要横向划分：

可以根据toB、toC划分，比如用户产品经理、后台产品经理；

也可以根据业务线划分，比如可以根据金融业务不同，划分为基金业务产品经理、保险业务产品经理、证券业务产品经理等；

还可以根据不同的系统划分，比如客户端、数据分析平台、开放平台等。

然后是纵向划分：

根据战略层、战术层、执行层进行细分：

有的产品经理能力已经达到了战略层和战术层的水平，就不要花过多的时间在执行层上了——其中，有的人思维开阔，更合适宏观决策，则可在决策层；而有的则业务能力更强，则更适合战术层。而有的人还处于打基础阶段，需要一个一个项目去亲手实践，那就需要归为执行层了。

但这三层并不是明确的上下级关系，执行层同样可以参与战术层和战略层，只不过各有偏重。通过横向和纵向的划分，一个几十人的产品团队就可以很好地组织成网状的架构了。

在实际做项目时，战略层、战术层和执行层的人会相互配合，一起负责同一个项目。比如，一个三人的产品经理小队负责一个项目—— 一个人主要负责执行，第二个人主要负责提供业务指导，第三个人主要负责拍板，把控大方向不出错。

这种三人小队的虚拟架构其实经常会出现，比如刚到一个实习生或者新人，产品负责人可能会安排一个老同事带他做项目，那么这个新人更多是做的执行层工作，而老同事则是提供业务建议和框架，产品负责人就是最终拍板的那个人，也就是战略层。

但这里也经常会出现问题或者摩擦，我在大公司和小公司都遇到过，因为产品负责人会不自觉参与对细节的把控，那带新人的老同事和产品负责人就容易出现冲突了。因为没有两个人的想法能完全相同，也没有绝对的对错，而优劣又常常难以衡量。

此时，最好的做法就是：放权。产品负责人充分信任带新人的老同事，只要没有纰漏或者明显地优劣，就不要过多参与到战术层和和执行层，自己把控好方向不跑偏即可。

这里有个小插曲：在大公司工作时，曾见过一种不太好的组织架构——

每个产品被分进一个个独立项目团队，即几个开发、测试、产品单独负责一个产品或系统，这样既失去了流动性，也难以形成合力，不利于管理。

因为产品经理都会有“地盘”意识，当一个系统基本搭建完成后，剩下的无非是一些修修补补的工作，很难有大的突破。但坐守已有成绩的人也不愿意把手中的项目交出去，只有引入新的力量、新的想法，系统的发展才会有新的可能。

当不同产品经理之间缺乏沟通时，不同的产品和系统之间也难以协同，此时会缺乏长远规划，只是一盘散沙。所以在后来，被打散进不同项目团队的产品，又重新组织在一起成立了独立的产品部门。

3. 工作流程不同

当产品团队人数少时，可能一个会议就可以沟通清楚，需求就能推到开发了。而在大公司，产品团队人数很多时，则需要引入一系列的流程和制度进行把控，其中包括需求排期会和内部需求评审会。因为每个产品经理手里都有自己的项目或者想做的项目，而设计、开发、测试、运营等资源是有限的，这里就存在矛盾，因此需要考虑投入产出比。

那么不只是每个产品经理需要对自己的需求池划分优先级，整个产品部门的大需求池也要划分优先级。此时就需要设立需求排期会了，需求排期会是一种很好的资源配置手段。所有产品经理聚在一起依次过一遍自己将要做的需求，此时的需求还没有详细策划，只是雏形阶段，然后产品总监和几个产品骨干根据当前的业务现状和战略目标敲定优先级。

这样，产品的高层不但可以把控大的方向不出错，也可以减少资源的浪费和冲突。因为每个人的认知都是局限的，自认为手中的某个需求是自己需求池中最紧急且重要的，但站在更高的视角，放到公司全局来看，却不一定了。

同时通过需求排期会，每个人都知道了其他人正在做些什么，既可以避免几个人在做同一件相似的事情，也可以明确自己所处的位置，明确自己要发挥的作用。经常在需求排期出现一个产品经理知道另一个产品经理要做的项目时，发现会涉及到自己负责的领域而对方遗漏了，这时自己就可以和他人协作，补上项目的漏洞，一起把项目做得更好。

等分配了优先级后，每个产品经理就可以将手中的项目详细策划了，而每个产品小组的组长负责审核，进行小组的内部评审。因为开发不会过多关注需求本身的合理性，他们更多是站在技术的角度看待问题，比如好不好实现、逻辑有没有问题、会不会破坏现有的系统架构等等。

那么对需求本身的把控，就要靠产品经理内部了。一个合格的产品经理应该对背后的开发、测试、设计等资源负责。若一个产品经理随意拍脑袋提需求，提出了一些不合理的需求，可能到最后，一整个团队的努力都会白费，这是极其不负责任的。

因此只有经过了小组内部的需求评审，经过产品业务骨干的把控，才可以提交给开发进行评审。从最开始的需求排期会，到小组内部的需求评审会，再到和开发一起进行的需求评审会，这一整套层层把控的流程也正是大公司规范性的精髓所在。

总之，这是通过我自己的切身体验，对比了大公司和小公司在工作内容、组织架构、工作流程三个方面的差异性，同时融入了自己的一些思考。

再回到最开始的那个问题：做产品究竟应该去大公司还是小公司呢？如果你现在是产品新人，有机会的话还是去大厂比较好，可以学到更规范的产品姿势，而要是想寻求从初阶产品到高阶产品的突破，则适合去一些初创公司，因为会有更多的机会和发挥空间。一句话总结：在大公司培养能力，在小公司发挥能力。