2023年做低代码产品经理半年后我有哪些思考

做低代码产品经理半年后，我有哪些思考今年三月份我转行做了低代码平台的产品经理。最近刚刚过了半年试用期，也在复盘自己入职以来的表现。客观来说，这半年的产出并不符合我的预期，我盼望自己可以发挥出更大的价值，但看起来事实并不如所愿。

我在想，究竟是哪里出了问题。

最近自己有了一些思索结果，也跟更高阶的产品同学有了一些沟通，盼望在这篇文章中能将这些成果共享出来。或许我四周有一些转行的产品经理正在经受我一样的心情，我盼望通过对自己工作的深刻剖析，给他们一些鼓舞和方法，在「迷茫」的心情中找到「知道该如何发力」的解决方案。

关于复盘，我会给自己提三个问题：

你认可自己在做的这件事么你有没有找到正确的方法你是否足够努力抱负状况下，对于自己负责的工作，我们应当是先找到价值，再寻求方法，最终付出努力。但事实上，许多人往往是先努力（加班），再从或有效或无效的努力中提炼出方法，最终再渐渐找到价值。

两种路径都可以，第一种方法更简单做得快乐，由于构建起了正反馈。价值是最基础的保障，正确的方法可以让努力变得更有回报，于是更加认可事情本身的价值。而其次种方法更简单上手，由于相比找到价值，努力反而是不需要思索的。

我们所说的价值，是这项事业本身所具备的价值，比如对低代码平台来说，就是它对现有的SaaS模式的影响。而绝非那种普遍适用的价值，比如这份工作让我能够生活得很好，有不错的社会地位。

当然我们不是否定其次种价值，只是这样的价值让我们更简单放弃眼前的工作，或者更不简单找到工作本身的乐趣。由于这种价值不是这个工作所独有的，这恰恰才是关键。

二、我认可低代码这个方向么？是的，毫无疑问

起初我认可这个方向，是由于我觉得这个岗位要求的业务抽象力量，是我所推崇的产品设计理念。但现在我会觉得，格局小了，熟悉太浅了。

《硅谷钢铁侠》这本书提到，在创建spaceX早期，马斯克制定火箭制造方案时，往往会从物理学的角度判定一件事是否可行。假如在底层规律上这件事是跑得通的，剩下来的就是方法和执行力的问题。

同样的，低代码这个方向假如在底层规律上跑得通，剩下的就是从业者们如何找到方法并付出执行力的问题。

在我眼中，低代码的价值依托于一个被普遍验证的经济学规律：科斯定律。通俗地说，谁能把资源用得好，资源就归谁。

我们再回顾下低代码产品和其他产品的区分，可以理解为下面这张图。

对于大多数产品来说，它是围围着需求而生的，从业务/用户需求到产品需求，从产品需求到产品；而对于低代码产品来说，它是围围着产品而生的，从业务/用户需求到产品，从产品到搭建产品的工具。

两种模式的差异在于，前者将最珍贵的资源投入在业务/用户需求到产品的这个阶段，而后者将最珍贵的资源投入在从产品到搭建产品的工具这个阶段。

在企业数字化早期，业务/用户需求差异性较大，通用化的解决方案几乎不存在，于是资源投入在第一个阶段是可行的，由于回报最大。

后来Salesforce带来了SaaS这种新兴的模式，但我始终认为这更多的是商业模式的变化，而不是应用生产模式的变化。例如对于国内SaaS厂商有赞来说，照旧会依据不同的行业开发出不同的版本，「资源投入在业务需求到产品」的本质没有变。

而低代码带来的恰恰就是应用生产模式的变化，从业务需求到产品的任务不再落到产品经理和研发工程师的身上，而落到了开发者的身上。

在第一种模式下，不同业务间即使具备了某种底层相像性，产品设计照旧要做多次。所以，假如存在一个假设：企业数字化转型是否给不同行业间带来了更多的底层相像性，那这种模式的边际收益注定是渐渐降低的。

而低代码模式下，业务间的底层相像性，被抽象为通用的工具，通过工具可以更快地搭建出满意业务诉求的应用，生产边际成本极大降低，相对的，边际收益就提升了。

总的来说，我认可一个假设：企业数字化转型给不同行业间带来了更多的底层相像性，同时我认可一个经济学定律，最终推导出，我认可低代码这个方向的价值。而这个假设是否成立，值得我们一起去思索。

二、如何找到正确的方法

我今年是做产品经理的第五年，对我来说，找到正确方法的最大堵塞恰恰是过去的阅历，过去是怎么把事情做成的，在做低代码的时候会不自觉地产生路径依靠。

要破除这种依靠，首先要想清晰：低代码产品经理跟其他产品经理有什么不一样。

从上面的介绍中不难看出，低代码产品经理睬经受的特别阶段叫做「从产品到工具」，这要求我们同时具备两种力量：扎实的业务学问和产品抽象力量。所以，低代码产品经理需要时时刻刻平衡好「详细和抽象的关系」。

对其他产品经理而言，他们的抽象力量一般发挥在从业务需求到产品需求的抽象中，例如销售盼望可以更好地管理手头的潜在客户和签约客户，于是产品经理给他们供应了一套CRM系统。

但低代码产品经理的抽象力量要求他们能够将CRM系统再做拆解，从后端的数据模型到前端的页面搭建，这对于抽象力量的挑战无疑是巨大的。

从最终状态来说，低代码产品经理的抽象力量应当成为他们的制胜武器，他们应当花更多的时间在这种力量的培育上。但从我半年多的经受来说，这个原则往往会带来一个误区，只关注抽象，而轻视业务。

我们所说的抽象，应当是从业务抽象到产品抽象，所以在早期，低代码产品经理肯定是要投身于业务中，他们必需具备了肯定的业务理解力量，再去谈抽象。

抛开业务的抽象，只是一种规律嬉戏，说严峻点，是一种自嗨。就像那句话说的，假如没有看过这个世界，又何谈世界观呢。

我最近在做CRM项目的时候，这种体会特别深刻。

起初我接到的任务是完成CRM系统中一些简单表格的搭建，后来我发觉，假如不能理解表格背后的数据，包括数据来源是哪里，表之间的关联关系如何，现在的CRM系统中每张表格的作用是什么，呈现的信息关系是怎么样的…

假如不懂这些，单纯地就是想着如何用无代码的方式搭建出眼前观察的这个表格，那肯定是走不通的，并且也会做得很苦痛，很懵逼。

总结下来就是一点，在刚刚做低代码产品的阶段，我们一方面要了解到这个角色与其他产品经理在力量要求上的不同，但另一方面也要清晰需要从业务中培育抽象力量。

三、打算要不要做一件事的决策模型至关重要

我在产品评审的时候，常常会面对的一个问题是：为什么要做这个需求。同时，也会受到几种挑战：1、有业务场景么；2、有业务提出这个场景么；3、竞品有做么。

首先，有场景是必需的，没有业务场景的需求，很可能是伪需求。举个不恰当的例子，我假如做一个表格放大闪入的加载动效，是一个需求么，是的，但有业务场景么，没有，那这件事就不应当做。

但挑战在于，需要区分你没有看到场景和没有场景这两件事。假如我们把没有了解到这样的场景，当作没有场景，那这个产品的天花板就会受到你熟悉的局限。那该怎么办呢？

广泛地体验不同行业里的SaaS产品，CRM、ERP、WMS等等，假如我们需要用低代码支撑起各种简单的企业应用，我们至少要知道这些应用现在长什么样子，这同时也验证了一点，在早期要投入到不同行业里，攒业务阅历。

假如我们现在对接的业务没有提出这样的场景，我们要不要做。

我始终坚信一点，对于真正有价值的诉求，假如发觉了再做，那我们很可能比SaaS产品的迭代速度更慢，由于我们只是完成了从工具到产品，而从产品到解决方案，还需要开发者或者实施团队的努力。

那假如做了，且在很长时间内发觉没有业务用，究竟是由于这个需求是伪需求，还是由于我们还没有找到真正服务的客户呢，这都是我们应当去考虑的问题，圆满的是这样的问题并没有标准答案，只有不断扩大自己对行业、对业务的了解，才能做出更接近事实的推断。

四、分工不是边界

我们的团队会根据产品模块有不同的分工，每个同学在这样的分工下又有自己更精细的责任，但分工不是边界，一个模块的工作能不能做好，有时候依靠于你有没有搞懂另一个不属于你责任范围内的事情。

比如在上面提到的CRM项目中，我负责的是表格搭建部分的工作，但深化了解后我发觉，假如搞不懂表格背后的数据结构，那表格搭建方案根本就无法落地。

我有个很明显的体会，之前我以为我只需要参加表格前端展现效果相关的gap梳理，但后面发觉数据源、数据加工和数据展现之间是一体的，前两者搞不懂，方案设计就是不完整的。

打破边界是为了获得更多信息，从而提高效率，但提高效率的行动往往简单带来对问题定义的忽视。为了加快进度，我们在工作中往往更重视找解决方案，但解决方案假如跟问题的定义是冲突的，便只能带来短期收益。

前面说了，表格搭建时需要去了解数据源、数据加工和数据展现之间的关系，而我们遇到的实际问题是，受到数据源本身特性的一些影响，后端需要补充一些数据加工力量，但这些力量在后端开发的成本比较大，而项目周期紧，所以大家就想到这部分工作是不是前端也可以做。

遇到这些问题的时候，我的第一想法是，前端能解决么，假如可以的话，成本大么，假如不大的话，那为了项目按时上线，就去做吧。

虽然争论的时候我也觉得，好像后端负责数据加工，前端负责数据展现是更符合直觉的，但假如我不做，是不是会显得我不够“协作”。由于可怕背负上这个标签，于是想方法从前端去搞定。

后来跟老板沟通下来，发觉我之前的思索并没有触及到问题的本质。假如这一次前端处理了，那后续遇到这样的状况，且数据源特征更简单，是不是都是前端来做。其背后真正的问题是：

整个低代码产品在搭建简单应用的过程中，面临这种简单的数据状况时，前后端应当如何分工，才更符合整个产品长期的规划。

短期内针对一个问题的解决方案有许多种，但对于将来应当要做成什么样子，大家的理解应当是全都的。

这种争论或许会影响一些工作效率，但的确是非常必要的。

五、接下来聊聊关于如何努力的问题

半年来，我对任务和目标颇有一些体会。在新人landing阶段，虽然也需要去制定自己的工作目标，但这些目标往往是依附于任务而存在的。

比如我刚来的时候，分到的任务是负责图表模块，那时候我的目标，也是围绕如何做好图表目标而去制定的。这个阶段是有必要的，由于信息不够，还在学习，从一个详细的任务开头是明智且踏实的。

但这个阶段不能持续太久，假如目标总是服务于任务，那我们全部的价值感和目标感都是依靠于详细的事情，而简单忽视我们自身的成长。

我自己就有过这样的体会，Q2的时候针对图表后续的规划做了许多调研，梳理了许多想法，但Q3开头我被告知，图表需要转交给其他团队，这让我在某个时刻突然陷入了一种空虚当中，似乎一下子失去了目标。

后来我开头投入在表单相关的任务中，也是给自己定了针对于这个任务的目标，但由于自己低估了任务的难度，最终跟团队一起评估下来，目前全力推动这个任务并不是时候，于是暂缓推动了。再一次地，我有一种失去了目标的感觉。

后来我自己开头反思，目标不应当服务于任务，目标应当是大于任务的，它应当去打算我在这家公司盼望变成一个什么样的人，目标是跟我这个人的状态相关联的，而不应当受制于详细的任务。

当我有了目标之后，我可以制定不同的任务去服务于目标，我可以或主动或被动地去调整目标下的任务，但目标之于人，就像北极星指标之于产品增长，是具有引领价值的。

六、摆脱“被动”，提前做预备

在大厂我能感觉到，身边都是特别优秀的人，大家的背景、专业度和沟通方法，在从业者中都是佼佼者。

以前在小公司的时候，我觉得自己要成为那个环境中最优秀的那一批人；来到大厂之后，我的内心总是布满着一种隐隐的自卑感，甚至一段时间祈求自己可以顺当度过试用期，这在以前是不行想象的。

好像大厂的产品经理们从不用别人去push他们要努力，会议、文档、项目、汇报、OKR，这些就足够产生强大的推力，推着我们向前走。

我曾经认为，只要自己能够做好努力这件事，就能生存下来。但后来我发觉，更重要的是找到为了什么而努力的答案。

上文说的从目标到任务，就是一种找到为了什么而努力的方式，而半年来我的另一个感受是，需要对产品布满奇怪   心。

刚刚入职的时候，就听人说起过，表单在现在的配置体验让人感觉到很惊奇，不理解为什么要这么做。由于我不在负责表单功能的团队，所以这样的说法听了也就听了，并没有很奇怪   。直到后来表单相关的任务来了，我才不得不从零开头讨论表单功能。

我在想，假如早一点可以去讨论表单，是不是自己能够为后来的任务做好更充分的预备；可又一想，是什么会驱动我去做这样的讨论呢。那应当就是奇怪   心了，除了奇怪   心，我想不到有别的驱动力。

我所说的奇怪   心不是指“我知道是怎么回事”，而是真正理解产品背后的基本原理以及它存在的价值。

七、劳碌的工作中，如何钻研其他产品

我问过自己，平常那么忙，哪有时间去钻研不是自己团队的产品呢。

我的一个体会是，肯定要跟不同团队的产品经理保持肯定频率的沟通，这种沟通不能仅局限于跨团队的需求，更好的方式是抛开需求，更开放而自由的沟通。

现实状况是，或许这只是我的一厢情愿，由于我看大家的日程，似乎每个人在工作日是真的很忙，但假如有人情愿找我了解一下关于组件的一些问题，我是很情愿的。

当然我盼望他们也带着自己负责的模块，来一场学问的交易。

另一方面，低代码产品经理需要跟研发有更多的沟通。我了解到许多公司都有自己的低代码平台，发起人往往是技术团队，低代码在技术视