今年3月，我转行做了一个低代码平台的产品经理。最近刚过了半年的试用期，也在检讨自己加入公司以来的表现。客观来说，过去六个月的产出并没有达到我的预期。我希望自己能发挥出更大的价值，但事实似乎并不尽如人意。我想知道到底出了什么问题。最近有一些思考的成果，和更高层次的产品同学有一些交流。我希望在这篇文章中分享这些结果。可能我身边有一些正在转行的产品经理和我有同样的心情。希望通过对自己工作的深入剖析，给他们一些鼓励和方法，在“迷茫”的心情计划中找到“懂得发力”的解决之道。1、关于复习，我会问自己三个问题：1、你是否认同自己所做的事情？2.找到正确的方法了吗？3.你工作够努力吗？理想情况下，对于你所负责的工作，我们应该先找到价值，然后寻求方法，最后做出努力。但实际上，很多人往往是先努力（加班），然后从有效或无效的努力中提取方法，最后慢慢发现价值。任何一条路都很好，第一种更容易获得乐趣，因为它建立了积极的反馈。价值是最基本的保证，正确的方法可以让努力更有回报，所以对事物本身的价值更加认可。第二种方法更容易使用，因为与发现价值相比，努力工作不需要思考。我们说的价值是企业本身的价值。比如对于低代码平台，就是它对现有SaaS模式的影响。而不是那种放之四海而皆准的价值观，比如这份工作让我过上了好日子，有了好社会地位。当然，我们并不是在否定第二个价值，只是这个价值让我们更容易放弃眼前的工作，或者更难找到工作本身的乐趣。因为这个值不是这个工作独有的，恰恰是关键。2我认同低代码的方向吗？是的，毫无疑问。一开始我是认可这个方向的，因为我觉得这个职位需要的业务抽象能力是我推崇的产品设计理念。但是现在觉得结构小，理解太浅。《硅谷钢铁侠》本书提到，在创建SpaceX初期，马斯克在制定火箭制造计划时，经常会从物理学的角度来判断一件事情是否可行。如果这件事在底层逻辑上可行，剩下的就是方法和执行的问题。同样，如果低代码方向在底层逻辑上做得很好，剩下的就是从业者如何找到方法并为执行买单。在我看来，低代码的价值依赖于一个普遍验证的经济规律：科斯定律。通俗地说，谁能利用好资源，谁就属于他们。让我们回顾一下低代码产品和其他产品的区别，可以理解为下图。对于大多数产品来说，都是围绕需求而生，从业务/用户需求到产品需求，从产品需求到产品；而对于低代码产品，它是围绕产品而生的，从业务/用户需求到产品，从产品到构建产品的工具。两种模式的区别在于，前者将最有价值的资源投入到从业务/用户需求到产品的阶段，而后者将最有价值的资源投入到从产品到构建产品的工具阶段。在企业数字化初期，业务/用户需求差异较大，通用的解决方案几乎不存在。所以第一阶段的资源投入是可行的，因为回报是最大的。后来Salesforce带来了SaaS的新兴模式，但我始终认为这更多的是商业模式的改变，而不是应用生产模式的改变。比如国内的SaaS厂商有赞，依然会根据不同的行业开发不同的版本，“从业务需求到产品的资源投入”的本质没有变。低代码带来的恰恰是应用生产模式的改变。从业务需求到产品的任务不再落在产品经理和研发工程师身上，而是落在了开发人员身上。在第一种模式下，即使不同业务之间存在一定的底层相似性，产品设计仍然需要进行多次。因此，如果有一个假设：企业的数字化转型是否带来了不同行业之间更多的底层相似性，那么这种模式的边际收益注定会逐渐降低。在低代码模式下，业务之间的底层相似性被抽象为通用工具，通过它可以更快地构建满足业务需求的应用程序，生产的边际成本大大降低，边际收益也相应增加。总的来说，我同意一个假设：企业的数字化转型带来了不同行业之间更多的潜在相似性。同时，我认同一个经济规律，最后推导出我认同低代码方向的价值。而这个假设是否成立，值得大家一起思考。两个如何找到正确的方法。这是我担任产品经理的第五个年头。对我来说，找到正确方法的最大障碍恰恰是过去的经验，过去如何把事情做好，做低代码的时候会不自觉地产生路径依赖。要打破这种依赖，首先要想清楚：低代码产品经理和其他产品经理有什么区别。从上面的介绍不难看出，低代码产品经理会经历的特殊阶段叫做“从产品到工具”，这需要我们同时具备两种能力：扎实的业务知识和产品抽象能力。因此，低代码产品经理需要时刻平衡“具体与抽象的关系”。对于其他产品经理来说，他们的抽象能力一般用在从业务需求到产品需求的抽象上。例如，销售希望更好地管理潜在客户和手头的签约客户，因此产品经理为他们提供了一套CRM系统。但低代码产品经理的抽象能力要求他们拆解CRM系统，从后台数据模型到前端页面构建，这无疑是对抽象能力的巨大挑战。从最终状态来看，低代码产品经理的抽象能力应该成为他们的制胜法宝，他们应该花更多的时间在这种能力的培养上。但是从我半年多的经历来看，这个原则往往会导致误解，只注重抽象，轻视业务。我们说的抽象应该是从业务抽象到产品抽象，所以在早期，低代码产品经理必须全身心投入到业务中。他们必须要有一定的业务理解能力，才能谈抽象。抛开业务的抽象，它只是一种逻辑游戏，说严重点，是一种自我放纵。俗话说，没见过世面，谈何世界观。最近在做CRM项目的时候，这段经历非常深刻。起初，我接到的任务是完成CRM系统中一些复杂表格的构建。后来发现如果看不懂表背后的数据，包括数据从哪里来，表之间的关系是怎样的，现在CRM系统中的每一个表，表的作用是什么，有什么关系呈现的信息之间...如果你不理解这些，光想着如何用无代码的方式构建你眼前看到的表格，那肯定行不通，你会做的很痛苦，很困惑。综上所述，在低代码产品开发阶段，一方面我们需要了解这个角色在能力需求上与其他产品经理的不同，但另一方面我们也必须了解需要从业务中培养抽象能力。三决定是否做一件事的决策模型至关重要。我在做产品review的时候，经常面临的一个问题就是：我为什么需要这个需求。同时也会面临几个挑战：1、有没有业务场景；2、有没有业务提出这个场景；3、有没有竞品？首先，要有场景，没有业务场景的需求，很可能是伪需求。举个不恰当的例子，如果我做一个表格放大和闪入的加载动画，是不是需求，是的，但是如果有业务场景，不是，那这个就不应该做。但挑战在于，你需要区分没有看到场景的事物和没有场景的事物。如果我们把不知道这样的场景当成没有场景，那么这个产品的天花板就会被你的理解所限制。那么该怎么办？广泛体验过不同行业的SaaS产品，如CRM、ERP、WMS等，如果我们需要用低代码来支持各种复杂的企业应用，我们至少要知道这些应用现在是什么样子的，这也验证了一点，前期需要在不同的行业进行投资，积累经营经验。如果我们正在连接的业务没有提出这样的场景，我们是否应该这样做。我始终坚信，如果我们发现了真正有价值的需求，那么我们很可能比SaaS产品迭代得更慢，因为我们只是完成了从工具到产品的过渡，从产品到解决方案，还需要开发者的努力或实施团队。那么如果我们去做了，发现很久没有业务使用，是因为这个需求是假需求，还是没有找到真正的客户来服务？这些都是我们应该考虑的问题。不幸的是，这样的问题没有标准答案。只有不断扩大自己对行业和业务的了解，才能做出更接近事实的判断。四、分工没有界限。我们的团队会根据产品模块有不同的分工。每个学生在这种分工下都有自己更细化的职责，但分工不是界限。一个模块能不能做好，有时候要看你是否做过了解另外一件不在你职责范围内的事情。比如上面提到的CRM项目，我负责的是表单构建部分，但是深入了解后发现，如果不理解表单背后的数据结构，表单构建方案根本无法实施。我有一个明显的经验。之前以为只需要参与表格前端展示效果相关的间隙梳理，后来发现数据源、数据处理、数据展示是一体的。前两者看不懂，方案设计只是不完整。打破边界是为了获取更多的信息，从而提高效率，但提高效率的行动往往容易导致忽视问题的定义。为了加快进度，我们在工作中往往更注重寻找解决方案，但如果解决方案与问题的定义相矛盾，只能带来短期利益。上面说了在建表的时候，我们需要了解数据源、数据处理和数据展示之间的关系，但是我们实际遇到的问题是，由于数据源本身特性的影响，后台需要补充一些数据处理能力。但是在后端开发这些能力的成本比较高，而且项目周期紧，所以大家想知道这部分工作是否也可以在前端完成。遇到这些问题，我第一个想到的是，前端能不能解决，如果可以，是不是成本高，如果不行，为了项目能按时上线，还是做吧。虽然在讨论的过程中，我也觉得后端负责数据处理，前端负责数据展示，这样看起来更直观，但是如果我不做，会不会显得我不是“合作”够了。因为害怕背上这个标签，所以想办法从前端搞定。和老大沟通后，发现自己之前的思路没有触及问题的本质。如果这次是前端来处理，那么后面如果遇到这样的情况，数据源的特性比较复杂，会不会由前端来处理呢？其背后真正的问题是：在整个低代码产品构建复杂应用的过程中，面对如此复杂的数据情况，前后端分工应该如何更符合整个产品的长期规划。一个问题的短期解决方案有很多，但每个人对未来应该是什么样子的理解应该是一致的。这种讨论可能会影响一些工作效率，但确实很有必要。五接下来，我们来说说如何努力。在过去的六个月里，我对任务和目标有了一些体会。新人在落地阶段，虽然也需要制定自己的工作目标，但这些目标往往是依附于任务而存在的。比如我刚来的时候，就被分配到负责图表模块的任务。当时我的目标也是围绕着如何做好图表制定的。这个阶段是必要的，因为没有足够的信息和学习，从特定任务开始是明智和实用的。但这个阶段不能持续太久。如果目标永远为任务服务，那么我们所有的价值感和目的感都将取决于具体的事物，很容易忽视自身的成长。我自己也有过这样的经历。Q2的时候，我对chart的后续规划做了很多研究，整理了很多思路，但是Q3一开始就被告知chart需要交给其他团队，这让我很受打击突然陷入一种空虚之中，似乎一下子失去了目标。后来开始投身于形式相关的任务，也为这个任务给自己定下了目标，但因为低估了任务的难度，最后还是和团队一起评估了。现在还不是全面推进这个任务的时候，所以我提前推迟了。再一次，我有一种迷失目标的感觉。后来我开始反省自己，目标不应该为任务服务，目标应该大于任务，应该决定我想在这个公司成为什么样的人，目标和我的状态有关，And不应受特定任务的限制。当我有一个目标时，我可以制定不同的任务来为这个目标服务。我可以主动或被动地调整目标下的任务，但目标是对人的，就像北极星指标对产品增长一样。的价值。6、在大厂，我能感觉到身边有优秀的人。每个人的背景、专业度和沟通方式在从业者中都名列前茅。当我在一家小公司时，我觉得我想成为那个环境中最好的一群人；来到大厂后，心里总有一种淡淡的自卑感，甚至祈祷过一段时间能顺利过关。熬过试用期，这在以前是不可想象的。各大厂商的产品经理，似乎从来不需要别人催促自己去努力。会议、文件、项目、报告、OKR，足以产生强大的推力，推动我们前进。我曾经以为，只要我能尽我所能努力工作，我就能活下来。但后来我发现，更重要的是找到为什么而努力的答案。上面说的从目标到任务是一种方式，找出努力的方向，而我这六个月的另一个感受是，我需要对产品充满好奇。刚入职的时候，听人说现在的表单配置体验感觉很奇怪，不明白为什么要这样做。因为我不在负责表单功能的团队里，所以我只是听了这个说法，并没有很好奇。直到后来出现了与表单相关的任务，我才不得不从头开始研究表单功能。我在想，如果我能早点学习表格，我是否能为后面的任务做更好的准备？但另一个想法是，是什么驱使我进行此类研究。那应该是好奇心。除了好奇之外，我想不出任何其他的驱动力。好奇心并不是说“我知道发生了什么”，而是真正了解产品背后的基本原理及其存在的原因。七我问自己，平时这么忙，哪有时间去钻研不是自己团队的产品。我的一个经验是，我们必须与不同团队的产品经理保持一定的沟通频率。这种沟通不能仅限于跨团队的需要。更好的方法是抛开需求，更开放、更自由地沟通。事实上，也许这只是我的一厢情愿，因为我看了每个人的日程安排，似乎每个人在工作日都很忙，但如果有人愿意来找我咨询有关组件的问题，我很乐意它。当然，我希望他们也将自己负责的模块带到知识交易中去。另一方面，低代码产品经理需要与研发部门进行更多的沟通。我了解到很多公司都有自己的低代码平台，发起者往往是技术团队。low-code的技术视角和产品视角不完全一样，所以需要更多的交流。上周末参加了美团在线技术沙龙。有一段是关于美团和阿里的低代码技术分享。我马上把拿到的信息发给了我对接的前端同学。我不知道大周末。打扰别人合适吗，但那一刻我真的很想分享一些东西。他也及时给我回了一些他了解到的信息。我能感受到他对低代码领域的热爱，有时交流会传播这种热爱。最终，我选择在这个节点输出这样的评论，更多的是为了自己的动力和鼓励。你是否还记得那三个问题：1.你是否同意你所做的事情？2.找到正确的方法了吗？3.你工作够努力吗？这三个问题我都给出了自己的答案，接下来就只剩下一件事了：去做吧。
