给软件付费的时候我们想得到什么？

背景概述

看完之后深有启示，很多时候在对客户讲解SaaS产品服务的时候太在意表现自家产品的功能强而全，平台性能大而广，以及团队牛而精，其实不如多讲讲能够怎样踏实的解决客户的问题，并能解决到何种程度。那样可能更能获得B端用户的青睐和关注（毕竟堆功能这件事对软件开发团队来说太简单，客户多见识过两家就厌烦了）。

从b端软件现状联想到自己的日常使用工具软件，其实也一样吧，我早早放弃了强大的notion（确实折腾不动了）包括obsidian，目前也就稳定用的插件就2个，一个图床辅助、一个是日历，大部分诉求在自带核心插件中都得到了解决。

曾经我也很想all in one

刚接触notion、obsidian都感觉这太geek了，简直无所不能酷极了，特别是看到大神们的各种分享的高级玩法和炫技似的分享工具的玩法上限。

一时间就想要把自己的整个世界都放进去。然后开始疯狂的找教程，找案例去搭建自己幻想中的世界。

但是在放过程中会感受到其中的各项痛苦（可能是我自己太懒+太菜的原因），需要忍受非常多的“也就能用”这种状态。各种对自己妥协和凑活，妥协就意味着有东西需要舍弃，舍弃后的东西总是有不完美，不完美多了，幻想就破灭了，最后又容易回归最初的原始状态。

举些例子：

1、notion的 速和中文问题三年又三年毫无进展也看起来不想要进展

2、ob插件装的多到软件卡顿完全记不住各插件的功能和快捷键，甚至辅助窗口面积都大过了正文输入区，让自己一度怀疑是在写作还是在开 刊亭？

同一类软件有很多个也没事

从底层逻辑来讲，作为每个工具软件的产品经理，一定也是知道和它同类产品的功能和特性的，没人会想去照抄一个一模一样的工具，那样如何说服别人来选择你的产品呢？制作和开发是需要成本投入的。

所以就算有一些软件在诞生之初会非常像感觉上毫无创新只是在抄袭，但它同时一定解决了其他成熟软件的某些缺陷或劣势问题（可能是技术架构选型的完全不同，为了支撑未来的某个强大服务功能），在未来会逐渐生长出他的产品经理的理念和思维，活下来了就说明他在某个点已经获得了市场的认可，因为解决了确定场景的问题。

就这一个优势，就足够了。