软件已死？SaaS就一定是未来？王者荣耀ar相机

趁着周末2天，读完了这本《SaaS产品经理从菜鸟到专家》，读到一半不小心弄丢在火锅店了，于是乎，又买了一本回来。

看书名就能猜出本书围绕的核心人群是SaaS产品经理，全书共分为5章，分别是：SaaS基础知识、SaaS产品的6大素养、5大技能、从0-1规划一款SaaS标品和SaaS产品经理进阶。

看完后，总而言之，是围绕一名SaaS产品经理的成长来展开的，首先需要知道什么是SaaS，其次，SaaS产品经理所需的能力和技能，再就是如何实战上手做一款SaaS标品，最后则是展望未来，看看如何迈向中高级的SaaS产品经理。

于我而言，最有用的章节是第5章——SaaS产品经理进阶，最有同感的是第2章——SaaS产品经理的6大素养，这两章节适合有一定基础的产品去看；其余章节讲的比较基础和接地气，适合刚刚入门的产品同学。

下面，就来和大家分享下读完的3点感受，其中有同感，当然也有一些持疑之处。

作者在第二章列出了SaaS产品经理的6大素养：热情、究竟精神、自以为非、学习能力、结构化思维、沟通能力，其实这不仅仅限于SaaS产品，也适用于大部分类型的产品经理。

从冰山模型来看，热情、究竟精神、自以为非都是处于最底层的动机、价值观这一层，是让我们愿意做、能够做好产品的底层因素；而学习能力、结构化思维、沟通能力则都是处于第二层——可迁移的能力层。

一个产品所需要的素养不止于此，但这6点中，我最近深有感触的倒是——究竟精神。

作者说自己认为的究竟精神有2层意思：

• 一是对于工作要刨根问底，寻求事情的真相

• 二是追求极致的工作结果，做到自己能力范围内的最好

看起来似乎是人人都懂的道理，但真正要做到「知行合一」却是很难。尤其是当产品积累了一定的经验之后，就越有可能陷入知识的诅咒，难以做到纯粹的究竟。

举一个自己的反面例子。

在一次需求评审的产品内部会议上，leader说需要通过A功能不仅实现A场景的需求、还需要通过A功能去实现B场景的需求。

但是，当时我认为A和B场景是截然不同的2个场景，怎么可以通过主打满足A场景的A功能去实现呢？

于是，我先是分析了2种不同场景的区别、再列举了竞品以及市面上大部分头部产品都有专为B场景设计的B功能的例子进行了反驳，并由此推论出B功能是为了提升整个系统健壮性，不能简单的用A功能去进行满足。

这时，leader反问我一句：既然你要提升系统的健壮性，那么，都有哪些因素和情况会影响系统的健壮性，你有做全面的调研吗？

没有。

于是，经过2天周末加班，看了非常多的资料，最终拿着充足的资料再次去找他re。不论最终的结果如何，这次的经历让我深刻地感知到——B端产品的每一步论证都需要像写论文一般严谨。

为什么？虽然几个功能做起来无非就是加人天的事，但长此以往会造成2个问题：

• 产品成了无脑的功能堆砌，一旦上线，砍不动但维护起来又极其恶心。如无必要，勿增概念和功能

• 在缺少思维锻炼后，会形成思维惰性。

  由A推导出B，一定是一个相对严密的论证过程，而如果你长期身处思维的舒适圈中，就会容易出现这样的情况：你为了推导出B，而选择了A；或是你轻易地用A这个必要不充分的论据直接得出B。

  在其他人大眼看起来，好像你还经过了一个相对比较严密的推论过程，但这其实是自欺欺人所得出的结论，甚至还不如直接拍脑袋做决策。

  因为拍脑袋至少会让人觉得有一定随机和失败的成分在，而这种假论证却像披着糖衣的炮弹，让人在一堆「正确的言论」中意识不到它逻辑的错误。

所以，相较于其他5点，究竟精神其实是很难知行合一的一件事，难就难在产品经理往往拥有过大的决策权，在这种容易「一言堂」的情况下，就更难做到纯粹的究竟。

说句题外话，可能这就像创业一样，大部分团队坚持到80%就死了或者放弃了，但成功的往往是最后那极小一部分坚持的人。究竟精神也是一样，大部分人很容易到自己思考能力的80%就放弃了，转而接受了这个凑合的答案。

长此以往，便很容易滋生出思维惰性，难以获得突破。

当然，这里并不是说所有的事情都要思考到自己的极致，而是要在关键方案和关键决策上尽可能地尝试做到极致，这是一个非常关键的突破点。

「软件已死」这句话是Salesforce创始人贝尼奥夫在从Oracle出走创建Salesforce时提出来的。

当然，这句话要辩证的来看。

毕竟贝尼奥夫在说这句话的时候，确实是在Oracle软件产品发现了一些问题和机会，才转而去做了SaaS；但这句话也未免不是一句具有营销性质的「广告词」。

但是时隔20年，我们也没发现软件「死」了， 甚至国内一些软件公司依旧混地风生水起。

当然你可以说就国内市场来看，2015年是SaaS元年，整个市场还在发展过程中，所以还没到完全替代软件的阶段。但这里我想说的是，SaaS从某种角度是一种趋势，它有其优点和适应的场景，但绝对不到替代软件的角度，甚至也可能不是互联网B端产品的终态。

SaaS的出现确实是一种全新的商业模式，它打破了软件公司高高在上的姿态：在新技术出现后、竞争越来越激烈的时刻，SaaS通过提升买方的议价能力倒逼软件公司自己开始卷起来，提供一种更便宜更好用的B端产品。

这种模式本身也适应了市场的发展规律，软件刚出来时还是卖方市场，逐渐随着竞争的加剧、技术的提升、壁垒的降低，逐渐转入了买方市场——B端客户拥有了更高的议价能力。

但SaaS这种模式，对创业公司对市场需求的把控、对产品的把握都相较于软件有了更高的要求，一股脑地冲进来创业，几年内都很难回本。

说了这么多，只是想表明我对SaaS的看法并不像书中那般乐观。

出于合规、数据安全、业务稳定等诉求，目前市面上还有大量KA客户会直接买源码、软件定制以及私有化部署等，并不是说他们不懂得花少点的钱买同样体验的产品，而是KA背后有非常多的出于业务稳定和数据安全的考量。

假设我买了一家SaaS产品，隔几个月突然升级更新了，我还需要在整个公司再上上下下培训一遍，甚至更新后的版本可能不符合我公司原有的业务；甚至再夸张点，SaaS公司毕竟是订阅制，数据都放在上面，过几年公司垮了或者将我的数据再转手给其他人怎么办？

所以，SaaS本质上只是降低了B端服务的门槛，在面向小微和某些KA客户的非核心数据业务肯定是非常有优势的，但要是面向KA客户的核心业务和核心数据，这种模式本身就决定了很难切入。

其实SaaS和软件并不是一个非此即彼的关系，就像画画时的纸笔和Apple Pencil。在创造和推广Apple Pencil时，你可以说出一百个用纸笔去画画的缺点：不易保存、基本功要求高等等，但Apple Pencil没法替代纸笔，因为纸笔所能满足的真实触感体验等Apple Pencil永远无法满足。

所以更建议大家在看SaaS相关的书籍和文档时，从整个B端的角度去看待：无论是SaaS还是软件，最终你都是在以一款产品或者一个服务去满足B端客户的诉求，那么形式到底是什么倒不是特别重要了，关注底层逻辑就好。

以前好像对产品和解决方案的边界不是特别清晰，通过这本书以及最近听的一次SAP产品架构分享，才对这两块有了非常清晰的界定。

产品是可以交付给他人去解决问题的方式，而解决方案是只能自己出面去解决问题的方式。

产品代表着毛利更高，因为它是标准化的产品，一个产品通过交付or实施顾问，可以不断地卖给不同的客户；但解决方案则很难做到标准化。

所以对于B端公司而言，标准化产品一定是最主要的核心骨。但B端产品中，过于标准化的产品也可能会带来更高的交付成本，那么，这也倒逼我们要做好2件事：

• 产品设计中，除了考虑产品本身之外，也要适当考虑和结合交付成本进行考虑——如何能够设计出利于交付、相对能够降低交付门槛的产品

• 产品本身的毛利高了，看起来是一件好事，但也有可能是这是因为把一些成本转嫁到了交付部门上。作为整款产品的Owner肯定不能做甩手掌柜，还需要考虑如何帮助交付部门降低交付成本和实施体系才行。

以上就是全部内容了，希望对你有帮助。有不妥之处，还望指正。