成功的决定性因素是人，所以SaaS产品公司产品团队的价值不言而喻。当核心人才缺乏时，不要轻易去SaaS创业。掉进坑里很难爬起来。
一般来说，B端产品的产品开发周期和难度要比C端产品大得多，尤其是产品和客户的维护成本会非常高。【/br/】其实B端产品的货架设置不当，每多一个客户都会大大增加后续维护的无形成本，所以这也是很多传统软件公司陷入泥潭的原因。因为有一定数量的客户，所以很难重构，也不容易再造，陷入进退两难的尴尬状态。从某种意义上说，这些客户都成了负资产，最后公司因为客户多而拖垮了自己。这个结论好笑吗？但这确实是很多公司的现状或未来。
关于SaaS创业团队的组建和日常管理，作者有一些小技巧，可以参考。
1:
根据公司的业务和阶段，来定义团队的MVP。和产品管理一样，在设计和构建团队时，也需要定义团队的MVP组织结构。【/br/】根据公司的业务和发展战略，确定产品线、产品线的总体发展路径以及前后合适的技术选择。基于此，定义了公司目前生产研发团队的MVP结构。
2.在组织架构上，首先要找骨架级别的人。
找一个合格的领导。
俗话说，兵生熊，必有窝。当一个团队缺乏一个合格的领导者时，这个团队基本上是无用的。所以在组建团队的时候，首先要在每一条线上找到合格的领导者。早期团队的领导者可能需要更多的业务能力。团队大了，需要的领导更倾向于管理能力。
在扩展之前，请找到合格的领导。如果短时间内没有办法找到，那就先把队伍搞小，不然以后会造成很多浪费，很多补救工作。
寻找具有核心技能的人才
优秀的产品经理、产品业务架构和功能架构师以及数据架构师在SaaS业务中不可或缺。如果前期找不到，还需要有这样技能的咨询师，这就是SaaS产品的基础人才。
对于B端产品，产品定位的架构师、产品业务架构的架构师、产品功能架构的架构师、数据库定义的架构师是非常重要的。在产品正式开发之前，最好在团队中有类似的角色，否则不要轻易启动或扩大客户。做的越多，客户越多，这可能是公司背后的枷锁。
3.通过适当的人才筛选评价
无论多忙，无论多急找人，都要严格把关这个水平。对于产品、设计、前端开发工程师、测试工程师，你需要定义一个合理的评估流程。不幸的是，笔者在国内从未见过专业的SaaS产品技术人才评估公司，因此大多数公司需要根据公司的情况为不同的职位定义自己的评估流程。
对于产品来说，逻辑思维、业务理解、沟通协调、分析抽象都很重要。可以把部分笔试试题写成测试逻辑思维，然后在面试中分析设计一些典型案例，考察他们的沟通能力、抽象分析和设计能力。
对于前端工程师来说，要有笔试、计算机测试、面试，要用一套笔试试题来考察他们的逻辑能力和基本功。笔者曾经看到一个国外的网站叫triplebyte.com，它的评价题目很好。笔试的时候检查了更多的基本功，电脑检查的很快，代码能力也很优秀。
对于B端产品技术人才，我觉得可以选择一些语文和数学能力比较强的人上学。这两门课程的能力基本决定了B端产品技术人才成长的天花板。
4.以更高的成本招聘高素质的员工
一个好的工程师抵得上三个以上的总工程师，不合格的工程师承担关键任务的后果是毁灭性的，在B端产品中尤为明显。作为一个B端产品，类似于盖高楼，找一个工资1.5倍以上的高素质工程师，总比拼凑一大批不合格的工程师好。
另外，优秀的人会吸引优秀的人，这一点很重要。
5.注意人才的梯度
每条线一般都需要几个角色，比如Leader，可以做Mentor的高级工程师，以及一些高素质、有潜力的初级、中级工程师，这是一个健康、快速成长的团队。另外，在年龄分布上，22-27岁、27-32岁、32岁以上的人群也需要一个合理的比例。
一个大比例的初级和中级工程师的团队，一个太老或者太年轻的团队，都不是很健康。
6.组建敏捷团队、产品线和职能线。
敏捷开发模式目前被证明是非常有效的。在组织架构上，可以采用实虚两条线的汇报方式。虚线为敏捷团队的产品线，实线采用职能线的汇报方式，通过敏捷开发管理的工具，降低日常沟通成本，提高效率。
7.态度比能力更重要，迅速淘汰不合格或消极的人
态度更重要，还是能力更重要。在我看来，很多时候，态度是1，能力是0。
在创业公司，项目认可度和投资往往比能力更重要。一旦态度出现问题，不要期望太高，尽快摆脱。作者的经历很少改变，即使通过交流改变一段时间，也会重复。
在一个团队里，消极的人刚开始是少数，但是很容易像瘟疫一样传播，对团队和公司负责。
8.建立积极向上的文化
创业的目的是什么？在我看来，每天谈论自己的感受和理想的创业者，十有八九不是蠢就是骗。除了创造社会价值，公司的目的是认可稻盛和夫的说法，即创业是为了让员工获得物质和精神上的双重收获。建立积极向上、不断成长的文化，让员工成长、收获，这一点非常重要。团队管理中有几个可以参考的行动:
编制工作的原则和规范
在产品团队中，要尽力为每一个工种制定相应的原则和规范，让大家都能遵守。
比如产品和技术的Backlog优先级的确定原则、交互规范、UI规范、代码规范、数据库设计规范等。这些规范和原则可以让所有员工参与制定、迭代、优化，方便大家理解，降低沟通成本。
庆祝小胜利，执行小处罚
团队需要尽可能频繁的庆祝胜利，每一次迭代都是按时成功发布，每一次产品数据有所突破，都需要一定仪式感的庆祝。对于一些低级的bug，可以用一个小的惩罚，比如给团队发红包。生产和研究团队很难用传统的KPI来管理，但他们也需要避免多做少做，做好破坏相同文化的工作。
高质量的分享交流会议。
对于每个功能线，作者强烈建议每周讨论一些关键问题，可能是一些产品需求，产品设计，技术解决方案，或者是一些相对想象的文化问题。
每周至少组织两次高质量的研讨会，让大家参与。高质量的分享和沟通会让团队更紧密，让大家学会从不同的角度思考问题。你可以买一些零食和水果，大家会围坐在一起讨论，寻求每个问题的最佳解决方案。
最后，团队也是产品，是公司成功最重要的产品；创新、保持和积极的方法都很重要。
