在转行后，或许会有很多需要学习与改进的地方，也免不了会在当中遇到一些问题。作者通过分享自己转行低代码产品经理的一些思考，帮助与同样在迷茫中转行的你找到正确发力的解决方案。
今年三月份我转行做了低代码平台的产品经理。最近刚刚过了半年试用期，也在复盘自己入职以来的表现。客观来说，这半年的产出并不符合我的预期，我希望自己可以发挥出更大的价值，但看起来事实并不如所愿。
我在想，到底是哪里出了问题。
最近自己有了一些思考结果，也跟更高阶的产品同学有了一些交流，希望在这篇文章中能将这些成果分享出来。也许我周围有一些转行的产品经理正在经历我一样的心情，我希望通过对自己工作的深刻剖析，给他们一些鼓励和方法，在「迷茫」的情绪中找到「知道该如何发力」的解决方案。
关于复盘，我会给自己提三个问题：
你认可自己在做的这件事么你有没有找到正确的方法你是否足够努力理想情况下，对于自己负责的工作，我们应该是先找到价值，再寻求方法，最后付出努力。但事实上，很多人往往是先努力（加班），再从或有效或无效的努力中提炼出方法，最后再慢慢找到价值。
两种路径都可以，第一种方法更容易做得开心，因为构建起了正反馈。价值是最基础的保障，正确的方法可以让努力变得更有回报，于是更加认可事情本身的价值。而第二种方法更容易上手，因为相比找到价值，努力反而是不需要思考的。
我们所说的价值，是这项事业本身所具备的价值，比如对低代码平台来说，就是它对现有的 SaaS 模式的影响。而绝非那种普遍适用的价值，比如这份工作让我能够生活得很好，有不错的社会地位。
当然我们不是否定第二种价值，只是这样的价值让我们更容易放弃眼前的工作，或者更不容易找到工作本身的乐趣。因为这种价值不是这个工作所独有的，这恰恰才是关键。
二、我认可低代码这个方向么？是的，毫无疑问起初我认可这个方向，是因为我觉得这个岗位要求的业务抽象能力，是我所推崇的产品设计理念。但现在我会觉得，格局小了，认识太浅了。
《硅谷钢铁侠》这本书提到，在创建 space X 早期，马斯克制定火箭制造计划时，往往会从物理学的角度判定一件事是否可行。如果在底层逻辑上这件事是跑得通的，剩下来的就是方法和执行力的问题。
同样的，低代码这个方向如果在底层逻辑上跑得通，剩下的就是从业者们如何找到方法并付出执行力的问题。
在我眼中，低代码的价值依托于一个被普遍验证的经济学规律：科斯定律。通俗地说，谁能把资源用得好，资源就归谁。
我们再回顾下低代码产品和其他产品的区别，可以理解为下面这张图。
对于大多数产品来说，它是围绕着需求而生的，从业务/用户需求到产品需求，从产品需求到产品；而对于低代码产品来说，它是围绕着产品而生的，从业务/用户需求到产品，从产品到搭建产品的工具。
两种模式的差异在于，前者将最宝贵的资源投入在业务/用户需求到产品的这个阶段，而后者将最宝贵的资源投入在从产品到搭建产品的工具这个阶段。
在企业数字化早期，业务/用户需求差异性较大，通用化的解决方案几乎不存在，于是资源投入在第一个阶段是可行的，因为回报最大。
后来 Salesforce 带来了 SaaS 这种新兴的模式，但我一直认为这