高代码产品经理时代来临，如何避免在技术型产品的浪潮中被时代淘汰

陈霈霖——vika维格创始人&CEO，前喜茶CTO & CIO、数字营销负责人，负责喜茶GO小程序、会员体系从0到1、全平台电商、私域运营、数字供应链、数据中台、IT信息化、SaaS选型采购等数字化相关所有模块。 

先分享两个故事。

第一个故事，2011年左右，我有一个计算机毕业的同学参加校招。当时现场有两条队伍，一条大排长龙，另一条无人排队。为了节省时间，他排了那条无人排队的队伍。

排长龙的队，是应聘软件工程师的；没人排队的，是应聘产品经理的。

就这样，他成为了微信的第一批产品经理。

可见，当下的产品经理虽然可能是产品的主宰者，但与之相关的经验理论、职业共识，在十年前都不存在。

第二个故事，我有另一个朋友，以前在银行做软件开发。他觉得现在的产品经理都很“矫情”。以往的他需要输出很长的、几百页的PRD，用非常复杂的材料进行软件开发，但他的职位叫项目经理。

总结来看，90%的产品经理是近十年才出现的；十年前所有的软件公司里，更多的是项目经理来输出文档，并且他们还懂技术、会写API，可以一个人囊括交互、原型与流程图等工作。

可见，职位和职责在不断地变迁；对产品经理的能力和要求依据时代的不同也会有所变化。

发现二：80%不懂编程原理的产品经理会慢慢消失

我们经常谈论的产品经理，其实说的都是“互联网产品经理”，有一个基本认识是要记住的：产品 = 软件；产品策划 = 软件工程。

但2010-2020这十年间，为什么许多产品经理不被称作软件工程师？甚至连编程都不会？因为很多产品经理在做吃喝玩乐型APP。比如下图，看看这些App的图标，我们便知道它背后所代表的是产品是什么样。

通过对比，过去10年，我发现可以留下深刻印象的效率工具型产品十分少见。因此，过去10年才会让人思觉失调地认为世界上只有这些类型的软件产品。

将时间往回倒，那些真正的软件又是什么样的？

比如Windows3.1、最早的DOS版WPS、FrontPage、FoxPro、Visual Basic等。

2010年前我们所理解的产品就是软件，且这些软件大都高度复杂、技术抽象，与当下这十年所看到的完全不同。

可以说，未来10年80%不懂编程原理的产品经理会慢慢消失，当下的软件产品，像B端软件、云计算软件、数据库软件、智能硬件嵌入式软件，都需要有大量的技术知识作为前提。产品经理对技术、对行业必须要深度了解；产品经理不一定需要懂得如何编程，但一定要深刻地理解技术原理。

发现三：20%的产品经理将拥有技术架构师的能力

如上图所示的新一代云计算产品，假如产品经理没有架构师的能力，你可能看都看不懂这些产品是做什么的，更无法将所有事物连贯起来。我在面试时就喜欢做这样的一件事情：给出一个海外技术产品的网站，然后让面试者默读三分钟之后说出这个产品的用途。

98%的人都无法通过这个面试问题，但若想把新一代的云产品做好，肯定需要对相应的东西十分了解。

为什么我们会出这样的面试问题？因为我们需要做一个开放平台，这个平台供给工程师和程序员使用，支持REST API，还可以做小组件SDK、自动化脚本等。因此，假如面试者不懂技术，又怎么能做得出这个产品呢？

其实我们的许多用户本身就具备了产品跟技术能力，例如有用户自己开发了一个ERP，通过API读取之后再自行写前端；也有用户基于一个简单的表格，生成了一个物流跟踪的小插件，用于跟踪物流速度。

还有的用户结合经纬度，做了一个门店地图小插件；他们中也有利用快捷指令批量生成二维码，或者利用快捷指令做一个图书管理相关的系统。

你会发现，已经有许多高级用户掌握了技术架构的能力，可以自己创新、建立、实现产品。这一现象近十年可能较少，但是在2010年以前，利用visual basic、Access等软件，都可以实现类似的结果。

— 2 —

展望100%产品经理的未来之路

100%的产品经理未来都会发生巨变。不过回望历史，这些变化同样有迹可循，因此，我们能够判断未来的产品经理大致会走向怎样的发展路径。

1.人人型

第一类“人人型”，即让一个普通人去分析老板、管理者、执行者是谁，并快速地进行业务建模，然后告知需求。除了客户，HR、市场、销售都会给产品经理提出解决方案的需求。

所以这种未来的产品经理形态是如何诞生的？可以从我的经历讲起。

大学时，我是一个非计算机专业的“外行”，后来自学技术入门。我很喜欢使用各种各样的复杂工具，也在具体实践需求中学会了编程。

那是有一次，我想做个网站，于是研究起网站设计需要什么软件。这一阶段经历了从使用Fireworks设计软件，到搭建Web开发框架，后续对接数据库，之后了解原理，学习PHP语言。

大学之后我进入更深层次的游戏领域，而在这个过程中，我经历了以下阶段：

摸索3DsMax美术软件 → 了解Unity框架 → 了解原理 → 相信C#编程语言。

假设未来充斥着各种各样的技术产品，我们应当如何避免被这些技术型产品淘汰？这几年，行业出现了低代码等技术产品，也有了普通人便能掌握软件的趋势。

这就要求我们具备掌握代码的能力，和掌握创新工具的能力。

2.功能型

第二种分类叫功能型。

我们公司对这一类型的产品岗和过往最大的区别是，不看过程，只看产出。PRD不是产出，而是过程。真正有用的产出是指给用户看的产品说明书、版本发布、以及API接口文档。

3.设计型

第三种叫设计型。此时所知的产出是指可供大家查看的UI库，比如Figma UI库，且生成可与前端工程师一一匹配的组件。

4.业务型

第四种叫业务型。这里我们定义的有效产出，即产品demo，另外还能产出可供销售照读的销售方案，等等。

5.运营型

最后是「运营型」，现在运营方案一出，便可将方案交给UI，后续又会有相关有效产出，比如H5、帮助中心、版本发布等。

最后再讲一点，我发现软件其实不需要那么复杂，我们可以进行倒推，做出一个可以做软件的软件，通过各种各样关系型数据库的关联、并结合基本的技术理论、通过API连接，许多软件需求、客户需求都可以完成。

— 3 —

结语

有人说低代码工具的出现真的会导致程序员失业，因为绝大部分工具都已经不需要程序员去写了。但是，随着低代码工具的发展，低代码工具，却出现了越来越多的“高代码”能力，比如小程序、扩展插件等等。

讨论低代码工具会不会导致程序员失业，已经毫无意义了，程序员应该如何用好低代码工具，为更高阶的程序开发服务？

6月10-11日，陈霈霖老师将受邀，在2022K+全球软件研发行业创新峰会上作《低代码工具与开发者的未来》主题演讲，感兴趣的小伙伴一定不要错过哦！

现在报名参会还可享受新春早鸟优惠

立减2380元起

早鸟优惠截止2月28日

报名还有机会抢占限额大时段工作坊"POY*敏捷杀 沙盘"的学习机会

赶快扫描上方二维码或点击阅读原文，了解峰会详情报名吧！