技术人如何提升产品能力

东少

个人介绍
之前负责了开源项目YApi和数据应用低代码搭建等工具，本篇文章就是基于做过的工具的经验总结，期望能对大家有帮助。

是否有必要提升产品能力

产品设计本身是产品经理本职工作，作为技术人员有必要提升产品能力吗？回答这个问题前我们先看下遇到一些问题：
1.很多同学在做业务产品时，仅仅关注怎么把功能按照产品经理要求做出来，不了解业务，不知道用户痛点，难以做出准确的技术判断和长期技术建设；
2.  团队内部有大量工具部分能力是面向研发同学使用，比如Sql编辑器、API调试工具和lowcode配置等，这部分工具传统pm对研发同学诉求不是非常了解，易用性很难做到极致；
3.  很多技术同学主导设计的研发工具用户体验是比较差的，经常被大家吐槽，不知道如何系统的提升用户体验和降低门槛；
4.  做的一些通用组件，框架sdk，易用性和专业性都比较差，难以推广出去；
为什么通用组件，框架sdk会被放到问题列表里。从广义上说只要是能被人们使用和消费，满足某些需求的东西都能被称为产品。不仅web业务系统是产品，还有像通用组件、框架sdk等因为涉及用户的使用和消费，本质上也算是一种产品。
提升产品能力带给我们好处：

1.  帮忙我们做好技术工具。比如很多技术工具适合技术同学去主导，传统产品经理不太了解研发诉求。
2.  有利于我们深入业务，关注用户痛点，思考如何用技术更好的解决用户痛点，辅助 pm 把产品打磨的更好。



3.  有利于职业发展。从能力模型看，有非常多的部分，与研发的能力模型其实是共通的。越往上层，两者的共通能力部分其实越多。有很多公司的 CEO，都是技术 & 产品双修的例子，比如雷军、张小龙、乔布斯、比尔盖茨早期都是做技术的。
总之提升产品能力，有利于我们做各类工具，有利于深入业务和产品经理共同打磨好产品，有利于我们职业的发展。
深入理解产品的本质

前面提到了产品从广义上说，只要能被使用消费东西都能被称为产品，本篇文章主要讨论两类产品，分别是web应用和技术SDK。
web应用 输入：时间、区域等参数；输出：图表分析结果；



技术 SDK
输入: 1,2；输出：3



从上图例子我们可以看出，web应用和技术SDK，都存在稳定的输入输出，看起来他们是一类东西，之间的差异就是 web产品有图形界面了，所以可抽象如下公式：
Product=f(x1,x2, …)
程序功能有图形化界面带来的影响

1.   降低了门槛能够面向更多人使用。比如 function sum(a, b){} 这个函数，如果没有做图形化之前，那么只有程序员这个群体能够使用。做了图形化界面后，只要会使用计算机的人就会使用；
2.  不仅需要考虑功能实现。在之前因为面向使用人群少，主要考虑 function sum(a, b){} 函数功能实现，但在使用人群扩大后，就需要考虑对于小白用户，如何做功能结构的设计、交互的设计，才能让他们用起来门槛低。那这个时候，不仅考验如何把能力做好了，还考验是否对用户有更深的理解，让他们爱上你设计的产品；
有意思的实验

基于上面的公式，我们带着技术思维做一些参数改动的实验，能够发现有意思的事情。
1. 减少输入参数
减少输入参数能快速降低使用门槛，100个输入参数的应用复杂度绝对要远远高于仅有一个输入参数的应用。抖音APP用户规模很大的重要原因是减少输入参数，用户只需滑动下屏幕，就能看到喜欢的小视频，门槛极低，老少皆爱，容易形成大的规模。
2. 给参数增加默认值，参数联动等能力
这个在业务表单非常常见，有大量的默认值和复杂联动需求，复杂联动和默认行为本质就是为了降低门槛和提高录入效率。比如一个常见的数据分析报表，默认已经选择了昨天和城市是北京的数据，用户无需操作就能看到数据，降低了操作的成本。还有选择城市北京后，行政区立马变成朝阳区、海淀等列表，极大提升了录入效率；
3. 增加参数
增加参数本质是给产品加功能，随着参数越来越多，产品学习成本会越来越高。比如我们团队门户网站搭建，为了支持各个业务方需求，增加了非常多小众功能。做了用户调研发现，这部分功能大部分用户无法理解，没有使用过。学习成本提升，意味着不利于用户规模增加。另外功能越来越多后，会导致产品研发成本变得越来越高，不能集中精力做最重要能力，大量时间耗费在一些不太重要事情了。所以通用化工具要克制加功能，加功能不一定是好事。
web应用和框架sdk差异

1. 面向用户不同
web应用大部分面向c端、b端商家和内部业务人员，只有深入了解这些人员诉求，痛点，才能做出比较好的产品。所以技术同学比较难以做好这类的产品，因为不了解用户。当然这个不一定，比如张小龙曾经也是技术人员，如果要做的这个功能你很熟悉，那理论上是有可能做好。
还有一部分工具类的web应用，理论上研发同学是可以设计好的，因为研发同学对研发同学诉求认知上是比较深入的，但这只是理论上，因为要做好产品涉及的点特别多。
2.  大系统和小系统
web应用是业务的完整的解决方案，相对而言整个系统链条长，功能复杂，对系统化思维、用户理解要求高，可以归类为大系统。
工具库是整体解决方案一部分，可以说是整个web应用内部独立一个子系统，相比web应用，框架sdk面向专业开发者，这部分用户学习能力强，对用户理解要求没那么高，但对抽象能力要求特别高，能通过比较好的抽象建模能力彻底解决某个细小领域的诉求，比如 React 框架能够解决几乎所有的网页应用开发。
技术人在产品能力上优劣势分析

优势是什么

1.  抽象建模能力，因为技术人经常做的思维训练就是抽象，逼迫我们不断去提升这方面能力，很多厉害的框架负责人产品能力也很强，比如Vue作者；
2.  对技术同学诉求认知更为深刻，比如一些技术工具的建设；
劣势是什么

1.  长期处于研发的工作环境，对一线业务人员需求不了解，对用户不够了解，那很难做出好用的产品；
2.  偏技术思维，功能能用就行，对用户是否能用明白和后续的运营考虑比较少，经常出现技术同学做出的产品只有自己能用明白的情况；
如何提升产品能力

思维上转变





从单一维度的技术解决方案思考方式往更加系统的思考方式转变。除了技术外，围绕着整个产品研发的生命周期，我们要深度思考产品战略，产品架构、交互设计和运营。万物皆系统，能学习和分析系统运行的本质，并将其梳理归纳出来。
产品战略本质上需要回答这个产品定位是什么？目前的市场规模怎么样？未来产品规模能做到什么程度？我们需要从逻辑上判断最终产品的发展能否符合我们的预期，比如之前做 YApi 时判断这个领域规模比较大，每个公司都需要，有不错的规模效应，所以团队才立项。产品战略制定好坏取决于对行业的理解，对用户的理解。俗话说，知己知彼百战百胜。提升这方面能力涉及对整个行业、用户调研研究了，关键是多实践和思考总结。听别人说的永远不如自己实际去该领域工作体验，只有在长时间实践过程中，才能了解最为真实的情况。之前认识一个前端同学，为了能在数据开发工具方向做的更好，亲自参与了数据开发工作好几个月，最终对于整个研发痛点有了更深入的认知，帮助他把工具设计的更好。
产品设计首先是做需求收集，然后基于产品目标抽象出用户的核心链路路径，围绕核心链路做产品功能设计。对于 web 产品，除了我们需要做核心诉求的功能设计外，我们还需要考虑在大规模团队使用时协作问题。比如 YApi 在做产品设计时，除了解决核心的文档定义、接口测试、数据Mock外，我们还思考到存在大企业怎么管理的问题，对标 gitlab，tower 等saas 工具，做了团队、项目、权限设计。
产品运营上是我们技术同学普遍做的比较差的点，很多同学只关注实现功能，不关注实际落地和推广，不关注用户是否能用明白。产品运营是非常关键的点，我们需要根据运营反馈去调整产品发展策略。
一些提升的关键点

产品设计涉及的概念非常多，上面的解答相对比较从整体视角看，所以下面从一些关键的小点出发，分享一些经验。
如何降低门槛

减少参数。 基于 Product= f(x1, x2) ****减少参数前文分析过了，能够有效降低门槛，但是难点是如何降低参数数量。最为有效办法是做更好的抽象，能设计一个能力解决某一类问题，另外还有一个比较有效的办法是我们把核心功能放到突出的地方，大量非核心功能放到高级配置等功能里，这样对于大部分用户，直接接触的功能就会少很多。
增加默认值、联动和帮助文档。 这个前面分析过了，很多PM在这块都快玩出花了，比如帮助文档做的非常智能，帮助文档不只是看文档，还能点击文档进行功能上的指导操作 。
培养用户的习惯。如果有一个APP你想推广让全国所有人使用，难度是非常大的。很多功能对于年龄稍大的人使用问题特别多，所以需要通过一些策略培养用户，手段包括花钱培养和提供文档视频培养，面向 toC 更多是靠花钱，比如有各种新人的活动，大礼包，推荐费等。对于公司内部的，更多是靠主动通过文档、视频培训等手段。
架构分层和模块解耦，利用用户已有认知，降低认知成本。我们在代码中实现一个非常复杂函数时，经常采用一个办法是做功能解耦和架构分层，这样独立的每个模块逻辑是清晰的，易懂的。在产品设计上，我们也可以采用类似的办法，比如YApi在设计时，整体架构拆分为【团队/项目/API配置】三层，其中团队和项目对标业内一些做的比较好的工具设计，整体上对于用户来说学习成本很低，主要需要学习 API 配置这一层。
降低操作链路。 链路越多，意味着用户需要按照步骤一步一步操作，中间任何一个环节出问题，都会导致达不到用户的预期，所以这里存在木桶效应，我们需要思考如何降低。比如我们使用 redux ，链路特别长，后面像 rematch, dva 等框架减少了链路，赢得了大量同学的喜欢。
系统思维很重要。能针对各个链路进行分析，尽量减少木桶效应带来的问题，比如做开源，我们不仅要把能力做强，使用上做的简单易用，同时还要考虑到部署的易用性和低成本。
代入到用户角色。 把自己想象成小白用户或者找没有用过该能力用户，想下或观察下用户是否能够用明白。最厉害的产品就是产品功能没有文档，用户也能用明白；
如何衡量低门槛呢？厉害的产品能做到核心功能无需任何人教，用户能自己摸索学会。差一点产品用户需要看通过文档学习才能学会。最差的产品是用户看文档、看视频很难学会。目前我们团队做的数据应用低代码搭建工具处于最差的这个序列，看视频和文档都难以学会 ，大量功能需要手把手的教，但这个工具价值还是很大，因为我们工具做了很多创新搞定了一个垂直领域的搭建，有足够的竞争力，并且我们找到了低门槛标品的路线，后面会重新对我们部分功能做设计。
如何做功能抽象，提升通用性？

做功能抽象可能是整个产品设计里面最难的点。回想下做技术架构设计，会发现代码里面核心架构抽象、核心模块抽象也是比较难的。很多优秀的框架、库都是非常厉害的同学做出来的，这部分同学无一例外都是专业能力很强，抽象建模能力很强的同学。从本质上看，所谓的抽象就是能够分析事物的表面现象提炼出来运行的基本规律。一方面要求你对该场景认知非常深刻，另一方面能通过一定的抽象建模把规律提炼出来。提升办法无外乎两点，第一多学习别人的思路，如果想提升框架sdk产品能力，能多看人家的架构设计；如果是web产品，多了解行业工具如何抽象的；第二是多思考，从本质出发思考用户的诉求和痛点，从万事万物的运动中找到基本的规律进行抽象归纳。
举个例子，多个组件联动如何抽象呢？
最浅的抽象是case by case解决，基本不具有通用型，或者只有很少的场景能够做到共用。
深一层解法是认识到联动本质是从 event 到 组件行为改变，然后抽象了一套组件事件配置能力，可以控制别的组件行为。本质上这类抽象是命令式编程，类似于jq时代直接操作dom，目前我们调研很多低代码工具，都用的类似解决方案。
那有没有更好抽象呢？从react vue框架发展看，声明式编程是发展趋势，那我们直接借用redux这套架构，抽象一套 event action 产品联动能力，触发事件后通过action修改store，store改变后会重新渲染绑定的 component。目前我们低代码工具已经完全做到了这一点，并且在业务中有比较好的应用。
如何提升扩展性？

随着日益增长的诉求，每个工具都需要思考如何通过合理的扩展能力，满足用户个性化的诉求。一个比较优秀的策略是插件机制。我们会发现这些年很多所有流行APP、工具都有类似的架构设计，比如微信小程序，figma 插件功能、koa 中间件等。插件机制能保证主产品聚焦核心功能，降低了主产品复杂度和维护成本。
如何做好插件机制呢？技术上插件机制并没有多么复杂，网上有大量讲插件机制实现方式。但为什么产品里面采用插件机制的比较少呢？这是因为插件机制对产品设计人员会有比较高的要求，需要和技术结合起来，另外只有大规模的用户量，插件机制意义比较大。对于web产品，插件机制的落地一般需要技术同学深度参与整体方案设计，这部分沟通协作成本和研发成本相对比较高，导致这一能力在实际很难落地执行。如果觉得插件式设计对工具未来发展很有帮助，那需要在产品早期和产品经理一起规划这方面能力建设。
比如团队内部门户搭建工具，目前使用的团队越来越多，很多业务方有自己的个性化诉求。我们接下来打算在架构层面支持插件能力，对于业务方特殊诉求通过安装插件的方式满足。
如何做创新，引领行业发展？

创新的本质是“找到万事万物内含的矛盾，再将矛盾转化为别的矛盾”。我们大部分的努力，其实都不算是创新。因为大多时候我们只是在原有的矛盾内打转，没有推动老矛盾转化成新矛盾。用大白话来说，创新就是换了一种新的思路解决问题。
好的创新的前提是对这个领域认知非常深刻和对现有解决有比较深入的了解。除了对产品能力创新外，也可以是使用和交互上的创新。比如在最开始，短视频app是用的快手那种模式，一个页面有好几个视频卡片，用户需要去选择。后来抖音创新了滑动查看方式，降低了使用门槛。
举个例子，在做 YApi 时需要设计一个数据结构编辑器，国内一些竞品在这方面都比较短视，采用的并不是 json-schema 协议。为了能和 swagger openapi 更好的融入，所以需要设计一个 json-schema 编辑器。
这是很早之前调研的一些国外 json-schema 设计器：
1. 基于图编排解决方案



2. 基于树形结构解决方案



我们的方案 demo地址 ：https://hellosean1025.github.io/json-schema-visual-editor/
上面调研产品方案最大问题的数据结构不够直观，易用性非常差。所以我们方案将数据结构和主要字段用树形表格展示出来，其他属性信息通过高级配置展示。最终这套方案除了在 YApi 使用外，很多商业化产品也采用了这套方案。





避免一些错误

思维固化导致对新事物认知出现错误



上大学时用htc window系统手机，因为从小学5年级到大学一直用的 window 系统，对window特别熟悉，所以当时觉得还挺好用的，一直到大学结束，当时也没有去尝试用苹果、安卓这类手机。但后面大家都知道，苹果和安卓统一了手机操作系统。类似的事情还很多，比如早期觉得qq好，很晚才用微信。思维固化有多种情况，一种是自己认知到有问题，但不愿意改变；还有一种是自己完全认知不到，比如上面提到两个例子，就是自己完全认识不到，除外有外力影响去改变。思维固化算是人类大脑为了降低功耗导致的一个缺陷，我们的大脑每天忙碌，功耗也很大。在原始社会，没有那么多时间去思考，稍微慢点可能被野兽吃掉了哈。所以为了提升效率和降低成本，大脑的设计其实很聪明，对于我们已经非常熟悉的领域，直接利用已有经验和直觉，否则精神内耗太严重了。那如何改变呢？一定要从心态上意识到每个人都会存在这样问题，对于问题多总结多研究，还有多和优秀的同学沟通交流学习。
产品调研浮于表面，不够深入
停留在简单使用，缺少深入的调研和使用，最终导致产品决策判断出现问题。事实上要完全把一个工具调研的很清楚是非常难的，我的建议第一要和这个工具比较资深的使用同学沟通，了解他们平时主要做什么和如何使用；第二点自己深入使用一段时间，比如用个几个月时间，完全把自己当成用户，解决工作的问题；第三了解这个工具主要面向群体是哪些，主要解决哪些问题，优势是什么。
设计的功能基本只有自己能用明白



这是我们做的一个主打面向研发用户的 lowocde 搭建工具其中的一个图表主题配置功能，由团队内部一个同学设计。整体设计是非常难以理解，为什么需要多个主题，为什么需要物料库id，主题配置到底写什么？这种设计学习门槛太高，发现问题后打算重新设计这部分能力。
小结

产品能力提升帮助大家对用户诉求理解更深，具备更好的抽象能力，有利于做业务和工具，同时在职业发展方面，产品能力提升有利于职业升职加薪。
产品能力提升关键是思维上转变，需要不断的思考，总结，学习，提升对整体系统理解力。另外对于开发者来说，找准突破方向也是非常关键的，比如我们团队负责门户搭建的同学因为这类工具部分能力主打面向技术同学使用，研发同学可以在一些专门给技术同学使用模块主导起来。例如数据结构配置、sql编辑器、页面编排、服务质量建设等主打面向研发同学使用功能，研发同学可以聚焦在该领域，和产品经理一起把能力打磨的越来越好。

刘术新

啊啊啊啊啊啊啊啊啊啊啊