多线产品作战，奔疲于不确定的路上

最近复盘自己操盘的项目，几条产品线并进，自己和团队一直处于忙碌的状态。

之前，我聊过业务方和用户提需求，才是我们产品迭代的源动力；我对业务方/客户方提出需求的态度，是积极包容，进可能去消化的态度。用户反馈也较为满意。

人们常说，产品质量最关键是精准的把握用户需求的本质，用户才真正的满意。

尽可能的把用户需求纳入到产品需求之中，这样经过一年甚至过久的演化，满足的需求越来约多，功能模块越来越多了。

虽然现在应用微服务，应可能的做切分，应可能的做复用。开发框架和开发标准化把控得也好，出问题的概率也就低很多了。

但毫无疑问，随着代码和业务逻辑越来越复杂，系统庞大起来了。

过于臃肿的产品，会大大增加客户的使用成本，在稳定性上，难免会出现掉链子的环节。

过于庞大的系统，用户一进来像迷失了方向，再加上很多功能来不及打磨，使用起来也不趁手。

这时候拼得不是产品，而是客情了。有句话叫：你在饭桌上拼的酒，就是团队没有流得汗。

但问题是团队整天也忙得团团转，汗也流了，那么肯定是管理层的问题，是策略性的问题。

现在回顾这一历程，可以说对于大部分垂直在一个细分领域的 SaaS 公司来说，产品标准化程度决定了企业的生死。

唯有打磨过的标准化，才能给用户带来确定性的感受。

SaaS 产品需要服务于众多企业：少则几十家，多则数十万家。因此，对业务的包容性比较强。代价则是标准化要做得好，上线前还需要打磨，产品迭代速度相对缓慢。

对客户的需求尽可能去消化，去满足，强调贴身的是伴侣氏服务，一般适合于自研系统，只服务于一家企业，本质上还是定制路线。

这样对产品包容性要求较低，但是迭代的速度快。当然客户的体验也好。

既已做了 SaaS 产品，那怎么破呢？

一个重要的标准就是：当用户数不断增加，产品功能不会被推翻或大幅修改，即我们可以只做加法，少做减法和改法。

减法和改法，意味着需要更改颠覆原来的模块，会波及其他的客户，同时数据也面临着考验。

好的 SaaS 设计就是尽量做“加法”，避免做“减法”和“改法”。

同时要求，产品功能尽量标准化，打磨稳定性和易用性，就是需要我们提前花大量的时间做各种细致的准备。

在资源有限的情况下，与其多线作战，奔疲于不确定的路上，不如以优势兵力打局部战争，确定性永远优于不确定性。

少即是多，多做不如少做。要做就做可叠加的加法，而不是在不增长的怪圈中只做需求变更和修改。