不少人觉得产品经理不需要什么特别高的门槛，也就导致不像技术、设计一样有技能傍身，导致部分产品没什么安全感，对自己定位比较模糊。这篇文章，我们看看作者分享的方法。

一、产品经理的价值

产品经理，是有价值的，关于这个结论，我一点也不怀疑，并且，我认为产品经理具有非常巨大的价值。尽管如此，我仍然时常觉得缺乏安全感，这种安全感的缺乏就好比我是一个身经百战的老练船长，但我正抱着一块木条，漂浮在汪洋大海中。我缺少了什么？仔细想想，我缺少了一条大船，另外还需要给我一批同样身经百战的水手。这也正是产品经理这个岗位的尴尬，我产出的内容有很大的价值，但要想让这些价值体现出来，你得给我一个团队以及足够的资源，否则我的产出物仅仅是纸上谈兵。这就是产品经理面临的困境。

二、我的破局之路

我是思想上比较传统的手艺人，所以追求的不是“你有金银堆北斗”，而是“我有手艺度春秋”。为此，我一直在寻找一种方法，让我自己可以完成价值转化，这样我就不需要再去考虑有没有合适的团队来实现我的设计，以及有没有公司正好想做我设计的方向。为此我打算将已经放下多年的研发技术重新捡起来。

1. 研发技术

于是我开始重新学习现在的云原生技术，以及目前常用的后端研发框架以及中间件。不得不承认，想法是很好的，由于我做过几年全栈开发，所以学习来并没有觉得很吃力，反而又找回了当时研发产品的快乐。这种快了是很纯粹的，就是将自己想要实现的效果一点点钻研和尝试，然后解决过程中遇到的问题，最终达成阶段性目标的成就感。如果能够一直这样下去就好了。很显然，我没有那么多时间，平时我是有产品经理的工作要完成的，业余时间学习研发技术，如果我真的打算自己一个人完成价值转化，那么我需要学习的技能树是非常庞大的，在经过了两个月的学习以后，我就放弃了。不过尝试的这两个月，确实是我最近几年最快乐的时光。

2. 低代码平台

由于2022下半年，给某个医药企业规划内部信息化建设的工作期间，我接触到了一些低代码平台。当时我是作为甲方，低代码平台的销售人员对自己的产品进行了详细介绍，在听介绍的时候，我就发现了一些端倪。

首先，有不少低代码平台介绍的时候，都提到了几个概念，一个是表单，一个是流程。但凡以这种套路起手的产品，我都排除了，因为当时我们需要的是可以研发出真正系统功能的低代码平台，而不是做一些表单审批和数据统计的低代码平台，虽然用表单和统计图表来实现某些功能会比较方便，但作为我们企业自身的长期发展来说，这些功能最后还是会被自己研发团队做的功能给替代掉，这样才能更方便的扩展功能。

当时，也接触了一些不同风格的低代码平台，在这里我就不点名，避免有宣传的嫌疑，这种类型的低代码平台会有自己的界面编辑工具，也是拖拽式的，但数据格式并非和界面绑定，有着单独的模型设计功能，说直白一点，就是需要先设计数据库结构，然后再做操作界面，这种低代码平台就自由很多，但也有着致命的缺点，那就是它真的只是“低”代码平台，基本的单表增删改查，低代码平台是可以解决的，一些简单的单表数据修改，或者关联表数据修改，经过一些还算不那么复杂的配置就可以完成，但是当我想要配置一些比较自由的功能，或者后端逻辑和前端交互需要更自由的联动时，这种风格的低代码平台也很难支撑了，我也问过了客服，客服建议我这种情况，还是用代码写，然后将后端接口集成到平台中，由前端的控件事件调用。所以，所谓低代码，其实也只是对研发的自由度进行了削减，换得的是研发效率上的一些提升，这很合理，想要效率更高，就需要损失自由度。

这段时间，由于我想靠自己就实现产品经理应有的价值，我又决定好好的挑选一款低代码平台，尝试在低代码的规则下，研发我擅长的领域的产品（ERP、财务、运输等企业管理软件及互联网后台产品）。这里我很可惜的告诉大家，我失败了，没有任何一款产品能够满足我这个想法，目前市面上的低代码产品，就不是用来做这种事情的，归根到底，低代码平台，还是只想做一些简单的功能，在舒适圈里小打小闹。

3. 其他方法

对于自己研发产品的尝试，我仍然没有放弃，经过长时间的尝试，我关注到了一款产品，这款产品让我觉得有希望自由的研发我需要的应用软件，并且效率相对较高。同样，为了避免宣传的嫌疑，我不会公布这款产品的名称以及任何信息，但我会在后续的文章中，将我使用这款产品自己研发软件产品的过程进行记录。这么做有两个目的，最重要的目的，是希望对整个过程有一个记录，以便我进行回溯和分析，第二个目的，如果各位同行也感兴趣，就可以多一个交流的渠道，我相信想要填补我开头所说的“安全感”的产品经理，一定不止我一个。

三、关于敏捷研发的思考

其实，我并不认为目前的研发模式存在什么问题，不过想要研发出一款产品，确实会有高昂的成本，因此软件供应商会尝试做出“通用产品”来满足不同需求的客户，这么做，有一个隐藏的风险，那就是产品本身的逻辑越来越复杂，影响点越来越多，导致在具体项目实施的过程中，本来成本应该较小的二次开发需求都需要考虑众多影响点，而变成大需求，甚至直接拒绝掉某些需求。

从我做研发那会儿就觉得，企业想要适合自己的软件，还是得定制化开发。阻碍企业选择定制化开发的原因主要是两个，其一是成本高，其二是成功率低。这两个原因完美的诠释了1+1>2，如果只是成本高，可以用价值来平衡，但加上成功率低，那企业往往就会选择放弃了。

成功率低在业内也有较好的解决方法，那就是敏捷研发，敏捷研发的基本目的，就是为了应对变化，只不过也有其致命的问题，那就是对人的要求，好的方法还需要正确的人来贯彻，一旦项目参与人员和工种变多，就很难很好的执行某个方针，最终回到原点。

因此，我并非仅仅是出于给自己找安全感的目的才想着寻找产品经理也可以使用的研发平台，更多的，是希望降低因为沟通带来的项目风险，以及让有能力的人发挥出其全部价值。