时间: 2021-08-03 08:28:32 人气: 3 评论: 0
编辑导语：2021年6月5-6日，人人都是产品经理举办的【2021年中国B端产品经理大**（上海站）】完美落幕。轻流CEO薄智元带来《无代码产品轻流的商业化之路》为题的分享，本文为演讲内容实录。
以前我从事To C领域。大概于2013、2014年，我负责独立音乐项目，后来转战至SAP，这也是我第一次接触到To B领域。后来我慢慢做出了“轻流”产品，今天所分享的就是轻流的商业化之路。
主要有这些方面：
无代码、低代码的概念最早于2014年由Forrester提出。因为在2014年以前，最早的一批无代码、低代码厂商已经开始有所行动；低代码最早的原型已经出现——在项目交付时，许多交付厂商**使用模块化的方式提升交付效率、降低交付成本；所以，低代码的概念其实大家并不陌生。
后来，无代码的概念逐渐出现。区别于低代码，无代码面向的人群不同。前者的使用人员仍需要写一定代码，用低代码工具提升交付效率；而后者真正地覆盖了不**写代码的人、即公民开发者，使得这些人可以更好地利用工具解决业务问题。
那么，为什么无代码和低代码这么火爆？Gartner也作出如下论断：
在未来三年内，低代码将推动几乎三分之二的应用程序开发。到2024年，65%的应用程序将使用低代码模式构建。
这背后代表着市场规模的问题。
目前在中国，SaaS的市场规模大致在200亿左右。但若说及传统的信息化市场或者传统的外包市场，其市场规模可达数千亿。如果说三分之二或者65%的外包市场将被低代码或无代码替代，则未来必然是一个千亿的市场规模。
正因为有相对较大的市场存在，现在许多SaaS产品开始推广自身低代码的控件或模块，很多传统软件厂商也开始转型做低代码产品，这也是低代码、无代码火热的原因。
但是火热的背后，存在着很大难题，可以总结为打磨无代码产品的三个难点（这三类产品在To B领域中也相对难打磨）。
在国内，人们对工具的付费意愿相对较低，因此在中国，SaaS应当有不同的商业模式和收费模式。比如现在的商业化SaaS、交易型SaaS，本质上并不依靠工具本身赚钱，而是通过其他方式收费。
举一个例子。
在做音乐领域时，我研究的是版权付费模块。2013年左右，那时大家可以在百度免费下载音乐。其他平台亦同，采取侵删原则。与之相比，国外音乐行业实行版权付费，比如在美国，采用的是iTunes单曲下载的模式，欧洲则选择包月模式。而当下中国所采取的模式，既非包月、也非单曲下载，而可能是利用粉丝经济来推动版权付费。
同时，许多音乐版权被掌握在与大厂相关的音乐平台手中，这也演变成了一个可能的流量入口，或者实现粘性绑定的一个方式。
由此看来，未来的工具型SaaS在一定程度上并不单纯依靠工具本身进行收费。
通用性的产品打磨十分难，因为各行各业有其相应需求。
之前在人人都是产品经理的**场上，也有嘉宾做了相应分享。他提及，创业公司可能需要花费大几千万、甚至上亿资金才可以将平台级产品打磨清楚。
那么，面对这些难题，为什么我们还愿意去耕耘这个领域？
一方面，不管是无代码、低代码还是纯代码方式，在某种程度上，它们所解决的都是信息化或数字化的需求。但另一方面，其解决方式的产生路径及获取路径仍有一定差别。
打败柯达的不是乐凯胶卷，而是数码相机。数字化时代，所有行业都值得被重做一遍。
许多To B的产品经理现在所做的产品，在很大程度上是采用互联网的方式将以前没有被互联网化的行业进行了重新规划。而这过程可能带来效率的提升、额外的增量，或打破以前供应链的壁垒。
我们公司大致于2014年开始做无代码、低代码，于2015年正式成立。
而在2015年左右，我离开了SAP。离开SAP之后，我的目标是去解决企业端的某些问题，因为那时，个人觉得SaaS的普及率并不高。而当时，我们所想解决的问题可以归源于一个问题场景。
此前，SAP某个客户的工厂购买了大概一千多万SAP的产品，但是其质量管理部门的负责人仍然使用Excel进行业务管理。提及原因，他的回答是，因为他所能控制的只有纸和Excel。
其实业务人员在系统化面前，其态度是十分矛盾的。一方面，业务人员需要此系统，但另一方面，于他而言，系统化的过程又相对较慢，当他面临业务可能发生变化的情况下，最好用的还是纸和Excel。
所以当时我们团队最早的思考，就是如何给这些业务人员一个新的工具。那时，我们的工具型态还有点像在线的Excel，更大程度上它还是一个工具，其目的在于让业务人员可以进行数据采集，并解决数据流转问题。
在产生这样的思路及想法之后，首先最重要的，就是找到合适的市场定位，即天时地利人和。
所谓天时，即目前IT资源相对紧张的情况，在这时，我们需要更多的人或途径来满足数字化需求。
所谓地利，则需要提及BPM。
其实，很多客户或传统企业对BPM并没有清晰的认知。于是当我们传播“轻流是一个BPM的产品”时，出现了如下问题。
其一，BPM本身在企业的覆盖面不广，其应用场景有限。
其实BPM不单纯是一个系统或产品，其背后是一种管理思想，其支持就是PDCA，即不断地修改、调整、完善。
在无代码或低代码工具出现之前，业务人员需要通过二次开发来实现业务流程的变化、响应业务需求。而随着业务的快速迭代，一般而言，IT方支持很难赶上业务人员所要求的二次开发和业务变化进度。
而我们在一开始宣传BPM时，并没有将客户需求与自身产品进行匹配集中宣传，此时宣传方向就出现了错误。这也就谈及所谓的人和，即我们需要对目标人群进行差异化分析。以前的业务人员可能没有一个趁手的工具，也不知道BPM的概念。这时我们就可以提及无代码、这种不需要开发即可构建系统的方式。
市场空间，其标准就是fit。
当下，低代码、无代码仍然存在争议，不过我们应当清楚，没有任何一个产品、行业或市场是完美无缺的。低代码、无代码不能解决所有的问题，但也并非所有问题都不能解决。而市场规模的大小决定了产品的发展规模。我们需要关注的，是低代码、无代码的市场规模多大、是否值得创业公司去做、以及这是否是一个我们可以覆盖的市场？
同样，对于B端产品，我们也可以如上进行思考：这是不是一个我们能覆盖到的市场？
其次，我们还应思考，这个产品是行业垂直还是功能通用？
无代码产品有点像Excel这种工具型产品，可能是功能通用的。但是许多客户需要解决行业内的问题，他们所需的是垂类场景化的解决方案。因此，我们采取协同措施，既保证了行业通用化，又保证了一定程度上的行业垂直。
那么我们是如何做行业垂直的？
就像乐高，它有一些通用的积木模块，但是可解决的问题很多是偏行业化的，而小的模块则可能属于行业化内容。
再者，我们要考虑产品是项目化还是平台化。
许多创业公司可能都**遇到这样的问题：碍于资源、资金的不足，可能**向一些大项目低头。
但是这要根据发展阶段来进行判断。假如这个项目于你而言既能赚钱、又有助于打磨标准化产品，那么在合适的时间与条件下，可以接一些项目。而在当下，我们采取的手段**有所不同，即让外部团队来完成可定制化的、非标准模块下的需求。
最后，是否要接受OEM。举个例子。
我有个做激光切割软件的朋友，用了大概三到五年的时间做到行业里的绝对头部，基本上头部百分之八十左右的用户使用他们的产品，现在公司已经上市。
而就目前来看，他们并没有失去其品牌优势或核心竞争优势。因为即使品牌的logo没有他们的标注，但是底层支撑仍属于他们。与之相类似，我们也可以依照这个标准来获取用户关注：即在行业里是否可以拥有更高的市场占有率，是否可以给用户带去真正的价值。当形成集群效应时，虽然品牌的logo非轻流，但是产品的底层支撑却属于轻流。
这就是我们团队在面对市场空间时所做的决策。
那么，我们可以如何看待轻流的市场规模？
如上图，左边是对SaaS市场的一个划分。在国内，SaaS的市场规模达两百亿人民币。市场规模**十亿的，如ERP、CRM、HR或者财务等，可能只占头部的百分之二十的场景。
除去头部领域，其余很多为中长尾场景。比如划红线的位置，可能指的是某个场景化的需求，在这个场景化的需求中，可能只有一个亿的市场规模。这样的规模很难成为一家公司的安身立命之本，也很难创造一个正向循环。
而在无代码领域，我们对多种垂类场景做了聚合，从而找到属于我们的市场空间。这里引入一个新的概念——aPaaS，我们利用这些“底层的积木块”拼搭出许多行业与场景的解决方案，每一个场景化的需求对应的则是某一些SaaS需求。
未来，我们并不打算替代SaaS，反之，我们**为许多SaaS产品提供底座或补充。比如最近，我们与业内的一些SaaS合作，为它们提供技术支撑，并覆盖其可能用户的一些垂类需求。
如何站在客户或用户的角度思考问题？我们的结论是，用户所需的并非单纯的工具，而是一定场景化的解决方案。此时，如轻流这类低代码、无代码产品，其竞争优势与竞争壁垒并不完全在于工具本身，也不完全在于模块——模块所代表的只是时间复杂度的问题。
总结一下：
实现差异化竞争，一个重要部分就是找到市场切口。那么针对公司内部，我们如何切到客户身上？
可以先找一个小场景，比如业务部门。举个例子。
一个500强客户按照正常选型并不**选择轻流，但是因为其中一个部门——质量管理部门产生了解决场景化需求的需要，因此公司的销售同学去到工厂，利用无代码直接为实际业务人员上线技术。当产品被单一部门采纳并投入使用后，其他部门也有所目睹，因此，这个工厂实现了整体采购。
因此，产品在面对市场时，可以采取小场景切入的方式，先控制可控部分，再不断地深入切入。
像轻流这样的产品，因为其实际需求较为分散，所以其产品化过程难度较大，合格的收敛便十分重要。
举个例子。
轻流的需求池可能有两千多个需求，每个月处理小一百个，最终新进的大概为三十多个。因此，虽然需求池还具有存量的大小，但是产品是可收敛的，即可产品化的。而功能的无穷尽可能导致产品很难收敛，当产品越来越复杂时，客户也越来越难以使用。
为了做到产品收敛，我们**用百分之十的功能复杂度去覆盖百分之九十的需求，额外百分之十的差异化需求则可以通过开放平台、插件或其他方式，实现功能定制。通过这样的形式，可以让产品实现一个较好的边际设定。
在19年时，我曾经陷入纠结的境地：
而笛卡尔对于世界的划分标准给予了我启示。
将笛卡尔的哲学投射至轻流的商业化，可以归为三个要素：
如图所示，红色区域表示人使用工具去落地方法。那么可以如何扩大红色区域？
但是这些做法似乎都不太现实，于是我们采取了如下方法。
因为人在移动趋势上**改变认知，此时假设人不动，让工具不断地趋近于人。而这关键之处在于是否针对目标人群打造了可使用的合适工具。在工具层面，考虑到人的接受程度与理解成本，工具面积的大小合适即可。
方法层面应当采取扩张，通过方法论的积累等方式扩张面积，进而覆盖人使用工具的面积。
以上就是轻流在商业化过程中面对人、工具、方法落地问题的处理方式，给予大家参考。
第四，即让客户成为产品的创造者。如轻流这类产品，其优势在于客户可以跟随实际需求打磨其所需要的产品。如做陶艺时，我们可能**跟家人、朋友等一起进行创作，即使做出来的东西十分丑陋，但由于情感参与其中，作品的价值就**不断提升。
做产品也一样，尤其是To B产品，目标群体在产品里的参与度很大程度上决定了用户与产品之间的黏性。
有一个说法，即每天吐槽你的产品、每天给产品提建议及功能需求的人士往往是使用产品最好的一批人，因为此类用户与产品产生了相对大的黏性，此时我们应当抓住这部分用户群体，并了解其需求是什么。如以下三个客户，他们其中有的属于传统行业，有的属于互联网公司，都是让技术同学头疼的客户。
“第一次使用轻流开发系统，我感觉我的手终于跟上我的大脑了。以往正常开发一个系统，可能要三个月的时间，而且可能三个月还不能产出一个很好的产品。但是用轻流，在三天之内就可以开发出一个完整的系统，而且可以快速迭代。”
“我觉得轻流像一个SAP和钉钉的结合体。SAP的强大能在轻流里边体现出来，钉钉的便捷性也能够在轻流里面展现出来。”
“轻流的自由度很高。不管是前端做数据输入时方式上的自由，包括后面数据匹配之后数据处理上的自由，在设计轻流的流程时，你也在帮管理者整理自己公司的业务流。这个思维逻辑加上IT方式的实现，是现在每一个小型企业或者初创企业都需要思考的问题。”
综上，大家可以从两方面来看待这件事情。
无代码产品和B端产品经理有什么关系？
前段时间我加入了一个B端产品经理的社群，做了一些采访后，得出了以下难题。
1）用户对B端产品包容度差
首先，用户对B端产品的包容度差。为什么？因为很多情况下，用户是由老板或上级“逼迫”使用B端产品的。
这要求B端产品经理要有提高能力，并体现真正的价值。
2）面对角色复杂，需求各异
第二，我们面对的角色是复杂多样的，可能是老板，也可能是使用者、技术人员或业务人员。
此时，我们需要将功能拆分，将面向管理者的功能与面向使用者的功能进行剥离。
3）B端产品落地，改变原有工作习惯
第三，产品的落地很可能**改变原有的工作习惯，导致推进难度增大。此时轻流如何解决？
我们的解决方法是，做好线上或线下的workshop，做好培训及课程性的赋能。毕竟在B端产品中，培训是十分重要的，你需要教**客户如何使用产品。以轻流产品为例，当客户使用轻流的产品时，作为厂商的我们应当协助客户、助其推广轻流的产品至其公司内部，因为客户也需要说服他的团队伙伴去使用产品，这其中少不了我们的协助。
4）B端产品用户需求的个性化程度高
第四，B端产品用户需求的个性化程度高。一方面，当下企业业务存在差异化，因此，企业对于B端产品的需求也存在差异化。此时，我们可以在产品打磨过程中注入低代码的产品思维，比如增加配置项、增加可以配置的模块。
但记住，我们应当把握好程度，于客户而言，配置项若设置太多，则**形成挑战；配置项若设置太少，则**降低自由度。
5）用户基数小，难以获得规模化反馈
第五，因为用户基数小，所以我们难以获得规模化的反馈。
就To C产品而言，To C产品上线时可以吸引大量用户，此时我们可以做ABtest。这就区别于To B产品，一方面，To B产品资源较少，难以实现ABtest；另一方面，To B产品的业务使用场景不同，用户数量少；若将用户当成小白鼠，可能第二天你就**接到投诉电话。
因此，这时我们应当更深入地走向客户，去倾听客户真正的声音。
在轻流内部，我们设有用户研究部门，负责研究客户、竞争对手及行业。但是我总**跟产品经理说，不能让用研部门成为他们的“眼睛”，用研部门只能协助赋能，产品经理应当“独具慧眼”。
6）产品功能增加易，删减难
第六，产品功能增加容易、删减难。
To B产品增加功能时需要考量多方因素，且不同于To C产品，前者撤除功能时**遇到极大阻力。
在这种情况下，轻流选择进行更深度的调研。比如A、B、C公司各有其需求，而我们经过分析，发现D需求可以满足三者差异化的需求，此时，我们就**采取D方式。
1）快速响应需求
在做B端产品时，产品经理可以试试看，无代码产品是否可以帮助你们做一些快速的需求响应。
2）快速实现需求变更
搭建容易，修改亦容易。
3）解放IT生产力
一方面，IT、研发人员业务需求繁重；另一方面，业务人员也承担着一定业绩。那么，当面对数字化需求时，作为IT人员及业务人员之间纽带的产品经理可以尝试运用工具、做好PMF的验证，从而减少双方业务需求的不满足现状，缓解IT资源紧张的矛盾。
最后进行简单总结。
最后再问一个问题：无代码出现后，IT**被替代吗？
随着IT需求的不断拉抻，具备专业技能的人**做更专业的事情，技术难度将随着技术公民化运动的进程而下沉。更多的人将随着技术门槛、技术难度的下降掌握更多基础能力，而专业人才可以去做相对更专业的事情。
化危为机，精彩才刚刚开始——2021中国B端产品经理大**·上海站现场报道
2021年全年产品经理大**、运营增长大**售票启动，北、上、广、深、杭五城巡回，最后六场！与**、阿里等大厂的实战专家一起，分享实战案例，探索行业趋势，深挖产品底层逻辑，提升个人能力！
扫描下方二维码进入大**专属咨询群~
本文为【2021年中国B端产品经理大**（上海站）】现场分享整理内容，由人人都是产品经理运营 @Aine 整理发布。未经许可，禁止转载，谢谢合作
题图来自大**现场
