关于ZAKER ZAKER智慧云 免费视频剪辑 合作 加入

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

在转行后,或许会有很多需要学习与改进的地方,也免不了会在当中遇到一些问题。作者通过分享自己转行低代码产品经理的一些思考,帮助与同样在迷茫中转行的你找到正确发力的解决方案。

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

我在想,到底是哪里出了问题。

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

关于复盘,我会给自己提三个问题:

你认可自己在做的这件事么

你有没有找到正确的方法

你是否足够努力

理想情况下,对于自己负责的工作,我们应该是先找到价值,再寻求方法,最后付出努力。但事实上,很多人往往是先努力(加班),再从或有效或无效的努力中提炼出方法,最后再慢慢找到价值。

两种路径都可以,第一种方法更容易做得开心,因为构建起了正反馈。价值是最基础的保障,正确的方法可以让努力变得更有回报,于是更加认可事情本身的价值。而第二种方法更容易上手,因为相比找到价值,努力反而是不需要思考的。

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

当然我们不是否定第二种价值,只是这样的价值让我们更容易放弃眼前的工作,或者更不容易找到工作本身的乐趣。因为这种价值不是这个工作所独有的,这恰恰才是关键。

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

起初我认可这个方向,是因为我觉得这个岗位要求的业务抽象能力,是我所推崇的产品设计理念。但现在我会觉得,格局小了,认识太浅了。

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

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

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

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

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

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

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

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

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

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

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

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

二、如何找到正确的方法

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

要破除这种依赖,首先要想清楚:低代码产品经理跟其他产品经理有什么不一样。

从上面的介绍中不难看出,低代码产品经理会经历的特殊阶段叫做「从产品到工具」,这要求我们同时具备两种能力:扎实的业务知识和产品抽象能力。所以,低代码产品经理需要时时刻刻平衡好「具体和抽象的关系」。

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

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

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

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

抛开业务的抽象,只是一种逻辑游戏,说严重点,是一种自嗨。就像那句话说的,如果没有看过这个世界,又何谈世界观呢。

我最近在做 CRM 项目的时候,这种体会非常深刻。

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

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

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

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

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

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

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

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

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

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

那如果做了,且在很长时间内发现没有业务用,到底是因为这个需求是伪需求,还是因为我们还没有找到真正服务的客户呢,这都是我们应该去考虑的问题,遗憾的是这样的问题并没有标准答案,只有不断扩大自己对行业、对业务的了解,才能做出更接近事实的判断。

四、分工不是边界

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

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

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

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

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

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

虽然讨论的时候我也觉得,似乎后端负责数据加工,前端负责数据展示是更符合直觉的,但如果我不做,是不是会显得我不够 " 配合 "。因为害怕背负上这个标签,于是想办法从前端去搞定。

后来跟老板沟通下来,发现我之前的思考并没有触及到问题的本质。如果这一次前端处理了,那后续遇到这样的情况,且数据源特征更复杂,是不是都是前端来做。其背后真正的问题是:

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

短期内针对一个问题的解决方案有很多种,但对于未来应该要做成什么样子,大家的理解应该是一致的。

这种讨论也许会影响一些工作效率,但确实是十分必要的。

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

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

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

但这个阶段不能持续太久,如果目标总是服务于任务,那我们所有的价值感和目标感都是依赖于具体的事情,而容易忽略我们自身的成长。

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

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

后来我自己开始反思,目标不应该服务于任务,目标应该是大于任务的,它应该去决定我在这家公司希望变成一个什么样的人,目标是跟我这个人的状态相关联的,而不应该受制于具体的任务。

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

六、摆脱 " 被动 ",提前做准备

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

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

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

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

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

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

我在想,如果早一点可以去研究表单,是不是自己能够为后来的任务做好更充分的准备;可又一想,是什么会驱动我去做这样的研究呢。那应该就是好奇心了,除了好奇心,我想不到有别的驱动力。

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

七、忙碌的工作中,如何钻研其他产品

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

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

现实情况是,也许这只是我的一厢情愿,因为我看大家的日程,好像每个人在工作日是真的很忙,但如果有人愿意找我了解一下关于组件的一些问题,我是很愿意的。

当然我希望他们也带着自己负责的模块,来一场知识的交易。

另一方面,低代码产品经理需要跟研发有更多的沟通。我了解到很多公司都有自己的低代码平台,发起人往往是技术团队,低代码在技术视角下和产品视角下,并不完全相同,所以需要更多的交流。

上周末我参加了美团线上技术沙龙,里面有一个版块是关于美团和阿里的低代码技术分享,我立刻将获取到的信息发给了我对接的前端同学,我不知道大周末的打扰人家是不是合适,但那一刻确实想分享一些东西。

他也及时回了我,带了一些他了解到的信息。我能感觉到他对于低代码这个领域的热爱,有时候交流会传播这样的热爱。

最后,我选择在这个节点输出这样的复盘,更多的是对于自己的激励和鞭策。还记得那三个问题么:

你认可自己在做的这件事么

你有没有找到正确的方法

你是否足够努力

我对这三个问题都给了自己的回答,那接下来就只剩一件事:干就完了。

专栏作家

大力哥呀,微信公众号:大力哥,人人都是产品经理专栏作家。一个 90 后产品经理,已经写了 6 年的公众号,通过输出获得了许多意料外的成长。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

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

最新评论

没有更多评论了

觉得文章不错,微信扫描分享好友

扫码分享

热门推荐

查看更多内容