校招入职的云计算产品经理，三个月的经验与你分享

笔者分享了自己校招入职云计算产品经理后的工作经验，涉及到云计算产品经理的四大工作内容，同时分享了在工作中面临的挑战及解决之道。

毕业后第一份工作，入职到现在已经三个月。作为一名职场新人，不得不说几乎每天都要接收到爆炸式的信息，尤其在云计算在这一高度专业的领域中。

入职前一周，每天都被各种新名词轰炸，那时想着下周应该好一些吧，结果第二周遇到的新名词更多。

入职一个月的时候，觉得自己已经度过新人过渡期了，但第二个月仍然需要继续面对新的事情，尤其是涉及到定价和底层需求。

现在入职三个月，对业务达到基本熟悉的程度，但是在这个需要不断学习的领域中，每天都会不可避免的遇到新事物。

入职之前，对于云计算产品经理，更多的是通过社区看别人的文章，或者看相关书籍进行了解。但入职之后，发现这些对于实际的工作环境还远远不够，于是更加深刻的理解了实践是检验真理的唯一标准这句话。

三个月的时间，对于云计算业务的认知提升还是很快的。除去业务，产品经理这一岗位本身又需要对接大量的人和团队，来完成产品的研发和设计。所以，这三个月，除去业务本身，对于产品研发过程中的项目管理和需求对接，更需要花费大量时间来进行学习和磨合。

工作到一定时间，需要反复进行个人总结，才能明确方向并不断提升。之前读书和找工作时候，就喜欢定期进行科研工作上的总结并复盘过往经历。

刚入职的时候其实对于业务还是有点懵的，毕竟是在一个全新的环境。而且之前自己的科研和实习上更多关注的是应用层，比如视频和图像的处理，对底层关注的很少，或者说几乎不关注。

入职之后，做的方向是关于云计算IaaS中的数据库和磁盘存储业务。而数据库RDS其实需要对接三个产品，MySQL，SQL Server和PostgreSQL，三个产品的后端完全是独立的，只是共享同一控制台。

至于磁盘存储或者叫块存储，是最底层的应用，只要是涉及到服务器或者云计算，块存储就不可缺少。而对于这两种产品，针对的用户一般都是开发者，一般都会在Linux环境中进行代码开发，所以产品经理必须对开发者的使用习惯有深入的了解。

云计算产品经理是科技行业发展至今的细分产物。除去云计算产品经理，还有数据产品经理，地图产品经理，中台产品经理，AI产品经理，国际化产品经理等等众多垂直细分领域。

产品经理这一岗位曾一度被流传为人人都是产品经理，而如今却发展出众多垂直行业的细分产品经理，足以显示出这一岗位的专业性。

一、工作内容

工作三个月，我将云计算产品经理的工作内容总结为以下几个方面：

1. 全面的行业跟进
2. 多渠道的需求分析
3. 复杂的产品设计
4. 多层的项目管理

1. 全面的行业跟进

云计算，不论是公有云还是私有云，其一整套系统都是由众多产品模块组成，包括计算、网络、存储、数据库在内的基础模块，也有安全、账号管理、交易系统、监控等必备的辅助模块，还有大数据、媒体CDN、边缘计算、物联网、人工智能、建站、云市场等较为垂直的模块。

对云计算的全行业跟进由宏观到微观，可以分为以下四个方面：

1. 对云计算行业的市场和战略调研；
2. 紧密跟踪主要厂商的历史和最新动态；
3. 对云上产品有横向的系统性认识；
4. 对自身负责的具体产品进行功能和体验层面的竞品调研。

作为初级产品经理，最需要关注的是最下面一条，即自身产品在功能和体验上的竞品调研，其次是云上全部产品的系统性认识。

云计算产品经理新人往往只会负责一个产品模块中的一部分功能，如只负责存储模块中的对象存储一条产品线。因此，为了明确产品的迭代目标，产品经理必须对该条产品线的竞品进行充分的调研，以明确自身产品在行业中所处的位置。

在脚踏实地的同时，仰望星空也很重要，哪怕对于初级产品经理而言。因此，在有限的时间内，产品经理也需要对云上其他产品进行系统性的认识，因为云上产品大多不是独立的，都需要与其他产品模块有交集。

同时，还要紧密跟踪行业最新动态，不仅局限于自身产品的历史和最新动态，更要对整个行业的重大新闻进行跟踪。

除去这些与产品直接相关的调研工作，对云计算行业的市场和战略方向，产品经理也要有足够的分析和认知，最好将日常的观察逐渐形成自身的结论。

2. 多渠道的需求分析

对于云计算B端产品，需求的来源是多渠道的。而且对于云计算，尤其是IaaS基础云而言，各家厂商对应产品线的功能基本是相似的，不会有太大的变化，其主要区别为机器的性能和服务的完善程度。

云计算的需求主要来源于以下几方面：

1. 业界通用需求
2. 大客户需求
3. 横向部门需求

这其中，需求又可以分为两类，一类是 功能需求 ，即需要在功能上对产品进行补全或改进；另一方面为 体验性需求 ，即需要完善用户的操作流程，包括控制台、API和帮助文档。

对于业界通用需求，是指一个产品模块在业界必备的一些功能组件。比如对于数据库产品，基本的实例管理、变更配置、数据库管理、日志与安全管理、监控等等，这些是基本的需求模块，业界任何一款产品都需要具备。

这里不需要像C端用户型产品一样标新立异来为用户创造新鲜感，而是只需满足用户广泛的使用需求。与云计算相对的，就是独立主机和本地自建数据仓库的使用形态。

云计算在产品线上的需求，其实和用户在使用本地机器时的需求是相同的，都是为了通过计算机来解决底层问题，包括计算、数据处理、数据分析、远程操作等等。因此，云计算产品线的功能模块和需求类别基本上就是用户在使用本地机器时的需求。

但不同的是，云计算不仅仅是一套产品，更是一套基于产品的服务。因此与本地机器不同的是，云计算开创了一套自己独有的服务性需求模块，以满足用户的高阶需求，如监控报警、慢日志优化建议等等。

其他的需求来源，如 大客户需求 很好理解，是指云计算大客户在使用过程中提出的需求。这类需求往往需要产品经理进行单独的排期，但若是与已排期的需求相重合，则需要告知客户经理或者售前经理明确的需求上线时间。

最后一类的 横向部门需求 ，则是云计算不同产品线在交叉使用过程中发现的其他产品需要补齐或者是改善的需求。这类需求一般都是体验性需求，如控制台或者帮助文档需要改善的地方等等。

总的来说，云计算的需求是多渠道的。基础的功能性需求各家厂商基本保持一致，不同的只是各家产品在性能上的差异，以及所覆盖场景的完备程度。

3. 复杂的产品设计

云计算产品具有复杂的产品设计逻辑和较高的进入门槛。云计算产品的设计，要求产品经理对于底层技术、商业定价有较好的理解能力，并且对客户关系有较好的协同能力。

首先明确一点，云计算的售卖对象虽然是企业级客户，但是真正使用的人却是企业中的技术开发人员。

因此，这往往要求云计算产品经理需要理解相应的开发流程和使用场景，包括控制台和命令行的操作方法。

可以举个例子，我在入职后主要做数据库和云磁盘。云磁盘是任何一套云计算系统中的必备模块，因为存储总是不可缺少的。

但对于云盘的操作，如挂载、卸载、扩容等，往往都是在Linux系统的命令行环境中完成，这要求产品经理能够理解用户在开发过程中的操作目的、操作环境、命令语法以及使用规范。

因此，云计算产品经理往往需要具有相匹配的专业背景，尤其青睐计算机、通信、电子专业的毕业生。

云计算产品的设计，可以分为三个模块：

1. 功能设计
2. 控制台体验提升
3. 定价

云计算产品的一项功能，往往都是业界通用的，而不是为了追求用户的新鲜感而专门设计，除非是一些厂商为了提升自身用户体验、或者是增加特色服务模块而设计新增。

比如说，对于云磁盘这一项产品，其核心的通用功能模块都是磁盘管理和快照服务，而磁盘管理又分为创建、格式化、卸载／卸载、扩容等等，快照服务又分为手动快照、自动快照等等。

所有厂商关于云磁盘的操作都是类似的，只不过在磁盘的种类、性能和价格上略有不同。

因此，云计算产品的功能设计并不会像C端产品一样去刻意追求用户的新鲜感和体验感，而都是行业内约定俗成的基本功能，而且产品模块越靠近底层基础云，其功能的种类就越少。

对于一些PaaS产品或者是SaaS产品，其因为处于云计算整体架构的上层，其可以发挥的产品想象空间就越大，往往并没有底层IaaS产品局限。

另外一方面，便是控制台的体验提升。云计算的产品可以通过两种方式进行操作，一种是通过控制台进行操作，另外一种是通过在后台的命令行中完成操作，通常会用到与单机使用时相同的命令语句，同时还会用到封装好的API或者SDK。

越靠近底层的产品会越重命令行使用，而越靠近上层的产品，就会越重控制台体验。比如，数据库产品的控制台使用频率就要就要多于云磁盘的控制台使用频率。虽然云计算是面向客户而言的一种售卖方式，但是控制台的实际使用者却是企业中的IT开发人员。

因此，控制台也需要用C端产品的思维来设计，产品经理也需要从多方面考虑来提升用户体验，比如连续操作的流畅性和串联性，操作提示的合理性等等。

以上两个方面结合起来，往往就是云计算产品需求和功能设计的大部分工作，而产品文档也主要围绕以上两个方面。

总结来讲，第一是要从产品需求和产品策略两个维度来进行产品功能的设计，第二是要在控制台提升产品的使用体验。

最后一点，云计算产品非常不同于C端产品的地方在于，云计算产品需要定价。产品经理需要从竞品价格、产品成本、毛利率等多个层面对产品最终的售卖价格进行确定。同时，产品经理需要对产品制定不同的售卖组合，并对计价方式进行设计。

云产品的计价方式是多种多样的，如存储容量的线性计费形式，还有计算产品CPU核数量和内存大小的组合定价形式，还有阶梯定价，阶梯命中定价等多种方式，用以满足不同产品的使用场景。同时，在支付方式上，支持包年包月形式的预付费和按量付款的后付费形式。

除此以外，涉及到大型的运营活动如双十一等，还需要设计额外的打折促销产品。在日常，为了留存拉新，还会发放不同形式的代金券为用户抵扣费用。

总的来说，云计算产品需要同时面向C端和B端进行产品设计，在满足客户价格、功能和特定需求的同时，还要提升客户企业的员工在控制台和命令行中操作时的用户体验。

除此以外，还要用合理的定价和促销活动来满足企业客户在预算上的要求。

值得一提的是，私有云在产品的设计上与公有云有很大的不同。公有云往往更倾向于将产品设计为一套通用的流程，满足大中小客户和个人的使用需求。

但私有云往往是针对某位大客户量身定制，因此需要在公有云的通用版本之上来针对客户特定需求进行特定开发。

私有云往往更重视售前和销售团队，只有强大的销售和大客户团队才能保证触摸到潜在客户，并且当销售将某位客户沟通为潜在客户时，产品研发团队需要与客户进行进一步的需求沟通，来了解客户的详细使用需求。

同时，私有云的产品研发和销售团队需要对客户的需求进行报价。若双方洽谈合适，那么该项目会进入私有云的PoC环节。若最终中标，那么就进入产品研发环节，直到最终交付客户。

但值得注意的是，一些大的厂商往往在发展过程中会研发出针对不同行业的底层版本，如金融版、政务版、交通版、制造业版等等。在这些行业通用的版本上，再根据某一位具体客户的需求来进一步定制化开发，会加大的减少开发工作量，能够对客户的需求做出更快响应。

因此，总的来说，云计算产品的设计流程与单纯互联网产品的设计流程有很大不同，往往需要产品经理考虑众多涉及营收和客户相关的事情。

从某个角度来讲，云计算产品经理的工作很像是技术咨询（IT Consulting），但又比技术咨询多了很多细节的考虑，不仅考虑宏观层面，而是需要宏观微观协同并进。

4. 多层项目管理

云计算产品的开发流程往往会涉及到多层同步/串联开发，这需要产品经理对项目进行多层管理，包括对项目的时间把控，流程对接以及风险控制。

比如，对于云磁盘产品，从底层到上层分为磁盘后端、集群后端、控制台后端、控制台前端等众多开发层次，中间还要涉及到每一层的测试和联调。

除此以外，若某一项功能需要接入计费，那么还有额外的计费模块开发，主要涉及账单和订单管理以及需求的启停等等；若一项功能需要接入监控功能，那么还会涉及到额外的监控开发，这需要协调产品侧和对应支持模块的开发联调时间。

项目中这么多开发人员，当某一个环节出现bug或者出现计划之外的人员变动时，需求整体难免出现delay风险。

因此，还需要产品经理对项目的风险进行把控，尤其对于产品的各层上线时间，都要做到心中有数。

二、思考与总结​

校招正式入职三个月，细细数一下，已经做了11个需求，完整的写了9份产品设计文档，将1个产品的官网帮助文档全部进行更新和重构，并在包括营收、运营、体验在内的多个方面开始全面跟进。

从对公司业务的一无所知，连CRM系统都不会使用，到现在可以逐渐回答一些客户的问题，开始对业务和产品开发流程逐渐熟悉，并能够思考改进之处，这中间其实要感谢很多人，尤其是我的经理和导师。

这三个月期间，不仅有了很大的收获，其实也遇到了很大的挑战。云计算其实是一个门槛较高的领域，新人想要熟悉领域内的业务，需要付出很多努力。这不止需要专业的知识背景，更需要缜密的多产品协同逻辑思维，还需要有较好的理解能力。

而且，云计算的开发流程都非常专注于底层设计。学过计算机网络的人都知道，计算机网络可以由底层的物理层，向上延伸到网络层，传输层，还有应用层。

越到底层，就越需要专业的知识背景，而且概念越抽象，理解难度越大。而我目前做的基础云，就是云计算体系中最底层的架构。

接下来，主要想谈一谈工作中所遇到的挑战，并复盘自己的解决方式。

这些挑战只是我所遇到的，不一定能代表所有人，毕竟不同的业务，需要对接不同的人，而且这跟个人的性格和处事风格有很大关系。

1. 职场新人在工作中遇到的挑战

作为一名职场新人，工作中遇到困难或者挑战都是难以避免的。从我的经验来看，挑战源自于以下几方面：

1. 对业务的不熟悉
2. 对团队成员的不了解
3. 对公司流程的不熟悉
4. 对自己的信心不足

在这四个方面中，第一条和第二条是面临的最大挑战，这直接可能导致第四条的产生。而第四条的发展，又可能会加剧第一条和第二条的严峻程度。

（1）对业务的不熟悉

虽然在入职前关注了很多云计算相关的新闻，并且还买了相关书籍来进一步了解，但到入职后才发现真实的业务场景其实更复杂。书本或者论坛上的信息都更加专注正常流程下的业务模式，在业务覆盖上不一定具备全面性和特异性。

我个人将云计算业务从一个宽泛的概念分割为几个方面：

1. 产品内功能逻辑：一款产品内的众多功能模块及模块间关系；
2. 云上产品间业务逻辑：云上众多产品间的逻辑和业务关联；
3. 云上业务定价及营收逻辑：涉及云上产品计费策略、月度营收分析等财务模块；
4. 客户关系管理：对接处理销售和客户需求并排期。

1）产品内功能逻辑

每个云计算产品都是由很多模块构建而成的，尤其是一些功能较为复杂的产品，如计算，网络，数据库，对象存储，磁盘存储等等。

比如，云计算最为核心的计算产品，从功能上可以分为计算实例模块，存储模块，连接模块，镜像模块等等。每个产品模块虽然在控制台上有独立的子页面，但逻辑上都是计算产品的一部分，有着相辅相成的关系。

再比如数据库产品，按照各家云厂商的广泛划分方法，可以将数据库产品从功能上划分为实例管理，数据库管理，日志管理，备份管理，安全管理，等众多模块。

每一个模块还包含众多的产品子模块，比如在备份管理中，可以分为全量备份和增量备份，或者划分为数据备份和日志备份；而日志管理中又可以分为慢查询、慢日志、日志下载和错误日志的几个模块。

因此，作为产品新人，若想要对负责产品有深入了解，那么必须对产品中包含的功能模块有足够的认识，要逐渐搭建起框架式的产品认知。

同时，产品经理还必须理解产品为什么会划分为这些模块，其内在逻辑的来源一定要清楚。

2）云上产品间业务逻辑

当工作到一定阶段时候，云计算产品经理必须对云上其他产品也要有足够的认知。当然这并不是说要有多么细致的认识，但至少要能知道云上其他产品的宏观状况，并对云上众多产品间的关系有较为清楚的梳理。

比如，计算产品作为云上产品的基础和核心，是很多其他产品在实现和使用上的基础。客户一般在购买其他产品比如网络、数据库、磁盘的时候，往往都先购买计算产品，即购买服务器。

那么，用户在此时的购买逻辑和使用场景，以及用户在使用产品过程中的串联需求，也是产品经理应该考虑的。因此，这要求产品经理需要不断熟悉云上产品间的业务逻辑。

3）云上业务定价及营收逻辑

云计算产品的一个特点，就是需要对产品进行定价。既然定出了价格，就会产生营收目标，因此也需要对营收定期进行分析。

在定价这一环，会涉及到很多事情，如收费策略（预付费或者后付费）、产品具体价格制定（包括成本核算）、计价方式（线性、组合、阶梯等等）、订单形式、账单形式、欠费后的启停操作、停服条件等等这些都需要考虑。

当定价结束后，还需要定期对业务营收进行复盘分析，涉及到环比/同比增长分析，增长/降低原因分析，大客户营收分析等等。

因此，定价和营收是除了产品功能以外，产品经理的又一大核心关切。

4）客户关系管理

客户关系管理是产品功能和营收外较为垂直的一块，同样需要产品经理额外关注。提到客户关系管理，很多人会说这是销售或者售前该干的事情。

确实，直接接触客户的肯定是销售或者售前同事，但是因为销售和售前需要对接云上众多产品，对某一个产品的一些核心功能不能做到深入了解。

当客户需要对产品的功能有较为深入了解时，销售同时往往会和产品经理一起去和客户沟通。

除此之外，当产品交付客户之后，客户在使用中可能会遇到各种各样的问题，更会对产品提出新的需求，因此客户希望研发侧可以开发解决。此时，也需要产品经理根据客户需求对产品进行需求排期，以满足客户（尤其是大客户）的关切。

因此，我们常说云计算卖的不止是产品，更是一整套服务，所以产品经理需要时刻关注客户关系，回应客户诉求。

以上是我个人对云计算业务的拆分。一千个人会有一千个哈姆雷特，不同的人对同一项业务也会有不同的解读，因此，都可以作为参考。

刚入职的时候，很难对以上几个方面做到了解，在面对一项新的项目时，往往是处于比较懵的状态。但是在做的过程中，你往往可以意识到自己需要从哪几个方向靠近，也能感觉到这是否是自己想做的事情。

很幸运，我从研二开始找工作时候，就明确了云计算B端产品经理的大方向，也很幸运加入了一个氛围很好的团队，感觉这就是自己想做的。因此，即使有时候遇到较难处理的问题，也不会产生较大的畏难情绪，会主动想办法去解决。

（2）对团队成员的不熟悉

除去业务上的不了解，团队成员的磨合期也会为工作带来一定的挑战。进入一家新公司之后，往往需要一段时间来适应新公司的工作氛围，并渐渐适应团队成员的工作风格。

对我而言，在人员方面，主要的磨合来自于三方面：

1. 同时对接多个团队
2. 多层产品开发
3. 沟通的不顺畅

1）同时对接多个团队

入职后，我负责磁盘存储和数据库方向的产品业务，而这两个产品需要对接不同的团队，互不相交。

每个团队都有各自的迭代计划和排期，且磁盘存储方向的开发也对接了多个产品，这需要去与其他产品竞争人力。

而有时候人力往往是不充足的，经常面临较大的需求delay风险，这需要产品经理不断去确认需求的上线时间。

2）多层产品开发

云计算产品的开发是分为很多技术层次的，有产品后端，还有控制台后端，集群后端，还有控制台前端。若要涉及到其他横向模块，比如计费、监控、主子账号，还需要产品经理去对接其他横向产品团队。

从需求被提出到上线的这一整套流程中，产品经理需要安排好各层的开发和测试时间，以保证产品能够按时顺利上线。

可以举个例子，磁盘存储某一个功能一旦开始开发，需要经过产品后端、集群后端的开发和测试流程，只有后端开发且测试结束才可以进入控制台后端的开发。

相比起移动app的开发流程，这两层开发的工作量是云计算所独有的。当后端测试完成后，还需要进行前端开发，包括控制台后端和控制台前端。

前端完成后，还涉及到联调，测试的安排。开发的流程，往往需要产品经理明确产品设计文档，将产品策略梳理清楚，保证没有歧义，并保证合理。

3）沟通的不顺畅

这一点的原因主要是因为自己是一个产品新人，对许多业务名词和业务逻辑不熟悉，导致和团队成员的沟通不太舒畅。

不过在入职三个月之后，这一点随着前两条的改善，也逐渐改善了很多。

但值得注意的是，当你需要和别人沟通一件事，且你对这件事不不太了解时，一定要做好功课，不能把自己真当成一个小白，要提前学习和了解一些相关知识，这样才能保证沟通的顺畅程度 。

（3）对公司流程的不熟悉

这一条其实影响是比较弱的，这基本是新入职一家公司都会产生的状况。

如果以社招身份入职，那么即使新公司的业务流程变了，但你仍然能大概判断出某一个环节或者某一个内部平台的功能是什么，因为这些平台在大部分公司都有，可能只是界面或者外观发生了变化，但一个平台和环节的功能和目的你可能是清楚的。

但作为应届生，可能就不那么清楚了，尤其是在入职一家大公司之后。最开始入职的时候，会遇到各种内部使用平台，有的是为了看客户信息，有的是为了看营收信息，还有的需要是产品管理平台，这些都需要一一去适应。

同时，要适当改变自己的工作方式，与周围大环境在工作方式和节奏上保持和谐。

虽然自己也曾在外实习，但因为公司的性质和规模有差异，在正式入职后依然会存在一段时间的流程熟悉期。很幸运自己有一个负责的导师，将这一整套流程在工作中慢慢教给我，省去了很多自我摸索的时间。

（4）对自己的信心不足

自信心不足，其实许多人都会遇到，且不一定是在工作中。但是，当进入一个新环境后，自信心不足可能会表现的更加明显，这也体现在我身上。

未知会产生恐惧，而恐惧会造成不自信，往往更会造成内心的焦虑。

2. 如何应对

车到山前必有路，办法总比困难多。人在任何一个时期都有各自的困惑和烦恼，此时该做的就是调整心态，积极学习，尤其是年轻人，我一直认为不能太丧，在工作中更是。

当遇到挑战后，其实我做的最多的就是顺其自然。但这并不是说我什么都不做，而是更加主动的顺其自然。遇到不懂的东西，或者不清楚的东西，经常会复用读研期间学术研究的方法，在网上搜索答案，主动自我解决，并多思考，多总结。

其实我认为，在任何挑战面前，每个人都应该更加主动的顺其自然：顺其自然的含义在于，困难是避免不了的，在心态上不能勉强，要乐观面对，敞开怀抱迎接困难；主动的含义在于，当挑战来临之后，要多思考多总结。

不仅要思考如何解决，更要思考为什么会有这样的困难，以及如何预防。

说到这里，其实非常想感谢我的母校，中国科学技术大学，这是一所以严谨和学术著称的高校。我在读研期间，写论文和做研究时候，我的导师和遇到的所有科大老师都经常说一件事，要讲清楚你为什么这么做，而不是罗列你做了什么。

工作以后，认识到这件事其实非常重要。只有多思考，才能有高的产出，才不会迷失方向。

多总结，更是一件意义非凡的事情。我承认自己一直是一个喜欢总结的人，从上学到读研到现在，我享受笔耕不辍的感觉。在写作总结的过程中，思维会越理越顺，自己也不再是一个无头苍蝇。

读研期间做深度学习，通过神经网络和算法来处理图像和视频。在视频的项目中，需要利用一种叫增强学习的算法对在线视频下一个视频块的码率进行预测，而这种增强学习算法的核心就是利用过去的经验值对未来进行预估，类似于数学中的马尔可夫过程。

虽然后续没有再继续研究下去，但是这段研究经历给了我很大启发，因为我忽然意识到人就是这样。触觉，听觉，包括神经系统的一些反应都是大脑根据过往经验总结出来的判断。

但一个特点在于，这些反应都是人类的本能。在工作和学习中，大多数人经常谈论的是我要多干活，但往往忽略了为什么要干这些事情，因此难以对未来形成有效的规划，难以形成有效的预测和反应机制。

因此，当面对工作中的挑战时，主动的顺其自然，是我的个人观点。

摆正心态，多思考，多总结，努力的像神经网络一样根据过往经验来对未来做出判断。未知减少，焦虑就会减少，工作和生活也会更加顺利平和。

本文由@Steven 原创发布与人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议。

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: