跨境电商营销推广,宁波seo排名方案优化,老外做的中国方言网站,做网站需要多少钱 都包括什么简介#xff1a; 在支持蚂蚁几乎所有核心业务运行和发展的过程中#xff0c;我们在平台建设、业务支持、平台运营、AI创新以及AI整体运营等各个方面做了很多尝试#xff0c;有了不少的收获和感悟#xff0c;在此分享给大家。 过去几年#xff0c;我和团队一直在负责蚂蚁集… 简介 在支持蚂蚁几乎所有核心业务运行和发展的过程中我们在平台建设、业务支持、平台运营、AI创新以及AI整体运营等各个方面做了很多尝试有了不少的收获和感悟在此分享给大家。 过去几年我和团队一直在负责蚂蚁集团内部相关平台产品的设计和运营工作。
这些平台产品包括人工智能部的A/B测试平台、机器学习平台、金融知识图谱平台、NLP平台、智能文案平台、金融视觉(CV)平台、搜索平台、机器人平台、标注平台等以及风控团队的相关平台产品。这些平台产品在背后支持了蚂蚁几乎所有核心业务的运行和发展。
整个过程当中我们在平台建设、业务支持、平台运营、AI创新以及AI整体运营等各个方面做了很多尝试有了不少的收获和感悟。
最近我花了一些时间将其初步梳理出来写成了这篇文章。
文章的内容涵盖了“需求管理、平台设计、产品验证、平台协同、人性对抗、跨界思维、挑战/成长”等7个方面既有一些抽象的、方法层面的总结也有很多真实的、有体感的案例。
篇幅比较长约1.5万字。感兴趣的话可以收藏下后面慢慢看。
希望本文对你有所启发更期待能抛砖引玉跟大家做深入的探讨和交流。
一 、需求管理“角色错位”与“无我境界”
1 、挖掘需求警惕“角色错位”杜绝“闭门造车”。
做好产品的第一步就是把握好需求必须搞清楚每一个产品和功能的真正用户是谁。
对于C端产品这个问题比较好解决因为设计者和使用者往往是重合的。但对于技术平台类产品、B端产品这两者经常是错位的即设计者可能并不是真正的用户。
举个例子支付宝的产品经理在日常生活当中天天用支付宝付款、理财他就是个典型的支付宝用户所以设计者与使用者就是同一个人。而在技术平台、B端产品当中产品的设计者可以用自己的产品但基本上仅限于做测试、做验证真正的用户却是其他的人。
因此设计者对于产品需求的一些推理判断可能会与真实情况有差别即使他用了那个以测试为目的的使用和真实的使用还是有区别的。
由此可见正是由于技术平台类产品中这种角色的错位就容易导致需求把控出问题。
下面先从我们标注平台的一个小故事开始讲起。
去年12月的一天我们标注平台的相关同学开会进行产品设计评审。
其间针对一个标注页面的产品设计细节问题在坐的产品经理、UED、前端、后端各个岗位的同学各抒己见、争论得不可开交。
突然间我意识到一个严重的问题——那就是会议室的所有同学并不是这个feature的用户。
因为具体的标注工作都是外包公司的数百个标注人员做的他们才是标注页面的真正用户。
不是真正的用户、没有处在那个场景就很难了解真实的情况。于是大家就只能根据自己的经验和专业能力进行判断和推演。
做产品不能闭门造车。于是我们就随即安排相关同学去了标注外包公司做现场调研。
一开始我们与几个标注团队的小组长进行小范围的初步沟通。当时随口问了下产品使用情况他们一致反馈“没什么问题挺好用的”。
这样的回答很正常毕竟这么简单、直接的问法是很难获取到有价值的信息、了解到用户的需求。 在产品经理的行业我们经常说的一句话是在汽车被发明之前如果你直接问用户要什么他只能说“我要一匹更快的马”。 钉钉原负责人无招同学来蚂蚁做“钉钉创业之路”的分享时也谈到这个问题。 他的观点是见到用户不能只是“就事论事”只问产品使用相关的浅层次的问题。即使问这样的问题也不能问“你有什么需求”之类很难获得真实需求的直白的问题。 正确的方式是先把具体的产品抛下多了解客户的背景、业务、状态等整体的、背景的、来龙去脉的信息要表现出对客户“感兴趣”要想成为客户的朋友。 只有这样客户才愿意跟你多聊、深聊只有这样你才能捕获到有价值的信息。再加上观察客户的具体行为和操作就能捕捉到真实的需求才能做到有所洞察。 于是结束会议后我们要求上楼到标注员工的办公区具体看看情况。
当我们站在标注人员身后仔细观察他们的操作、与他们深入交谈后就有了新的发现。
很多原来没有想象到的使用方法和场景、产品设计的细节问题在标注人员的不断操作中就显现出来了。之前产品评审会上大家争论的问题自然就有了答案。
半天下来我们总共记录下数十个有价值的反馈和发现并在后续工作中一一做了处理和跟进。
可见如果你不是真正的用户你没有亲眼观察真正用户的操作很多问题你是无法预料到的。
大家IQ都不差遇到问题我们往往习惯于谈方法、讲逻辑经常在会议室里面唇枪舌战甚至拍桌子瞪眼睛最后谁也说服不了谁得不到有效的结论。
在这时不妨先问下自己“真正的用户是谁”再试试“笨办法”走出办公室走到客户那里去问问他们、跟他们聊聊天看看他们怎么用我们的产品。
那时候很多问题便豁然开朗了。
2 、满足需求不断“由浅入深”修炼“无我境界”。
接着让我们的思考再深入一些。
现在假设你已经明确了用户是谁、摸到了需求的大概脉络那也要考量“对需求理解是否深入”的问题即浅层需求和深层需求的问题。
换句话也是手段和目的的问题——“浅层需求”往往只是手段而“深层需求”才是目的。
举个例子对于我们负责的金融视觉平台有用户反馈“我需要模型报告”即模型训练出来后将一些“准确率、召回率、AUC之类”的指标用图表的方式展示出来。
如果你只是将这个需求做了那是不够的。
为什么呢因为用户要的模型报告只是“浅层需求”——他的确需要看各种指标但他最想要的是在新模型训练出来后他要对不同版本的模型效果进行对比——不仅要知道指标是多少更想知道指标的具体变化哪些升了、哪些降了以及具体数值是多少。
只有这样才算是满足了深层需求。
道理是相通的类似问题在C端产品中也会碰到。
如果你留意的话你会发现很多电商网站、汽车导购产品的产品经理已经摸到了深层需求。
比如汽车网站里面基本都有一个“车型对比”功能不仅能将不同车型的各项配置、参数用表格逐项列出来而且还提供了“高亮不同配置、隐藏相同配置”等贴心功能。这就是深层次地满足了用户的需求。
因此对于一个需求多问几个为什么多问自己“这是用户的真实目的吗他用这个功能到底想干什么”等。只有这样才有可能触及到用户深层次的需求才有可能做出让用户感到很贴心的功能。
对于深入满足用户需求除了做浅层、深层的分析之外还可以采用“分而治之”的思路将产品从模块和功能上分层即分出“N级火箭”每一级“火箭”用来满足不同类型的用户需求或者同一用户在不同阶段的需求。
举个例子尽管我们的图谱、NLP、CV、搜索、机器人、标注等几个平台产品的功能各不相同但我们还是找到了共性即抽象出了需求分级和业务赋能的“五级火箭”包括“功能嵌入、API调用、数据训练、模型定制、算法开发”等五级。业务方可以根据具体情况来选择不同的接入方式。
第一级功能嵌入通过iframe等实现成本最低的手段将平台的某个功能模块嵌入到自己的系统当中。第二级API调用直接调用平台提供的成熟API比如调用身份证、驾驶证之类的OCR识别的API。第三级数据训练平台的模型符合需求但需要提供自己的训练数据或者字典数据等来解决具体场景需求。第四级模型定制平台的现场模型不太符合要求所以要对算法参数进行配置然后训练出符合自己需求的新模型。第五级算法开发最高级的情况就是业务方懂算法、要开发新算法。平台则提供“算法开发、数据管理、模型训练、模型测试和发布”等一系列深层次的能力来提升算法研发的效率。
上述“五级火箭”由浅入深地满足了不同类型用户以及同一个用户不同阶段的需求。 记得多年前我参加了一个管理方面的高级培训班。培训有好几天内容很多不过几乎所有的培训内容我都忘记了——除了一位老师无意中介绍的一个“万能四步法”。 所谓四步法就是“分类-排序-找规律-应用”这四个步骤。无论在学习新的领域知识、接手新的工作还是来到新的环境时都可以尝试这个万能四步法相信再复杂的问题都能迎刃而解。 用户分层、五级火箭就是“分类-排序”的一个应用。 谈完“需求/用户分层、五级火箭”了那是否就是对用户需求360度、无死角地满足了呢
答案是否定的因为我们还没有做到“无我境界” 。
所谓“无我”的境界就是满足用户需求的时候不能只考虑“我是谁、我有什么”而要忘掉自己去看用户需要什么什么东西对用户最有用。
比如虽然你是做AI技术平台产品经理但你眼里不能只有AI、算法、模型——要做到“无我”就是要做到如果有一种非算法、非AI的产品策略若能切实帮到业务那也应该去做。
在业务同学的眼里有没有算法没关系是不是高科技不重要——而有没有业务效果才关键。正所谓不管白猫黑猫抓到老鼠才是好猫。
比如我们的智能文案平台能够智能生成千人千面的营销文案。过去一直在迭代产品、提升算法能力力图生成更加智能、精准和个性化的文案。
然而大家知道算法的提升不可能一蹴而就算法效果都是慢慢地打磨和优化的。
在这个过程中产品经理同学不能干等。
于是我们就在思考不管多么高深的算法、多么智能的平台我们生产的仍然是文案。而文案这个岗位随着广告行业的发展已经存在了数百年那么一定有成熟的方法论和模式。
作为互联网从业者我们崇尚创新和颠覆但我们还必须对行业保留敬畏之心。
于是我们的产品经理同学就去把一些市场营销、广告文案经典书籍研读了一番总结出了所谓“18种优质文案句式/模板”这里面既有文案从业者的经验总结也有广告学、心理学等领域的科学原理。
将这些“优质句式”、“文案法则”产品化之后配合算法和技术就能给业务输出更有效果的文案。
我们相信机器不能完全代替人机器智能和行业知识、专家经验等人类智慧一定会相得益彰、交相辉映。
二 、平台设计平台产品也必须“秒懂”
讲完需求再来说说设计。
在互联网行业面向C端用户的产品不仅供给充裕、极大丰富而且普遍都免费获取成本基本为0。
没有付出就不会“珍惜”。
所以对用户来说产品必须容易上手即必须“秒懂”。如果用户几分钟甚至几十秒看不懂、不会用那他基本就放弃了产品就没有机会了。
对于中台、平台产品来说其实也是这样的只不过用户遇到不爽的体验只能忍忍因为使用你的产品来解决他的业务需求这是他的本质工作。
但是这并不意味着产品随便搞搞就行因为他还可以有别的选择。你要知道公司内部往往也有类似的产品更不用谈外部的、免费开源或者收费的解决方案了。
所以你在平台设计上也要下功夫必须能快速抓住用户让用户迅速上手、接入、上线帮助业务拿到业务结果。
如何才能做到“秒懂”呢可以从“产品框架、术语体系、帮助指引、产品demo、统一交互”等几个方面来考虑。
1、 有清晰明了的产品框架
用户一打开平台的页面就应该清晰地感知到平台能做什么产品框架是什么样的包含什么功能模块模块之间的关系包含、先后等第一步做什么、第二步做什么等等。
这一点看起来没什么深奥的但常见的问题是产品经理在产品设计前期对框架的思考不够充分。经常是到了PRD、视觉评审阶段才发现模块设计不合理、流程不清晰等等。这时再返工、改动成本就大了。
更为糟糕的是频繁的返工和变更会让产品经理个人的专业性和权威性丧失殆尽。以后还怎么向技术提需求、磨资源
为了避免这样悲惨的事情发生产品经理要在台下多下功夫。
一个好的习惯是先在脑中重建再动笔绘制。很多产品经理习惯一上来就画demo这是不对的——大脑的认知和计算资源是有限的顾“此”就会失“彼”当你陷入种种细节后就不可能从根本上、框架上思考问题了。
那怎么办呢可以用充分使用脑图这种工具。具体来说你先不要考虑任何demo图而是先把整个平台产品层级结构全部理出来包括各级导航和模块、每个模块包含的页面及核心功能板块。画好脑图之后站在用户的角度反复梳理和模拟直到横向、纵向的逻辑和流程都没有问题了再动手做具体的demo、PRD。
2、 有顾名思义的术语体系
产品的整体框架梳理清楚之后还要重视“术语/概念体系”即产品中的核心概念命名以及概念之间逻辑关系的设计。
这个之所以重要那是因为概念和术语体系是每一个领域知识沉淀的结果也是人们学习新事物、进行沟通交流的介质。
概念复杂产品必然复杂概念简单产品才能简单。
比如同样是人机交互的指令和方式微信的“摇一摇”就能让用户“顾名思义”并立马有体感地照做而我们支付宝的“咻一咻”就比较难理解和付诸行动了。
又如当年乔布斯发布iPod的时候并没有直接抽象地说“存储空间高达4.8G”而是说“把1000首歌装进口袋”。
可见产品中的新概念命名不合理或者将晦涩难懂的底层术语直接暴露出来都会对用户造成很大的困扰。
再比如在A/B实验平台中最初的概念体系自顶而下分别是“业务域-业务线-产品-实验”。
我们发现用户很难分清“业务域”与“业务线”的区别里面的“产品”也不是大家所理解的“支付、借呗、花呗、余额宝”这样的产品所以存在很多困扰。
后来我们借助大家熟知的“物理实验室、化学实验室”这些事物将概念体系改造成这样达尔文是一个“实验平台”里面可以创建“xxxx实验室”“yyyy实验室”在每一个实验室当中可以做各种各样的“实验”。这样就好理解多了。
除此之外我们还对实验室中的角色命名进行了修改。
之前实验权限管理里面有“管理员”、“成员”这两种常见的角色设置我们同样参照现实生活中实验室工作人员的岗位名称将其改成了“实验室主任”和“研究员”。
有趣的是“研究员”在阿里体系有“高P/组织部”的层级含义这样小小的一个文案的修改也包含着平台设计者的“人文关怀”——对那些用A/B实验来践行数据驱动创新的、追求科学严谨做事方式的同学们给予一点点温情和荣耀。
而且日后的运营活动也好做了比如可以评比“十大研究员、十佳实验室”等等。
总之在设计产品的术语体系首先是“如无必要勿增实体”其次要尽量借助大家脑海中已有的概念而不是直接照搬技术实现或者生造新的概念。
3 、有恰到好处的帮助指引
即使你在概念设计上下了功夫也不能保证用户不会产生任何疑问。
因此就需要设计“帮助体系”做进一步的解释和阐述。
这里并不是说让你写一份冗长的产品文档。文档应该写但它不是重点因为大部分人并不会仔细把产品文档读完才动手操作——他只有遇到问题才有可能去查查手册。
这里说的“帮助体系”指的是产品化的帮助体系即 “文档产品化”。具体来说就是把帮助文档中的要点尽量嵌入到产品页面当中让产品实现“自解释”而不是放到产品体外、仅仅存到帮助文档中。
“文档产品化”具体的措施包括如下几个方面
页面上有辅助说明
常见的情况是我们的页面太干净、太空了舍不得放一句解释的话当用户遇到问题就不知所措了。所以可以在标题下面做小字解释、在概念上面出tip气泡提示。对于复杂的情况在帮助文字后面还可以加上“了解更多”链接——直接跳转到帮助文档的相应地方而不是要用户从头查找。
新功能上线有提示和告知
平台不断做迭代改进但经常发现用户并不知道上了新功能。所以可以对此做适度的提示和告知大迭代可以蒙层弹窗、小的改动可以出小红点等等。
4、 有简单直观的全流程demo
只看教学视频学不会游泳光学“科目一”是学不会开车的。
天花乱坠说半天不如动手玩一遍。
现状是很多技术平台完全没有demo和体验能力。那么用户就很难上手。
因此平台一定要搭建一套“全流程、有体感、简便易行”的demo让用户亲手体验一下。
全流程指的是你的demo要涵盖平台的全部环节和步骤。有体感指的是要有直观的结果而不是只显示抽象的数值、json代码输出之类。简便易行指的是要足够简单、几分钟就能完成因此你需要内置几组demo的语料、图谱、数据集等等。
举个例子在NLP平台和金融视觉平台当中用户可以很便捷地在线体验金融NER/文本分类、身份证/银行卡OCR的效果。
也可以全流程地完成“项目创建、数据上传、数据打标、模型训练、模型测试”等环节。
值得指出的是对于平台的demo一定要越简单越好千万不要高估了人的耐心。
记得在金融视觉平台第一版全流程demo上线后当项目组成员在具体体验时才发现还是很繁琐甚至要放弃。
要完成demo你仍然需要写一堆表单比如项目名称/简介、模型名称/简介、数据集名称/简介而且还要自己准备训练数据不得不去网上搜索、下载几十/上百张图片……
后来我们就对此做了大幅度的简化能点鼠标的就不要让用户输字比如自动填充各种名称和简介。此外平台还内置一些测试数据集供用户使用等等。
经过一番简化之后用户才能在几分钟之内完成全流程、非常有体感的demo了。
5 、有标准/统一的交互体验
在做好每一个平台的设计之外还需要考虑不同平台的体验一致性即平台的统一。
做好这件事情既能让用户降低学习成本、在不同平台之间平滑切换也能减少UED、产品经理、技术同学们的重复劳动。
首先可以将平台通用的框架和模块抽象出来、统一起来包括Portal页、项目管理、权限管理、数据管理、任务管理、发布管理等等。
其次将细节的体验也统一一下具体到组件的设计、命名、颜色、位置等等。
当我们沉淀出一套经典的产品框架和交互标准那产品迭代速度和用户体验都会大幅提升。
三 、产品验证用不“深”就做不好
1、 要深度验证而不是蜻蜓点水
产品经理要真正做好一个产品必须要自己多用。
这个道理很简单但这里要谈的是使用的“深度”——随便点点、看看跟深度使用的差别是很大的。
举个例子如果让你设计导航产品中的路口转弯提示语你可能觉得设计成类似“前方500米路口右转”这样就没问题了。
你看既包含距离又说清了方向感觉已经很完美了吧。然而当你深入使用产品时、当你自己驾车的时候才会发现情况并非如此——你很难精确地把握是否到了500米处很可能在300米处的一个路口就错误地提前右转了。
所以现在的导航提示不仅会说“前方500米第N个路口右转”并且会在不该右转的路口提示“正在经过第N-1个路口”只有做到这样精细才能保证用户不会走错路。
对于我们的标注平台来说深度使用体现在做数据标注的次数——标注几次与几十、几百次你的感知是完全不同的。
标注页面中的一些设计的细节问题在你做一两次标注的时候感觉不明显当你做上几十次、上百次之后再小的问题也都会暴露出来、被放大了。
比如有一种图像分类任务你只需要标注“对”还是“错”。
之前的设计是每页展示一张大图答完题后就切换到下一页。当我们自己亲自标注了几十张之后就感觉这样的效率很低。
于是我们就改成了一页展示一二十张图片标注人员只需要扫一眼把其中“对”或者“错”的勾选出来然后整体提交就好了同时也减少了每一页刷新页面、加载图片的等待时间。这样简单的一个改动其实并没有什么技术难度但标注效率直接提升了好多倍。
2 、自己“做业务”结果大不同
真正要把一个平台做好不仅要像上面说的自己多当“标注员”更应该做做 “业务方”。支持业务、赋能业务跟自己做业务还是有很大差别的。
下面用我们做的垃圾智能分类的项目“分类宝”这个案例来说明下。
在2019年7月份全国很多城市开始推行垃圾分类。
我们的同学基于沉淀的图像、NLP和图谱等AI技术能力迅速开发出了智能垃圾分类的技术和产品项目命名为“分类宝”。用户可以通过“拍照片、语音搜索”等便捷的交互方式在支付宝小程序以及智能垃圾回收箱IoT设备上来体验AI垃圾分类了。
这个项目并不是各个业务BU给我们提需求而开始做的。这一次我们有了双重身份我们自己既是平台方也第一次做了“业务方”。
做起业务方之后我们才发现垃圾分类这个事情看似简单实际上却包含很多复杂的环节从“训练数据的获取、物品类目的整理、垃圾分类标准的维护、线上回流数据的订正”到“物品类目权重和优先级的调整、标注结果的确认”再到与内部各个部门的协同、与外包ISV的对接、节假日与特殊物品的应对等等。
经过一番手忙脚乱的折腾总算是把项目磕磕绊绊地做了起来。
在这个过程中我们遇到了很多之前不知道的问题其中既有平台设计不合理的产品问题也有训练时间过长之类的技术问题。
更重要的是让我们看到了不同流程、不同系统以及不同团队之间衔接的“真空地带”——这正是大公司由于分工、边界带来的常说的“三不管、踢皮球”的问题。而这些衔接上的问题正是隐蔽的、极大影响效率的问题需要被发现通过产品和流程等机制进行解决。
“自己做业务”的这一次实践让我们平台同学换了一个视角深刻体会到了业务同学的不易也直接推动了平台的迭代改进以及团队配合、流程设置的完善。
四、 平台协同连接产生价值
前面讲了很多但大部分还是聚焦在某一个平台的个体上。
孤立存在的平台就可能会降级成一个工具其价值和能量就变得非常有限。
因此要做好、做大平台需要跳出平台本身以连接、全局、生态的思维来看。
如果让不同平台产生协同和连接会产生“112”的效果。如果把封闭在平台内的“控制流、数据流”延伸出去变成闭环就会迸发出很多创新。
下面介绍几个方法和案例。
交叉链接带曝光带流量
这是最简单的一种平台协同的方法。每一个平台不仅要完成自己的使命还应该考虑为兄弟平台做点什么比如带带曝光、带带流量什么的。所以我们在每个平台产品的导航栏都增加一个“AI产品矩阵”的菜单把七八个产品的logo、名称、链接都列了上去。数据表明这个小小的菜单每天都能为其他平台带来可观的曝光和转化做这个菜单的ROI非常高。
平台能力复用杜绝浪费
平台在不断迭代升级的过程中对于一个新需求不要一上来就自己做而要先看看其他平台有没有可以复用的现成的能力哪怕是“曲线救国”或者“权宜之计”。
比如知识图谱平台的知识更新和智能文案平台的文案发布都需要走打标和确认流程我们发现标注平台的标注能力就够用了。所以我们就没有重新开发而是在平台之间打通连接快速解决了这个问题。
反哺和闭环实现共同发展
如果一个平台只是单向的输出能力而没有从下游获得反哺没有形成闭环那也不是个完善的系统和平台。
举个例子我们的标注平台已经累计对上亿条数据进行了打标这些标注数据使得各类模型的训练变成了可能。正所谓没有人工就没有智能。
在这个过程中标注平台只是输出价值、为智能化助力自己并没有从智能化中获益。
后来我们就考虑把这个链条形成闭环即让打标数据训练出的模型反哺回标注平台从而实现“智能辅助标注”。
这样将整个平台从“纯人工标注”转变为了“智能辅助标注”大大提升了标注效率、降低了标注成本。
沉淀数据资产创造更大的价值
如果一个平台有数据的沉淀那么这些数据就需要深度挖掘从而产生更多、更大的价值。
比如每个业务最开始接入知识图谱平台为了解决自己的业务问题就得从头建Schema、导数据。但随着平台的发展沉淀的知识越来越丰富。那么后续的平台就能直接受益于之前沉淀的知识而不一定要自己重新建设了。这就是平台数据沉淀出的价值。
再比如标注平台里的标注数据在完成模型训练之后生命周期就终结了躺在那里没有人管了这是很可惜的。
现在我们计划将这些数据沉淀下来、开放出去让数据产生更大的价值。
首先标注数据对内开放。在业务刚接入AI平台存在一个冷启动的阶段最缺的是打标的数据。所以可以将标注平台中海量标注数据梳理和开放出来让业务可以先到平台里面搜索下看看有没有已有的数据有的话就可以复用。如果没有再考虑重新建数据。
其次标注数据对外开放。我们可以把一些不涉及隐私、不牵扯我们核心技术能力的部分数据开放出去为社会创造更大的价值。
比如在智能垃圾分类“分类宝”项目中沉淀了数十万打标的垃圾图像数据。在我们开放了相关模型API之外再把其中一部分数据开放出去就会对整个社会的垃圾智能化处理贡献蚂蚁的一份力量。
接入开放平台实现强强联合
这里再说说开放的具体做法。如果自己直接对外开放做起来就比较麻烦有很多对接和维护的事情。应该考虑将自己的能力接入到现成的、大的平台比如支付宝小程序平台/开放平台、阿里云平台等等。借助这些大的平台很多获客、对接、运维的事情就有兜底了。
这里再分享一个考虑平台协同创新的思路那就是“图解法和穷举法”。
一开始平台协同创新都是散点发生的想到一个就做一个很不系统和体系化。 后来为了把所有“连接”和“协同”的可能性都穷尽我们就画了一张系统协同大图和矩阵图把所有的平台都放进去全方位地思考平台之间有什么没有打通的有什么协同创新的可能性。 这个方法大家在做其他工作时也可以参考。
五 、平台中的人性对抗
大家常说有人的地方就有江湖。一个平台也是一个江湖。
不同角色、诉求的人参与其中人性就展示出来了。
因此就需要思考人的事情就需要对平台进行运营和治理。
1 、平台的误用
首先要纠正平台上出现的不正确的用法。
为什么会存在这种情况呢
原因在于尽管产品经理在产品设计的时候本身就会尽力杜绝大部分错误的发生在平台的玩法中也有相应的规则告知到用户但大家并不会像你想象的那样“守规矩”他们会有意无意地“妙用”、“错用”甚至“滥用”。
比如在我去年负责A/B实验平台的时候我们曾经对平台中所有实验进行深入分析结果就发现了很多惊人的现象。
数百个实验只有一个版本正常来说需要两个或者更多的版本来进行对照实验但很多实验竟然只有一个版本其中一个很大的“妙用”或者“误用”是用户仅仅把平台当作灰度平台来使用了。数百个实验内流量为0有的用户并没有使用平台的分流能力而是自己做分流这也是我们没有料想到的。数百个实验运行时间小于3天或者大于30天正常来讲实验需要运行一周左右。但很多同学将实验运行一两天一看到数据有变化就把实验推全或者下线了这其实是不科学的。有的实验运行了好几十天原因竟然是有人忘记处理了可能实验场景都不存在了。……
可见大家对A/B实验的了解还是很不够的导致在平台上出现了各种“奇特”的用法。那么需要在平台培训和产品设计等方面做更多的工作。
除了A/B实验这样的平台在我们的金融知识图谱等平台上也发现很多问题。
我们知道在知识图谱的Schema规范当中同样一种实体只能有一种类型。
比如对于“公司”这个金融领域最常见的实体类型来说全局定义一个名为“Company”之类的类型就可以了。不同的业务域可以有不同的业务场景但类型应该共享一个。
然而现实情况是业务同学为了简单、好把控往往都想自己创建一个类型。于是在平台上就出现了类似Company1、Company2这样重复的类型。
在图谱平台上除了Schema重复数据也存在重复、不一致的情况这些都需要一个一个进行治理。
然而平台治理这件事既是科学也是艺术——既不能放任自由也不能卡的太严。尤其是在平台建设的初期如果限制得太死业务方是很难理解和配合的甚至会丢掉客户。
所以要把握好力度。
2 、“滥用”与“违规”
上面提到的这些平台治理的问题其实还不算太糟糕。
接下来给大家介绍一些需要高度重视和严肃处理的“滥用、违规”的行为。
分别是标注平台中的两个真实案例“任务释放”和“串通磨洋工”。
先说第一个“任务释放”功能的滥用。
考虑到外包标注人员变更比较多所以产品经理在标注页面上设计了一个“任务释放”的按钮用于防止任务卡在一个人手中。
然而后来标注小组长们反馈“希望取消这个按钮”说这个按钮被不少标注人员用来“挑活”当遇到难度较大的标注题目他们就点击“任务释放”给跳过了。
于是我们就把这个功能从一线的标注人员那里收回只给小组长开放了这个问题也是去外包公司实地调研时发现的之前团队同学们都没有料想到。
第二个是违规行为说的是人员串通起来“磨洋工”。
有一段时间算法同学反馈标注速度下降了。我们分析了下报表发现个别小组的多个标注人员的标注速度都降低了包括之前做的比较快的人员。
经过调查发现原来是有个别害群之马不光自己偷懒还教唆、串通其他人一起降低标注速度来集体“磨洋工”。
当然“串通磨洋工”这个问题最根本的原因在这些标注人员的绩效管理方案上——之前采用的是月薪制而非计件制有绩效奖金但微乎其微。
最近我们在专项建立任务难度分级标准并在完善外包人员的整体管理方案。
3 、“太智能”了也不行
最后再说一个非常有趣的事情。
我们知道如果一个产品不够贴心不够聪明和智能那用户肯定不喜欢但反过来如果“太智能”了那有时候也不行。
人是不安的、焦虑的如果让他感到“太过于神奇、不知道里面发生了很么”他就不敢用。
举个例子在模型服务平台的产品当中有同学设计了“模型一键部署”功能即把离线模型部署到在线过程中的复杂、繁琐的特征处理等工作自动化了。
然而当大家花几个月开发出来后却发现根本找不到一个业务方因为大家都说不敢用。最后这个“智能”的一键部署功能只能无奈地下线了。
要说明的是并不是说“简化模型部署”这个产品方向有问题而是上述“黑盒的、让用户心里没有底”的方案需要多斟酌要多站在用户的角度来思考
六、 跨界、跨界、跨界
所谓跨界就是突破原有行业惯例和常规通过嫁接其他行业的理念和技术从而实现创新和突破的行为。
世界著名投资家、沃伦·巴菲特的黄金搭档查理芒格是一个极具智慧的人他非常推崇跨界的思考方式他指出
你必须以跨学科的方式思考。你必须经常使用所有可以从各个学科的大一课程中学到的概念。如果能够熟练地掌握这些基本概念你解决问题的方法将不会受到限制。
要做好技术平台的设计、运营和推广工作你也需要跨界的思维和打法——比如你可以把营销思维与产品、技术跨界地结合起来。
所谓营销思维简单来说包含“认知规律、品牌体系、素材载体、传播路径”等几个关键点首先要服从人们对新事物的认识规律简单、直观搭建起一套品牌识别和记忆的体系logo、命名不断策划出有创意的活动和素材并在合适的地方进行曝光和传播。
那么对于技术平台的运营和推广也可以跨界地使用上述营销领域的理论和方法。
具体来说可以从以下几个方面着手
平台产品需要品牌
我们对所有的平台的品牌识别体系进行了梳理参照“阿里动物园”的惯例分别命名为知蛛金融知识图谱平台、鲸语NLP平台、图鹰金融视觉平台、千鲟搜索平台、灵犀机器人平台每种动物的选择都尽量体现了该平台产品的特点毕加索智能文案平台、AlphaQ智能标注平台的名称已经有一定认知度就未做修改。
除了名称之外我们给力的UED同学们还设计出了非常有区隔度、记忆度异常精美的logo。有了名称和logo交流、传播和推广的时候就好办多了。
产品体系需要品牌
不光要给予每一个平台以记忆度和识别度还要考虑多个平台作为一个整体如何记忆和传播。同样是考虑到阿里的武侠文化我们就包装出了“AI中台天龙八部”的整体品牌概念来传播八大AI技术平台产品。后来发现这个“天龙八部”的在内部的影响力很高很多人都用“天龙八部”来整体指代AI技术平台家族。
运营活动需要品牌
做运营、做推广也需要有一个品牌的体系。所以我们构造出了一个“AI特派员”的形象。对于我们对内发布的所有文章、视频和海报都纳入到这个体系当中。比如所有的内网文章标题、文章的首尾都统一格式加入“AI特派员”的名称和形象这样既方便形成统一认知也方便大家日后检索信息。
此外在运营活动和物料的设计中也有品牌营销思维技术和平台再高深传播的时候也必须考虑互动、创意和趣味。
为此我们定制了印有平台名称和slogan的有趣的可乐瓶为标注产品体验的同学颁发“聘书”等等。
由此可见将营销与技术、产品跨界融合站在用户角度进行产品品牌体系和运营活动、素材的设计就会收到较好的效果。
七、 平台产品经理的挑战和成长
读到这里你可能觉得做平台挺有趣、挺容易。
其实不然大家都难。
对于技术平台的产品经理来说会面临“心、脑、体”全方位的挑战。
在专业技能方面除了要有产品经理岗位必须的“需求管理、产品设计、项目推动”等能力之外还需要“懂技术”。要懂研发流程要懂各种算法、模型的术语和原理因为你不仅要与平台的开发团队对话你还要跟平台的用户进行对话——这些用户大部分也是技术同学。
这并不是要求你比技术同学更懂技术、代替技术同学去做技术的事情而是要求你要理解技术点的本质要知道这个技术能做什么、不能做什么这项技术与其他技术的区别是什么这个技术大的发展脉络是什么。
当你下功夫搞清楚了这些问题之后才不至于处于太过被动的局面。
但是“缺乏主动权、成就感不强”还是困扰着技术平台的产品经理同学。
要解决这个问题可以从如下几个方面来考虑。
深入了解业务需求提升业务sense
平台最终是为业务服务的平台再牛逼对业务没有帮助也是不能立足的。因此当你对业务需求有十足的把握就能有理有据地规划平台建设的方向就有成就感。
考虑自己能为团队带来什么独特价值
一个项目的成功、一个平台的成功除了专业能力之外还需要有足够沟通、协调、推动、BD、销售的能力。毫不夸张地说要做好产品产品经理不只是产品经理更要有产品的“小CEO”的角色。当你通过自己的多方努力把一件事情做成自己就会很开心也会赢得团队的认可。
任何一件事情都有创新和提升的空间
对于标注平台你可以沿着“人工标注”的老路子去做也可以朝着“智能辅助标注”的方向去创新。对于智能文案平台你可以只依赖算法提升的路径也可以主动创新把领域知识和行业经验产品化来实现产品经理驱动。对于用户反馈的获取和产品的迭代进化你可以使用“当面交谈、问卷调查”的传统方式也可以尝试“分析用户日志使用大数据AI”的新手段。要相信只要以终为始从业务出发从用户出发就能找到产品创新的机会。
时刻敬畏产品、敬畏用户认真做每一件事
我们曾经用这样一句话来鼓励自己团队的同学我们要用做几亿DAU产品的心态来打磨几百、几千DAU的技术平台。认真的人不会吃亏你今天的每一个付出都会产生价值都会提高自己。人生没有白走的路每一个“需求”都算数。
八 、结语
总算到结尾了在这里再对文章的内容做一个小结
需求管理“角色错位”与“无我境界”
越基本、越简单的问题却越难回答也越容易被有意、无意地忽略。做产品第一步就是要回答这些基本问题搞清用户是谁搞清楚用户的真实需求是什么。要深度满足用户需求要多问为什么了解用户真实的目的。还要忘掉自己多从用户角度去思考。
产品设计平台产品也必须“秒懂”
如果一个产品一眼看过去都乱七八糟的搞不清楚怎么回事那基本上就很失败了。因此要从“产品框架、概念体系、帮助体系、demo体验、交互统一”等多个方面着手来实现“秒懂”。
产品验证用不“深”就做不好
想做好产品就要做好产品验证产品经理要想方设法去高频、深度地使用自己的产品。有机会的话还要自己“做点小业务”你才会惊叹“啊原来还有这么多问题”。在这个过程中你自己还会有很多意想不到的收获。
平台协同连接产生价值
单个平台的价值和能量是有限的当你突破平台的界限创造更多的连接和闭环你就会打造出一个欣欣向荣的系统和生态。
平台中的人性对抗
有人的地方就有人性。对于多种角色参与的平台来说要做运营、引导和治理这样才能让整个平台平稳、健康发展。
跨界、跨界、跨界
面对复杂多变的环境需要多元化的人才、互补的技能需要不同行业和领域进行跨界融合。跨界会产生化学反应跨界会产生创新。
平台产品经理的挑战和成长
成年人的字典里没有容易二字。有问题有困难平台、团队和个体才能提升和发展。产品经理岗位是个复合体不是单个技能就能立足产品经理同学需要不断迎接挑战不断修炼自己。
相信平台的力量相信产品的力量。
我们刚刚起步我们继续前行。
作者蚂蚁集团资深产品专家栢柠先后负责蚂蚁AI平台、风控平台产品工作。
本文为阿里云原创内容未经允许不得转载
