前几天的春季发布会上，飞书正式推出了业务三件套，其中就包括飞书自研的低代码平台：飞书应用引擎。

恰好至今年 3 月 9 日，我加入字节跳动整整一周年，也在飞书做低代码产品整整一周年。在我们圈子有一句话，叫做字节一年，人间三年，以此来形容字节跳动工作的繁重和压力。

对我来说，这漫长的一年确实有许多值得回顾和复盘的地方，虽然在一年的时间节点上几乎没有任何仪式感，因为一直有下个重要的任务等着你去完成，但从个人成长的角度来说，这个特殊的节点是值得纪念的，而纪念它的最好方式，莫过于写下这样一篇文章了。

我知道字节、飞书、产品经理，都是互联网圈子里的流量词汇，在许多自媒体或是职场社交平台，都能看到与之相关的内容。但这篇文章并不会将过多的笔墨放在字节、飞书、职场、大厂的话题，我会更关注我在这一年的真实收获，那就是在做低代码产品这件事上的收获。

为什么呢？

在字节跳动这样一个超大型组织内，每天都会有很多事情剥夺你的精力，平台的光环也好、盛传的裁员危机也罢，这些消息就像精神鸦片，吸食起来很爽，却几乎没有益处。

相反的，你正在做的事情，事情背后体现的能力，能力背后蕴含的基本功，反而是每天忙碌的会议背后，更容易被忽略的东西。对个人来说，这些东西才是我们在平台之外所独有的，真正属于我们自己的东西，说白了：

这是可以带走的东西。

一、关于产品

我在飞书做的是低代码产品，虽然这个领域在大类上属于 to B 产品，但同已经比较成熟的企业内部工具或 SaaS 产品来说，低代码在国内还是比较新的领域。

这个「新」体现在：

1、不同公司对低代码的理解和策略可能都不一样，没有一个成熟而公认的从 0 到 1 的演进模式，产品的形态基本都跟公司对低代码的定位有关；

2、少有成熟的方法论可借鉴，只能从现有的产品去倒推底层的产品设计理念；

3、圈子很小，5 年以上的低代码产品经理很少很少，招聘候选人很多是 B 端其他业务领域的产品，或者是国外 PaaS 平台的产品（如 Salesforce）

这些也导致我们在做这款产品的时候，也面临了很多的不确定性。

在这种不确定下，必然会导致讨论→结论→推翻→讨论的无限循环，这对于一线产品经理来说某种程度上是一种消耗和伤害。

但另一方面，也正是在这样的无限讨论中，我们才能对自己所做的事情有更多理解，更深刻地认识到它的价值和做事情的正确方法。

在这一年的时间里，我从完全不了解低代码，到开始能用低代码平台搭建应用，再到逐渐了解每个平台背后设计的理念，这其中最深的感触只有一条，我姑且把它叫做：用户分层。

二、用户分层

凡是做产品经理的，一定会对一个问题非常敏感：我们的用户是谁。而对低代码产品经理来说，这个问题又显得稍微抽象一些。

广义上，低代码的用户是开发者，但开发者是谁，他们和企业的关系是怎么样的，低代码又如何为他们提供了不可替代的价值，这些都是我们在做这款产品时，需要去思考的问题。

经过一年的探索，我发现去研究开发者这个群体时，也需要用到用户分层理论。

我最早接触到用户分层，是在美团做会员产品经理的时候，无论是 VIP 体系，还是等级体系，本质上都是按某种标准对用户做分层，目的是在不同的层次下，匹配不同的功能和资源，从而达到整体收益最大化。

开发者也同样需要并且可以分层。这个群体大致可以分为三个层次：

1、无代码开发者

典型画像是中小型公司内的业务人员，他们的诉求是希望通过一款好用的工具，快速搭建出一个业务系统。

这种业务系统一般是经典的四件套：数据表格、详情、表单和报表，例如最简易的图书借阅系统。包括所有图书的列表、单本图书的详情、借阅申请表单和借阅数据统计，再辅以简单的审批流程和权限控制，基本上就能搭建出一个最简单的图书借阅管理后台了。

大多数无代码开发者很少具备写代码的能力，因此提供给他们的产品需要足够好用，易用性需要足够强，才能被他们喜欢。

具体来说，在产品设计上，既需要保证一定的抽象性，功能不能太定制化，否则就偏离了 PaaS 的定位，同时也要屏蔽开发者无需感知的功能细节。

以按钮的样式配置为例，对无代码开发者来说一般需要的是封装好的快速的样式配置：蓝底白字无边框的按钮，一般用在强提示场景下，例如表单的提交；白底黑字有边框的按钮，一般用在弱提示场景下，例如页面的返回。

如果我们将按钮的 CSS 样式全部开放给无代码开发者，他们可能会觉得没有必要且非常难用，因为他们的业务系统对灵活性要求没有那么高。

但这样的限制在某种程度上也同时限制了业务系统本身的天花板。

2、混合开发者

典型画像是大型企业里的业务人员，他们一方面渴望一个好用的应用搭建系统，另一方面希望这个希望满足一定的灵活性，哪怕是通过写部分简单的代码实现。为此，也要求 他们懂得一些基础的编程知识。

对大型公司的复杂业务系统来说，完全无代码的搭建几乎很难满足自己的需求，而对公司内的业务人员来说，完成比完美更加重要。

他们更看重的是能不能实现，其次再是体验好不好。对他们来说，如果能力上无法实现，即使产品再好用，价值也等于零。

对这部分开发者，在产品设计时需要尽可能避免黑盒逻辑，尽可能白盒化展示。更通俗一点来说，从易用性出发，需要做一些逻辑封装，但这种封装逻辑需要在产品上展示出来，最终目的是方便开发者可以自主修改。

还是以按钮的样式为例，在产品设计时既要考虑将通用的 B 端业务领域经验沉淀为快速的封装配置，同时这种封装逻辑的底层应该是原子化的。

例如，对强提示场景下的「蓝底白字无边框」按钮来说，这种封装应该体现为「背景 = 蓝色」、「文字 = 白色」、「边框宽度 = 0 px」等原子化配置。开发者在 90%以上的场景下不需要关心底层的逻辑，但是需要修改时，例如「公司内部的设计规范要求，强提示场景下的按钮必须用黄色」，可以快速进行修改。

与无代码开发者相比，给混合开发者提供的产品功能在天花板上是更高的，但因为暴露的产品细节也要多很多，因此在易用性的设计上挑战更大。

但有一个原则我认为是需要达成共识的，对这部分用户来说，他们往往并不喜欢黑盒逻辑，他们的诉求是：

我可以不用，但你不能不告诉我。

3、低代码开发者

典型画像是独立软件开发商（Independent Software Vendors）的 IT 人员，他们对平台的要求是提供最大程度的开放性。他们日常的工作是基于低代码平台提供的能力去做二次开发，对他们来说，大部分的应用搭建过程其实还是写代码的过程。

这类开发者往往基于低代码平台去构建复杂的业务系统，包括 CRM、ERP、HRS 等常见的 SaaS 产品，都有可能是 ISV 基于低代码平台开发完成的。

面向这类用户去做产品设计时，往往需要考虑更底层的通用性，有时候甚至是代码级别的通用性。举几个例子：

平台自带的数据模型模块和外部数据源，能否作为一个统一的数据查询端口供前端页面调用，这种情况一般发生在系统迁移中。复杂的业务系统迁移很多时候是页面先行，数据基座不变。

如果客户公司有一套独立的组件设计规范，那这套规范在接入低代码平台的同时，能否复用平台已有的组件能力，包括属性、样式、事件、动作、方法等能力。

这些复杂的场景都需要产品经理在设计某个模块的时候，前置地去考虑更多开放能力的接入，而这对低代码产品经理的考验是巨大的。

甚至，可能只有产品架构师才能完成面向低代码开发者的产品设计。

如上可得，即使我们的用户都叫做开发者，但这个群体的角色、身份、所在公司不同，对平台的诉求是不一样的，没有一套统一的标准可以描述低代码产品应该怎么做，原因大概就在这里。

三、关于方案设计

做低代码产品，对需求文档的要求非常高。

复杂的需求文档，一般会有两个阶段：1、需求概要；2、需求方案描述。

在需求概要中，产品经理需要描述清楚问题的背景和价值、竞品调研、核心方案。

背景和价值说明了为什么要做这个需求，为什么要在现阶段做这个需求。低代码产品的技术复杂度很高，因此说清楚需求的价值无论对于资源的分配，还是后期的跨团队协作，都是十分重要的事情。

在这一年的时间里，我也经历过着急忙慌地把需求方案赶出来，最后因为没有对齐价值，导致在评审会上被质疑，最后使得需求被降级或取消，这样的事情对产品经理来说是非常致命的资源浪费。

在价值证明阶段，最容易出现的矛盾是产品自身的规划与用户反馈之间的冲突。例如在很早期的阶段，低代码产品大多都很难用且天花板也比较低，共创客户可能会有非常多的负向反馈。那这时候，到底是先提升能力还是先提升体验，就非常考验产品 leader 的判断能力。

很多人会说，就不能「既要也要」么。

如果资源充足，当前可以。

但经济社会的常态就是「资源永远稀缺」，否则就没有成本的概念。当一个选择一定伴随着成本时，优先级的抉择就成了产品经理每天要面对的最大矛盾。

当价值确定了，该怎么做就成了第二个问题。

中国的低代码市场整理来说起步较晚，2008 年，Saleforce 的 PaaS 平台已经承载了上万个应用时，国内的 PaaS 平台可能还在襁褓阶段。

对于后来者来说，追击领先者的有力武器便是借鉴，你也可以理解为「抄」。我觉得抄并不是一件丢人的事情，当我们对一个新事物的认知真的很有限时，与其用并不科学的旧法则来套用，不如用现成的新法则来尝试。

但这个过程中对产品经理最大的挑战不是搞清楚别人是怎么做这个功能的，而是搞清楚别人是怎么解决这个问题的，以及为什么是这样的解决方式。

围绕问题而不是围绕功能，这是低代码产品做竞品调研的核心。

当然，正如用户分层里说到，不同的产品针对的目标用户是不同的，因此他们设计的理念也是不一样的。

做竞品调研时，找到值得研究的竞品比调研本身可能更重要。只有你的产品和研究对象在目标用户分层中基本保持一致，这样的调研才更有参考价值。

最后就是核心方案，这部分的首要原则是解决核心问题的逻辑需要自洽。写核心方案其实并不需要太多的笔墨，但难点在于推导过程是否逻辑自洽，是否是跑得通的。

在这一年的前半程，我的概要方案很多时候总会在若干个特定的点上没有跑通，比如权限问题没有考虑，跟其他系统的协作没有考虑，跟正在开发的其他需求之间的冲突没有考虑等。

因此要做到逻辑自洽，无其他更好的方式，只能不断使用自己的产品，对产品的所有模块都非常了解。这样在一个复杂需求里，你才能在一开始就知道涉及到的重点有哪些。

只要在一开始没有硬伤，后续的细节都是可以慢慢打磨的。

如果概要没有问题，那更具体的方案设计就基本没有问题，只是依据不同产品经理的水平不同，有的人可能写得很细致，这样开发过程中的沟通会更高效，有的人可能写得比较粗略，那过程中的沟通就会更频繁。

四、关于项目管理

虽然团队里有 PMO 这个角色，但是很多时候需求的项目管理角色都会由产品经理担当，在复杂的需求里，项目管理能力有时候可能比产品设计能力更为重要，因为它确保了交付成果。

对于产品经理工作的考察，大家都有一个共识，只有真正上线的需求，才算是一个产品经理的成绩，在此之前的所有内容，都只能算是过程。

没有一个产品经理在写简历的时候会说，我上一段工作经历中共写了多少篇需求文档，一共包含多少个字。大家在聊的都是，上线的需求对实际业务到底带来了多少价值。

关于项目管理的标准流程，就不必多说了，在这里想分享一些推进大型复杂需求时，在标准流程之外的发力点。

1、前置沟通

虽然从流程上来说，需求在设计完后就是评审，但为了评审顺利，是需要做很多工作的。尤其是对低代码产品来说，由于这是个新事物，且团队里的很多人可能之前就不是做低代码相关的领域，因此在认识上对齐就显得更为重要。

沟通的内容与概要中的内容基本一致，也都是做这件事的价值和大致思路。

有沟通就有分歧，面对分歧时，需要产品经理提供足够的参考信息，主要是竞品的参考信息和用户的反馈，在因为主观认识不同而导致的分歧中，这样的客观信息反而能在求同存异时发挥更大的用处。

2、showcase

对复杂需求来说，最大的成本可能就是返工成本。为了避免返工，在流程中可以增加一环叫 showcase，即面向研发、产品、设计展示冒烟用例，在提测之前将已有的问题尽可能暴露，这样在研发阶段中可以增加一个质量监督节点，确保最终交付的需求是符合业务预期的。

3、需求范围管理

复杂需求往往牵一发而动全身，虽然 B 端产品不能像 C 端产品那样快速交付持续迭代，但对于低代码这个新领域来说，如果产品还在商业化之前的基建阶段，我的建议是找到共创客户，快速敏捷地交付独立模块。

对于低代码平台来说，只有真正能搭建出实际的应用，并经受住真实用户的考验，它才算是一个合格的低代码平台，而平台背后的产品经理，也才算是真正的低代码产品经理。

因此，明确管理每个需求的范围，在指定时间内交付指定的功能给到用户，接收真实业务场景的考验，并拿到真实的反馈，可能才是低代码平台向前迭代的最踏实的道路。

五、关于低代码业务

最后，聊聊我个人对低代码业务的理解。

很早之前，我在读吴军的《浪潮之巅》时看到过这么一个观点，如果某种技术对生产力的提升是 10 倍以上，那这个技术的诞生很有可能会颠覆某个领域。

例如从马车到汽车的进化，从汽车到飞机的进化，每一个新物种的出现，都带来了产业革命性的变化。

低代码是这样一个新物种么？很遗憾，我认为并不是。

至少在目前来看，低代码对于生产力的影响，并不足以达到 10 倍以上。目前天花板级别的低代码产品，也只能实现说「所有通过写代码而生产的应用，都可以通过拖拉拽+简单的代码实现」，况且能实现这个目标的产品，屈指可数。

既然不是新物种，无法出现突变式的演进，那就必然要遵循 B 端产品已有的客观规律，渐进式演进。

在团队内部的全员大会上，我向「飞书应用引擎」的负责人提过一个问题：如果说有一条原则需要所有的低代码产品、研发、设计、业务人员都去遵循，那这个原则是什么？

答案依旧是：客户第一。

与 SaaS 产品不一样的是，低代码产品的客户并不会来自一个特定的行业，甚至并不是应用使用方本身，那这时候，客户第一的原则背后就有一个更大的命题：谁是我们的客户。

这个命题在商业化之前就变得尤为关键，到底是根据现阶段种子用户的反馈去迭代，打造满足他们的产品，还是根据我们对产品的定位找到更适合的客户，我相信没有绝对正确的答案，但这个问题需要每个低代码产品经理反复去思考。

做产品久了，会发生很多时候并不是没有解决办法，而是解决办法太多的时候，选择哪一条路去进行下去，就显得尤为重要了。

六、结语

很早的时候，我问过 flomo 创始人少楠一个问题：

背景：

我们现在做的工具处于早期，面临很多上手门槛问题，但体验优化不能带来工具天花板的提升，我们想要做的进阶和复杂功能，在竞品中都有，但是否要投入资源去做，团队希望产品经理可以给要做的新功能想场景搏资源。我很怕陷入自嗨的诅咒里，最后做出了一个大家并不会用的功能。

问题是这样的：

1、如果做工具产品时，目标是提升工具的天花板，那产品经理是否需要为想要做的功能去想象场景。这些场景是目前的业务方没有提出来的，但产品经理也不知道用这个工具的业务在什么时候会遇到这样的场景。

2、进一步地，如果从逻辑 （或者从竞品分析）中判断这个新功能是合理的，但它基于这个新功能的场景在上线很长的一段时间内（比如半年）都没有出现在实际业务中，那这个新功能是不是一个伪需求。

少楠的回答简单而坚定：

别看竞品，给 50 个用户打电话聊聊，逻辑没用。