编辑导语：作者在这篇文章中向我们讲述了他的转型经历，谈到了过往的产品经验和现在的不同之处，补充了自己对以往工作的认知，并向我们提供了一些建议，希望对你有所帮助。

今年 3 月份，我入职了字节跳动飞书团队，岗位是 aPaaS 产品，也就是低代码产品。

在我之前的职业生涯中，我虽然做过 C 端产品也做过 B 端产品，但我在面试这个岗位之前，我从未听说过低代码这个方向，因此这次跳槽对我来说是一次全新的产品探索。

理论上说，每一次跳槽都会对一个人产生或多或少的影响，无论是在工作方式上，还是在产品认知上。但这一次跳槽对我来说跨度尤其大，所以积累的经验与教训较以往也更多。

另一方面，随着工作年限的增加，我对于新信息的接受度往往是更高的。年轻时觉得突破认知的事情，在见识多了之后也就见怪不怪了。

而这次在入职后，我对这个产品仍然有「哇」的感觉时。我希望及时记录下来，并与大家分享出来。也许以后再回看的话，别有一番体会呢。

与这个岗位的渊源，要从面试说起。

收到HR电话的时候，我正在乘坐地铁，本来想挂掉电话加微信仔细聊的，但HR说想跟我先介绍一下岗位的内容，我就跟她聊了起来。

HR跟我说了很多，但我记住的只有，这是对于产品经理逻辑抽象能力要求很高的岗位。

我当时在前司做评论组件化的项目，正好跟岗位描述的产品能力有重合的地方，于是我说，那就聊聊吧。

整个面试过程一共有 4 轮，只聊了我过去做的两个项目：退款优化和评论组件。

那段时间我将这两个项目重新整理了一番，从产品架构开始一步步做下钻分析。

我知道对于 C 端产品来说，这两个功能是看似普通且通用的功能，但真的研究起来之后，其实会发现很多地方是设计产品时没有想得很清楚的。

通过面试的过程重新思考自己过去的工作，这便是面试的价值之一。

读到这里，你可能一直有个疑问：到底什么是低代码？

在IT 相关行业里，如果要开发一个新的应用，需要经历需求调研、分析、设计、开发、测试、上线等诸多环节，如果应用本身很复杂，这个开发周期就会变得非常长。

在行业发展早期，应用开发主要还是发生在互联网企业，这些公司可以用更高的薪资吸引程序员和产品经理来完成应用开发，在探索中，产品开发流程也经历了诸多模式的迭代。但无论是哪一种模式，都离不开一个前提：

程序员是需要为应用开发写代码的。

互联网的指数级增长，使得很多探索类的产品固化为行业的基本玩法。很多产品的底层逻辑，都是关于数据的获取、流转与展示。只是在不同的企业或者行业中，包装为不同的产品而已。

另一方面，越来越多的传统企业也逐渐开始数字化转型，而数字化的第一步，就是传统的离线信息需要在线化，于是在线应用成为了很多传统企业的新缺口。当他们需要一个适合自己企业的应用（比如招聘管理系统）时，或者是自己招程序员进行开发，或者选择提供标准化产品的服务商。

前者的成本极高， IT 从业人员的平均薪资已经被互联网公司捧起来了；后者的灵活性有时候不能完全满足自己企业的需求。

这时候低代码产品就发挥作用了，它的最大价值是：支持快速搭建应用，无需开发或者只需要少量开发。

低代码平台能够让真正懂业务逻辑的人高保真无折损地完成应用构建；让 IT 研发人员真正从繁琐重复的工作中释放出来，专注在有差异化、创新性的工作上。

总的来说，低代码产品是「为创造产品而服务的产品」，产品是对需求的抽象，低代码是对产品的抽象，所以说，它对于产品经理抽象能力的要求是极高的。

到这里，关于这次转型的背景就介绍完了。下面聊聊这次转型中我的一些沉淀，我相信对于想要转型或者正在转型的你来说，也许会带来一些启发。

一、每一个项目的背后都是机会

能够顺利拿下 offer，其实主要得益于我做的两个项目：退款优化和评论组件。虽然两个项目都是被安排的，但在当时的重要性完全不一样。

退款项目起始于去年 3 月，但真正启动要到 7 月才开始，因为用户体验优化的需求，往往要让位于业务创收需求，因此在两次大促间隙，才有产研资源投入到这件事上。

而评论组件项目起始于去年 12 月，立项后立刻找到我作为产品 owner 去推进，半个月后 prd 就写完了，整体效率非常高。

对于产品经理来说，业务价值是决定要不要做的重要参考，可是一旦开始，就要尽力做好产品设计本身的完备性。虽然退款和组件项目的起点不同，但在产品设计中，他们的复杂性是相当的。并且在后续的面试中，他们受到面试官的关注程度也是相当的。

所以，无论你此刻在做重要的事情还是边缘的事情，一旦开始，就要保证交付质量，这需要你投入足够多的思考和努力。无论这件事在公司的价值如何，当你努力投入时，背后可能都是一个机会。

二、反讲是最好的交接方式

入职 aPaaS 团队后，我负责的是报表模块，交接时间只有一周。

对我来说，低代码产品和报表产品都是之前没有做过的新领域，当这两者结合时，交接压力是巨大的。

为了让我尽快熟悉新工作内容，我和老板决定用反讲的方式。根据给到我的交接文档，反向给老员工们讲解要接手的工作，讲解内容主要包括功能介绍、问题和规划这三个部分。对于新员工来说，要讲好这三个模块是不容易的，这需要在短时间内集中消化交接文档和新工作，然后再反向输出。

是的，这就是费曼学习法的应用。

尽管压力很大，但这样的交接方式实实在在帮助到我了，一周后，我就完全将工作接手过来。

后来，反讲成为了我们组固定的交接形式，我认为这是一种值得推广的方式。

三、你的经验和基本功可能会麻痹你

今年是我做产品的第五年，已经积累了一些自己做产品的经验，并培养了比较实用的基本功。但这次转型过程中我深刻体会到：

经验和基本功可能会成为你进阶路上的麻醉剂

当我接手了新工作之后，便开始跟进在进行中的工作，同时也从一些小需求练手。这个过程不太依赖你的专业能力，更多的是跟研发和设计团队的沟通，在出现冲突时根据经验和常识给出解决方案。在第一个月内，借助之前攒下的经验，工作基本处于顺利推进的状态。

随着时间的推移，我开始越来越觉得，自己似乎一直是在用基本功解决问题，但对于所负责产品的认识并没有比刚入职的时候提升多少。

或者说，我的认识都是在表象，无法透视到产品底层架构和行业现状等更考验专业能力的地方。

这是一个危险的信号：工作中的事情并没有阻塞，但是这种表面的顺利并不能带来专业度的提升。表现在我无法做出真正有价值的产品规划，只能把之前产品遗留的工作做好。

那段时间，我在自己的小报童里写到：

1. 我对于“专业”的理解，是能画地图，能有坐标。对于一个人专业的评价，是基于某个领域的。比如电商，比如快消。
2. 专业的第一个要求，是有一张行业地图，描述了这个行业的概况。
3. 专业的第二个要求，是知道自己在地图中的位置，应该往哪里走。
4. 经验丰富不一定就专业，只能代表遇到同类事情的时候，你会有肌肉记忆。但是这个行业如何，你该去到哪里，如果只是经验丰富，可能是给不出答案的。
5. 为什么会思考这些，因为我越来越发现，只是经验丰富，已经不足以给我信心，甚至把经验误以为专业，这会让我恐慌。
6. 只有不断的学习、请教、检验自己脑子里的地图和坐标，才能不断地给自己信心。

所以，不要将眼光停留在表面的顺利，如果不能变得更专业，我们对自己的信心终究会消耗完毕。

四、从架构出发做产品规划

对于产品经理来说，能够获得产出的前提，是你对于手头的工作有自己的规划。而对于转型期的产品经理来说，针对负责的新产品制定一个合理的规划，是必经之路。

我曾经在小报童中记录过自己在入职后做工作规划的方式：「广泛收集」+「分类」

对于新业务的信息，应该从各个渠道收集，无论是之前负责人交接过来的，还是老板反馈的，或者是业务给到的，只要这个信息是一手的，是与工作规划相关的，都应该收集并整理。

其次，对信息进行分类，这里最核心的就是分类的角度，角度切入得好，工作计划自然就出来了。

事实证明这样做规划是不够的，做出来的东西只能称之为一个待办清单，而不足以成为具有指导意义的工作规划。

规划是一个地图，通过它你可以看到现状是什么，目标在哪里，通过什么样的路径达到目标。

回归到产品规划，我认为它至少要建立在架构层面。当然如果你的影响力足够大，你可以在战略层做出规划，只是对于绝大多数一线产品经理来说，在转型期首先要理解战略。在理解的基础上，在范围层对产品做出规划。

分享一个我在工作中的实际思考：

1. 架构直接决定产品规划

我认为，战略层决定产品定位，体验层决定具体需求，而功能层直接决定了产品规划。

回归到报表上，我们知道报表模块的本质是一个 BI 产品，只是在我们的低代码平台，这个 BI 产品是由开发者自己搭建的。

从产品迭代原则上来说，我们始终要坚持「降低开发者的搭建门槛」「提升终端用户的体验」「提升产品的天花板」

遗憾的是，产品迭代原则不能作为产品规划，它只是检验你的规划是否合理的标尺。

真正的规划，是建立在「起点」、「终点」和「路径」这三个要素上的。而要弄清楚当前的起点是什么，终态如何，应该如何迭代，就要深入剖析产品的架构。

2. 真正解决问题而不是打补丁

如果产品经理不关注架构，那么做需求就容易变成打补丁。

这个逻辑在于：业务方是不会替产品经理去思考架构问题，他们只会思考业务架构，产品对于他们来说是工具，工具用得不顺手，就有了问题反馈。

比如有业务反馈过希望矩阵表里可以支持文本展示，比如分数指标在 60 以下时显示不合格，这个诉求对业务来说是合理的，因为他们就需要更直观的信息展示，开会的时候看起来效率更高。

但产品经理关注这个问题的角度就不能停留在「指标满足某个条件时显示文本」，那如果之后有业务说希望「指标满足某个条件时显示颜色块」，那是不是又得作为新的需求去支持？

所以，真正要解决问题，就是将问题的本质思考清楚，从业务反馈的体验问题中，看到功能层的局限性并思考对应的解决方案。关注架构才能真正解决问题。

3. 提前半步思考，提升产品竞争力

当然，有人可能会问，如果连打补丁这件事情都做不到位，产品又何谈竞争力呢？这个问题我也一直在思考，我曾经也以为，如果能够以最快速度去响应业务诉求，这是不是产品最大的竞争力。

是的！

但是，「最快速度」的实现方式不是加快处理业务诉求的速度，而是逐步降低处理每个业务诉求的成本，直到零成本处理。

这一愿景跟 aPaaS 的本质是相同的，不是要让加快原有的产品上线流程，而是通过架构的升级（比如组件化）让产品上线是零代码或低代码的。

因此，提前半步思考产品架构问题，当业务诉求到来的时候，用产品已有的能力零成本或低成本去解决，才是产品竞争力提升的关键。

五、把擅长的事情做到极致

我们都希望在团队中找到自己独特的价值，成为团队里那个不可获取的一部分，那如何做到这一点呢？

我的答案是：在自己擅长的事情上做到极致。

前面说到了工作交接的反讲，后续的故事是，当我做完反讲之后，我们团队后续的反讲文档都是参考我的那份文档去做，然后我根据自己入职后的体会，写了团队的新人 Landing 文档，而这个文档也被aPaaS内的其他团队操作。

在写文档这件事上，我抓住每一个机会争取做到极致，然后渐渐地，团队里与写作有关的工作基本就交给我了，甚至，我还在团队内部做了一次关于写作的分享。

大多数人其实是能找到自己擅长做的事情，只是这些事情看起来跟自己的本职工作没有太多关系。每个人在潜意识里都希望被更多人看见，而被看见的理由是我们对于团队产生了自己独特的价值，而实现这一目标的方式之一，就是把自己擅长的事情做到极致。

这不是推理出来的方法论，而是实践出来的总结。

当我们做到极致，做到别人做不了的程度时，我们在某些方面，就为自己占据了一席之地。

以上就是我转型做低代码产品之后的一些经验与教训，有偏职场的，有偏产品的，但每一个都是我真实的经历与体会。

如果你是低代码产品，如果你想了解低代码产品，欢迎交流~

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

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

题图来自Unsplash，基于CC0协议