|
|
在转行后，也许会有得多需求学习与改进之处，也免不了会在傍边遇到一些问题。作者经过分享本人转行低代码产品经理的一些思考，帮忙与一样在迷茫直达行的你找到正确发力的解决计划。
往年三月份我转行做了低代码平台的产品经理。比来刚刚过了半年试用期，也在复盘本人入职以来的表示。主观来讲，这半年的产出其实不合乎我的预期，我但愿本人能够发扬出更大的价值，但看起来事实其实不如所愿。
我在想，究竟是哪里出了问题。
比来本人有了一些思考后果，也跟更高阶的产品同窗有了一些交流，但愿在这篇文章中能将这些效果分享出来。或许我四周有一些转行的产品经理正在阅历我同样的表情，我但愿经过对本人任务的粗浅分析，给他们一些激励和办法，在「迷茫」的情绪中找到「知道该如何发力」的解决计划。
对于复盘，我会给本人提三个问题：
你认可本人在做的这件事么你有无找到正确的办法你是不是足够致力现实状况下，关于本人担任的任务，咱们应该是先找到价值，再追求办法，最初付出致力。但事实上，得多人往往是先致力（加班），再从或无效或有效的致力中提炼出办法，最初再缓缓找到价值。
两种门路均可以，第一种办法更易做得开心，由于构建起了正反馈。价值是最根底的保障，正确的办法能够让致力变得更有报答，因而更为认可事件自身的价值。而第二种办法更易上手，由于比拟找到价值，致力反而是不需求思考的。
咱们所说的价值，是这项事业自身所具备的价值，好比对低代码平台来讲，就是它对现有的 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协定。
该文观念仅代表作者自己，人人都是产品经理平台仅提供信息存储空间办事。 |
|
注册会员